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

> What I'd like to do is that if we're certain that e.g. Accept is always set based on a request context, we specify that logic as part of Fetch. That way it is clear when Accept is set, whether service workers can observe it, and what kind of values it can have. (That would mean that <img> no longer needs to talk about Accept but can depend on the request context.)

That makes sense. What's the best way to tackle this? Go through each context and compile a set of context-specific headers and values into a table, or some such? Would it make sense to draft some fetch-spec boilerplate that we can fill in as we go? Might help clarify what we need, etc.

> In the case of fetch(url, {as: "image"}) we'd need to restrict the Response so that it can only be used by <img> and background-image (otherwise CSP is broken). At this point, that would only make such an API useful in service workers (and even that is a bit of a stretch as service workers have their own CSP policy), but perhaps in the future <img> et al can be fed a Response directly.

Not sure I follow the "useful in SW only" - how so? For `<img>` case, I'm picture: fetch() the data, then `img.src = window.URL.createObjectURL(responseBlob)`... not sure what the right/required security plumbing to make that work though.



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