{"action":"created","issue":{"url":"https://api.github.com/repos/whatwg/fetch/issues/64","labels_url":"https://api.github.com/repos/whatwg/fetch/issues/64/labels{/name}","comments_url":"https://api.github.com/repos/whatwg/fetch/issues/64/comments","events_url":"https://api.github.com/repos/whatwg/fetch/issues/64/events","html_url":"https://github.com/whatwg/fetch/issues/64","id":87427971,"number":64,"title":"Mechanism to indicate \"destination context\"","user":{"login":"igrigorik","id":10652,"avatar_url":"https://avatars.githubusercontent.com/u/10652?v=3","gravatar_id":"","url":"https://api.github.com/users/igrigorik","html_url":"https://github.com/igrigorik","followers_url":"https://api.github.com/users/igrigorik/followers","following_url":"https://api.github.com/users/igrigorik/following{/other_user}","gists_url":"https://api.github.com/users/igrigorik/gists{/gist_id}","starred_url":"https://api.github.com/users/igrigorik/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/igrigorik/subscriptions","organizations_url":"https://api.github.com/users/igrigorik/orgs","repos_url":"https://api.github.com/users/igrigorik/repos","events_url":"https://api.github.com/users/igrigorik/events{/privacy}","received_events_url":"https://api.github.com/users/igrigorik/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":22,"created_at":"2015-06-11T17:48:05Z","updated_at":"2015-07-13T19:25:37Z","closed_at":null,"body":"This is a continuation of https://github.com/whatwg/fetch/issues/43: we've added language to set Accept, Accept-Language, and priority when request context _is not fetch_. However, this is not sufficient as we need to account for cases where request context _is fetch_. \r\n\r\nTo address this, I'm proposing that we add some notion of \"destination context\", which is an optional attribute that allows the developer to indicate how/by whom the response is intended to be consumed. This value does not affect or override \"context\" value (which remains as \"fetch\"), but it can be used in the [fetching algorithm](https://fetch.spec.whatwg.org/#fetching) to set the appropriate request headers and priority. Optionally, this allows the UA to also enforce how/where the response is consumed.\r\n\r\nWhy not just override context? Because that would allow fetch() to bypass connect-src, and we also lose the initiator context -- e.g. within ServiceWorker I'd like to distinguish between `<img>` initiated requests and prefetch initiated image requests.. both have same destination context, but may need different processing logic.\r\n\r\n---\r\n\r\n1. I want to make an image request (https://github.com/slightlyoff/ServiceWorker/issues/279):\r\n * `Request({url: '/whatever.png', destinationContext: \"image\"})`\r\n   * The request `context` is set to 'fetch': request is subject to connect-src.\r\n    * The request `destination-context` is set to 'image', which is used to initialize Accept, Accept-Language, and request priority.\r\n\r\n1. I want to prefetch an image asset:\r\n  * `<link rel=prefetch href=/other.png as=font>`\r\n    * The request `context` is set to 'preload'.\r\n    * The request `destination context` is set to 'font' (via `as`, or whatever we call it), which is used to initialize Accept, ..."},"comment":{"url":"https://api.github.com/repos/whatwg/fetch/issues/comments/121030431","html_url":"https://github.com/whatwg/fetch/issues/64#issuecomment-121030431","issue_url":"https://api.github.com/repos/whatwg/fetch/issues/64","id":121030431,"user":{"login":"igrigorik","id":10652,"avatar_url":"https://avatars.githubusercontent.com/u/10652?v=3","gravatar_id":"","url":"https://api.github.com/users/igrigorik","html_url":"https://github.com/igrigorik","followers_url":"https://api.github.com/users/igrigorik/followers","following_url":"https://api.github.com/users/igrigorik/following{/other_user}","gists_url":"https://api.github.com/users/igrigorik/gists{/gist_id}","starred_url":"https://api.github.com/users/igrigorik/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/igrigorik/subscriptions","organizations_url":"https://api.github.com/users/igrigorik/orgs","repos_url":"https://api.github.com/users/igrigorik/repos","events_url":"https://api.github.com/users/igrigorik/events{/privacy}","received_events_url":"https://api.github.com/users/igrigorik/received_events","type":"User","site_admin":false},"created_at":"2015-07-13T19:25:37Z","updated_at":"2015-07-13T19:25:37Z","body":"@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.\r\n\r\nAs 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}. \r\n\r\nYes, 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.\r\n\r\nFWIW, 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\"."}}