Skip to content
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

Closed
nikhilm opened this issue Mar 13, 2015 · 9 comments
Closed

Prevent modifying headers on Responses #24

nikhilm opened this issue Mar 13, 2015 · 9 comments

Comments

@nikhilm
Copy link

nikhilm commented Mar 13, 2015

I'm not qualified to comment on if it is appropriate or not to do something like:

// serviceworker.js
onfetch = function(e) {
  e.respondWith(fetch(e.request).then(function(response) {
    response.headers.append("Reply-from-SW", "yes");
    return response;
  })
}

but from talking with @annevk on IRC, it seems this is not ok.

@jpmedley
Copy link

That should throw a TypeError.

@annevk
Copy link
Member

annevk commented Mar 14, 2015

@jpmedley (and also @jakearchibald) should fetch() return a response with an immutable Headers object?

@annevk
Copy link
Member

annevk commented Mar 16, 2015

The alternative is introducing a new guard (response-cors; for opaque we can reuse immutable). Using immutable everywhere for now seems simplest though. @KenjiBaheux thoughts?

@jakearchibald
Copy link
Collaborator

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 fetchEvent.requests & responses returned by fetch throws now, it's something we can open up later.

@annevk
Copy link
Member

annevk commented Mar 26, 2015

Yeah, I guess I prefer immutable for now then. Until someone comes up with a complete proposal.

@annevk annevk closed this as completed in b04be25 Mar 27, 2015
@wheresrhys
Copy link

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

@annevk
Copy link
Member

annevk commented Sep 6, 2016

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.

@mnot
Copy link
Member

mnot commented Sep 7, 2016

/me admits to thinking it'd be cool if SW would automatically add itself to the Via header.

@wheresrhys
Copy link

Ok, I'll create an issue, though others will have to fill in the details on caching etc. as nothing problematic occurs to me

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

6 participants