Figure out if request header mutation is possible

[annevk]

There's a number of things that would be nice to mutate in a request as it passes through a service worker, but a particular one that comes up often and might be the easiest is adding a header.

Adding headers seems fine when request mode is "same-origin" or "cors", but harder when it is "navigate" or "no-cors" (see also #380).

For "navigate" and "no-cors" we could maybe tag an additional flag to the added headers (making the map a little more complicated, which I guess we could do after we fix some other issues with headers) and drop the added headers upon encountering a (cross-origin?) redirect.

[RReverser]

What exactly would be the point of such flag on the request? Meaning, why not just allow to add headers or any potentially same-origin request (incl. no-cors and navigate), and just drop them when it goes to another origin?

[annevk]

Well, you can set certain headers today even for no-cors (e.g., Accept). So the flag would mostly be about preserving those, while removing the others. If we drop all headers, while simpler, we'd also end up regressing on functionality we offer today.

[RReverser]

@annevk Yes, I meant removing only non-whitelisted headers (whitelist is already part of the spec) on cross-origin redirect. This will preserve backward compatibility and will still try to send as much changed headers as allowed for that specific context.

[annevk]

That could maybe work. A problem with that approach could be that we also have certain non-safelisted headers added by other standards at the API layer. I'm not entirely sure whether that is the case however. There are headers that other standards add that violate CORS, such as DNT, Upgrade-Insecure-Requests, etc., but maybe all use a hook at the network layer in which case it would be less of an issue.

@mikewest do you know?