I propose that we fix this bug by documenting, very very loudly, that using mod_cache simply breaks mod_authz_host. A Large warning in the mod_cache documentation, the Caching User Guide, the output of configure when mod_cache is enabled, and the error log when mod_cache is loaded is what I'm thinking.
This issue has been known about for a while now, and in that time I've looked at seeing if it is possible to add logic to mod_authz_host to figure out the cases in which we have a tautalogical allow from all, but I don't see a way of accomplish this, and it's problem ridden anyway. Moving mod_cache to being an ordinary handler, instead of a quick handler has been brought up here before, and I don't think that's going anywhere. I can't see a way to fix this problem :/ On Wed, Oct 05, 2005 at 03:57:07PM +0200, [EMAIL PROTECTED] wrote: > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT > <http://issues.apache.org/bugzilla/show_bug.cgi?id=36937>. > ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· > INSERTED IN THE BUG DATABASE. > > http://issues.apache.org/bugzilla/show_bug.cgi?id=36937 > > Summary: mod_cache not respecting mod_access > Product: Apache httpd-2.0 > Version: 2.0.54 > Platform: Other > OS/Version: other > Status: NEW > Severity: normal > Priority: P2 > Component: mod_cache > AssignedTo: [email protected] > ReportedBy: [EMAIL PROTECTED] > > > our environment: > > SetEnvIfNoCase Referer ^http://host validreferer > > <Directory /> > Order deny,allow > Deny from all > Allow from env=validreferer > </Directory> > > if the object is not cached, using mod_cache and mod_mem_cache, it's returned > 403, however, if the object is already cached, it does not respect mod_access > and the object is served right away. > > example below > > - first request, invalid referer > GET /probe.gif HTTP/1.0 > Host: host > Referer: http://invalidhost > > HTTP/1.1 403 Forbidden > Date: Wed, 05 Oct 2005 13:47:24 GMT > Server: Apache/2.0.54 (Unix) > Connection: close > Content-Type: text/html; charset=iso-8859-1 > > - second request, valid referer > GET /algo.gif HTTP/1.0 > Host: host > Referer: http://host > > HTTP/1.1 200 OK > Date: Wed, 05 Oct 2005 13:52:40 GMT > Server: Apache/2.0.54 (Unix) > Last-Modified: Wed, 05 Oct 2005 13:52:37 GMT > ETag: "31-402621f003340" > Accept-Ranges: bytes > Content-Length: 49 > Cache-Control: max-age=315360000 > Expires: Sat, 03 Oct 2015 13:52:40 GMT > Connection: close > Content-Type: image/gif > > - third request, invalid referer > GET /algo.gif HTTP/1.0 > Host: host > Referer: http://invalidhost > > HTTP/1.1 200 OK > Date: Wed, 05 Oct 2005 13:54:27 GMT > Server: Apache/2.0.54 (Unix) > Content-Type: text/plain; charset=ISO-8859-1 > Last-Modified: Wed, 05 Oct 2005 13:54:20 GMT > ETag: "31-402622523db00" > Accept-Ranges: bytes > Content-Length: 49 > Cache-Control: max-age=315360000 > Expires: Sat, 03 Oct 2015 13:54:22 GMT > Age: 4 > Connection: close > > mod_cache configuration: > CacheEnable mem / > CacheDefaultExpire 21600 > CacheMaxExpire 21600 > CacheIgnoreCacheControl On > CacheIgnoreNoLastMod On > CacheDisable /nocache > MCacheSize 262144 > MCacheMaxObjectCount 4096 > MCacheMinObjectSize 1 > MCacheMaxObjectSize 100000 > MCacheRemovalAlgorithm LRU > > I already tried to change mod_access and mod_cache load order, but with no > results > > -- > Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Colm MacCárthaigh Public Key: [EMAIL PROTECTED]
