DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=43196>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43196 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID ------- Additional Comments From [EMAIL PROTECTED] 2007-08-28 10:52 ------- I believe this has nothing to do with LDAP, and is a configuration error. The configuration includes an authn/authz block in <Location /> as well as one in .htaccess (in a <FilesMatch> section). Since <Location> is merged after <FilesMatch>, the <Location /> block will be at the end of the merge. It should be noted that the merge of "Require" directives simply uses the Require directives of the last-merged block which contains a Require. Consequently, it is not possible to build up Requires by merging two blocks. Although the <Location /> block presented above has a 'Require ldap-attribute' directive in it, I suspect that the configuration actually used to generate the debugging output did not have that directive, and that the only require directive in the <Location /> block was "require valid-user". That's consistent with the debugging output, and demonstrates that the <Location /> block was merged last (in the second debugging run, with a direct url to the file); the request succeeds since the userid has been authenticated. This leaves the question of why mod_autoindex denied access to the file when creating a directory listing. The answer is that mod_autoindex does a ap_sub_req_lookup_dirent() to check the file; as far as I know, that version of sub_req does not do a <Location /> merge. If there is a bug here, it's a documentation bug; the documentation for <Location> correctly states: Use <Location> to apply directives to content that lives outside the filesystem. For content that lives in the filesystem, use <Directory> and <Files>. But then goes on to say: An exception is <Location />, which is an easy way to apply a configuration to the entire server. As can be seen here, attempts to use <Location /> for the purpose of applying a default configuration to the entire server are likely to fail, and the documentation possibly should be tightened up. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
