www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: config/1941: AllowOverride ignored in <Directory ~ pattern> and <DirectoryMatch pattern>
Date Fri, 27 Mar 1998 09:00:01 GMT
The following reply was made to PR config/1941; it has been noted by GNATS.

From: Dean Gaudet <dgaudet@arctic.org>
To: Mike Brudenell <pmb1@york.ac.uk>
Cc: apbugs@apache.org
Subject: Re: config/1941: AllowOverride ignored in <Directory ~ pattern> and <DirectoryMatch
pattern>
Date: Fri, 27 Mar 1998 01:20:22 -0800 (PST)

 You sure do like to create complex configurations!  Honestly I'd be afraid
 of the number of potential errors even if Apache were bug free.
 
 On 25 Mar 1998, Mike Brudenell wrote:
 
 >  The reason, of course, is "obvious" after the umpteenth re-reading of the
 >  manual pages...  Apache FIRST processes <Directory> and .htaccess files
 >  (with the latter overriding the former) and THEN pattern matches set with
 >  <DirectoryMatch>
 
 Without this ordering it is impossible to optimize the directory walking
 process.  You would end up with an O(NM) process where N is the number of
 <Directory>/<DirectoryMatch> sections and M is the number of directories
 in the path to be examined.  This is how 1.2 and earlier behave.  1.3 on
 the other hand is O(N+M)... a situation I find far more appealing. 
 
 I suppose there's another option too -- O(N'M + N'') where N' is the
 number of DirectoryMatch sections, and N'' is the number of Directory
 sections.  I still find this ugly. 
 
 >  Personally I still find this ordering not terribly intuitive...
 
 There's a reason for it that I can't remember right now.  You can argue it
 both ways. 
 
 >          <FilesMatch "*">
 
 Depending on the regex library that could be a bogus regex... I think you
 want ".*". 
 
 >  *   If I instead set the htdocs tree to "AllowOverride Indexes" I would
 >  expect
 >      this to NOT allow the request at all (not even ask for athentication)
 >      because an .htaccess file is supposed to only allow "allow" if and =
 >  only
 >  if
 >      "AllowOverride Limit" is in force, (likewise "require" if and only if
 >      "AllowOverride AuthConfig" is set).
 >  
 >      But instead the request IS honoured (subject to authentication).
 
 It should actually give you a 500 error because the .htaccess file is
 malformed.  But to be honest, I can't follow any of what you said, and if
 you want me to look at it further then please send a MINIMAL configuration
 file (i.e. less than 25 lines) and .htaccess file which show this
 behaviour.  It's far easier for me to look at a config file than it is to
 follow a long string of "suppose this" and "then change that"s...
 
 >  This suggests that setting "AllowOverride Indexes" for an area correctly
 >  prevents "allow", "require", etc from working if they are "loose" within =
 >  an
 >  .htaccess file, *BUT* (surely wrongly?) allows them if they appear within =
 >  a
 >  <FilesMatch> section in the .htaccess file.
 
 <FilesMatch> are dealt with after all <Directory>s and .htaccess files. 
 It's entirely possible/likely that some other directive is changing the
 AllowOverride again before <Files> are dealt with. 
 
 I will readily admit that the whole process is terribly confusing, and
 subject to many errors.  Which is why I try to KISS in my own configs. 
 Unfortunately I've yet to figure out a way to make the whole process
 magically simple or easily debuggable.  Pretty much every time we get a
 report like yours it ends up being "oh yeah that's expected behaviour
 because you've got some little thing hiding somewhere in some other config
 file which you forgot about". 
 
 Dean
 
 

Mime
View raw message