OK geeks, help me out, for I am vexed.
FireFox 1 is out, and it’s great. In FireFox tradition, it’s very strict about web standards. I like that. But it also means that if a server sends a particular MIME type for a file, the browser handles it as such. Most browsers ignore the MIME type for .css files, and just handle them. But if FireFox hears from the server that a .css file has a type of text/plain rather than text/css, it will refuse to render it, and you’ll see the complaint in its console.
And suddenly, this site and others that we host are sometimes displaying without stylesheets when viewed through FireFox 1. To test whether the server is doing the right thing, I went to web-sniffer and enter the URL of a dirt-simple test: http://birdhouse.org/temp/styles.css. Look at the return for Content-Type — about half the time it returns text/css, half the time it returns text/plain (try toggling settings for GET vs. HEAD, etc.) WTF?
So just fix the MIME type for .css on the server, right? Right. In mime.types, we already have the default:
text/css css
That should be sufficient, but obviously isn’t. For good measure, I added an explicit AddType to commonhttpd.conf:
AddType text/css .css
No change. For giggles, I add the same to an .htaccess in one of the affected directories. No change.
I’ve posted messages to the apache-users mailing list, to an apache config newsgroup, to the Mozilla forums, and to DevShed. No useful responses. Finally I decide to do something I’ve never done: Pay for Unix support. Found some recommendations on an apache guru-for-hire and just spent an hour on the phone with him. He studied our apache config up, down, and sideways, couldn’t find anything unusual, and certainly nothing that would cause MIME types to change intermittently.
The problem is not unheard of. Google for css firefox mime apache to find similar problems. Some people actually are missing the right MIME configuration, and are able to fix the problem by adding it. But we’re already configured properly.
Update: I just got around to testing an index.html file with the sniffer rather than .css, and found that it alternates between types of text/plain and text/html, just as css files alternate between text/plain and text/css. Something is definitely weird.
Flummoxed, and no fix in site. Fun way to spend veterans day. Suggestions welcome.
I have no idea how to fix your problem, but I wanted to mention that in Firefox, if you right-click on the page (even your CSS), select “View Page Info”, a dialog pops up giving you tons of info about the page, including the content-type… So you don’t have to go to web-sniffer to figure it out.
Yeah, I found that. Or you can just use Ctrl/Cmd-I to Get Info. Neat!
Hi Scot,
Say, I’ve been looking at it a bit (with your /temp/styles.css) and spotted the following pattern:
– Post & Head always returns text/css
– Get returns text/plain when there’s an ‘age’ header, and text/css when there’s no such header.
My question would be: is there a proxy, are you caching anywhere, and if so, would they be responsible for messing with your headers?
Good luck – and keep us posted if you please,
-Erwin
i know nothing about what you are asking, but…
I have been running firefox for a week or so, the speed is incredible. I had assumed browsers had gotten to the place where rendering speed was less of an issue than the connection speed and file size issues. I was wrong. I am amazed at the difference.
I tested ESPN site in ie, safari and firefox. Fire fox was way faster and rendered with fewer mistakes. Further tests reveled firefox un-cached often beat ie or safari cached. How can that happen?
I have had a few crashes, one wouldn’t even allow a forced quit. Nothing worth not using it though.
Scot, I don’t have any practical suggestions for fixing this. But I would like to comment that this is why strict standards are a problem. Without some hysteresis in your interpreters, you run the risk of breaking anything that isn’t fully compliant. With innovations happening so fast, compliance is very difficult to impossible to achieve and maintain. It’s like a person who refuses to speak with you if you don’t speak the Queen’s English. Obviously some structure is necessary, but perfect obedience to structure is also destructive of communication. Requiring a particular MIME type is definitely a purist engineer’s stipulation. It would be great if everyone observed the formal tenets of the system, but unfortunately the world don’t work that way (sic).
Erwin, I think you may be onto something with caching. If the caching mechanism isn’t respecting the MIME database for some reason… Hmm.. let me look into this. Nice observation, thanks.
Chris, I agree with you to some extent, but …
> you run the risk of breaking anything that isn’t fully compliant.
I would argue that we run the risk of breaking even more if we aren’t standards-compliant. Just look at how hard it is to create CSS designs that work in all browsers due to shoddy standards compliance, especially among the majors. Browser and web developers tear their hair out daily grappling with the problems created by the release of non-compliant browsers into the wild. Yes, the user experience trumps the developer experience, but if we can’t guarantee a user experience (or even begin to), then we’re screwed.
> It’s like a person who refuses to speak with you if you don’t speak the Queen’s English.
Except that computers demand a rigidity of communication that humans don’t, so the analogy only partly holds.
Imagine the difficulty of communication if TCP/IP had similarly loose implementations.
In any case, this is a peculiar situation because both apache and mozilla are strict about standards compliance, which is a bit different from the usual situation where some product is standards compliant (or tries to be) and another is not.
My, seems like we’ve stumbled into a discussion on whether or not to be strict on your output/lenient on your input…
Here’s a workaround solution for the issue of invalid MIME types returned for cached .css files when running Apache 2. I’ve been googling like mad for a solution to this, but haven’t seen anything else posted, so pass this along if you like.
It sounds like there is a known Apache 2 issue with mod_cache and mod_disk_cache modules when running with mod_jk enabled. This issue is described in the Apache Bugzilla database (see article: http://issues.apache.org/bugzilla/show_bug.cgi?id=30278).
Tonight I disabled loading of the both cache modules in the Apache 2 config files by moving them out of my conf.d directory. I also took the suggestion from the bug report and enabled the AddDefaultCharset option in the httpd.conf file.
I will need to do further testing, but everything on my development server now seems to be displaying correctly on all Mozilla flavors, including Firefox 1.0.
Cheers.
I just stumbled on this discussion whilst trying to find how to make Firefox relax a little about standards.
The html page I was trying to view is being served as Content-Type: application/octet-stream.
Firefox sticks to its guns and you end up with a page rendered from a local file, with all the links broken and images missing.
I also came accross IE content-type logic, which is a bit about why IE renders this sort of thing without complaint.
5 months later, and this page is still helping people.
Thanks for the link, Nick, it works perfectly now!
I’ll second that. My research group has been having the same trouble, and now we have an idea of where to go. Thanks for all your efforts!
Hi folks, I think I’m having almost the same problem as Scot.
My wepage:
http://guests.mpim-bonn.mpg.de/rybu/
renders fine in Konqueror, but Mozilla, Firefox, Epiphany, etc, do not render the .css file correctly.
Yes it gets delivered as text/plain, that’s the problem. But the webserver is running Apache 1.3.xxx
Does this older version of Apache have the same problem? Does anyone know of a work-around?
There is a
TypesConfig /etc/mime.types
line in apache2.conf.
If you add a
text/css css
line in your /etc/mime.types file, all .css files are well recognized by your browsers.
I have an application for Limo Dating, that clients upload images and data over to the system. The problem is the MIME BUG with new Internet Explorer 7 on Windows Vista, none of the users using Vista and IE7 can upload images, until they install Firefox. I am wondering if anyone else has come around this problem, or any solution?
Hey Pashalex, I just had a look at your site, we had the same issue, when it comes to validating the file type(MIME), the idiot IE overrides the standard file type, so the system will fail to validate the file.
here are the following recommendations for your Limo Dating site.
1. ask them to use Firefox
2. change the validation engine (will be less secure)
3. store the server updates somewhere on the server and write another script for manual validation, it won’t be real time anymore.