Skip unnecessary checks when we have a preloaded response candidate in main fetch #1803
Conversation
That's not possible. See https://html.spec.whatwg.org/multipage/links.html#consume-a-preloaded-resource |
|
@nidhijaju did you create a test for dynamically changing the CSP in combination with preload? |
I believe @noamr actually wrote a test for this case a couple years ago in wpt/preload/preload-dynamic-csp.html. We can probably update the test expectation at the end to be "load" instead of "error". I created a PR for that at web-platform-tests/wpt#50204. |
|
@nidhijaju wouldn't this circumvent CSP for early-hints? As in
|
|
@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. Open to thoughts here, the primary goal here is to enable more efficient use of preloaded content. |
Do you have data you can share about the improvement this would bring? Naively, I wouldn't have thought there's a lot of content out there where preloads get dropped due to CSP. |
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. |
…date This CL skips checks during fetch that cannot change between when a resource is preloaded and when that preload is consumed. In these cases, we only perform the checks once when the initial preload occurs. We also introduce a new feature flag to bypass CSP when we consume a preload. This is because we would have blocked the load when we initially preloaded the resource if we needed to do so. This causes a behavior difference when CSP is changed dynamically, but it is behind a feature flag so we can measure if it is worth changing the standard to align based on the impact. whatwg/fetch#1803 has some relevant spec discussion around this topic. Bug: 348442535 Change-Id: Ic49951b6588d3d4365b7c0c3b84919fffc5bfc35 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6332466 Commit-Queue: Nidhi Jaju <[email protected]> Reviewed-by: Takashi Toyoshima <[email protected]> Cr-Commit-Position: refs/heads/main@{#1440180}
This PR skips checks that are not needed when we have a preloaded response candidate in the main fetch algorithm. We talked about this offline at the last TPAC, but the main motivation behind this is to optimize reusing preloaded content where possible.
The main observable difference due to this change is that once a preload is made with a certain CSP policy, a subsequent request for the same resource will get the same response. This means that dynamically setting the CSP policy will not affect the ability to use preloaded content.
We could maybe argue the same for mixed content checks, but it seems better to respond to live changes in user preferences to block insecure content. Although, I'm open to thoughts and could see an argument either way.
This PR also skips all the irrelevant checks for clarity and ease of implementation, but another approach would be to only skip the observable checks in the spec.
@annevk @domenic Could you please take a look? Thank you!
(See WHATWG Working Mode: Changes for more details.)
Preview | Diff