httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <>
Subject Re: Let's get rid of .htaccess files :-)
Date Thu, 18 Jul 1996 13:31:06 GMT
> >  > I guess the question would then be as to how you identify .htaccess
> >  > files. Do you look for them at startup? If you have a lot of
> >  > directories, that could take a while. I suppose it could read each in
> >  > once, the first time. (it'd have to also store then which directories
> >  > *didn't* have .htaccess files, to avoid the extra stat for each request).
> > 
> > The obvious optimistation to make first would be to parse them all
> > at startup and hold them in an internal structure and then do a stat
> > on the file at each access rather than a full parse. I suspect that in
> > itself would be a considerable performance boost. If the file's newer
> > than it's cached contents then re-parse it.
> On large systems, I am not sure it is a good idea to go hog-wild like that
> and search the entire disk for these things.  You would need to search 
> through every ~user/public_html tree as well, and on a lot of boxes this
> could be many thousand directories.  Perhaps an option to read a list of
> top-level directories to search would speed this up a bit.
> -Rasmus

One of my goals in this was to move the .htaccess files out of the
webspace to improve security and prevent corruption of these files.
Secondly, by creating a standard format like this, it would make it
very easy to write configuration interfaces. By creating a separate
conf/ tree, we reduce the depth of directories we need to search.

I'm playing with a format that would be as follows:

conf/      <-- toplevel config "database"
.htconfig  <-- contains and global config info	
    /   <-- each of directories contain Vhost info
    /   <-- the docroot directory structure would
    /   <-- be mirrored _only_ where there were .htacces

You would only need to parse the tree at startup and SIGHUP.
It would be very easy to have a separate daemon watching the
conf/ for changes and sending a SIGHUP when needed. The conf/
could even be a DBM format file, however I prefer the idea
of leaving it accessible by basic system tools like 'vi'.
Hell, I could even imagine an Emacs mode for configuring the
server! :-)

My suggestion that you could point conf/ at the DocumentRoot was
really only for backward compatibility and perhaps a mode that
would allow you to easily build a conf/ from the existing webspace.

View raw message