On Fri, Aug 2, 2013 at 8:24 PM, Mikhail T. <mi+t...@aldan.algebra.com> wrote: > The modules in your examples deliberately use the authz mechanism to > generate different output based on the results. But what is doing it in the > case I describe -- where the generated content is exactly the same?
Obviously nothing is doing a subrequest to validate the auth, they're doing sub-requests to fulfill the original request. httpd is doing the auth because it's the right thing to do from a security perspective. The generated content is not the same. The main request has no generated content it's essentially a redirect, it just happens to be handled internally. > Why would anyone want to provide distinct authorization rules to /foo/ and > /foo/index.html, for example? What is a possible use-case? They are different paths they may have different auth rules. httpd can't assume that it'll be okay. Keep reading and I'll explain why. > Likewise, why would anyone configure mod_fastcgi to hand off processing of > PHP-files to FPM: > > FastCGIExternalServer /usr/sbin/php-fpm -socket /var/run/fpm/main.sock > AddHandler php-fastcgi .php > Action php-fastcgi /php-fpm > ScriptAlias /php-fpm /usr/sbin/php-fpm > > but need the /php-fpm/foo/ to have authorization rules different from those > of /foo/? You don't seriously expect the auth system to know all of those intricacies? It has no idea why the subrequest is being made it just knows there's a request to process. Even if it did know why the subrequest is being made the variety of authz systems doesn't allow you to make assumptions like the above. In 2.4.x there's the new provider architecture that at least lets you optimize away subrequests that have the same conf. But the modules have to say it's ok because if the modules are handling path based matching on their own then even httpd has no idea if /foo and /foo/index.html have the same configuration. mod_authz_svn is an example of such a module that could not use the CONF flag (but at this time it isn't using the new provider system and is still using the old hooks system). given that there are authz modules like this you can't even make the argument that we can ever assume that authz isn't necessary 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.
