Message-Id: <199607182226.RAA18713@sierra.zyzzyva.com>
To: new-httpd@hyperreal.com
Subject: Re: Let's get rid of .htaccess files :-) 
In-reply-to: mikedoug's message of Thu, 18 Jul 1996 16:57:45 -0500.
         <Pine.SUN.3.94.960718165415.19866L-100000@millenium.texas.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 18 Jul 1996 17:26:37 -0500
From: Randy Terbush <randy@zyzzyva.com>
Sender: owner-new-httpd@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

> On Thu, 18 Jul 1996, Randy Terbush wrote:
> 
> > The reasoning for using the filesystem was to use the system's
> > built in access control to control who has permissions to edit
> > config files. If the ownership of the conf/ directory tree mirrors
> > that of the webspace, the problem is solved. From the standpoint of
> > writing a configuration tool, it seems that locking issues etc. 
> > become much less of an issue.
> 
> So you want to create another file system structure that mimics the
> webspace, and place the .htaccess information there?  What exactly is
> the purpose here?  Is your purpose to prevent the web server from
> parsing htaccess files on each access (trying to rid the overhead of
> reading in the file from the disk?)?  Why not keep the information in
> the webspace (why mimic it?) and simply read them in at start time from
> there?  I can't see a use for having a seperate directory tree.  The
> primary access.conf file already controls *what* the individual user
> can override, so the issue can't be one of security.
> 
> Absolutely confused,

The purpose is to remove them from prying eyes, put them in a place
that requires users to edit them in an environment that validates
the input and create a configuration mechanism that would allow us
to stop having to hunt for .htaccess files on every request.

This model would also allow you to keep the .htaccess files in the
webspace. Your choice.