302 redirects are cached within a single page load
Reported by
charles....@gmail.com,
Jun 14 2017
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36 Steps to reproduce the problem: 1. Load a resource that executes a 302 redirect 2. Load the same resource on the same page, at a later time 3. The redirect is cached, and doesn't hit the original request URI Repro case viewable here http://chrome-302-broke.herokuapp.com/test.html It's on a free heroku dyno (in case you reach it while it's offline). What is the expected behavior? According to the HTTP spec, upon loading a resource that results in a 302 redirect: ...the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field. What went wrong? However, within a single page load, I'm seeing Chrome resolving subsequent requests to the initial Request-URI to the resolved value from the first request, even when the redirect specifies no caching. Safari and Edge both properly refer to the initial Request-URI every time. It seems like caching the redirect from the initial response, even within the same page load, is taking liberty with the description from the spec. A strict interpretation shouldn't cache this request at all. Especially with a growing number of web applications that don't navigate between pages for a considerable amount of time, and file hosts that redirect requests to temporary locations, this seems like it would cause problems for an increasing number of use cases. Did this work before? No Does this work in other browsers? Yes Chrome version: 59.0.3071.86 Channel: stable OS Version: OS X 10.12.5 Flash Version:
,
Jun 16 2017
Confirmed the behavior. Firefox shows the same behavior. I think https://html.spec.whatwg.org/multipage/images.html#the-list-of-available-images is the basis. What do you think?
,
Jun 19 2017
That behavior (4.8.4.3.3 The list of available images) seems reasonable. The issue I've had that caused me to look into this arose when a downloaded video was no longer available in the cache, and yet the redirect from the initial Request-URI is presumed to still be correct. For instance, I load a video from a CDN that performs a 302 redirect to a temporary location. Throughout further usage of my media heavy page, that video is no longer active, and too large to stay in the cache. At a later point, a user interaction requests the video again, and the file no longer exists at the previous temporary location. The file would still load appropriately from the initial Request-URI, but that's not what happens.
,
Jun 28 2017
> Comment #3 Hmm, the caching of 302 response seems to be done in the disk cache (not sure though), because Blink's MemoryCache doesn't cache in per-redirect-leg basis. The test case of Comment #0 is hitting MemoryCache and image-specific conditions of cache reusing (that corresponds to 4.8.4.3.3, that is not applicable to video), and thus I think it doesn't test the original issue described in #3. Adding more labels for the browser-side caching and media processing.
,
Jun 28 2017
,
Jun 29 2017
Sounds like this working as intended then - Blink caches the imgs differently. When cycling just the image src, the network stack is not getting asked for the resource (so removing Internals>Network>Cache). When the network stack is asked for the resource (either a top-level page navigation, or requesting through an iframe) the redirect is resolved as you expect. I attached a different repro - if you rotate the URL of an iframe instead of an img it reloads as you expect. Interestingly that also seems to change the behavior of cycling the img too.
,
Jul 4 2017
should not be OS specific though iOS is an exception...
,
Jul 11 2017
charles.skoda@, can you provide a reproducible test case of your problem (downloading video)?
,
Aug 17 2017
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by mmenke@chromium.org
, Jun 14 2017