302 redirect causes cached resource to be fetched again
Reported by
trevorbu...@gmail.com,
Jul 25 2016
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 Example URL: http://trevorburnham.com/302-test/ Steps to reproduce the problem: 1. Fetch a resource, e.g. <link rel="stylesheet" href="//styles.css"> 2. Fetch a resource from a different URL that yields a 302 response pointing to the same URL as the fetched resource. What is the expected behavior? The 302 response should not trigger a duplicate request. What went wrong? The 302 response triggers a duplicate request. Did this work before? No Chrome version: 51.0.2704.103 Channel: stable OS Version: OS X 10.11.6 Flash Version: Shockwave Flash 22.0 r0 This seems to happen regardless of when the 302 occurs (before or after the resource is fetched). Additionally, it happens if you use <link rel="preload"> instead of <link rel="stylesheet">: The resource is preloaded, and the 302 causes it to be fetched again.
,
Jul 27 2016
That regression test doesn't work - the test URL has no cache headers, so we always try and revalidate it. Looking at the test site, I'm seeing the second response served from the cache. trevorburnham: How are you testing? You're not using F5 to reload the page, right? The forces us to revalidate the cache, currently, so if you reload that way, we won't use the cache for the response, since the server doesn't support revalidation.
,
Jul 27 2016
> Looking at the test site, I'm seeing the second response served from the cache. Hmm. You're right, I see the same when I visit the page with a clear cache. However: 1. If I force reload (Shift+Cmd+R), I see two requests for styles.css and two 200 responses, neither served from the browser cache. 2. If I reload (Cmd+R), I see two requests for styles.css and two 304 responses. 3. If I clear the browser cache and then reload (Cmd+R), I see two requests for styles.css with one 200 response and one 304 response. So, this issue is narrower than I'd thought. I incorrectly assumed that the hard refresh behavior reflected the clear cache behavior, when actually only the reload behavior is suboptimal. (And it looks like Firefox and Safari do no better.)
,
Jul 27 2016
So reload attaches magic headers to each request. Each renderer page has a per-request view of the world, and isn't smart enough to say "I already revalidated this resource for this page". This is probably a WontFix issue, as it would require either having a third per-page cache inside of the renderer, or replacing the per-renderer-process in-memory cache with a per-page one, which would reduce cache hit rate for normal loads, but I'll defer to the loading team on this one.
,
Jul 28 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 28 2017
|
||||
►
Sign in to add a comment |
||||
Comment 1 by b...@chromium.org
, Jul 26 2016Labels: -OS-Mac OS-All
Status: Available (was: Unconfirmed)