Various tastes of this question have already been asked, but I have not yet found a real answer for this.
We have a separate image service that our web application uses to retrieve some of its images. The image service is well-tested and functioning properly. To make this specific, our application will be shipped from domain.com . The src element of img elements is images.domain.com/{imageId} . The image service retrieves the URL of the image and sends back an HTTP 302 redirect for the image.
The application allows users to modify images. Therefore, say that user 5 has image A as a profile image and decides to change it by downloading image B When a user uploads an image, the application cache is correctly invalid and the database is updated. The application performs the standard redirection after POST , and one of the elements on the page that the user is redirected to after changing its image looks something like this:
<img src="example.domain.com/5">
The problem is that Chrome never makes a call to example.domain.com/5 to retrieve the image the first time it redirects or reloads the page regularly, it just serves to image A from the browser cache. A standalone call to example.domain.com/5 correctly returns image B , and hard updating or clearing Chrome Chrome forces Chrome to request an src image that correctly returns image B Note that I'm not talking about serving the image from the cache after receiving a 304 Not Modified response, I'm talking about the fact that Chrome decided not to visit img src at all and just return image A In addition, adding some unique query string to the img src attribute fixes the problem, but this is a hack that we do not need to do.
It is worth noting that Firefox did the same thing at first. Initially, the response did not have Cache Control headers. We added the Cache Control: no-cache header (and tried no-store ) in the response header, and this fixed the behavior in Firefox, but Chrome and Safari still serve an obsolete cached image without accessing the src image.
It seems like this was a long-standing bug in Chromium ( https://code.google.com/p/chromium/issues/detail?id=103458 ), which was supposedly fixed about 6 weeks ago, but we are using the latest version of Chrome.
We examined the answers here and here , but in reality they do not answer the question.
In section 14.9.1 of RFC 2616 :
If the no-cache directive does not specify a field name, then the cache SHOULD NOT use the response to satisfy a subsequent request without successfully retrying the source server. This allows the origin server to prevent caching even by caches that have been configured to return stale responses to client requests.
If something is missing or something is wrong, it seems that Chrome (and Safari) do not comply with the RFC behavior for no-cache headers to redirect 302 ? Does anyone experience this before or have any understanding?