On 11/08/2005 01:36 AM, Roy T. Fielding wrote: > On Nov 7, 2005, at 3:03 PM, Ruediger Pluem wrote: >
[..cut..] > >> but the next request for this (fresh) resource will not check the >> access control and >> deliver it to any client, regardless of the IP. Correct? > Many thanks for sorting my confused thoughts. > > The forward proxy would deliver it to any client that had the > ability to GET from that proxy. > And this actually depends on if the resource requested by the client has been already cached or not. If it has not been cached things like <Proxy *> order allow,deny allow from 192.168.1.10 </Proxy> work as expected (access to the proxied resource is only granted to 192.168.1.10). But once the resource has been cached by mod_cache access to it is granted to *every* client, because the access checker has not been run when the quick handler decides to deliver the (fresh) content by inserting the CACHE_OUT filter and kicking the filter stack. Although this is not a regression to 2.0.x (is it one to 1.3.x???), it is a weird behaviour from the users perspective. Even more as http://httpd.apache.org/docs/2.0/mod/mod_proxy.html#access suggests to secure a forward proxy by using mod_authz_host. Currently the advice should be the opposite: Yes, secure your forward proxy, but do *not* do this with mod_authz_host as it does not work as expected. Nevertheless I regard this discussion as very useful with respect to caching reverse proxies or other cached local resources that are under access control. That said I come back to the starting point of this discussion: I think Paul's patch to make it configurable where to run the cache handler is currently the best proposal on the table, provided that it is configurable in a way that expresses what it does from the users perspective. So I would regard something like CacheRunQuickHandler as a bad idea. I would have something in mind like CacheDisableAccessControl (ok the flaming can start :-). Regards Rüdiger
