IIS 6 Does not Know What a CSS File Is (Missing MIME Types)

Posted by Hans de Ruiter

Recently the OWB web-browser for Amiga OS 4.x was updated to version 10, and last night I upgraded and tested this website with it. To my horror OWB was ignoring the CSS (Cascading Style Sheet) stylesheet and presenting the user with an unformatted page. Initially I thought that CSS might be broken, but no other website that I visited had this problem. Even stranger was that the webpage was shown properly when viewed from a version that had been saved to disk.

After a lot of checking and rechecking that there was something in the page code that was breaking the latest version of OWB, it turned out to be the webserver at fault. This website is hosted on a Microsoft IIS 6 server and it was not sending the appropriate MIME type for CSS files. The latest version of OWB appears to be very strict about MIME types, and thus refused to use the CSS files given that the server had not identified them as such. CSS files have a MIME type of "text/css".

The fix to this problem was to add a custom MIME type associating .CSS files with the type "text/css". In truth, OWB's overly strict MIME type handling was also part of the problem; web-browsers should be tolerant of mistakes made by other systems that they interact with.

Personally I think that MIME types should be made irrelevant. software should generally determing file types by looking at the file itself. This is what the Amiga datatypes system has done for years. Where this is not possible (e.g., a CSS file  has no header, and is also a plain text file), the file suffix (e.g., ".css") should be used. This is what servers tend to do when sending MIME type infromation, anyway. Why trust/rely-on a server to perform a task that could be just as easily performed by the client?

Invalid HTML Markup in Widget/Advertising Code

In the process of searching for the CSS layout on OWB problem, it was discovered that this website had over one hundred XHTML errors on the page. Almost all of these were due to code in the advertising widgets not being standards compliant. In  fact, almost all of the errors were due to incorrectly using the ampersand character, i.e., "&". The & character has a special meaning in HTML. Therefore, if one wishes to show an &, it must be written as "&", not "&". This is true even if the ampersand is contained within a URL. Not one advertising provider got this right; not even Amazon. Every & character resulted in several errors, so eliminating these errors quickly dropped the number of errors to almost zero.

At this point this website is still not 100% W3C compliant. The ClustrMaps widget also contains code that does not pass the W3C validator. However, all browsers handle the code correctly, and there are plenty of other things requiring my attention. I do find it surprising that even large organizations are providing code for others to use their services that is not standards compliant.

Comments (0) | 16 April 2009