I used Fiddler & Firebug to analyze the HTTP traffic and rapidly came to the conclusion that this bug was related to the HTTP caching mechanism. To solve this bug I had to understand how HTTP caching works. The HTTP 1.1 spec describes how the caching mechanism of a web server should be implemented – this is a simplified version:
A) The client send an HTTP request to a server
B) Based on several factors (see below) the server will decide if it will serve a specific resource with a response code 200 or return a 304. A response 304 means that the client should use his cache to serve the resource.
A web server returns a 304 when all the following conditions are true:
1. The resource on the server is configured to be cached (for most of the web servers this means that cache is not disabled for the specific resource)
2. The Last modified date of the resource is < than the Request date
3. The Request does not contain any header that disable the cache (see RFC)
4. The resource is fresh enough (see RFC)
In my situation the web server returned a 200 when using IE and a 304 when using Firefox. This was because condition 1 -2 & 4 were true but 3 was only false when using IE. The page displying the images contained a meta tag: <META HTTP-EQUIV=”Pragma” CONTENT=”no-cache”>. This tag instructs IE to add the header pragma=no-cache when it request the image. This HTTP header instruct the web server that it has to return a 200 (see condition 3). The problem was that Firefox don’t understand this tag.
I solved the bug by tackling the root cause of the problem; I disabled the cache on the web server for this particular resource.
If this is not feasible in your situation other possibilities are:
– Disable the cache via the request by adding the proper meta tags, for Firefox a valid tag is: <meta content=”-1″ http-equiv=”max-age” >.
– Make sure that the last modified date is updated correctly
– Generate a random character as a querystring after the jpg extension: e.g: myimage.jpg?201003321023