Chromium not respecting the Expires response header.
Reported by
sandeshy...@gmail.com,
Jun 16 2018
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 Steps to reproduce the problem: 1. Send Expires:0 in response header for a resource like javascript file 2. Reload the page. 3. After reload, inspect the response header and http status code. 4. The http status code is 200(from memory cache) and not 304(not modified). This is causing problems because ideally the browser should validate the staleness of cache resources before reusing them but in this case chrome is not validating staleness from server. What is the expected behavior? Expected behavior is that browser should send an If-Modified-Since or If-None-Match for the ET Tag and Last-Modified-Time tag request to the server and in return it will receive a 304 (Not modified) which means the browser can then actually reuse the cached resource. What went wrong? I suspect chromium is not validating the cache staleness if its finding 0, -1 or a time zone specific time string in Expires response header. When I set a time string with GMT time zone, then it is successfully making a validation request for which it is receiving a status 304(not modified). I have attached screen shots showing how the browser is failing to validate for different values of Expires in response header Did this work before? N/A Chrome version: <Copy from: 'about:version'> Channel: n/a OS Version: 65.0.3325.181 Flash Version: Shockwave Flash 28.0 r0 I have gone through the RFCs and found out that all invalid date formats or values for Expires header should be counted as 'expired' and hence browser should revalidate with the server, which in case of chromium is not happening.. I've tried the same with firefox and everything is perfectly working.
,
Jun 18 2018
,
Jun 18 2018
Chrome doesn't re-validate all resources on reload - the same is true for other browsers as well. This is to save bandwidth when people reload due to a page not being fully loaded. This is expected behavior. Pressing shift+reload forces a re-validation, I believe.
,
Jun 19 2018
This case is not just for reload - it is behaving the same when I navigate through pages or enter in the url and access the page again. For firefox and IE it is working fine - I can consistently see a 304 (not modified) code, but from chrome it is showing 200 (from memory cache). I think this is part of the spec https://tools.ietf.org/html/rfc7234#section-5.3 and other browsers are following it. I am facing issues because even though content is changed on my js files and chrome does not go to check it.
,
Jun 21 2018
https://tools.ietf.org/html/rfc2616#section-14.21 > HTTP/1.1 clients and caches MUST treat other invalid date formats, > especially including the value "0", as in the past (i.e., "already > expired"). It seems MemoryCache does not comply this. https://chromium.googlesource.com/chromium/src/+/4ab6aa61e8a9a1ae40079099edc7057e44522444/third_party/blink/renderer/platform/loader/fetch/resource.cc#441 If |expires_value| is not a valid value, |last_modified_value| is used.
,
Jun 25 2018
@japhet is this the only library used by chrome for cache?
,
Jul 5
Any updates on this??? |
||||
►
Sign in to add a comment |
||||
Comment 1 by susan.boorgula@chromium.org
, Jun 17 2018