Friday, February 25, 2011

CSS delivered as Content-type: application/octet-stream

I do not know if this could ever be any benefit of anybody. It could be just that there is something wrong with our servers…

On our site, sometimes (it appears) CSS files are delivered to clients as Content-type set to application/octet-stream.

The story starts as a few colleagues report pages are displayed ugly without styles on Firefox and Chrome. OK on IE.

I found that the CSS is stored in the browser's cache as application/octet-stream. This is tricky because once you clear the cache and go to the page again, the CSS would be downloaded OK.

There seems nobody having similar issue, or at least reporting to the net. I tried to come up with an own workaround.

I wrote an HttpModule to verify if responses for css files are generated correctly as Content-type: text/css, and correct it if not. It writes into the log file each time it find such a problematic response. By the way, in the course of writing the module and testing it, I found that IE applies styles even if it receives the css file as application/octet-stream. This is why the problem has been reported happening only on Firefox and Chrome. Furthermore, for some css, those that SharePoint generates, you can change the Content-type (to application/octet-stream for the testing) in the MIME type configuration of IIS. However, those of our own creation, those in the /Style library folder, come as text/css, even after the change in the IIS’s MIME section. So it is SharePoint that controls it.

Towards the end of the first day after the module is plugged in, the module reported that it did the Content-type correction. And a lot! We have two Web Front End in a farm. Both connect to one single Content database. Each web server generates those mal formed css responses at different timings.

Each has a IISRESET scheduled job. At different times of a day, obviously. Each generates the problematic responses after the IISRESET and stops doing so when the application pool gets recycled. (it gets recycled when the memory usage reaches the threshold)

Sh*t!! I should have requested pages from the server while the module there was reporting the problem!! I could have verified that my Content-type correction does the trick. No worries. It would come again, I guess…

2 comments:

Unknown said...

Thanks for a great article. We have an ongoing case with MS regarding this. We have a multitenent loadbalanced sharepoint 2010 environment with 3 frontends.

As a workaround, we wrote a policy in Citrix Netscaler, who acts as load balancer.

Peter Holpar said...

I know this post is about SP2010, but those of you who face the issue with any version of SharePoint, ensure that the IIS 6 Metabase Compatibility windows feature is installed, see description here: https://blogs.technet.microsoft.com/stefan_gossner/2018/11/30/common-issue-sp2019-items-in-document-libraries-are-downloaded-with-mime-type-application-octet-stream-rather-than-the-accurate-one/