Chrome doesn't send “If-Modified-Since”

Question

I want browsers to always add (except first time) \"If-Modified-Since\" request header to avoid unnecessary traffic.

Response headers are:

Accept-Ranges:         


        

Answer 1

1. Don't disable cache in Chrome Dev Tools (on "Network" tab).
2. Cache-Control should be Cache-Control: public. Use true as second parameter to header PHP function: header("Cache-Control: public", true);

Answer 2

I just now found this question, and after puzzling over Chrome's If_Modified_Since behavior, I've found the answer.

Chrome's decision to cache files is based on the Expires header that it receives. The Expires header has two main requirements:

1. It must be in Greenwich Mean Time (GMT), and
2. It must be formatted according to RFC 1123 (which is basically RFC 822 with a four-digit year).

The format is as follows:

Expires: Sat, 07 Sep 2013 05:21:03 GMT

For example, in PHP, the following outputs a properly formatted header.

$duration = time() + 3600 // Expires in one hour.
header("Expires: " . gmdate("D, d M Y H:i:s", $duration) . " GMT");

("GMT" is appended to the string instead of the "e" timezone flag because, when used with gmdate(), the flag will output "UTC," which RFC 1123 considers invalid. Also note that the PHP constants DateTime::RFC1123 and DATE_RFC1123 will not provide the proper formatting, since they output the difference to GMT in hours [i.e. +02:00] rather than "GMT".)

See the W3C's date/time format specifications for more info.

In short, Chrome will only recognize the header if it follows this exact format. This, combined with the Cache-Control header...

header("Cache-Control: private, must-revalidate, max-age=" . $duration);

...allowed me to implement proper cache control. Once Chrome recognized those headers, it began caching the pages I sent it (even with query strings!), and it also began sending the If_Modified_Since header. I compared it to a stored "last-modified" date, sent back HTTP/1.1 304 Not Modified, and everything worked perfectly.

Hope this helps anyone else who stumbles along!

Answer 3

I've noticed almost the same behaviour and my findings are:

• First of all the 200 status indicator in chrome is not the whole truth, you need to look at the "Size Content" column as well. If this says "(from cache)" the resource was take directly from cache without even asking if it was modified.

• This caching behaviour of resources that lack any indication of expires or max-age seems to apply when requesting static files that have a last-modified header. I've noted that chrome (ver. 22):

  1. Asks for the file the first time (obviously since it is not in cache).
  2. Asks if it is modified the second time (since it is in cache but has no indication of freshness).
  3. Uses it directly the third time and then on (even if it is a new browser session).

• I'm a bit puzzled by this behaviour but it is fairly reasonable, if it is static, was modified a long time ago, and hasn't changed since last check you could assume that it is going to be valid for a while longer (don't know how they calculate it though).

Answer 4

I had the same problem, in Chrome all requests were always status code 200, in other browsers 304.

It turned out I had the disable cache (while DevTools is open) checked in on Devtools - Settings - General page..:)

Answer 5

I've been chasing this issue for some time, thought I'd share what I found.

"The rule is actually quite simple: any error with the certificate means the page will not be cached."

https://code.google.com/p/chromium/issues/detail?id=110649

If you are using a self-signed certificate, even if you tell Chrome to add an exception for it so that the page loads, no resources from that page will be cached, and subsequent requests will not have an If-Modified-Since header.