httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: Let's get rid of .htaccess files :-)
Date Thu, 18 Jul 1996 23:43:27 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.

     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.

  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.  

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 --- 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.

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.

  * 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






Mime
View raw message