Bug 38017 - mod_cache not working in reverse proxy setup?
mod_cache not working in reverse proxy setup?
Status: RESOLVED FIXED
Product: Apache httpd-2
Classification: Unclassified
Component: mod_cache
2.2.0
PC Linux
: P2 major (vote)
: ---
Assigned To: Apache HTTPD Bugs Mailing List
: PatchAvailable
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2005-12-22 22:09 UTC by Dick Snippe
Modified: 2006-06-29 02:24 UTC (History)
0 users



Attachments
Patch proposal against trunk (1.59 KB, patch)
2006-01-05 16:23 UTC, Ruediger Pluem
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dick Snippe 2005-12-22 22:09:42 UTC
mod_cache does not serve cached content.
We'd like to use mod_cache + mod_disk_cache + mod_proxy + mod_proxy_ajp
as a reverse caching proxy.
The backend server (tomcat) sets all the right http headers (Expires,
Last-Modified) but apache refuses to serve cached content.
The same problem also shows up with mod_mem_cache and/or mod_proxy_http
Examination shows that entries are inserted into the cache using the hostname
"_default_". I assume this is because of the logic in cache_generate_key_default
in modules/cache/cache_storage.c 
However, cache lookups are done with the actual hostname. So, apache cannot find
the data it inserted on earlier requests.

Our setup is as follows:
./configure --prefix=/software/apache-2.2.0-cache --with-mpm=worker
--enable-cache --enable-mem-cache --enable-disk-cache --enable-proxy
--enable-proxy-http --enable-proxy-ajp --enable-proxy-balancer --enable-rewrite
--enable-mods-shared=all

The relevant bits in the config file are:
ProxyPreserveHost       On
CacheDefaultExpire      60
CacheMaxExpire          3600
CacheIgnoreCacheControl On
CacheIgnoreNoLastMod    On
CacheEnable             disk    /
CacheRoot               /e/fp/shrd02/tmp/cache
ProxyPass               /       ajp://shrd01as:8009/
ProxyPassReverse        /       ajp://shrd01as:8009/

BTW:
we use apache-2.0.X mod_mem_cache extensively. In the 2.0.X instances caching
works, so I'm quite surprised to encounter problems in 2.2. I assume I must be
doing something wrong, but can't figure out what.
Comment 1 Ruediger Pluem 2006-01-05 16:23:18 UTC
Created attachment 17342 [details]
Patch proposal against trunk
Comment 2 Ruediger Pluem 2006-01-05 16:24:28 UTC
I can confirm that this is a regression. Could you please give the attached
patch a try and let me know the results?
Comment 3 Ruediger Pluem 2006-01-06 10:34:26 UTC
Oh I forgot: Thanks for the good analysis of the problem. That eased my search
for the cause very much.
Comment 4 Dick Snippe 2006-01-10 14:51:32 UTC
(In reply to comment #2)
> I can confirm that this is a regression. Could you please give the attached
> patch a try and let me know the results?

the patch works!
I tested all comninations of mod_mem_cache, mod_disk_cache and mod_proxy_http,
mod_proxy_ajp and it appears to work in all cases
Comment 5 Ruediger Pluem 2006-01-10 22:38:26 UTC
Thanks for testing. The patch has been commited to trunk as r367798
(http://svn.apache.org/viewcvs.cgi?rev=367798&view=rev) and been proposed for
backport to 2.2.x as r367800
(http://svn.apache.org/viewcvs.cgi?rev=367800&view=rev).
Comment 6 Ruediger Pluem 2006-02-04 22:39:42 UTC
The patch has been backported to 2.2.x as r374931
(http://svn.apache.org/viewcvs.cgi?rev=374931&view=rev) and will be part of 2.2.1
Comment 7 Alex Georgopoulos 2006-06-29 00:31:20 UTC
I am still seeing these errors on 2.0.58 & 2.2.2 using mod_proxy for a reverse
proxy for RPC over HTTP and Exchange.  Downgrading to 2.0.54 fixes the problem,
maybe there are still some other occurences besides the ones patched here that
have not been fixed?  I also tried this on 2.2.2 and it didn't work either.

[Tue Jun 27 18:08:08 2006] [error] (70014)End of file found: proxy: prefetch
request body failed to 10.2.181.53 from 15.235.153.107 ()
[Tue Jun 27 19:07:46 2006] [error] (104)Connection reset by peer: proxy:
prefetch request body failed to 10.2.181.53 from 10.2.181.18 ()
Comment 8 Ruediger Pluem 2006-06-29 09:24:32 UTC
Sorry, but your problem is completely unrelated to this bug.