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 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
  registry?

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

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.

rst






Mime
View raw message