-
Notifications
You must be signed in to change notification settings - Fork 315
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
Service-Worker-Allowed header #604
Comments
We should also specify what happens if the HTTP response contains multiple values for "Service-Worker-Allowed". If I understand correctly, there is no ABNF for "Service-Worker-Allowed" defined so the parse step https://fetch.spec.whatwg.org/#concept-header-parse won't fail. I think Chromium will just take the first value. |
Yes, for all the Update/Soft Update cases (ServiceWorkerContainer.register(), ServiceWorkerRegistration.update(), 24h update, navigation matching), the given registration's scope (NOT the script URL) is re-evaluated against the new max scope.
I think so as the site is trying to give it a new restriction upon those updates.
I double-checked and couldn't find misuse of those. Probably, the use of similar names, |
Cool. Do you mean the current spec says this, or you plan to add it? AFAIK it's not yet in the spec. Currently if the path restriction fails you only delete the registration if there is no installed worker.
It should be "Let xxx be" and "Set xxx to". Sometime there is "Let xxx to" and "Set xxx be". Minor quibble but reading spec language is hard enough as it is :) |
You're right! I added a step which invokes Unregister algorithm when there's been a worker in the registration: 1613f9f.
Fixed. Thanks! |
Hmm.. I have second thoughts about this, what if you do: register("resources/sw.js", { scope: '/' }); // OK, ServiceWorker-Allowed = "/"
register("resources/some_other_sw.js", { scope: '/' }); // no ServiceWorker-Allowed header It would mean the registration is uninstalled, that doesn't look right. I guess the uninstallation should only happen for same-script URL update? |
I agree. Service-Worker-Allowed says, "I would allow this script to be running even in the designated scope". Will fix this. |
|
Thanks Jungkee. I thought about this a little more last night.
|
Also, |
Maybe 3-4 above are OK. If you can't even parse the Service-Worker-Allowed header, it's is probably a network error. I was confused between URL parsing and HTTP header parsing. Which brings me to the next question, can URL parsing fail? For the step "Let maxScope be the result of parsing serviceWorkerAllowed with client's API base URL.", is it possible for maxScope to be failure? |
Agreed. Let's keep it more consistent to other cases (i.e. not unregister.) Yes, it's a SecurityError so we stop updating it right here but the one already installed had had a permission to do so then. If authors wanted to unregister this, they should explicitly do so.
Good catch. If we parse it against the client's base URL, the value would change based on the document locations in which the methods are invoked. Will fix this.
It's aligned to Fetch spec. A header parsing failure leads to a network error there. |
[1][2][4]: 4c4fec3. |
As a perhaps-unrelated issue, I a conversation I had with @metromoxie makes me think we should also add a special |
To my understanding, That said, if it's something we wanted to kill the SW registration this script has been bound to, then I think it sort of makes sense we use this header for that. The expected behavior would be to invoke Clear Registration algorithm no matter whether some pages are currently being controlled. (or to invoke Unregister if we take more conservative approach.) But if it's something we wanted to kill all the registrations or something like that, then it seems we need another header (directive). |
I'd be happy with a different header to kill things, but something seems necessary. @jakearchibald @annevk: thoughts? |
I had the impression If we want a protocol solution to removing a service worker, using HTTP 410 seems much more applicable. Using |
Tracked in gecko here: |
Spinning off of #468. I have some comments about the spec change in ddb21be.
The text was updated successfully, but these errors were encountered: