I am doing some work with Apache 2.2.3 (win32 and linux) and am running into some problems with CacheEnable and proxy requests. My ultimate goal is to cache only forward proxy requests (with mod_disk_cache), but right now I am running into problems with the basic scenario of just http proxied url's. The 2.2 CacheEnable documentation lists the following example: # Cache content from www.apache.org CacheEnable disk http://www.apache.org/ This works as expected (caches proxy requests to apache.org, but not others). If I then change it to: CacheEnable disk http:// My same proxy request to http://www.apache.org does not get cached on my server. The debug level error log does not list the cache save filter as ever being added (while it does when i use CacheEnable disk http://www.apache.org/), so I never am able to see why the request to the url was not cached. Should this not be cached? I see the same example in the CacheEnable 2.2 doc for proxied ftp requests (CacheEnable disk ftp://). I know an easy solution to caching only proxy requests would be to put the catch all 'CacheEnable disk /' in a virtual host - but I need to be able to cover the scenario of when a customer wants to only cache proxy requests, and specifies it in the server context. Should 'cacheenable disk http://' be caching all http proxy requests? How do you cache proxy requests to all protocols? Would I have to cacheenable for every protocol? This problem exists on win32 and unix 2.2.3 source.
Created attachment 18694 [details] (cache_util.c)Fix CacheEnable forward proxy when only protocol specified my fix is in uri_meets_conditions(). One line fix.
(In reply to comment #0) I have attached a proposed fix to this problem. Should work for all protocols.
Please provide a diff file of your fix for review (see also http://httpd.apache.org/dev/patches.html).
Created attachment 18695 [details] unified diff for cache_util.c Sorry bout that - 1st time patch submitter. Here is the unified diff file for the patch.
Please never change the assignment of bugs.
(In reply to comment #4) > Created an attachment (id=18695) [edit] > unified diff for cache_util.c > > Sorry bout that - 1st time patch submitter. > Here is the unified diff file for the patch. The patch is not general enough I think. The language in the documentation leads to me think that *any* subprefix matches. That "ht", "http:", "http://", "http://www.", "http://www.apa" all match "http://www.apache.org". So the "strcasecmp(filter.hostname, url.hostname)" should be replaced by "strncasecmp(filter.hostname, url.hostname,strlen(filter.hostname))" or equivalent. Actually this check should be applied to the whole URI, not just the 'hostname' part.
(In reply to comment #6) Agreed. I think the documentation could be worded a little better, and even the addition of a CacheEnableMatch could be handy. I think your suggestion is correct for the problem at hand though.
Created attachment 18889 [details] Fixes some issues in 'CacheEnable' and 'CacheDisable' matching and extends a bit the functionality.
(In reply to comment #7 and #8) > Agreed. I think the documentation could be worded a little better, and even the > addition of a CacheEnableMatch could be handy. I think your suggestion is > correct for the problem at hand though. Oh I got impatient with the matching logic and while I have not added 'CacheEnableMath' or 'CacheDisableMatch' I have rewritten and rather generalized the matching process by giving it comprehensible semantics. I found that the matching logic is passed not the URI but four distinct fields for scheme, hostname, port and path, so they are matched separately. Then I decided that the scheme should not be really prefix-matched. Among the changes: * Now a "/...." will not match a proxy URI like "http://...", and viceversa of course. * Prefix matching for hostnames does not make much sense, do I have added minimal suffix matching: "*w.example.com" will match any hostname ending in "w.example.com" and ".example.com" will match any hostname ending in ".example.com". All I have tested it a bit (I have removed the extensive debugging code from the submitted patch) and it is all nicely commented.
Documented and fixed on trunk in r821333.