-
Notifications
You must be signed in to change notification settings - Fork 330
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
Prevent modifying headers on Responses #24
Comments
That should throw a TypeError. |
@jpmedley (and also @jakearchibald) should |
The alternative is introducing a new guard ( |
Being able to add headers like this is kinda nice, but not essential. If we make them mutable, we should do the same with requests. self.addEventListener('fetch', function(event) {
event.request.headers.append('foo', 'bar');
}); Of course, that shouldn't work with 'no-cors' requests, probably other kinds of requests too. If editing headers on |
Yeah, I guess I prefer |
Is it too soon to revisit the decision on this? It is already possible to achieve cloned headers for non-opaque requests via long-winded hacks (constructing an init object and body from the response/request). For responses it's easier to do this in a non-performant way - wait for the body before creating a response - than it is to do so using streams. It'd be good to make modifying responses in a performant way easier. What are the reasons for not supporting mutability on same domain requests/responses? @annevk |
We could revisit it in a new issue. Stuff we need to be clear about if we allow things like that is what it would mean for caches and such. |
/me admits to thinking it'd be cool if SW would automatically add itself to the |
Ok, I'll create an issue, though others will have to fill in the details on caching etc. as nothing problematic occurs to me |
I'm not qualified to comment on if it is appropriate or not to do something like:
but from talking with @annevk on IRC, it seems this is not ok.
The text was updated successfully, but these errors were encountered: