Re: CGI spec revisited

> Yes.  For example, what purpose does PATH_TRANSLATED serve? It appears
> to be a catentation of the document root and the PATH_INFO, which is
> superfluous if both those are available.  If this is correct, it should
> be deprecated in a coming CGI version.
> 
> > * I like NCSA's DOCUMENT_ROOT idea (which Paul mentions).  A number of
> > people have bitched about not being able to reliably determine the document
> > root or server root across a variety of servers without asking for help
> > from the humans.
> 
> I'm all for it too, as long as it's consistently documented somewhere.

The problem I have with these two (I discussed it with
PATH_TRANSLATED, which I wound up punting on) is that they assume that
"document root" can be interpreted in some way that makes sense. Given
that most servers allow arbitrary URLs to be aliased to arbitrary
directory trees, the concept of "document root" doesn't seem to make
sense.

Which is why AWS did away with it. AWS doesn't have a "document root"
per se; it just has URL->directory mappings, one or more of which can
handle URL's starting with "/". A given URL can map to different paths
depending on the existence or non-existence of other files, the IP
address the request came from, and other things I haven't thought of
yet.

If someone is going to take another look at the CGI, I think that
tagging features as "optional dependent on server architechture" might
be worth doing. This lets CGI authors know which things they can
depend on being there, and allows us to create names for data items
that might not be present in all - or even many - servers, but that
some servers want to make available.

	<mike

Received on Saturday, 29 April 1995 23:18:29 UTC