Re: Content-Encoding and storage forma

From: Henrik Nordstrom <hno@dont-contact.us>
Date: Tue, 2 Mar 2004 11:33:41 +0100 (CET)

On Tue, 2 Mar 2004, Jon Kay wrote:

> I think our decision not to keep just encoded versions around
> immunizes us from that one; I don't see how a redecoding could arise,
> as encoded versions follow different paths to encoding-accepting
> clients than decoded versions to unaccepting, purist clients.

I do not quite follow what you are saying here.

The issues is not about what happens within a single Squid but what
happens at the clients or in a cache mesh.

> Now, one troubling aspect to this is that different caches can
> generate different valid encodings of the same object. Can you guys think
> of an action path by which that could produce corrupt results?

There is plenty in cases of range merging if you consider any multi-path
situation

a) Clients having multiple paths, such as a laptop moving between networks
where recoding is used and where not.

b) Secondry caches with clients of different classes.

c) Change of encoding details (compression level etc) making the object
binary different.

If you modify the ETag to include details on how the object has been
recoded then you are immune as each variant then has a different identity.
Also if you use weak etags you are mostly immune to your own actions, but
there is secondary caching implications where clients may get a different
encoding than expected because the two are told to be semantically
equivalent.

If you allow strong etags which does not account for the recoding or there
is no ETag then you must be very careful to ensure there under no
conditions is multiple paths between the clients and the recoding proxy,
and that recoding parameters are not modified.

Regards
Henrik
Received on Tue Mar 02 2004 - 17:16:37 MST

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