Same problem, similar solution
I was trying to determine why Google Chrome will not send If-None-Match headers when visiting the site I'm developing. (Chrome 46.0.2490.71 m, although I'm not sure how relevant the version is.)
This is a different, albeit very similar, answer than the ultimately quoted FP (in the commentary on the accepted answer), but it solves the same problem:
The browser does not send the If-None-Match header in subsequent requests "when it should" (i.e. ETag Server-side logic, through PHP or similar, was used to send ETag or Last-Modified in the first response),
Background
Using a self-signed TLS certificate, which in Chrome renders the lock red, changes the behavior of Chrome's caching. Before trying to fix this kind of problem, install the self-signed certificate in the effective trusted root store and completely restart the browser, as described at https://stackoverflow.com/a/4125/ .
1st Epiphany: if-None-Match requires an ETag from the server, first
I quickly realized that Chrome (and possibly most or all other browsers) would not send an If-None-Match header until the server sent an ETag header in response to a previous request. Logically, that makes sense; after all, how can Chrome send an If-None-Match when it is never assigned a value?
This made me look at my server-side logic - in particular, how headers are sent when I want the user agent to cache the response - to determine why the ETag header ETag not sent in response to Chrome. The first request for a resource. I did my best to incorporate the ETag header into the logic of my application.
I use PHP, so the @Mehran (OP) comment popped up on me (it says calling header_remove() before sending the necessary headers related to the cache solves the problem).
Frankly, I was skeptical of this decision because a) I was pretty sure that PHP would not send any native headers by default (and this is not so, given my configuration); and b) when I called var_dump(headers_list()); shortly before setting my custom caching headers in PHP, the only set of headers was the one I specifically set just above:
header('Content-type: application/javascript; charset=utf-8');
So, I have nothing to lose, I tried calling header_remove(); before posting my custom headers. And, to my great surprise, PHP suddenly started sending the ETag header!
2nd Epiphany: compressed response changes its hash
Then it hit me like a bag of bricks: specifying the Content-type header in PHP, I told NGINX (the web server I use) a GZIP response as soon as PHP returned it back to NGINX! To make it clear, the Content-type that I pointed out was on the list of NGINX types for gzip.
For simplicity, my NGINX GZIP settings are as follows, and PHP is connected to NGINX via php-fpm:
gzip on; gzip_min_length 1; gzip_proxied expired no-cache no-store private auth; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript image/svg+xml; gzip_vary on;
I wondered why NGINX could remove the ETag that I sent to PHP when the "gzippable content type" was specified, and came up with the obvious answer at the moment: because NGINX modifies the response body that PHP passes back when NGINX compresses it! It makes sense; it makes no sense to send an ETag if it does not match the answer used to generate it. It's pretty nice that NGINX is so smart at handling this scenario.
I don’t know if NGINX was always smart enough not to compress the bodies of the responses, which were uncompressed but contained ETag headers, but this seems to be what happens here.
UPDATE : I found a comment that explains the behavior of NGINX in this regard , which in turn leads to two valuable discussions on this subject:
- NGINX forum thread discussing behavior .
- Tangentially related discussion in the project repository ; see comment
Posted on Jun 15, 2013 by Massive Bird .
In the interest of preserving this valuable explanation, if it disappears, I quote Massive Bird contribution to the discussion:
Nginx removes Etag when it receives a response on the fly. This is in accordance with the specification, since a response without gzipped is not a byte-sized response, comparable to a gzipped response.
Nevertheless, the behavior of NGINX in this regard can be considered slightly erroneous in that
... also says that there is a thing called weak Etags (Etag value with the prefix W /), and tells us that it can be used to check if the answer is semantically equivalent. In this case, Nginx should not bind to this. Unfortunately, this check did not get into the source tree (unfortunately, the quote is now filled with spam). "
I'm not sure about NGINX's current position in this regard, and in particular whether it added support for the "weak" Etags.
So what is the solution?
So what is the solution to return ETag back in response? Run gzipping in PHP so that NGINX sees that the response is already compressed, and simply passes it, leaving the ETag header unchanged:
ob_start('ob_gzhandler');
As soon as I added this call before sending the headers and body of the response, PHP started sending the ETag value with each response. Yes!
Other lessons learned
Here are some interesting points gleaned from my research. This information is very useful when trying to test the implementation of caching on the server side, whether in PHP or another language.
Chrome and its "Net" developer toolbar behave differently depending on how the request is triggered .
If the request is "re-made", for example, by pressing Ctrl+F5 , Chrome sends the following headers:
Cache-Control: no-cache Pragma: no-cache
and the server responds 200 OK .
If the request is made only with F5 , Chrome sends these headers:
Pragma: no-cache
and the server responds with 304 Not Modified .
And finally, if the request is made by clicking on the link to the page that you are already viewing, or by placing focus in the Chrome address bar and pressing Enter, Chrome sends the following headers:
Cache-Control: no-cache Pragma: no-cache
and the server responds with 200 OK (from cache) .
Although this behavior is a little confusing at first, but if you do not know how it works, this is an ideal behavior because it allows you to very carefully test every possible request / response scenario.
Perhaps the most confusing thing is that Chrome automatically inserts the Cache-Control: no-cache and Pragma: no-cache headers into the outgoing request when Chrome actually receives responses from its cache (as evidenced by the 200 OK (from cache) response).
This experience was quite informative for me, and I hope that others will find this value analysis in the future.