Am Freitag, 2. August 2013, 23:05:09 schrieb Ben Reser: > If all of your authz/authn providers are using the CONF flag and > you're getting duplicated authz processing for subrequests that have > the same conf applied to them then it's possible there's a bug > here. I haven't ever specifically looked at this code so I can't > tell you how it works, all I can do is tell you what the > documentation says it does. Unfortunately I have other priorities > right now so I don't really have the time to go down that rabbit > hole and find out if there is a bug that's causing extra authz > calls. > > Any attempt to optimize when authn/authz happens on subrequests is > going to have to be done very carefully since you really can't make > any assumptions about what should be allowed. I realize that in > your specific case that seems absurd but the httpd core code > supports use cases that are very different from yours.
The AP_AUTH_INTERNAL_PER_CONF / AP_AUTH_INTERNAL_PER_URI switch has a design flaw in that modules cannot decide which flag to use dynamically, depending on the modules' configuration. Instead, if any module using AP_AUTH_INTERNAL_PER_URI is loaded, httpd will call the auth hooks for every URI, even if the respective module is not enabled by configuration. It would be much better if that flag was a runtime setting that could be switched on only if needed, on a per vhost basis. AFAICS, the only module shipped with httpd that uses AP_AUTH_INTERNAL_PER_URI is mod_log_debug, where I have assumed that the ability to inject trace messages for every subrequest is more important than performance. Not sure if that was a good idea. Do you have mod_log_debug loaded? If yes, try if things change if you don't load it.
