Prevent modifying headers on Responses about fetch

[mnot]

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

[jpmedley]

That should throw a TypeError.

[annevk]

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

[annevk]

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]

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]

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

[wheresrhys]

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]

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.

[wheresrhys]

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