Re: [squid-users] Content-encoding header lost when getting a "304 Not Modified" reply

On tis, 2007-12-11 at 02:23 -0800, Johan Sarnstrom wrote:

> The first reply correctly states that the content is compressed, but
> the second reply tells the client to use the locally cached copy, and
> does not give the "content-encoding: gzip". This causes Internet
> Explorer to try to use the compressed locally stored file, but not
> uncompressing it.

This smells like there is a broken server returning the same ETag for
both compressed and uncompressed, or perhaps not indicating Vary
properly.

MSIE when not configured to use HTTP/1.1 via proxies fail to understand
compressed content should it get delivered to it for some reason..

304 replies do not contain much information as all they say is that "the
object has not changed, use whatever I gave you before". Which means if
the client got a compressed object before it should continue using that
compressed object.

> What's the solution? Not using compression at all?

Using compression correctly, which entitles

* Sending different ETag values for compressed and uncompressed variants
* Sending a proper "Vary: Accept-Encoding" header.

Regards
Henrik

---
Commercial grade Squid support is available. See
http://www.xenion.com.au/squid for details.