httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Robert S. Thau)
Subject Re: Let's get rid of .htaccess files :-)
Date Fri, 19 Jul 1996 02:27:09 GMT
  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

It's *incompatible*.  Something like that might be a good solution to
transition to over the long term.  It would be unacceptable to impose
it suddenly, by fiat.  

BTW, there are namespace issues --- if a directory is symlinked to
from three different places, the .htaccess file placed in that
directory will cover all of them.  A central <Directory> will only
cover that *particular* path to the directory in question.

This is one of the reasons that I think it would probably be best to
key a central config registry off of <Location> and not filesystem
location --- it doesn't imply capabilities that the registry hasn't
got.  (The other biggie is that it generalizes more easily to data
which is back-ended on something other than a filesystem entirely ---
the database issue.  <Location> makes sense for that kind of data;
<Directory> may not.  This wouldn't solve *all* the db-backend
problems, of course, but it would be a step in the right direction).

  > 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 don't have any quarrel with that notion at all.  I have a problem
with using it to replace .htaccess files immediately, without allowing
my users (and everyone else) a good, long, graceful transition period.
And I keep on getting the impression that you're talking about doing
that.  F'rinstance, take this:

  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.

As I have explained before, "looking for them on every request" *is*
the current .htaccess mechanism, and anything that reduces that
overhead (which is real, and which I have acknowledged) is an
incompatible replacement for it.  I know perfectly well that a central
config registry read at startup would have lower overhead than the
current machinery --- but only once we've turned the current .htaccess
machinery off completely.  So, it seems to me that you are advocating
doing that here.

And it is *that* *suggestion* to which I am reacting so strongly ---
the suggestion of dropping the current .htaccess mechanism in favor of
something incompatible (even if it has less overhead, or other
potentially attractive features) without a graceful transition period.

Now, if you're talking about getting rid of the overhead only after
a graceful transition period, then it turns out we're just agreeing
heatedly (one of the unfortunate phenomena that plagues technical
discussions --- email makes it worse, but I've had it happen plenty
of times f2f).  

*However*, if that is the case, then you could make things easier
by making this clear when the subject of overhead, or the current
.htaccess mechanism generally, comes up.


View raw message