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/, [email protected]Received on Thu May 08 2003 - 19:16:56 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:16:28 MST