Return-Path: owner-new-httpd Received: by taz.hyperreal.com (8.6.10/8.6.5) id LAA17324; Sat, 8 Apr 1995 11:44:50 -0700 Received: from get.wired.com by taz.hyperreal.com (8.6.10/8.6.5) with ESMTP id LAA17319; Sat, 8 Apr 1995 11:44:49 -0700 Received: by get.wired.com (8.6.12/8.6.5) id KAA26211; Sat, 8 Apr 1995 10:42:59 -0800 Date: Sat, 8 Apr 1995 10:42:58 -0800 (PST) From: Brian Behlendorf To: Mark J Cox cc: new-httpd@hyperreal.com Subject: Re: apache In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-new-httpd@hyperreal.com Precedence: bulk Reply-To: new-httpd@hyperreal.com 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 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)? http://hopf.math.nwu.edu/ 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 attributes. 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). i.e. 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 it... > 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. Brian --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/