Chrome browser is not sending if-modified-since he

Question

I have these headers being sent to the client by the server:

Cache-Control:private
Connection:keep-alive
Content-Encoding:gzip
Content-Type:text/html
Date:Sun, 27 Nov 2011 11:10:38 GMT
ETag:"12341234"
Set-Cookie:connect.sid=e1u...7o; path=/; expires=Sun, 27 Nov 2011 11:40:38 GMT; httpOnly
Transfer-Encoding:chunked
last-modified:Sat, 26 Nov 2011 21:42:45 GMT

I want the client to validate that the file hasn't changed on the server and send a "200" if it has otherwise a "304".

Firefox sends:

if-modified-since: Sat, 26 Nov 2011 21:42:45 GMT
if-none-match: "12341234"

Why isn't the chrome sending the same on a refresh of the page? I'm after the behavior that .Net has running:

context.Response.Cache.SetCacheability(HttpCacheability.ServerAndPrivate)

Answer 1

I know this question is old, but still.. I noticed that chrome remembers the last refresh that you made. So if you press ctrl+shift+r (refreshing and deleting cache), and pressing ctrl+r (just refreshing), chrome keeps on deleting cache and does not show the 304 in the received response. There is a workaround for this. Press ctrl+shift+r and then go to the address bar, focus it, and hit enter. If your etags are set correctly, and your server is ready to serve a 304, you'll see a new response code in the debugger - 304. so it works.

Answer 2

In my experience you need more than just the "Private" Cache-Control header. You need either "Max-Age" or "Expires" to force Chrome to revalidate content with the server.

Remember that revalidation will only start after these time values have elapsed, so they may need to be set to a small value.

Answer 3

In addition (https://stackoverflow.com/a/14899869/362780):

F12 > Settings > General > Disable cache (while DevTools is open) -> uncheck this...

Answer 4

Browsers have a lot of counter intuitive behavior when it comes to caching. You would expect, that if the response includes a last-modified-date, that the browser would revalidate this before reusing it. But none of the major browsers actually do that.

The ideal settings for your situation depend on when you want the browser to revalidate, see link below.

Not only do browsers act counter intuitively, different browsers also behave differently in the same situation. For example when the user clicks on the refresh button.

You can read how the different browsers (Internet Explorer, Edge, Safari, FireFox, Chrome) behave with different caching directives (Etag, last-modified, must-revalidate, expires, max-age, no-cache, no-store) at https://gertjans.home.xs4all.nl/javascript/cache-control.html

Answer 5

After spending half a day on this yesterday, I tracked down what was causing the issue for me. So long as you have the Chrome object inspector/Client Debugger/Network monitor/Thing that pops up when you hit F12, Chrome will not send cache request headers. Period. (update: in newer versions of Chrome, there is a checkbox "Disable cache"). Even if you don't have the "network" tab open (ex: have the javascript console open), this checkbox still disables all cacheing.

Its sad, because debugging this from the client side obligates you to leave the network panel open to see what headers are being sent and received, and what codes are being returned. Without the network panel open, there is no way to know if your content is being cached from the client side.

If you dig into your server access logs, you will notice your server returning 304s(Cached Content) the minute you close the debug window on your Chrome client. Hope this helps.

Chrome 24.0.1312.57

Answer 6

I found one answer to this behaviour when using HTTPS, thought I'd share what I found. You do not specify if you are requesting via HTTP or HTTPS.

"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.