58797 2011-04-18 10:55:56 -0700 Vary header and Conditional HTTP request error 2024-07-24 06:22:56 -0700 1 1 1 Unclassified WebKit WebKit Misc. 528+ (Nightly build) Mac (Intel) OS X 10.6 NEW InRadar P2 Normal --- 1 psadauskas webkit-unassigned achristensen aestes ahmad.saleem792 ap cdumez fishd jaffathecake japhet koivisto mathias m_finkel m.goleb+bugzilla mnot psolanki tonyg webkit-bug-importer youennf oldest_to_newest 387867 0 psadauskas 2011-04-18 10:55:56 -0700 What steps will reproduce the problem? 1. Have a resource that accepts multiple representations (json/html), includes `Accept` in the `Vary` response header, and handles conditional requests with `If-Modified-Since` 2. Have Safari visit the resource, first with a modified Accept header (json), then with its normal header. What is the expected result? A 200 OK response from the server for the second request. What happens instead? A 304 Not Modified response to the second request, because Safari includes both `If-Modified-Since` and `If-None-Match` in the request, even though the `Vary: Accept` response header indicates the altered Accept header should result in a different response. The end-user effect of this is that Safari downloads the json file on the second request, rather than rendering the html. Please provide any additional information below. tcpdump output of Chrome/Safari vs Firefox: https://gist.github.com/925714 Cross-posted to the chromium bug tracker: http://code.google.com/p/chromium/issues/detail?id=79758 388050 1 ap 2011-04-18 14:43:57 -0700 Sounds like one of the many consequences of keying WebCore memory cache off URL alone. 388586 2 fishd 2011-04-19 10:41:30 -0700 Chromium's network stack implements Vary header support by computing a hash of the request headers subset and storing that hash in the cache meta data. Before reusing a cache entry, the hash of the current set of request headers is computed and then that is compared against the stored value. You can see the code for this here: http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_vary_data.cc?view=markup It is important to note that if we are caching redirects (I don't think WebCore's cache does so), that we should always assume that a cached redirect has an implicit "Vary: Cookie" header for compat with the web. 986833 3 jaffathecake 2014-03-04 08:58:36 -0800 Seeing this issue at http://jakearchibald.com/2014/browser-cache-vary-broken/#changing-api-response-type-based-on-accept However, in this case the response has a max-age, so the wrong content comes straight from the cache. Although Safari fails when varying on "Accept", it seems to get it right when varying on "Accept-Language". 987230 4 jaffathecake 2014-03-05 06:05:49 -0800 Here's the bug, https://github.com/WebKit/webkit/blob/e025cae9b34b75b236b30a614fa43cd39337fe65/Source/WebCore/loader/cache/CachedRawResource.cpp#L206 - "m_headers.add("Accept");" shouldn't be there. (based on https://codereview.chromium.org/85623006) 987502 5 ddkilzer 2014-03-05 19:22:55 -0800 <rdar://problem/16244607> 1384483 6 m.goleb+bugzilla 2017-12-22 09:28:21 -0800 Any updates after 3.5 years? This has just bit me in a project that works correctly everywhere (Chrome, Firefox, Edge) except in Safari. 2007226 7 ahmad.saleem792 2024-01-24 08:33:26 -0800 (In reply to Jake Archibald from comment #4) > Here's the bug, > https://github.com/WebKit/webkit/blob/ > e025cae9b34b75b236b30a614fa43cd39337fe65/Source/WebCore/loader/cache/ > CachedRawResource.cpp#L206 - "m_headers.add("Accept");" shouldn't be there. > > (based on https://codereview.chromium.org/85623006) It seems to be now this in WebKit Source: https://searchfox.org/wubkat/rev/ec4f4923b19d0ed56921d6b5b0aadb69ada735eb/Source/WebCore/loader/cache/CachedRawResource.cpp#290