Re: Content-Encoding and storage forma

> Applying Content-Encoding in an accelerator makes sense, and can be done
> reasonably well. Applying Content-Encoding in a general purpose Internet
> proxy is a different beast and you then need to be very careful.

Yes, indeed.

Looking at the spec, I've decided to add a squid.conf flag to turn
content encoding off if desired. That seems like a good idea anyway
for other reasons.

> A recoded object such as gzip can be regarded semantically equivalent
> providing the user-agent knows how to decode gzip, but are obviously not
> binary equivalent to the non-encoded entity. If you are 100% certain that
> all user-agents ever accessing contents from this server accepts gzip
> content-encoding then you may use the same weak ETag for both original and
> encoded, but if there ever is cases where clients should get the original
> then you must not, as if you do you instruct downstream caches the gzip
> and original are equivalent regardless of what the client accepts.

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.

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?

Jon
Received on Tue Mar 02 2004 - 02:24:04 MST