As an example of the missing images, if I attempted to view one of the failed images say, http ://someweb_site/Style%20Library/Images/btn_home.gif, it would display :
In case you haven’t memorised the HTTP codes Wikipedia offers this refresher:
304 Not Modified
Indicates the resource has not been modified since last requested. Typically, the HTTP client provides a header like the If-Modified-Since header to provide a time against which to compare. Using this saves bandwidth and reprocessing on both the server and client, as only the header data must be sent and received in comparison to the entirety of the page being re-processed by the server, then sent again using more bandwidth of the server and client.
Even though fiddler does a cracking job of recording what happening, I can never resist firing up Wireshark to confirm the same information. Below shows the server returning the 304 Not Modified response.
So the file was being requested from the server and the server was telling the client it hadn’t changed since last visit. But I hadn’t visited the site before. I flushed the client’s web browser cache just to be sure and still got the same error. To me that confirmed the error was at the server end.
SharePoint has its own caches to speed up page and content delivery. The one I was interested in is the binary large objects (BLOB) cache and initial thought was to flush this cache and fix the problem, MS have a nice simple powershell script to do this http://technet.microsoft.com/en-us/library/gg277249.aspx
The fix was easy; we created a BLOB cache and everything worked beautifully, then we disable the BLOB cache and everything still worked. Despite the web page displaying the content correctly, I confirmed under the hood with fiddler and as you can see a much happier result.