Re: CGI and typing files by suffix

robm@ncsa.uiuc.edu (Rob McCool)
Message-id: <9312301946.AA27382@void.ncsa.uiuc.edu>
From: robm@ncsa.uiuc.edu (Rob McCool)
Date: Thu, 30 Dec 1993 13:46:15 -0600
In-Reply-To: john@math.nwu.edu (John Franks)
       "CGI and typing files by suffix" (Dec 29,  9:15pm)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: john@math.nwu.edu (John Franks), rst@ai.mit.edu (Robert S. Thau)
Subject: Re: CGI and typing files by suffix
Cc: www-talk@nxoc01.cern.ch
Content-Length: 2459

/*
 * CGI and typing files by suffix  by John Franks (john@math.nwu.edu)
 *    written on Dec 29,  9:15pm.
 *
 * According to Robert S. Thau:
 * > 
 * > n) There should not be any indication within the URL, selector string,
 * >    etc., as to whether or not a retrieval will cause a script to be
 * >    invoked.
 * > 
 * > The reason I want it is that having put something up as a file, or
 * > collection of files, I may want to turn it into a script, without having to
 * > track down all the references to it and change them as well --- which I
 * > would necessarily have to do if the script/file distinction were explicit
 * > in the URL (selector, whatever).  
 * 
 * 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.

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