httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch>
Subject Re: AuthN only once per request instead once every subrequest
Date Tue, 24 May 2011 19:29:12 GMT

On Tuesday 24 May 2011, PlagiaTUM wrote:
> 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.

There may already be something for you in 2.3:

Can you try if 2.3.12 or the version from svn trunk fixes your 

I fear these changes will never be backported to 2.2.x, because they 
are way too intrusive. But 2.4.0 will hopefully come real soon now 
(tm). We would be really interested to hear about your experience with 

> 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?

The above commit contains some modifications of the _merge() 
functions. I have not looked at them more closely, though.
The commit message contains a link to some mailing list discussion, 
maybe that helps.


View raw message