You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For using URLPattern as an input of the static routing API, it makes sense to have a limit to the route size, as the router evaluation is on the critical path, and it can create resource considerations. whatwg/urlpattern#182 will include some common constraints in the future, so the static routing API should follow that.
This is more specific in the static routing API, we may have to consider the limit to the number of match rules that can be registered. Currently the API allows multiple rules but the maximum size is not defined. This would bring similar considerations to browsers.
This should be considered eventually in the ServiceWorker spec level, that will be ideal if we have the mention in w3c/ServiceWorker#1686.
The text was updated successfully, but these errors were encountered:
Since the memory size and storage size are limited, it might be generally good to have a limitation. When we decide the limitation, I suggest to decide lower limit instead of upper limit so that browser venders can set the size upon their situation.
By the way, do we have any concerns on the route size? Can registering tons of routes cause DoS to pages out of SW scope? ...Maybe indirect attack by consuming resources?
Derived from whatwg/urlpattern#18.
For using URLPattern as an input of the static routing API, it makes sense to have a limit to the route size, as the router evaluation is on the critical path, and it can create resource considerations. whatwg/urlpattern#182 will include some common constraints in the future, so the static routing API should follow that.
This is more specific in the static routing API, we may have to consider the limit to the number of match rules that can be registered. Currently the API allows multiple rules but the maximum size is not defined. This would bring similar considerations to browsers.
This should be considered eventually in the ServiceWorker spec level, that will be ideal if we have the mention in w3c/ServiceWorker#1686.
The text was updated successfully, but these errors were encountered: