Hello, again. We're making progress; I think I've decided what the actual
bugs are. :) Please let me know if you disagree. On certain requests, such
as requests which ask for directories and require the aid of
DirectoryIndex, lookup_uri() is called. This call creates a subrequest
that appears as if it is a new one up until the content handler phase.
>From the eagle book, pages 452-3:
lookup_file() and lookup_uri() invoke Apache
subrequests. A subrequest is treated exactly
like an ordinary request, except that the post
read request ... [is] not run... lookup_uri()
performs the URI translation on the provided
URI, passing the request to the access control
and authorization handlers, if any...
The bugs, I believe are the following two:
1) set_handlers() doesn't do what it claims except with respect to using
undef. If you add handlers in, it is ignored, at least if the handlers you
are trying to add are in the same phase the handler from which you are
calling set_handlers(). This bug is evident in the error log snippet
attached. It shows that, even though I call set_handlers twice in a row,
once to clear the stack and once to add the AuthzCache::dummy handler, the
dummy method in fact is not added as shown in the subrequest. I've also
attached the AuthzCache code with the debug statements included.
2) The subrequest's handlers stack is not reset to what it was when the
initial request began. It is whatever is left from the initial request's
processing up to the point that the subrequest launched. Here's the
important steps that occur when I request a directory URL (ie, /foo/).
1) AuthzCache runs and has a hit. It clears the
all handlers in the phase and returns OK.
2) lookup_uri() is called and the first name in
DirectoryIndex is examined.
3) While running through the phases for this
subrequest, the PerlAuthzHandlers is empty.
4) The subrequest completes with what I presume
is an AUTH_REQUIRED error, since the user
didn't match the required group.
5) Steps 2 through 4 are called for all
DirectoryIndex files. The server finally
returns the directory contents instead.
The second bug may not be a bug, per se, but while it functions like it
does, I don't see any way to do what I want while the first bug with
set_handlers exists. If I could set_handlers(PerlAuthzHandlers =>
[ \&OK ]) and the handler stack would actually be modified, I'd be set.
I'll keep banging away on this problem, but I'd appreciate hearing from
y'all whether you can reproduce my problems and whether you believe I'm
right with respect to the analysis of the problems.
Regards,
Christian
> -----Original Message-----
> From: Christian Gilmore [mailto:[EMAIL PROTECTED]]
> Sent: Friday, July 07, 2000 3:34 PM
> To: Modperl Mailing List (E-mail)
> Subject: More on the set_handlers() / push_handlers() bug...
>
>
>
>
> Hello, again.
>
> Here's a quick summary of the problem: upon clearing the
> stack of handlers
> (with set_handlers(PerlAuthzHandlers => undef)) the server
> appears to not
> recognize when it has found a DirectoryIndex file and returns
> the contents
> of a directory instead of the index file.
>
> Since last writing on this topic, I upgraded to all of the
> newest versions
> (apache-1.3.12, perl-5.6, mod_perl-1.24) and configured mod_perl with
> PERL_TRACE=1. Looking at the error_log with the handler
> tracing on and
> httpd
> running in single-server mode, I discovered that the server
> does appear to
> cycle through the directory indexes, but doesn't realize when
> it has found
> one. I've attached two error logs for the request
> http://dw3.tivoli.com:81/home/passwd/group/: one with the
> cache enabled,
> one
> without. I've also attached a copy of the document returned
> by the server
> for the with-authz-cache request. The document is the auto-generated
> contents of the directory. As you can see, index.phtml does
> exist in the
> directory and is the first file searched for by the server.
>
> Does anyone have any ideas here? Can anyone reproduce the
> problem? I've
> also
> included the source for the AuthzCache and AuthzLDAP. If
> anyone could use
> at
> least the Cache code and see if you could reproduce the
> problem, I'd really
> appreciate it.
>
> I noticed that the error log with the cache enabled shows
> that subsequent
> internal requests (such as those you see when requesting a directory
> instead
> of a named file) don't reset the handler stack to what is in the
> configuration. See about line 65 of each log file for this difference.
>
> Regards,
> Christian
>
> -----------------
> Christian Gilmore
> Infrastructure & Tools Team Lead
> Web & Multimedia Development
> Tivoli Systems, Inc.
>
> - AuthzCache.pm
> - AuthzLDAP.pm
> - group-dir.html
> - error_log_with_cache
> - error_log_without_cache
AuthzCache.pm
error_log_with_cache
