Two things are happening here:
Chrome is caching too aggressively.
ifModified=true
might not do quite what you think it does.
Chrome should always send a request to the server to verify the validity of a cached resource, but it appears that sometimes it simply doesn't. This behavior frequently frustrates Web developers who rapidly alter their resources during development.
JavaScript can only observe 304
responses when the script issuing the request explicitly sets cache headers. JavaScript cannot leverage cache-date information known by the browser; any cache-date information must be discovered or chosen by the script itself (probably by reading last-modified headers of previous responses). Actual 304
responses given to the browser will be reported to JavaScript as 200
responses, unless JavaScript set the If-Modified-Since
header (or other cache headers).
The first fetch for a resource with jQuery will never return 304
. This is because jQuery does not save values to use with the If-Modified-Since
header between page loads. See my answer on How to check if jQuery.ajax() request header Status is “304 Not Modified”?:
jQuery does not persist cache information (e.g., in cookies) between page reloads, however. Therefore, the first fetch of a resource after a page reload will never be a 304, because jQuery has no cache information to send (i.e., we reset back to the "first fetch" case). There is no reason why jQuery couldn't persist cache information, but at present it doesn't.
The reason for this that 304 requests always come back empty. It's assumed that your code is storing the response the first time it comes back as a 200, but jQuery doesn't want to impose the requirement for you to save your cached result across page reloads.