Mailing List Archive

On Tue, 11 Apr 1995, David Robinson wrote:
> Why can't you use AddDescription in a .htaccess file for this?

I want to separate them from the rest of the stuff in the .htaccess file.
I don't like people downloading my .htaccess files (and patched it so you
can't). This description file is a standard in the PC world - especially
image archives. I don't want to have to have two copies of the
descriptions in each directory and something that creates one from the
other.

The only effect is one extra file access each time a directory is indexed -
this could even be turned off if "DescriptionFileName" isn't present.

Mark

>It is common on BBS and when you have lots of pictures to have a 4dos-style
>description file. The file contains a simple list of filenames and
>descriptions, one per line. This patch adds the ability to parse these
>files automatically at the expense of one extra file access each time
>a directory is visited.

Why can't you use AddDescription in a .htaccess file for this?

David.

WRT downloading .htaccess files, one approach might be to have a
TotallyIgnore directive, along the lines of IndexIgnore, which would
direct the server to behave as if files which matched the relevant
regexp's were not even present, if a client asked to retrieve one.
(This would handle one case which bugs me --- right now, attackers
can probably get source code for *.cgi scripts from a lot of sites
by fishing around for emacs backups).

rst

>I want to separate them from the rest of the stuff in the .htaccess file.
Actually, I've always thought that the indexing should be as separate as
possible from the other httpd functions.
Unfortunately, upon further reflection, I realised that users would probably
want to set index options for an entire directory tree, and so the options
would have to be in a .htaccess -type file. (That is searched for in
every directory of a path.)

>I don't like people downloading my .htaccess files
Presumably the same problem applies to description files.

David.

On Tue, 11 Apr 1995, David Robinson wrote:
> >I want to separate them from the rest of the stuff in the .htaccess file.
> Actually, I've always thought that the indexing should be as separate as
> possible from the other httpd functions.

This is one of those creeping-featuritis-potential functions, like log
file processing, that as said before are probably better handled by
passing that functionality off to a script.

Here's a proposal:

DirectoryIndexGenerator some_script

DirectoryIndexGenerator would be the program that generates the pretty
HTML directory index. It's got the full suite of CGI scripts, and gets
information about the directory it's in by whatever the language it's
written in has for obtaining the current working directory (like CGI
scripts do).

By default, httpd uses the built-in generator it has now - however, both
the 4DOS "descript.ion" and ALIWEB mechanisms can use this, and we could
distribute those scripts in the utils/ directory.

Thoughts?

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/

On Tue, 11 Apr 1995, Robert S. Thau wrote:
> WRT downloading .htaccess files, one approach might be to have a
> TotallyIgnore directive, along the lines of IndexIgnore, which would
> direct the server to behave as if files which matched the relevant
> regexp's were not even present, if a client asked to retrieve one.
> (This would handle one case which bugs me --- right now, attackers
> can probably get source code for *.cgi scripts from a lot of sites
> by fishing around for emacs backups).

This has my support - code away!

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/

David Robinson wrote:
> Unfortunately, upon further reflection, I realised that users would probably
> want to set index options for an entire directory tree, and so the options

Yes. The problem with using "AddDescription" is that any subdirectories
inherit the descriptions on their parents. So after a few levels you start
having to parse loads of useless AddDescription files.

Brian wrote:
> DirectoryIndexGenerator some_script
>
> DirectoryIndexGenerator would be the program that generates the pretty
> HTML directory index.

Now this is a much better solution: It won't be long before we want the
pretty index to include tables if they accept html3.

I've not studied Multiviews in any great depth - whilst it is easy to
select between documents based on the Accept headers, does this work for
CGI scripts? I have a CGI script that can output with tables or not -
does it have to parse the Accept headers itself (or have .cgi and .cgi3)

Mark

On Wed, 12 Apr 1995, David Robinson wrote:
> DirectoryIndex index.html /cgi-bin/4dos.pl

But 4dos.pl doesn't know which directory to index. I suppose you could write

DirectoryIndex index.html /cgi-bin/4dos.pl/this/directory

but its a bit of a hack and has to be done in every directory...

Mark

Date: Tue, 11 Apr 1995 18:19:58 -0800 (PST)
From: Brian Behlendorf <brian@wired.com>

This is one of those creeping-featuritis-potential functions, like log
file processing, that as said before are probably better handled by
passing that functionality off to a script.

Here's a proposal:

DirectoryIndexGenerator some_script

DirectoryIndexGenerator would be the program that generates the pretty
HTML directory index. It's got the full suite of CGI scripts, and gets
information about the directory it's in by whatever the language it's
written in has for obtaining the current working directory (like CGI
scripts do).

By default, httpd uses the built-in generator it has now - however, both
the 4DOS "descript.ion" and ALIWEB mechanisms can use this, and we could
distribute those scripts in the utils/ directory.

Thoughts?

Seems like a reasonable compromise... it would also probably work well
with an internal gateway mechanism, for sites where this sort of thing
comes up enough that CGI overhead might be a problem.

rst

Date: Wed, 12 Apr 1995 08:51:38 +0100 (BST)
From: Mark J Cox <M.J.Cox@bradford.ac.uk>

Now this is a much better solution: It won't be long before we want the
pretty index to include tables if they accept html3.

I've not studied Multiviews in any great depth - whilst it is easy to
select between documents based on the Accept headers, does this work for
CGI scripts? I have a CGI script that can output with tables or not -
does it have to parse the Accept headers itself (or have .cgi and .cgi3)

Multiviews will run a script if it finds one there, and it's the only
variant; however, it won't choose between different scripts based on
the client's accept headers; you have to check HTTP_ACCEPT and do it
yourself.

rst

Yes it should; SCRIPT_NAME might be the requested URL, and if not it would
be easy to have a convention of putting the URL as the PATH_INFO.

I think the point is that scripts used as index generators *would* have
to be special-cased somehow... given that, I think the earlier suggestion
for an IndexGenerator directive is probably the best way to handle it.
(Besides, having "server-absolute" URIs in a DirectoryIndex directive
just looks a bit weird...).

rst

On Wed, 12 Apr 1995, David Robinson wrote, quoting me:
> But are we not already there? Wouldn't
> DirectoryIndex index.html index.cgi
> suffice?

No, because then you need an index.cgi for every directory... this would
be a single script that somehow gets "plugged in".

> Or even
> DirectoryIndex index.html /cgi-bin/4dos.pl

I like this a little better - more generally, if we can allow absolute
paths in DirectoryIndex then we can also have

DirectoryIndex index.html /sorry.html

Where if there's no index.html in a directory, DOC_ROOT/sorry.html gets
returned. I do like solutions which don't require new directives.

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/

>On Tue, 11 Apr 1995, David Robinson wrote:
> > >I want to separate them from the rest of the stuff in the .htaccess file.
> > Actually, I've always thought that the indexing should be as separate as
> > possible from the other httpd functions.
>
> This is one of those creeping-featuritis-potential functions, like log
> file processing, that as said before are probably better handled by
> passing that functionality off to a script.
>
> Here's a proposal:
>
> DirectoryIndexGenerator some_script
>
> DirectoryIndexGenerator would be the program that generates the pretty
> HTML directory index. It's got the full suite of CGI scripts, and gets
> information about the directory it's in by whatever the language it's
> written in has for obtaining the current working directory (like CGI
> scripts do).
>
> By default, httpd uses the built-in generator it has now - however, both
> the 4DOS "descript.ion" and ALIWEB mechanisms can use this, and we could
> distribute those scripts in the utils/ directory.

Absolutely! I've always thought httpd should be able to do something like
this.

But are we not already there? Wouldn't
DirectoryIndex index.html index.cgi
suffice?
Or even
DirectoryIndex index.html /cgi-bin/4dos.pl
?
Question: can DirectoryIndex be set in the .htaccess file?

David.

Brian wrote:
>On Tue, 11 Apr 1995, Robert S. Thau wrote:
>> WRT downloading .htaccess files, one approach might be to have a
>> TotallyIgnore directive, along the lines of IndexIgnore, which would
>> direct the server to behave as if files which matched the relevant
>> regexp's were not even present, if a client asked to retrieve one.
>> ...
>This has my support - code away!

Or how about a magic mime type text/x-server-ignored ?

David.

Mark wrote:
>> DirectoryIndex index.html /cgi-bin/4dos.pl
>But 4dos.pl doesn't know which directory to index. ...
Yes it should; SCRIPT_NAME might be the requested URL, and if not it would
be easy to have a convention of putting the URL as the PATH_INFO.

David.

Date: Wed, 12 Apr 95 12:50 BST
From: drtr@ast.cam.ac.uk (David Robinson)

Or how about a magic mime type text/x-server-ignored ?

David.

Unfortunately, some of the patterns you want to ignore don't
necessarily take the form of .foo extensions --- for instance, I don't
*think* that

AddType bogus/null-and-void ~

would actually cause httpd to recognize foo.bar~ as bogus/null-and-void.

rst

Rst wrote:
> Yes it should; SCRIPT_NAME might be the requested URL, and if not it would
> be easy to have a convention of putting the URL as the PATH_INFO.
>
>I think the point is that scripts used as index generators *would* have
>to be special-cased somehow... given that, I think the earlier suggestion
>for an IndexGenerator directive is probably the best way to handle it.
>(Besides, having "server-absolute" URIs in a DirectoryIndex directive
>just looks a bit weird...).

You may be right that an IndexGenerator directive might be better.
But in general I prefer to adapt existing directives (in ways that are not
too counter-intuitive) rather than create new directives.

Actually, I got it wrong. If DirectoryIndex could take paths, they should be
server filenames, not URIs. But I can think of one use already;
DirectoryIndex /httproot/messages/noindex.html
would send a page which explained how directory indexes were disabled.
It could even be a .asis file with a Status: 400 line...

David.