Bug 58797 - Vary header and Conditional HTTP request error
Summary: Vary header and Conditional HTTP request error
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac (Intel) OS X 10.6
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2011-04-18 10:55 PDT by Paul Sadauskas
Modified: 2024-01-25 16:03 PST (History)
16 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Sadauskas 2011-04-18 10:55:56 PDT
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
Comment 1 Alexey Proskuryakov 2011-04-18 14:43:57 PDT
Sounds like one of the many consequences of keying WebCore memory cache off URL alone.
Comment 2 Darin Fisher (:fishd, Google) 2011-04-19 10:41:30 PDT
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.
Comment 3 Jake Archibald 2014-03-04 08:58:36 PST
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".
Comment 5 David Kilzer (:ddkilzer) 2014-03-05 19:22:55 PST
<rdar://problem/16244607>
Comment 6 Michał Gołębiowski-Owczarek 2017-12-22 09:28:21 PST
Any updates after 3.5 years? This has just bit me in a project that works correctly everywhere (Chrome, Firefox, Edge) except in Safari.
Comment 7 Ahmad Saleem 2024-01-24 08:33:26 PST
(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