Bug 245346 – Cross-Origin-Embedder-Policy incorrectly blocks scripts on cache hit

• Component: Page Loading
• Status: RESOLVED FIXED

[Predrag Gruevski]

Background:
I'm building a site that relies on web workers and SharedArrayBuffer functionality: https://play.predr.ag/

Accessing SharedArrayBuffer requires the top-level document to be served with security headers like "Cross-Origin-Embedder-Policy: require-corp". Any scripts loaded into web workers need to be served using "Cross-Origin-Resource-Policy: same-origin" headers.

The site serves all resources with "Cache-Control: public, max-age=0, must-revalidate" caching headers.

All this is currently implemented on the site.

Expected behavior:
All resources on https://play.predr.ag/ load correctly regardless of whether web worker scripts were newly-downloaded or hit the local cache. No violations of Cross-Origin-Embedder-Policy are shown in the browser console.

This is what currently happens on Chrome 105.0.5195.102 and Firefox 91.13.0esr.

Actual behavior:
On the first page load with an empty cache, all resources are loaded correctly and there are no errors related to Cross-Origin-Embedder-Policy shown in the console.

However, refreshing the page causes the web workers to not be started due to reported Cross-Origin-Embedder-Policy violations, presumably referring to a missing Cross-Origin-Resource-Policy header for the web worker's script file.

The following messages are shown in the console:
> Refused to load 'https://play.predr.ag/src_hackernews_fetcher_ts.js' worker because of Cross-Origin-Embedder-Policy.
> Worker load was blocked by Cross-Origin-Embedder-Policy.
> Cannot load https://play.predr.ag/src_hackernews_fetcher_ts.js due to access control checks.
> Failed to load resource: Worker load was blocked by Cross-Origin-Embedder-Policy

This is currently the behavior on Safari 15.5 (17613.2.7.1.8) on macOS Monterey 12.4 (M2), and on Safari 15.6.1 (15613.3.9.1.16, 15613) on macOS Catalina 10.15.7 (Intel).

To reproduce:
- Visit https://play.predr.ag/ once with a cleared cache. Note the absence of Cross-Origin-Embedder-Policy errors in the console.
- Refresh the page. Note that the console now shows multiple Cross-Origin-Embedder-Policy errors in the console and indicates the page's web workers were not started.

The site's source code is here:
https://github.com/obi1kenobi/trustfall/tree/main/experiments/browser_based_querying

(The site is currently also affected by bug https://bugs.webkit.org/show_bug.cgi?id=238442 which I have not been able to find a workaround for. When you open it in Safari, even when web workers are started correctly, it will say that it's disabled in Safari. This will not affect your ability to reproduce the bug -- just looking at the browser console is sufficient.)

Suspected cause:
On cache miss, the 200 OK response sent from my hosting provider (Netlify) includes the Cross-Origin-Resource-Policy header that the web worker scripts require, which is why everything works fine.

However, when Safari attempts to revalidate the resource and is successful, the 304 Not Modified response does not include a Cross-Origin-Resource-Policy header.

Per RFC 9110, section 15.4.5, 304 Not Modified should not carry headers that are not sent for the purpose of guiding cache updates. The Cross-Origin-Resource-Policy header's value has not changed since the last 200 OK, and there is no caching-related purpose for that header. Thus, I believe that header should not be sent on 304 responses, and Netlify's behavior is correct here.

But perhaps Safari expects that header to be present even on 304 responses, causing this bug?

Thanks for looking into this! Please let me know if I can be of any further assistance.

[Radar WebKit Bug Importer]

<rdar://problem/100389164>

[Chris Dumez]

Thanks for the detailed bug report. I'll investigate as soon as I have some spare cycles.

[Predrag Gruevski]

(In reply to Chris Dumez from comment #2)
> Thanks for the detailed bug report. I'll investigate as soon as I have some
> spare cycles.

Happy I could help. Thank you for taking a look, and for all the work you're doing.

Unless you think it's an easy fix, I may need to work around this and disable caching the web worker scripts. Otherwise my site is entirely unusable on iOS devices as well as desktop Safari, which means a lot of frustrated users.

Do you think you can reproduce this easily without the issue being "live" on https://play.predr.ag/ ? Or would that impede your work and I should try to keep it up as long as possible?

[Chris Dumez]

(In reply to Predrag Gruevski from comment #3)
> (In reply to Chris Dumez from comment #2)
> > Thanks for the detailed bug report. I'll investigate as soon as I have some
> > spare cycles.
> 
> Happy I could help. Thank you for taking a look, and for all the work you're
> doing.
> 
> Unless you think it's an easy fix, I may need to work around this and
> disable caching the web worker scripts. Otherwise my site is entirely
> unusable on iOS devices as well as desktop Safari, which means a lot of
> frustrated users.
> 
> Do you think you can reproduce this easily without the issue being "live" on
> https://play.predr.ag/ ? Or would that impede your work and I should try to
> keep it up as long as possible?

I think I have enough information that I should be able to investigate and fix.
Please work around the bug on your site for now.

[Predrag Gruevski]

Thanks, I appreciate it!

[Chris Dumez]

Pull request: https://github.com/WebKit/WebKit/pull/5140

[Chris Dumez]

Pull request: https://github.com/WebKit/WebKit/pull/5141

[EWS]

Committed 255302@main (126473bd1f9b): <https://commits.webkit.org/255302@main>

Reviewed commits have been landed. Closing PR #5141 and removing active labels.