httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: internal data format critical to api/config issue
Date Wed, 11 Jun 1997 09:15:53 GMT
On Tue, 10 Jun 1997, Marc Slemko wrote:

> Really unrelated to this, but two things I would like to see are expanded
> security abilities, so control over commands is far more fine-grained and
> the ability for users to specify startup-time config files; like .htaccess
> files, only they are only parsed at startup or at certain intervals.  Of
> course good caching of .htaccess files (erm... more likely the parsed
> structures resulting from them) could perhaps accomplish much of that
> without the pain.

There is already a per request cache of htaccess files, see
parse_htaccess().  I've also got the basis of a "directory contents cache"
designed, something which caches the only data we use from readdir().

Oh btw, as the code is presently written, it's not necessarily true that
"AllowOverride None" is a performance win.  The loop in directory_walk
is iterated O(n*m) where n is the number of directory sections, and m
is the number of components in the filename.  Whereas with no directory
sections, and using htaccess you can reduce that to O(m).

We should be able to reduce the "AllowOverride None" case to something
like O(lg n) by doing a pre-merge which lets us search only for longest

We should also be able to reduce the combined htaccess and <Directory>
case to O(n + m) by partitioning the <Directory>s by the number of
components in each.

Oh yeah, arbitrary wildcards (and regexs) screw all of that up :)  But if
we had a wildcard ^ which matched exactly one component we could still do
cute stuff... I'm thinking of cases like <Directory /home/*/public_html>.

Every time I walk down this path I think of how it'd be cool to compile
the <Directory>/<File>/<Location> sections into a lex grammar and generate
a pattern matching engine.


View raw message