Skip unnecessary checks when we have a preloaded response candidate in main fetch

[nidhijaju]

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!

• At least two implementers are interested (and none opposed):
  • Chrome
  • …
• Tests are written and can be reviewed and commented upon at:
  • Update test for dynamic CSP with new preload behavior web-platform-tests/wpt#50204
• Implementation bugs are filed:
  • Chromium: …
  • Gecko: …
  • WebKit: …
  • Deno (not for CORS changes): …

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[annevk]

Looking at this one concern I have is that we preload for X and fulfill for Y. Is that possible? Can I preload something pretending it's going to be used as an image but then have it execute as a script?

cc @noamr

[noamr]

Looking at this one concern I have is that we preload for X and fulfill for Y. Is that possible? Can I preload something pretending it's going to be used as an image but then have it execute as a script?

That's not possible. See https://html.spec.whatwg.org/multipage/links.html#consume-a-preloaded-resource
The key for the preload cache includes the destination (the as attribute). So effectively each as has its own map.

[annevk]

@nidhijaju did you create a test for dynamically changing the CSP in combination with preload?

[nidhijaju]

@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.

[noamr]

@nidhijaju wouldn't this circumvent CSP for early-hints? As in

• You preload a script in early-hint Link header
• The main response adds CSP to prevent external scripts
• The document can now run scripts from that URL

[nidhijaju]

@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.

[yoavweiss]

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.

[noamr]

@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.

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.