[Webkit-unassigned] [Bug 233559] New: Cache issue with crossorigin, 'vary: *' Responses

[bugzilla-daemon at webkit.org]

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

            Bug ID: 233559
           Summary: Cache issue with crossorigin, 'vary: *' Responses
           Product: WebKit
           Version: Safari 15
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Service Workers
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: lion.ralfs+webkitbugzilla at gmail.com

When attempting to add requests to the cache via the CacheStorage API (https://developer.mozilla.org/en-US/docs/Web/API/CacheStorage), 
any request that results in a response with the response header 'vary: *' causes the operation to fail with an error:

"TypeError: Response has a '*' Vary header value"

I'm assuming that this is the expected behavior.

However, when adding a _crossorigin_ request with a 'vary: *' header, no error is thrown.

Instead, Safari adds the cache entry without replacing previous entries with the same URL. This becomes evident by repeatedly reloading a page that attempts to add a crossorigin, 'vary: *' request to the cache.
If one reads the cache after a few page-reloads (via `cache.matchAll` for example), the same response is returned multiple times.

I've isolated a test case in this repository: https://github.com/lionralfs/caches-vary-crossorigin-behavior

1. Run `npm install`
2. Run `npm start`
3. Visit localhost:8000 in Safari
4. Reload the page a few times
5. Click the button to read the cache which displays the cache entries
6. Take a look at the index.html for details

To be honest, I'm not entirely sure what the expected behavior is for crossorigin + 'vary: *' responses and I've file a Chrome bug as well (since they have a similar issue): https://bugs.chromium.org/p/chromium/issues/detail?id=1274098

-- 
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/20211129/4052f46d/attachment.htm>