-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider maximum route size #5
Comments
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? |
w3c/ServiceWorker#1752 defines the max conditions, which works beyond each rule. That indirectly limits the number of rules. |
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: