I know you have alreadly expressed a distaste for the redirection
mechanism in HTTP/1.0, but this situation is exactly what it is
designed to deal with. If you find this mechanism cumbersome in the
server you use then perhaps that is the part of the server you need to
rewrite.
>
> Now, in order to satisfy the goal above, you need some way of
> distinguishing the scripts from the ordinary files, other than selector
> syntax. In other words, you need a mechanism for typing the files.
>
> Like it or not, most of the existing servers already have such a mechanism
> --- to tell what type a file is (in order to report the proper MIME type),
> they discriminate on the basis of the name. If you put a GIF file up under
> the name 'foo.au', or even just plain 'foo', then (with the stock NCSA
> server, and Plexus and CERN as well, I believe), the wrong MIME type will
> be reported back to the client, and things fall apart.
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.
John Franks Dept of Math. Northwestern University
john@math.nwu.edu