Re: [squid-users] Caching CGI output

I wrote:
>> 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.
Received on Tue Nov 16 2004 - 17:28:07 MST