Thank you for your prompt reply! And your two fine suggestions.
On 18/03/11 11:45, Nick Kew wrote:
> On 18 Mar 2011, at 10:22, PlagiaTUM wrote:
>> With a little profiling we found out that authentication is done
>> for every subrequest, of which mod_autoindex uses plenty.
>
> You have two good solutions to that. Either use the ShowForbidden
> option to mod_autoindex, or use mod_authn_socache.
We did not know about mod_authn_socache; It is not in 2.2. Sorry for not
looking more thoroughly. Sounds like a sensible addition from our
perspective!
For our case, we cannot confirm that ShowForbidden helps at all.
The mod_autoindex code (looking at 2.2 trunk) looks like the subrequest
is done anyways; with ShowForbidden it is just ignoring its return value.
We can create a patch for mod_autoindex if you'd like us to.
We were hoping to fix the issue a level below that, possibly catching
more than just the mod_autoindex module in the process.
>> There is some logic in ap_process_request_internal() that should
>> optimize these out; however, it does not work for us. The
>> comparison (r->main->per_dir_config == r->per_dir_config) never
>> succeeds as ap_merge_per_dir_configs() always returns a new
>> configuration vector.
>
> It does if the configurations to r and r->main are not the same.
Yes, but can the pointer ever be the same?
request.c (2.2 trunk), lines 169ff:
> /* Reset to the server default config prior to running
> map_to_storage */ r->per_dir_config = r->server->lookup_defaults;
Just a page down of that file, the comparison is done:
same file, line 204
> if (r->prev && (r->prev->per_dir_config == r->per_dir_config)) {
Also, the comments in the source code above indicate that the pointer
equality is reached by having ``optimized'' _walk() functions:
> /* 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.)
That sounded like a fruitful way to go, but we didn't understand what to
do. Are these _walk()s ``optimized'' already?
Please excuse our being so stubborn about this.
Greetings from Munich!
--
PlagiaTUM is Heike Muni, Thomas Kittel and Florian Sesser.
Messing with others' code when we should be studying.
