But surely you can see the point that script execution and document
retrieval should be interchangable?
* If typing files by suffix were adequate there would be no point in
* using the MIME type at all, the client could just look at the
* suffix. In HTTP/0.9 file types were determined by suffix and there was
* no MIME type. One of the reasons for HTTP/1.0 was to get away from
* this limitation. It is reasonable for the default MIME type for a
* file named foo.gif to be image/gif, but it is not reasonable to
* require that an image/gif file must have a name with suffix .gif.
*
* It is a bad idea to do so, but surely it should be *possible* with any
* HTTP/1.0 server to put up a GIF file with the name foo.au and have it
* work perfectly. BTW, the reason it is a bad idea is precisely the
* same reason it is a bad idea to have PATH_INFO data look like part of
* the path -- it is misleading and obscure.
*/
You can override the default typing conventions under NCSA httpd... you can
make the extensions whatever you want. You can also special case files like
foo.au (for your .gif of Australia) with configuration directives.
I think you're missing the point that Robert was trying to make... yes, MIME
types are great. I hope we can eventually move away from using filename
extensions to determine type on the server side. When this happens, it will
be even better since it will be transparent to the client. However, until
then, we're stuck with them.
--Rob