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…

media="print" and proxy

Really strange thing happened.

One of our developer tried to do a print-friendly rendering of a page. That is, when you print the page, logo is removed, hyperlinks is followed by their URLs written etc. A usual stuff.

He did so using media="print" trick with CSS.

He made it work nicely with FireFox but not on IE. Still needs some improvement, to support various browsers. That's OK. Not my business.

The weird thing is that it behaves differently when you get the page, css everything via a proxy.

The simplest example. If I start Fiddler to see if all come from where they are supposed to, you see it already different in the print preview...

You would normally suspect that some element of the page such as a css file fails to come, due to some authentication/authorization issue for instance, when you go thru the proxy. But Fiddler reports none. The key, linked as media="print", css seems downloaded OK. If the elements are the same, whether or not via proxy, it should behave in the same way...

After almost one day of fruitless investigation, given up... Asked him to revise it, so it works OK with IE as well, and with or without a proxy.

Mmmm...

A small good-to-know with FireBug

Like me, I think you like it, the FireBug. It is really nice, helpful when especilly you work with CSS.
But have you ever been frustrated when you work on those for hyperlinks i.e. a:link, a:hover etc?
You want to know which of the classes takes the effect when it appears on the browser, but it tells you that only when you click the element.
But with the case with a hyperlink, when you do so, what takes the effect is that of “hover”, not that takes the effect when the page is loaded.

I was very frustrated, helpless, but found out that just by coincident, after you once selected the element, if you refresh the page, it tells you the css class that takes the effect at the page load time.