Re: Content-Encoding and storage forma (fwd)

From: Henrik Nordstrom <hno@dont-contact.us>
Date: Fri, 5 Mar 2004 00:19:49 +0100 (CET)

---------- Forwarded message ----------
Date: Fri, 5 Mar 2004 00:18:04 +0100 (CET)
From: Henrik Nordstrom <hno@squid-cache.org>
To: Jon Kay <jkay@pushcache.com>
Cc: Henrik Nordstrom <hno@squid-cache.org>
Subject: Re: Content-Encoding and storage forma

On Thu, 4 Mar 2004, Jon Kay wrote:

> So, are you suggesting that, for example, if we get an uncoded server
> response with ETag: "page12345", then we would tag a gzip-coded
> version as ETag: "gzippage12345"?

It's one way. If you have a tuneable for which gzip encoding level to be
used or otherwise may generate different binary codings of the same
original at different times make sure these are reflected into the etag.
You should also at a minimum include a unique identifier for the proxy
instance where the recoding is done.

But due to the dynamic nature of online recoding I would recommend using
guaranteed one-time etags each time an object is recoded. This way you are
guraranteed the object identity is unique per recoding done. This ETag is
for use between you and the client, not of interest (or value) to anyone
else.

Two copies of the same URI is supposed to be guaranteed 100% binary
equivalent if they have the same stron ETag, or just semantically
equivalent if they share the same weak etag.

By correcly using strong ETags you

 * Guarantee cache mesh consistency
 * Allow optimizations by Range request merging

By using weak ETags with encoding added you

 * Guarantee cache mesh consistency
 * Probit optimizations by Range request merging

By using weak ETags without encoding added

 * You risk causing some minor cache mesh inconsistency as the original
and encoded versions are then said to be semantically identical (which
they are not entirely)
 * Probit optimizations by Range request merging

Regards
Henrik
Received on Thu Mar 04 2004 - 16:19:52 MST

This archive was generated by hypermail pre-2.1.9 : Thu Apr 01 2004 - 12:00:04 MST