Re: [fetch] Mechanism to indicate "destination context" (#64)

@annevk the ability to set a custom Accept header (amongst others) does not and should not preclude a mechanism that allows the UA to set it automatically based on a shorthand hint. If we were to force developers to manually specify the Accept header on each fetch and resource declaration then that'd be both very painful and verbose. That said, I think we agree on all this already.

As I noted earlier, "context" has its pitfalls too. For example, the target context may be an `iframe` but I can load any content-type within an iframe; knowing that context is "navigation" does not tell me anything about content-type -- i.e. context is not sufficient to determine what Accept headers should be set. Also, an optimization proxy can observe what resource types are being fetched and inject those as preload/prefetch hints (with type attribute) without any knowledge of context in which they're used -- this is an important use case for pre{load,fetch}. 

Yes, content-type is a weaker prioritization signal. That said, it's still strictly better than today's complete absence of any prioritization information and something the UA (and developers, once we give them such control) can leverage as part of its prioritization algorithm.

FWIW, knowing what type of resource we're about to fetch is an important input both to the UA and developer-specified process algorithms. Source and destination contexts (where they're known and meaningful) should be available too, but context is not enough. As such, I think we still need and should pursue support for "type".

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