httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Robert S. Thau)
Subject Re: CGI specification (was Re: restructuring the server)
Date Fri, 28 Apr 1995 10:51:03 GMT
   From: (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.

   ScriptAlias /cgi-bin/ /htdocs/cgi-bin/
   ScriptAlias /htbin/ /htdocs/cgi-bin/

   for a client request of
   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
   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.


View raw message