Bug 58797
| Summary: | Vary header and Conditional HTTP request error | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Paul Sadauskas <psadauskas> |
| Component: | WebKit Misc. | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | achristensen, aestes, ahmad.saleem792, ap, cdumez, fishd, jaffathecake, japhet, koivisto, mathias, m_finkel, m.goleb+bugzilla, mnot, psolanki, tonyg, webkit-bug-importer, youennf |
| Priority: | P2 | Keywords: | InRadar |
| Version: | 528+ (Nightly build) | ||
| Hardware: | Mac (Intel) | ||
| OS: | OS X 10.6 | ||
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
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
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