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

> RE referrer: First, consider the mixed content case: Referrer should NEVER be sent for mixed-content subresources. But, with referrer control, we may opt into sending Referrer for HTTP->HTTPS navigations. More generally, pages should be able to control referrer separately for subresource and navigation loads; see https://briansmith.org/referrer-01 for what I'm shooting for.

Sure, but I don't think `type` prevents anything here. If you have a document-wide policy than pre* fetches would inherit the policy; if you want to control referer on per-request basis then we should expose something similar to CORS setting attribute (e.g. referer=policy).

> RE predicting type: I think we should be able to initialize appropriate request headers without predicting the type. For example, preload for foo.png where foo.png may be WebP or PNG depending on the user-agent. I guess your thinking is that you can say type=image/png and it will work out OK even if it is actually WebP, however that seems quite hacky. The important thing is the intended context, in this case `<img src>`, not the type of the response, but <link type> is about the type of the response.

Neither solution is perfect.. I could be prefetching an image that I want to navigate to or load within an iframe (e.g. `<iframe src=image.jpg>`); the context is not always sufficient to determine the type. I agree that specifying the full mime type is not ideal, but I do believe that it's a better overall fit.

> Re CSP: If people don't define CSP controls when they add new features then that effectively breaks CSP every time such a new feature is added. 

Sure, I'm 100% with you. My point is simply that prefetch and prerender are _already shipped_, and they went out without any formal specs.. hence the CSP gaps. The RH spec is, in effect, an attempt to rationalize what was shipped and smooth out the edge cases, which is the reason we're having this discussion. FWIW, we should fork this part of the discussion as a separate thread against CSP spec.

> I understand why it is tempting to overload type instead of defining a new attribute and new flags. But, it seems like whenever we do such overloading, we end up creating future problems for ourselves.

I disagree, I don't believe we're overloading the [meaning](http://www.w3.org/TR/html5/links.html#attr-hyperlink-type). It's an advisory hint, and we're using it as such to help initialize fetch settings.

Re, connect-src: I think this is orthogonal to this discussion, and I'll defer to @mikewest on details. That said, related issue: https://github.com/whatwg/fetch/issues/77.

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