httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: [Patch]: PR 3454, PR 3019. .htaccess ignored in <Directory ~ "reg-ex"> directories.
Date Thu, 05 Aug 1999 20:11:41 GMT
On Thu, 5 Aug 1999, Rodent of Unusual Size wrote:

> Dean Gaudet wrote:
> > 
> > > I can't find that behaviour documented.  Even if it is, at
> > > first blush I consider it broken -- if the only <Directory*>
> > > container you *have* is a regex one, not processing .htaccess
> > > files in matching directories is counterintuitive and (IMHO)
> > > bogus.
> > 
> >
> > 
> >     If multiple (non-regular expression) directory sections match the
> >     directory (or its parents) containing a document, then the
> >     directives are applied in the order of shortest match first,
> >     interspersed with the directives from the .htaccess files.
> IMHO, that hardly documents the fact that .htaccess processing
> *isn't* done for regex containers.

Then reword it.  But it does say (non-regular expression).  And then it
goes on to explain the ordering in which the regex ones are handled, and
even has this little blurb:

    In Apache 1.3 the regular expression isn't considered at all at that
    point in the tree. It won't be considered until after all normal
    <Directory>s and .htaccess files have been applied.

Which seems fairly explicit to me...

> My point is that saying that those two specific cases don't
> need regexes hardly allows us to assume that *all* <Directory*>
> cases can be reasonably represented w/o regexes.

My point is that I don't care.  Until someone shows me a configuration
which is not possible to implement, and which has the potential to have
wide-spread usage, then why would we want to make this whole thing go
even slower?

It's fine if you think this behaviour is broken.  Now go and fix it
properly, and don't make things any more slow than they already are.
The patch proposed fails to fix things -- it only handles a single
.htaccess file, it doesn't go about recursing to find the rest of them.

Prior to 1.3 we paid O(n*m) for each directory scan -- where n is
the number of components in the directory path, and m is the number
of <directory> containers.  This is bloody expensive!  It's fine for
people with a handful of <Directory> containers, or short pathnames,
but sucks rocks for anyone else.  I changed it to be O(n+m) in 1.3.


View raw message