Hello again!
Sorry for not writing so long, and please excuse our being such a pest
about this.
You probably have overseen the remaining questions in our last email.
The mod_auth_socache way should indeed work, but is a work-around, not a
fix. We would like to fix the situation for the benefit of all httpd users.
Using show_forbidden does not work, because the subrequest is fired
anyway, including re-authorization. From what we (us three) can see in
the code, the subrequests are pretty much needed, for example for
find_title(), find_icon() and find_alt().
The most promising and hopefully also un-intrusive way in our opinion is
to fix the per_dir_config comparison in ap_process_request_internal()
that should optimize out the unnecessary re-auths.
We wrote (Fri, 18 Mar 2011 03:23:01 -0700):
> The comparison
> (r->main->per_dir_config == r->per_dir_config) never succeeds
> [...]
Nick Kew wrote (Fri, 18 Mar 2011 03:46:05 -0700):
> It does if the configurations to r and r->main are not the same.
From looking into the debugger, the _content_ of the per_dir_configs
is, in our case, the same. The memory location is not. So the ==
operator returns false.
In server.c we find this:
/* Skip authn/authz if the parent or prior request passed the authn/authz,
* and that configuration didn't change (this requires optimized _walk()
* functions in map_to_storage that use the same merge results given
* identical input.) If the config changes, we must re-auth.
*/
Might this be relevant for us? Do we have to modify a _walk() or
_merge() function? Can you give us a hint where to look?
Thanks again!
