I have a relatively slow CGI application that I'd like to accelerate by caching its output. So far I've tried Apache's mod_disk_cache and Squid (I'm using the Debian version of 2.5.7) and neither works, I believe because they both consider the CGI output to be uncacheable. I'm hoping that someone on this list can offer some advice about how or if Squid can be made to work in this scenario.
I have now progressed a little; some clues in the Apache mod_cache source code pointed me to RFC2616 section 13.9 which says that, even though you use the nice HTTP 1.1 functions to declare the cacheability of your content, anything with a "?" in the URL must not be cached because that is "traditional". Aaarrgghh!!!
To work around this I have added an "Expires: (current time)" header, and Apache mod_cache does now cache the content and revalidate it.
Henrik Nordstrom asked: > What does the cacheability check engine say about the results?
Having added the redundant Expires: header to keep mod_cache happy the cacheability engine says:
This object will be fresh for 2 sec. The object had changed when validation was attempted. Because of the must-revalidate header, all caches will strictly adhere to any freshness information you set. It doesn't have a Content-Length header present, so it can't be used in a HTTP/1.0 persistent connection. The clock on this Web server appears to be set incorrectly; this can cause problems when calculating freshness.
(It's wrong and I'm right about the clock setting.)
And make sure you have not explicitly denied caching by the no_cache directive.
Nope.
The recommended squid.conf for example does not cache URLs with a ? in them even if the server returns caching information.
I removed that.
Squid-2.5 does not support ETag, unfortunately (only Vary).
OK, well that would explain it.
There is a patch at http://devel.squid-cache.org/ which adds ETag support to Squid-2.5.
I'll investigate that if necessary. At the moment it looks as if Apache's mod_cache might do what I need.
The "must-revalidate" may also be a bit troublesome, and with "Vary: Cookie" it should not really be needed, should it?
The page must still be revalidated even if the cookie has not changed, so I think both are needed - unless there is something in RFC2616 that adds an additional dependency.
Regards,
Phil.
