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 12:57:04 GMT
   Date: Mon, 17 Apr 95 17:34 BST
   From: drtr@ast.cam.ac.uk (David Robinson)
   Precedence: bulk
   Reply-To: new-httpd@hyperreal.com

   I know...
   My main problem is that I think the current ssi behaviour is completely
   crap. The only spec is the source code itself, which is more broken than
   a very broken thing, and upon which users probably depend. Hence my rather
   argumentative comments. Maybe it would do some good if I tried to write an
   actual specification.

OK, but given that users currently depend on the current behavior, I'm
not at all sure it's proper to change it incompatibly just because it
was never written down (even if you do think it's "completely crap").

   Anyway, the only useful definitions of DOCUMENT_URI that I can think of are:
   1. The path part of the URL for the requested resource.
   2. The shortest URL formed by repeatedly removing path segments from the
      path specified in 1 that would cause httpd to execute or parse the same
      file (as for the full path).

   It shouldn't be a surprise that I prefer 1.

   Currently, for server-side includes, httpd implements some form of 2.
   But I do think that for cgi scripts and handlers, knowning the actual URL
   the user specified is important if you want to be able to return a document
   with relative links. I would suggest that this is better to be completely
   specified in the DOCUMENT_URI variable, than in the concatenation of
   PATH_INFO and DOCUMENT_URI.

You can prefer that if you like --- but the current behavior parallels
the CGI case (users's full URL available only as the concatenation of
SCRIPT_NAME and PATH_INFO), and the CGI case really oughtn't change.

(Besides, in the handler context, which is what started this off, I
really think the current behavior is just more useful.  A handler for
a discussion-form type system will probably want to do things like:

   /some/forum/doc00001 --- the document

   /some/forum/doc00001/followup_form --- a form which posts a
                                          follow-up note

   /some/forum/doc00001/post_followup --- URL which actually posts
                                          the follow-up; this is why
                                          POSTs to documents with
                                          handlers work.

etc.  The way DOCUMENT_URI is now defined for handlers, this works out
very conveniently for the author of the script --- the "command", if
any, is in PATH_INFO, and the relevant file is always named in
DOCUMENT_TRANSLATED, without any additional adornment that you'd have
to strip off.  I've been thinking of actually implementing something
along these lines just so people could see how it fits together).

   My original point was that, conceptually, I think about the URL for
   a directory as having a trailing '/' as part of the resource name.
   After all, I've been trained to think that way by the standard redirect
   behaviour if the '/' is missing.

   In fact, would you do a redirect for http://host/dir if it were handled
   by a httpd/unix-directory handler? The CGI script could determine that the
   user did not append a '/', and modify its relative links accordingly.

The current code does send these redirects even if a unix-directory
handler is defined --- that's why the relative URLs generated by the
sample handler I included in previous mail work correctly.  (And yes,
that means that unix-directory handlers are *always* invoked with
PATH_INFO of '/').  I could be persuaded to change this, if I thought
it would actually make someone's job easier, but right now, it seems
to me that it goes more the other way...

rst



Mime
View raw message