We changed the server to respond Access-Control-Allow-Origin: * so the demo urls will no longer work (sorry prod bug, couldn't hold)

Since I had to change the demo URL's: The specific case is where the same page (same origin domain) is loaded using different protocols (http / https) - it looks like vary origin on the font request is only using the domain part not the protocol part of the origin t ovary but checking the whole thing in the allow-origin response.

It would be very helpful to have a test page where this can be reproduced, or a chrome://net-internals log when this occurs.

+toyoshim FYI

CC: tyoshino who knows CORS well
CC: ksakamoto who discussed similar CORS related topics at a different crbug, IIRC.

Repro case test page https://storage.googleapis.com/relay-scratch-storage/Chromium663240/ch663250-test.html

BTW this looks suspiciously like https://bugs.chromium.org/p/chromium/issues/detail?id=453306

Sounds like this is not a regression, but we just fixed an existing problem, then Chrome start working correctly.

https://tools.ietf.org/html/rfc6454#section-5

Origin is a combination of scheme, host, and port. So, http://X and https://X is not the same origin.

Since the original server response says
> Access-Control-Allow-Origin: https://www.example.com
requests from http://www.example.com should be rejected.

Sorry, I didn't understand the problem correctly.
Sakamoto-san confirms some curious behaviors around this report.
Let me reopen this again.

Here's chrome://net-internals log for the CORS-rejected font request:

--------
1744: URL_REQUEST
https://cdn.relaymedia.com/i/PdEckWxgKZgHZB3wah5u3w/?url=https%3A%2F%2Fstorage.googleapis.com%2Frelay-media-assets%2Ffonts%2Ffontawesome-webfont.woff&nwo=1&_=123
Start Time: 2016-11-28 12:38:19.915

t=3737 [st=0] +REQUEST_ALIVE  [dt=7]
t=3737 [st=0]    URL_REQUEST_DELEGATE  [dt=0]
t=3737 [st=0]   +URL_REQUEST_START_JOB  [dt=5]
                 --> load_flags = 34624 (DO_NOT_SAVE_COOKIES | DO_NOT_SEND_AUTH_DATA | DO_NOT_SEND_COOKIES | MAYBE_USER_GESTURE | VERIFY_EV_CERT)
                 --> method = "GET"
                 --> priority = "HIGHEST"
                 --> url = "https://cdn.relaymedia.com/i/PdEckWxgKZgHZB3wah5u3w/?url=https%3A%2F%2Fstorage.googleapis.com%2Frelay-media-assets%2Ffonts%2Ffontawesome-webfont.woff&nwo=1&_=123"
t=3737 [st=0]      URL_REQUEST_DELEGATE  [dt=0]
t=3737 [st=0]      HTTP_CACHE_GET_BACKEND  [dt=0]
t=3737 [st=0]      HTTP_CACHE_OPEN_ENTRY  [dt=1]
t=3738 [st=1]      HTTP_CACHE_ADD_TO_ENTRY  [dt=0]
t=3738 [st=1]      HTTP_CACHE_READ_INFO  [dt=0]
t=3738 [st=1]     +HTTP_STREAM_REQUEST  [dt=2]
t=3738 [st=1]        HTTP_STREAM_REQUEST_STARTED_JOB
                     --> source_dependency = 1747 (HTTP_STREAM_JOB)
t=3740 [st=3]        HTTP_STREAM_REQUEST_BOUND_TO_JOB
                     --> source_dependency = 1747 (HTTP_STREAM_JOB)
t=3740 [st=3]     -HTTP_STREAM_REQUEST
t=3740 [st=3]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=0]
t=3740 [st=3]        HTTP_TRANSACTION_SEND_REQUEST_HEADERS
                     --> GET /i/PdEckWxgKZgHZB3wah5u3w/?url=https%3A%2F%2Fstorage.googleapis.com%2Frelay-media-assets%2Ffonts%2Ffontawesome-webfont.woff&nwo=1&_=123 HTTP/1.1
                         Host: cdn.relaymedia.com
                         Connection: keep-alive
                         User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.3 Safari/537.36
                         Origin: http://storage.googleapis.com
                         Accept: */*
                         Referer: http://storage.googleapis.com/relay-scratch-storage/Chromium663240/ch663250-test.html
                         Accept-Encoding: gzip, deflate, sdch, br
                         Accept-Language: en-US,en;q=0.8
                         If-None-Match: "f84ffa8dd9706d3cf7c8e800372c0cc0"
t=3740 [st=3]     -HTTP_TRANSACTION_SEND_REQUEST
t=3740 [st=3]     +HTTP_TRANSACTION_READ_HEADERS  [dt=2]
t=3740 [st=3]        HTTP_STREAM_PARSER_READ_HEADERS  [dt=2]
t=3742 [st=5]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                     --> HTTP/1.1 304 Not Modified
                         Date: Mon, 28 Nov 2016 03:38:19 GMT
                         Via: 1.1 varnish
                         Cache-Control: public, max-age=31449600
                         ETag: "f84ffa8dd9706d3cf7c8e800372c0cc0"
                         Expires: Sun, 26 Nov 2017 16:13:47 GMT
                         Age: 41073
                         Connection: keep-alive
                         X-Served-By: cache-nrt6124-NRT
                         X-Cache: HIT
                         X-Cache-Hits: 3
                         X-Timer: S1480304299.919908,VS0,VE0
                         Vary: Fastly-Orig-Host, Host, Origin
t=3742 [st=5]     -HTTP_TRANSACTION_READ_HEADERS
t=3742 [st=5]      HTTP_CACHE_WRITE_INFO  [dt=0]
t=3742 [st=5]      URL_REQUEST_DELEGATE  [dt=0]
t=3742 [st=5]   -URL_REQUEST_START_JOB
t=3742 [st=5]    URL_REQUEST_DELEGATE  [dt=0]
t=3742 [st=5]    HTTP_CACHE_READ_DATA  [dt=1]
t=3743 [st=6]    URL_REQUEST_JOB_FILTERED_BYTES_READ
                 --> byte_count = 32768
t=3743 [st=6]   +HTTP_CACHE_READ_DATA  [dt=1]
t=3743 [st=6]      CANCELLED
t=3744 [st=7] -REQUEST_ALIVE
--------

Chrome sends the request with If-None-Match header and the server responds 304, without Access-Control-Allow-Origin header. I think this is working as intended; the server should put the Access-Control headers to the 304 response.

See also https://bugs.chromium.org/p/chromium/issues/detail?id=453306#c6.

ksakamoto's proposal would work but I'm not sure what the best thing to do for this.

Taking into account CORS header info when creating Etag or splitting Etag space into one for HTTP and one for HTTPS might make more sense but I'm not familiar with it enough for suggesting that.

Why is chrome sending the if-none-match header for a different origin? If etags are origin specific in chrome's eyes then if the original request was a CORS request it's origin specific so sending if-none-match to another origin is a problem? 

I'm not sure if it's legitimate that Chrome sends if-none-match.

jkarlin, could you help further triage this?

This seems related to https://bz.apache.org/bugzilla/show_bug.cgi?id=51223 where discussion is ongoing about whether the server should include the access-control header in 304s. According to that issue, both FireFox and Chrome will block these requests.

I believe the cache is working as intended in this case. Closing as WontFix. Please reopen if https://bz.apache.org/bugzilla/show_bug.cgi?id=51223 resolves to something other than adding the headers to the 304 response.

UGH this is really hard to fix server side one you get a CDN in the loop.  We generate an etag on the hash of the content (as most people do). Then we serve it, via our CDN (Fastly) with a Vary: origin.  They correctly store two version with both with the same etag. I suppose I could fold the origin into the etag calculation however that feels like a kludge that will bite me later.

Then along comes chrome and requests the https version - it works.  Then later it requests the http version.  And for reasons that are beyond me, and despite the Vary: origin header, it sends the etag from a the https version it has in cache in an if-none-match.  Why? Surly at that point chrome only has one cached version that is not a match due to the vary header. 

Why is it taking the etag from an object that is not a match due to Vary: origin and asking if it is a match?  That's the root issue here and I fail to see how that's not a bug.  More to the point the issue happens in chrome early, before it even talks to the server for the second request it's picked an invalid version from it's cache to match against.
 

On further testing it's not just http/vs https - it's any origin.  if I load the page from http://locahost:8000 chrome sends the etag it got when it requested from the cloud hosted page.  Vary: Origin doesn't work for CORS request in chrome.  That's a bug.

The spec says:

If the selecting request header fields for the cached entry do not match the selecting request header fields of the new request, then the cache MUST NOT use a cached entry to satisfy the request unless it first relays the new request to the origin server in a conditional request and the server responds with 304 (Not Modified), including an entity tag or Content-Location that indicates the entity to be used.

https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.6