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 Fri, 19 Jul 1996 01:13:26 GMT
>   Why can't we search for them once at startup and reread them when
>   SIGHUP'd?
> Because:
>   1) It's *way* too slow --- a 'find' on a large webspace, which is
>      what you're proposing, is likely to take several minutes.  This
>      is unacceptable for server startup or restart.

Not if it's done in a "registry" area where you are looking for one
filename. It's likely that in a "large" webspace, you have very few
.htaccess files relative to the number of directories/files. There
is no need to create these directories in the "registry" if they
don't lead to a .htaccess file.

>      At sites which have to use ~user/public_html functionality, it
>      gets even worse --- the server couldn't start unless all the
>      file servers were up.  This is unacceptable.

Only if the .htaccess files were _not_ stored in a "registry".

>   2) If users are used to having .htaccess file changes take effect
>      immediately, it will require a rain of SIGHUPs (and a substantial
>      amount of education) to duplicate that functionality.
>      Doing the SIGHUPs on some sort of scheduled basis means that
>      changes could not be tested more than once every half hour,
>      or whatever interval you choose, and an error inadvertently
>      introduced, no matter how critical, could not be corrected in
>      less than that amount of time.  Again, this is unacceptable.
> Some of these points go away if the per-directory configuration
> directives are moved out of the webspace --- but that is, from the
> users' perspectives, incompatible with the current .htaccess
> mechanism.

What is wrong with giving them a script or CGI to run in a directory,
(call it .htaccess) that opens the corresponding config file in the

> In any case, there's no reason why such a central config registry
> could not coexist with the current .htaccess machinery, exactly as it
> exists right now.  In fact, as far as I'm concerned, that's a
> requirement ---

Done. The small bit of code I uploaded last night accomplishes just

> I can't *use* a server which doesn't support .htaccess
> files exactly as they exist right now.  I can see transitioning my site
> off them over time if a better solution comes along, but that would have
> to be a *transition*, not a massive incompatible flag day.  That means
> supporting the current .htaccess mechanism *along with* a central config
> registry for at least one major release.

Jesus Christ!  Who said anything about turning them off? My
whole thought towards this has been that it was backward compatible.
One of your well founded crusades.

> In short, no sale.
>   * What I am suggesting would take advantage of the existing .htaccess
>     system as I see it.
> You are proposing to completely throw away the current .htaccess
> system.  You have, at this point, said so repeatedly.  I'm afraid that
> the way you also keep on denying it --- sometimes in the very same
> sentence --- is starting to give me an impression that you're in over
> your head.

Now look. I raised this topic for discussion. I don't expect it to
turn in public display of your dislike for me. Perhaps you can keep 
these comments to yourself and offer feedback pertaining to the
proposal and not my ability to carry it out.

To set the record straight, I have not once suggested that I am
going to dive into Apache and remove all reference to .htaccess.

What I have said is that I think that there is a way to provide
a configuration registry that would allow us eliminate the need
for .htaccess, or at the very least greatly reduce the overhead
of looking for them every request.

>   * I think that a configuration tool can be created that would allow us
>     to move the .htaccess files out of the webspace.
> I agree, and not hunting for files is one of the attractions of such a
> mechanism.  (It is a significant, known performance hit).  However, if
> you really want to replace .htaccess files, you need to design
> something which is at least as flexible --- meaning, in particular,
> allowing updates to take effect immediately, without being as
> disruptive to server operations as a whole as even a "gentle" SIGHUP.
> I don't think that's infeasible, BTW, but it is, pure and simple, one
> of the design constraints for any config mechanism which seeks to
> replace .htaccess files, and if that's your ambition here, then you
> might as well face up to it.
> rst

Perhaps some positive suggestions might help us arrive at what that
mechanism is.

View raw message