Why is Firefox not sending the If-Modified-Since header?

Question

According to Firebug, here are the response headers the first time the resource is retrieved:

Accept-Ranges   bytes
Cache-Control   public, max-age=86400
Content-Language    en
Content-Length  232
Content-Location    http://localhost/myapp/cacheTest.html
Content-Type    text/html; charset=WINDOWS-1252
Date    Wed, 05 Sep 2012 15:59:31 GMT
Last-Modified   Tue, 01 May 2012 05:00:00 GMT
Server  Restlet-Framework/2.0.3
Vary    Accept-Charset, Accept-Encoding, Accept-Language, Accept

I click away and click back, and here are are the request headers sent to the server:

Accept  text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding gzip, deflate
Accept-Language en-us,en;q=0.5
Connection  keep-alive
Host    localhost
Referer http://localhost/myapp/cacheTest2.html
User-Agent  Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20100101 Firefox/15.0

And so, naturally, the server can't send a 304 like I want, and instead sends the entire resource again.

This was happening in Firefox 14, and I thought it might be a bug, so I upgraded. But it is still happening in Firefox 15. Chrome has no problem.

I have tried both with and without an "Expires" header, it makes no difference. Firefox just refuses to send an If-Modified-Since header.

Answer 1

For me, the problem turned out to be that the Last-Modified date in the response I was sending wasn't exactly RFC 1123. Chrome didn't mind; it happily sent my malformed timestamp back in the If-Modified-Since header. Firefox, however, quietly ignored it.

I can see from your headers this wasn't the reason in your case, but I'm posting this answer anyhow, since it took a while for me to realise this was the issue, and maybe, some day, somebody else will have the same problem.

This is under Linux, FWIW (Mint 17, to be precise) but I expect both browsers would behave the same way under other OSes.

Answer 2

Okay, I feel like a doofus but decided to put my pride aside, and rather than just deleting this question, tell what the solution was in case anyone else ever did the same thing...

Once upon a time, in order to test something, I had turned off caching in Firefox. I turned it back on, and now it is sending the header.

Answer 3

For me, it was that Firefox (ESR 60.4.0) wasn't sending "If-Modified-Since" nor "If-None-Match" headers for some resources (like CSS, JS) when I loaded site from address bar.

However, when asking for reload with "ctrl+r", it was sending both headers, but resources still were reloaded with "200 OK" even if they should have returned "304 Not modified"

After some tracking, I found out that it was due to apache 2.4.25 deflate module. If resources were compressed, they effectively would not be cached (that is, they would be reloaded on next access). When looking more into it, it turns out it is due to ETag handling when using deflate.

So the most reasonable kludge for me was using "FileETag None", and now I properly get "304" even for compressed documents when I do "ctrl-r".

Amazingly, even after that it still showed green "200 OK" indicating full retrieval od CSS and JS (and no "If-Modified-Since" in detailed "Request headers" panel) which drove me crazy, until I figured out that this column is sometimes FAKED (there is another column called "Transferred", and if it says "cached" instead of number of bytes, it means firefox actually got the value from internal cache, and not from network "200 OK" request it shows. Checking access_log on server side confirmed that there is no network activity then, so that part just bad UI)