On 27 Sep 2010, at 1:44 PM, Igor Galić wrote:
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...
I'm not entirely sure what purpose would be served by
touching .htaccess at all.
.htaccess files are what they are, a way to configure the server at
request time. For obvious reasons, with a server where the
configuration is parsed on startup and then shared amongst all
children processes using copy-on-write, any attempt at configuring the
server at request time will be significantly slower by definition.
Giving an unprivileged user the power to change the config of the
server has security implications again by definition. But on the other
hand, configuring at request time may be the only choice an admin has,
and .htaccess is a very simple solution that fills that bill.
The strength of the httpd server lies in it's ability to be
customised. If your particular usecase doesn't require .htaccess,
simple switch them off and don't use them. We've had alternative
config mechanisms for years, such as the ability to configure the
server from mod_perl, I don't see any reason why mod_lua can't work
right now in addition to everything else, or why any support of lua
has to have anything at all to do with .htaccess.
I am wondering however why there is a "use X instead of Y" meme
floating around, instead of the far more practical "offer X in
addition to Y". Let end users use X if they want to. X doesn't need to
be shipped by default with httpd if it's particularly large.
Having looked at the config mechanism in the past, the interface to
the mechanism could probably be improved. Rather than the hard coded
idea that a "file" is being parsed (in the form of a file descriptor),
it would make far more sense that a generic callback function was
provided that said "give me one line of config, I shall parse it". How
those lines came into existence (read from file, generated as output
of a lua script, bash script, perl script, database lookup, etc etc
etc) becomes less important.
Regards,
Graham
--
