On Sep 27, 2010, at 7:44 AM, Igor Galić wrote:
Hi folks,
I remotely remember that we briefly touched this topic on IRC, but
I'd really like to
bring this to the lists attention:
.htaccess is one of the features that have guaranteed httpd's
success in the past, and
at the same time it's the single biggest clutch imaginable. It's a
support nightmare,
exploit vector and a performance bottleneck.
Most competing products don't have such a thing either, and if
needed, solve it via
scripting: http://diaryproducts.net/about/web_servers/lighttpd/htaccess_lighttpd
(first hit in google, I'm sure you can do better)
I'd like to discuss the possibility to either disable the use
of .htaccess at
compile time, or alternatively concentrate it into a module.
With mod_lua in place, people who chose to, could use yet a
different way for
per-dir configs, I suppose...
As much as we dislike .htaccess files, they certainly seem to be a
necessary evil. You *can* disable them (although not at compile time),
but this is simply not an option for many folks. Educating them when
it's better to use the main config than .htaccess files is the job of
documentation, and we've done a somewhat poor job of that. Perhaps
that can be improved. The largest problem here is the *HUGE* number of
third-party sites peddling bad advice, and I honestly have no idea how
to address that problem.
It's been frequently suggested that .htaccess files could be improved
via some kind of "cache and only reload if the timestamp has changed"
mechanism, but in my benchmarking, simply stat'ing a .htaccess file
(even in cases when there's no file there to begin with) accounts for
an awful lot of the performance hit of "AllowOverride All", so I don't
know whether this would really be a solution.
For the most part, folks who need to use .htaccess files are not in a
position to really do much in the way of performance tuning, and vice
versa.
--
Rich Bowen
[email protected]
