httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: CGI specification (was Re: restructuring the server)
Date Fri, 28 Apr 1995 10:51:03 GMT
   From: drtr@ast.cam.ac.uk (David Robinson)

   Apache, for one.

   As you say, there is at least one URL for which PATH_INFO is well defined.
   However, that does not require this to be the only URL which can invoke the
   script. Thus, given this URL, one can deduce PATH_INFO. But given
   PATH_INFO and SCRIPT_NAME, one cannot deduce what the URL was.

   Consider:
   ScriptAlias /cgi-bin/ /htdocs/cgi-bin/
   ScriptAlias /htbin/ /htdocs/cgi-bin/

   for a client request of http://host.name/htbin/script/path
   SCRIPT_NAME=/cgi-bin/script and PATH_INFO=/path are valid settings
   (and quite likely with apache or NCSA httpd). Even the NCSA docs
   acknowledge this.

Hmmm... I was very careful *not* to require that the URL which causes
a script to be invoked with null PATH_INFO be unique.  However, there
is the possibility, at least with NCSA 1.3-deriviative code, that with
multiple mappings like this, unmunge_name may choose the wrong
mapping.  But I'd still prefer to see PATH_INFO specified as above,
and to consider the Apache and NCSA 1.3 behavior to be a bug
(particularly since the same behavior, from the same routine, can
cause the URLs logged in case of various errors to differ from what
the client actually presented --- which is clearly and unambiguously
erroneous, even though it's incredibly hard to fix).

   Or consider:
   /doc.shtml is a server-side include document which does
   <!--#exec cgi="/cgi-bin/script" -->

   If the client requests http://host.name/doc.shtml/path
   then the script is called with SCRIPT_NAME=/cgi-bin/script, PATH_INFO=/path

   I do not consider these to be pathalogical cases. In fact, I was
   told (on this list) that people rely on the behaviour shown by the
   second example.  (Much as I deplore it.)

Invocation of scripts from server-side includes is an interesting
thing to think about, but I think the CGI spec proper can be confined
to direct invocation of scripts for the moment.

Still, this is an awkward case... a script which can be invoked either
directly, or through <!--#exec cgi--> can construct, at the very
least, a URL which will cause it to be reinvoked in the same manner,
but it has to jump through an uncomfortable number of hoops to do it.
Sigh...

rst



Mime
View raw message