Re: [fetch] Initializing context/content specific fetch defaults (#43)

To be clear, `<img>` and `fetch()` already share logic. They both invoke [fetch](https://fetch.spec.whatwg.org/#concept-fetch). That algorithm takes care of HSTS, CSP, Mixed Content, Referrer Policy, Service Workers, etc. E.g. `fetch()` ends up as `connect-src` in CSP.

The problematic case with allowing `fetch()` to set the CSP policy to something other than `connect-src` is that you could then use `fetch()` to bypass CSP. The only way to prevent that would be to taint the response somehow. So that if you do `fetch(url, {context: "image"})` the `Response` object can only be used by `<img>` and `background-image` and such.

About initializing defaults. We could do this in fetch, but are engines actually setting these defaults based on an enum in the network layer or are they set in the DOM layer based on the environment? I can see how we could take over handling `Accept` in fetch, but client hints seems trickier?

(As for header management. The way it works is that feature-specific headers are set by those invoking fetch. So currently e.g. the specification for `<img>` would have to set `Accept` and any client hint headers. And fetch adds headers in the network layer for CORS, cookies, etc. and these are therefore not exposed to service workers.)

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/43#issuecomment-90828210