httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject Re: apache
Date Sat, 08 Apr 1995 18:42:58 GMT
On Sat, 8 Apr 1995, Mark J Cox wrote:
> On Fri, 7 Apr 1995, Brian Behlendorf wrote:
> > Sort of like an AddDescription but set on a per-directory basis like 
> > .htaccess... what about allowing AddDescription in .htaccess?
> I (and several others who run Web sites) already have these description
> files in a certain (standard) format.  The file consists simply of a line
> per file containing the filename, any amount of whitespace, and the
> description.

Ah, okay.  This introduces overhead in checking for the existance of the 
file, but that's only introduces when an index is being created anyways 
(which has its own amount of overhead) and is only done in that one 
directory (rather than checked for in every directory like .htaccess).  
Okay, I'd support a patch like this in theory.

> > (indeed, we have them here) where those who want to be able to edit the
> > .htgroup file do not also have access to modify the password files.  
> Well lets make a separate group DBM file for it then.  I would imagine
> then that your 160,000 users are not in a default group?  Parsing a
> standard .htgroup file with a few thousand entries takes forever.

Right, I don't have the 160K in a group at all, I simply have

<Limit GET POST>
require valid-user

I would support turning the htgroup files into DBM files as well, where 
the key is the user and the group is the value.  

> Wish-list:
> A way of storing an objects information in a separate file (things you
> might find in the Head or Header like Expiry, Owner...).  Like the CERN
> .meta files.  You could include a global realm here too (see below)
> Disadvantage is you are adding another file to look for on each request. 

Have you ever looked at GN (or WN)? is the 
home for it - its model is based on only serving files that exist in a 
per-directory menu file, and in that menu one can specify all these 

Better yet, as suggested on new-httpd a little while ago, why not have a 
new file type recognized by the server to have its own HTTP headers, 
which the server then dishes out and labels text/html (a la .shtml files).

AddType text/html-with-headers .asis

The problem is that this isn't a general solution, i.e. it won't work for 
GIF's or any other non-text file format (well, it could, but the creation 
and modification of a GIF file once it has text garbage stuck to the 
front would be a pain).  The overhead would involve a stat() for every 
access and a file-read-and-interpret if a .meta file existed.  If this is
a run-time configuration (a la the .htaccess check) then I might support 

> Global realms for password authentication.  You define a realm, (name, who
> can access it, location of password file) and just have the realm name in
> the .htaccess file.  Would make updating and management easier.  I think
> CERN does something like this, and it allows you to say things like ".y"
> extensions are only accessible by "XYZZX" realm. 

Good optimization... 

> Host Authentication Fall-back.  If you use host authentication to limit
> some documents locally you can provide a "fall back" document if the host
> is not allowed.  I bodged something like this with a "-fail" extension. 
> It the host was not allowed the -fail document was returned if it was
> there.  If no -fail it failed as normal.  This could be something for
> MultiViews

I'm wondering if we're going to bury ourselves with file name extensions 
here :)  It sound like custom error responses almost meets your needs, if 
it were configurable per directory that's almost all the way.



View raw message