[Webkit-unassigned] [Bug 245346] New: Cross-Origin-Embedder-Policy incorrectly blocks scripts on cache hit

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=245346

            Bug ID: 245346
           Summary: Cross-Origin-Embedder-Policy incorrectly blocks
                    scripts on cache hit
           Product: WebKit
           Version: Safari 15
          Hardware: Other
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: New Bugs
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: obi1kenobi82 at gmail.com

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220918/d0fffd57/attachment.htm>