New issue
Advanced search Search tips

Issue 731157 link

Starred by 2 users

Issue metadata

Status: Assigned
Merged: issue 730697
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

XHR HEAD requests do not honor cache

Reported by miki...@gmail.com, Jun 8 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36

Steps to reproduce the problem:
1. Open test page served from local server (e.g. not open file directly)
2. Open dev tools network tab
3. Make sure "Disable cache" is not checked (e.g. cache is functional)
4. Refresh the page multiple times to make XHR request* multiple times

* XHR request makes HEAD request to https://httpbin.org/cache which in turn returns response with "Last-Modified" header.

In case test file does not work XHR request is very simple:

var xhr = new XMLHttpRequest();
xhr.open("HEAD", 'https://httpbin.org/cache', true);
xhr.send();

What is the expected behavior?
After first fetch of the resource, subsequent requests should be sending "If-Modified-Since" header in which case server can return 304 Not Modified response.

In other browsers (tested in Firefox and Safari) it works as expected and non-first requests indeed return 304 responses.

What went wrong?
Chrome does not send "If-Modified-Since" header hence server is always returning 200 OK response.

Note that Chrome honors cache for GET requests. This behavior seems only to be present for HEAD requests.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 59.0.3071.86  Channel: stable
OS Version: OS X 10.10.5
Flash Version: 

https://httpbin.org/cache does not seem to return Cache-Control header so in my local server I also was returning "Cache-Control: private, must-revalidate, max-age=3600" header which did not affect XHR HEAD requests caching in any way.
 
cache-test.html
279 bytes View Download

Comment 1 by miki...@gmail.com, Jun 8 2017

BTW HEAD requests are eligible to be cached. See https://tools.ietf.org/html/rfc7232#page-16
Cc: pbomm...@chromium.org jkarlin@chromium.org
Components: Internals>Network>Cache
Labels: pre-stable-59.0.3071.86 M-59
Mergedinto: 730697
Status: Duplicate (was: Unconfirmed)
Status: Untriaged (was: Duplicate)
Oops, looks like this is a different issue.
Chrome will use existing entries in the cache to resolve a HEAD request, but won't store a HEAD request if an entry doesn't already exist for the URL.

The reason for this appears to be due to complexity of implementation, according to https://bugs.chromium.org/p/chromium/issues/detail?id=350407. 
jkarlin@, is this is issue still relevant, can you help retriage?
Owner: morlovich@chromium.org
Status: Assigned (was: Untriaged)
I doubt we're going to do anything with this, but I'll send it over to Maks in case he's interested. Otherwise, please close it.

Sign in to add a comment