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:06:18 GMT
   Date: Mon, 17 Apr 95 16:39 BST
   From: drtr@ast.cam.ac.uk (David Robinson)

   I didn't mean in general, only for accessing a directory index.
   I do not see that PATH_INFO would be relevent to an http/unix-directory
   handler. But its not the value of PATH_INFO that I mind; rather that
   if PATH_INFO has the '/', then DOCUMENT_URI does not, which is surely wrong.

*Surely* wrong?  The semantics of httpd/unix-directory handlers aren't
even defined yet!  If you have an argument to make as to why these
handlers should see a '/' on DOCUMENT_URI (as they presently don't),
then please make it, but ex cathedra statements like this aren't
terribly compelling.

I've got two arguments in favor of the status quo:

One is simple consistency with other handlers --- the implementation
would have to be special-cased to add the '/' for unix-directory
handlers, and I'd prefer to avoid that.

The other, which is somewhat more important, is that the major use for
DOCUMENT_URI in actually *writing* an httpd/unix-directory handler is
in generating headers --- and for headers you'd probably want to strip
the '/' off, if it were present, for the sake of neatness.

FYI, a simple httpd/unix-directory handler is included below (it's
actually a cut-down version of my test code); I'd prefer to keep the
minimal unix-directory handler at least this simple unless there's a
fairly compelling reason to do otherwise.  (Yes, it does work, and the
relative URL's it generates are resolved correctly).

(If we were actually shipping $ENV{'DOCUMENT_URI'} values back to the
client in the http headers, I'd see more of an argument for setting
them "correctly", by your version of correctness --- we shouldn't be
referring clients to URLs which we will only redirect instantly.  But
we aren't sending these values back to clients in the headers, so that
issue is moot.  By the looks of things here, *very* moot).

rst




#! /usr/local/bin/perl

$dir_uri = $ENV{'DOCUMENT_URI'};
$dirname = $ENV{'DOCUMENT_TRANSLATED'};

opendir (dir, $dirname);
local (@files) = readdir(dir); closedir(dir);

print <<EOF;
Content-type: text/html

<Title>Index of $dir_uri</title>
<H1>Index of $dir_uri</h1>

<ul>
EOF

foreach $entry (@files)
{
print "<li> <a href=\"$entry\">$entry</a>\n";
}

print "</ul>\n";


Mime
View raw message