Re: [whatwg/fetch] Skip unnecessary checks when we have a preloaded response candidate in main fetch (PR #1803)

> @noamr You're right. Although I don't have strong opinions on how early-hints should work with regards to CSP, I think the same argument, that we are using for allowing preloads that were previously fetched to continue to work despite a CSP update, would apply here. Separating out early-hints would also be an option, but could also result in more complexity and differing behavior to regular preloads which may be confusing.
> 
> Practically, this would mean that if someone wants to apply a particular CSP policy to a hint, then that should have come with or before the 103 response itself.
> 
> This would update the behavior that was discussed in [httpwg/http-extensions#687](https://github.com/httpwg/http-extensions/issues/687).
> 
> Open to thoughts here, the primary goal here is to enable more efficient use of preloaded content.

Early hints and the main response can be provisioned by different parties, e.g. an optimization CDN middleware can provide the 103 response, and they might not even be aware (and shouldn't be aware) of the CSP.

CSP is often a protection against harm to the page, e.g. against running scripts from untrusted sources, not against network fetches. So by enabling this feature, a site that allows a party like a CDN to send a 103 gives them implicit trust to use any CSP they want... I don't think that's desirable.

We can special-case early hints by re-checking the preload map once the document is created for CSP violations, but I think it would be more complex than the existing model. The nice thing about the current model is that the CSP violation is always reported when trying to fetch the protected resource.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1803#issuecomment-2609182084
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1803/c2609182084@github.com>