comment 8 on the stackoverflow issue indicates that some links to the resources had crossorigin="anonymous" while others didn't. Removing this everywhere fixed the issue.

Not sure whether this is WAI, a CORS issue, or a Cache issue

Hey,

we had been dealing with a bug that seemingly matches the behaviour described here.

We received bug reports from a customer who is seeing issues when a request is first made from our back-office and then from the customer website. In a scenario where that cross-domain XHR response (with respective Cache-control headers) is cached, trying to request the same URL from a different domain will obtain the resource from the cache and subsequently trigger a CORS error.

Here is a practical example:

- Open this article: https://magazines.styla.com/v2/bijoubrigitte/story/mit-lilithmoon-in-paris
- Click the product image over the label "Kette - Modern Heart" (necklace with a red heart)
- An overlay will be opened with an overview of that product
- Reloading the page and clicking the product again will work fine, the overlay successfully loads.
- Open the URL that is being called through XHR directly in its own tab: https://productapi.styla.com/api/bijoubrigitte/product/DEBB352080610?withImages=1 - do a hard reload in that tab
- Reload the article and click the product again, now the request will fail.

-----------------

I have attached two files: page1.txt and page2.txt.

> page1.txt is the CORS XHR request & response from the external website when requesting the API endpoint
> page2.txt is the request & response when directly calling the API endpoint

Note that in the moment the article is reloaded and the browser tries to request the API endpoint from the external website again, it will fail. We assume this is related to the browser using the cache entry from when the resource was cached without CORS headers.

Deleted: page1.txt 1.2 KB

page1.txt 1.2 KB View Download

Deleted: page2.txt 1.0 KB

page2.txt 1.0 KB View Download

I haven't read all threads yet, but maybe dup of 741958?

Through 741958 I became aware of 809891 which is discussing disparring Amazon response behaviour due to a lack of Vary: Origin. Reviewing the response headers as attached to my previous comment, a Vary: Origin header is not included.

I understand and follow the reasoning underlying the strictness of Chrome, or pedantry, but I am seeing issues with the lack of documentation about this specific behaviour. Mostly, because the HTTP layer prioritisation in the caching process seems non-trivial.

I was thinking about how this could be used to fingerprint user devices. In our tests, the "failing" requests were obtained from the cache in 4ms to 17ms; priming the cache with respective CORS headers on the third-party domain - making the requests fail quickly when requested from the other domain - could allow for enough entropy to fingerprint a user device.