MIME types. You may or may not know what a MIME ty…

MIME types. You may or may not know what a MIME type is. If you don’t, you probably don’t care what one is either. Too bad, you’re going to learn!

Every time a client requests something from an internet server, the server tells the client what type of file it is. This is the MIME (Multipurpose Internet Mail Extensions) type. The webserver tells your browser that this file is an HTML page, or that file is an image, or that one is an executable. This is a very handy feature. It allows me to do some cool things, like have a Perl script generate an image file. Even though the URL ends with .pl instead of .jpg, the server tells my browser that it’s a JPEG, so my browser shows the picture properly.

Here’s where the problems start. Due to error, inactivity, or apathy, many webservers send incorrect MIME types. In the example above, an incorrectly configured webserver would tell my browser that the file is a text file. So my standards-compliant browser shows the “text” it was sent. A bunch of garbage shows up in my browser window. Certain popular non-standard browsers look at everything sent to them, and guess at what type of file it is. This usually works, but basically stops everything when it doesn’t work. At least with the garbage, you can do a Save As, and save the file to view it in whatever program you have to handle that type of file. With the non-standard browser, you can’t do anything to stop it from guessing the wrong type. This also allows people to embed code into “image” files. This is why certain systems could be sent a shutdown command by going to a .jpg URL.

Try these URLs in your favorite browser… they should all come out as plain text if the standards are followed.






Note that according to W3C web standards (the rules that make the web “world wide” and accessible via so many different browsers and devices) state that a browser must accept the MIME type the server tells it. While you can add non-standard features like the <blink> and <marquee> tags without breaking anything else, the RFC says that you have to do what the server says. Either you do what the server says and are standards-compliant, or you do something else and aren’t standards-compliant.

http://forums.mozillazine.org/viewtopic.php?t=16497 is a huge thread of debate on this topic. Not the first, and not the last either. Basically it comes down to the fact that honoring the standard makes things difficult for the average end user. But at the same time, breaking the standard to make things easier for end users in many situations could cause problems with unusual (though perfectly acceptable, standards-wise) configurations. You’re breaking working stuff to fix a server admin’s error. Essentially, the standards say that the extension on a file doesn’t mean anything on the web. If I have a plain text file named text.zip, that’s perfectly acceptable as long as my server tells the browser that the file is a text file. If you were to disregard the MIME types standard, your browser would probably guess that this is a ZIP archive and that the server is incorrectly saying it’s a text file, which would be wrong in this case.

Obviously, the best solution to this problem is for everyone to not make mistakes. If all filetypes on all servers were configured correctly, this wouldn’t be an issue. The server would tell the browser what type of file it is, and the file would be of that type, and the file would get displayed properly and/or open in the correct helper program. The latest Mozilla code is supposed to be improved to handle these server configuration errors, but I haven’t had a chance to test it out yet. Even if your browser can now handle this stuff, let the server admin know when something isn’t working right. It might be an honest mistake or oversight. They can’t fix what they don’t know about!

Leave a Reply

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

Note: This post is over 5 years old. You may want to check later in this blog to see if there is new information relevant to your comment.