SharePoint 2010 returning HTTP 304 for files in Style Library directory

I asked to look into  a very curious problem with a new SharePoint 2010 site’s images not being displayed which, in theory, shouldn’t have happened.  Red crosses replaced the images on the page and the JavaScript code wasn’t running.

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 :

 (the white square and red cross is intentional, please don’t adjust your screens)

rather than  

 

With the aid of fiddler2 I could clearly see the process of the connection to the SharePoint server. What was odd was the 304 HTTP message from the server, despite it being the first time I visited the site.

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

Flushed BLOB cach for the site, but still no dice. Then took a bit of a step back and looked at how SP used blog caches. Tobias Zimmergren’s blob piece was very help in understand where to look for the BLOB setting in the web.config file. A few simple checks showed that this site wasn’t using BLOB caching. Somehow SharePoint must have got confused in to thinking it did have a BLOB cache and was trying to return the images and JavaScript from the non-existent cache.

 

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.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>