Re: [squid-users] Vary / Accept-Encoding / mod_gzip Redux

On Friday 09 May 2003 02.29, R Pickett wrote:

> We're batting around if it's worth it to throw time and energy at
> this solution, or try for some other kind of workaround. It seems
> like a sane thing to want to do, though, no? "This object that you
> cached has changed, please forget about all instances of it."

Yes, as sane as "we have published a new version of the site, forget
about all old content".

What you can do is to keep track of URLs and their corresponding
filenumber by keeping a additional index based on store.log. This way
you will have a quick way to look up URL -> files, and from the files
you can easily find the variance data to PURGE.

> I suppose we're sort of approaching the problem backwards, having
> the content provider pro-actively tell the cache about changes, but
> that is basically what our application demands.

Quite common requirement for accelerator setups.

> We're currently
> programatically forcing squid to refresh content when it changes,
> but when we switch to a situation where Vary comes into the
> picture, that whole scheme breaks badly.

Only gets a bit more complex.. especially with the simple Vary support
of Squid-2.5 with no ETag support.

> We are also toying with the idea of adding proper ETag and
> If-None-Match support to mod_gzip, ourselves, at this point. I
> took a look at the ETag squid patch, and it looks interesting in
> principle. Doesn't apply cleanly to 2.5.STABLE2, but I think I
> managed to massage in the rejects into the correct places, so we'll
> be taking a look at that.

The patch has now been updated to current Squid-2.5.STABLE sources.

> This is the part where I wonder out loud if we are the only group
> in creation that's trying to do this gzipping and caching in a
> reverse proxy situation, or if it's just our need for long cache
> times and conditional purges that is unique.

Probably not many doing acceleration of mod_gzip servers today. If
they were mod_gzip would have correct Vary and ETag support I think.

But just doing acceleration of mod_gzip makes great sense, especially
with ETag support in both the cache and mod_gzip as with ETag support
the ETag saves mod_gzip from compressing what is already compressed
in the cache and all that needs to take place is that mod_gzip
teaches the cache to use the gzip:ed (or identity) response via
If-None-Match 304 reply.

One could in a sense say that a mod_gzip vith correct Vary and ETag
support is what caches is waiting for to implement correct caching of
such replies. Before there is any application making good use of
Vary+ETag it is hard to make and test a good cache implementation.

Regards
Henrik

-- 
Donations welcome if you consider my Free Squid support helpful.
https://www.paypal.com/xclick/business=hno%40squid-cache.org
If you need commercial Squid support or cost effective Squid or
firewall appliances please refer to MARA Systems AB, Sweden
http://www.marasystems.com/, info@marasystems.com