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: indexing suggestion (ATTN NCSA: possible 1.4 bug...)
Date Mon, 17 Apr 1995 11:33:14 GMT
   Date: Mon, 17 Apr 95 16:22 BST
   From: drtr@ast.cam.ac.uk (David Robinson)

   In fact, I don't understand why allowing PATH_INFO for server-side include
   files is needed. I suspect it may be something to do with invoked CGI
   script...

Precisely.  There are a people with fairly elaborate setups which use
PATH_INFO to pass information around between scripts which are invoked
from different SSI pages.

   Anyway, if it is, then the ssi documentation should emphasise the point
   that you cannot use relative links without a BASE tag.

When we get around to documenting it ourselves, rather than borrowing
the NCSA docs, sure.

   And earlier, Rst wrote:
   >(Note that the server requires PATH_INFO of '/' when actually invoking
   >httpd/unix-directory handlers --- sending out a redirect as usual
   >otherwise --- so the handler can generate HTML which looks like:
   >  <a href="file_in_dir.foo">some file in this directory</a>
   >without worry).

   Actually, I think this is the wrong way of think about this case.
   I would rather the DOCUMENT_URI ended in a '/', and the PATH_INFO was NULL.
   A null PATH_INFO makes more sense.

Again, not to me.  If you have a request for /script.cgi/foo/bar/zot,
then the PATH_INFO winds up as /foo/bar/zot.  I am unable to see why
PATH_INFO of a single '/' should be treated any differently.  In any
case, the current behavior is by far the simplest thing for anyone
actually *writing* an http/unix-directory handler (and yes, I've
written one to test the feature); I think that justifies it.

rst




Mime
View raw message