Vary:Origin not honored on 304 responses
Reported by
simon.ob...@gmail.com,
Aug 13
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0 Example URL: https://orfondevtest01.orf.at/cors-304.html Steps to reproduce the problem: 1. Load https://orfondevtest01.orf.at/cors-304.html 2. Observe that the CORS fetch requests succeeds 3. Load http://orfondevtest01.orf.at/cors-304.html 4. Fetch requests fails What is the expected behavior? Chrome should not reuse the cached CORS response if a 304 is returned but the Origin is now different. What went wrong? It seems chrome stores the response and re-uses it for 304 responses even though the origin is now different; all involved responses set the Vary:Origin Did this work before? No Chrome version: Version 68.0.3440.106 (Official Build) (64-bit) Channel: n/a OS Version: ubuntu bionic Flash Version:
,
Aug 13
It looks like we send a re-validation request, as required when there's a vary tag mismatch, and the server responds telling us to re-use the old response, without an updated origin header. Looks like it's the server that's misbehaving to me, though I'm not cache expert.
,
Aug 13
Looks OK to send a conditional request for me per: https://tools.ietf.org/html/rfc7234#section-4.3 Vary mismatch here is the "can't be selected" part.
,
Aug 14
Indeed chrome behaviour seems ok. I have amended the relevant issue at apache https://bz.apache.org/bugzilla/show_bug.cgi?id=51223
,
Aug 16
simon.oberhammer@ Thanks for the update. As per comment #4, can you please confirm if this issue can be closed? Thanks..
,
Aug 16
yes, close it
,
Aug 16
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 16
Done, thanks! |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by swarnasree.mukkala@chromium.org
, Aug 13