Re: CGI and typing files by suffix

john@math.nwu.edu (John Franks)
From: john@math.nwu.edu (John Franks)
Message-id: <9312301622.AA01013@hopf.math.nwu.edu>
Subject: Re: CGI and typing files by suffix
To: sanders@BSDI.COM (Tony Sanders)
Date: Thu, 30 Dec 1993 10:22:01 -0600 (CST)
Cc: www-talk@www0.cern.ch
In-reply-to: <199312300817.CAA16656@austin.BSDI.COM> from "Tony Sanders" at Dec 30, 93 02:17:42 am
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1738      

According to Tony Sanders:
> According to John Franks:
> > 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.
> Yes, this is a MUST in my book.
> 

OK, I would be happy to allow this to be an implementation dependent
feature.  Some implementations could use "cgi-bin", others ".doit",
others the execute bit and still others could encode this information
in the part of the URL path before the PATH_INFO data since that part
of the URL is opaque even to CGI.

> > 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.

> It is indeed possible and does work.

> >  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.

> I fail to see how:
>     http://server/path/cmd;args
> Is really any clearer or better than:
>     http://server/path/cmd/args
> 

Does Plexus parse the URL by doing stats through the file system to
find out where the "path/cmd" ends and the "args" begin?  I find this
objectionable.  I don't really care how efficiently one can do stats,
or whether one can patch NCSA httpd to need fewer stats than the
original.  If this is the best way to implement this protocol then
IMHO the protocol is badly designed.


> The `;' scheme simply has too many drawbacks (namely you can't front-end
> existing directory hierarchies with scripts).
> 

Could you explain this?  What couldn't you do with the ';' scheme that
you can with the current scheme?