Bug 58797 – Vary header and Conditional HTTP request error

• Status: NEW
• Component: WebKit Misc.

[Paul Sadauskas]

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

[Alexey Proskuryakov]

Sounds like one of the many consequences of keying WebCore memory cache off URL alone.

[Darin Fisher (:fishd, Google)]

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.

[Jake Archibald]

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".

[Jake Archibald]

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)

[David Kilzer (:ddkilzer)]

<rdar://problem/16244607>

[Michał Gołębiowski-Owczarek]

Any updates after 3.5 years? This has just bit me in a project that works correctly everywhere (Chrome, Firefox, Edge) except in Safari.

[Ahmad Saleem]

(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