Re: squid-2.4 and macs?

This we have always been doing. It is not our fault if it is a
http:// request. The origin server then forgot to set a "Vary:
Accept-encoding" header telling caches that the content varies for
different browsers.. (or the administrator is anonymizing away
Vary:..)

If it is a ftp:// request then it is our fault. We do not care what
the client claims to accept but always sends content-encoding
matching the file extensions. To get around the possible browser
confusion in such case the user can select the "download" link
instead (icon on the right), or reconfigure their mime.conf to not
have content encodings (change them to the corresponding content
types).

Squid SHOULD NOT touch the content encoding of proxied objects. It
may play with HTTP/1.1 transfer encoding, but not content encoding.
Both have roughtly similar capabilities however.

A gateway can play with content encoding. It it then the
responsibility of the gateway to ensure correct semantics are
provided on the object (note: range requests etc).

Regards
Henrik

On Saturday 09 March 2002 05:32, Adrian Chadd wrote:
> Hi,
>
> I've been getting reports here and there from some Australian
> ISPs that the latest squid-2.4 release(s?) seem to be breaking
> with Macs. From what I've been told, if someone requests
> a content-encoded (say gzip)ed page squid will cache it and
> then return that particular gzip'ed page to anyone who
> requests the same page.
>
> What should squid be doing with content-encoded requests?
> Mark them as non-cacheable, and pass them through?
> Whats squid-2.4 doing? :)
>
>
>
>
> Adrian
Received on Sat Mar 09 2002 - 03:38:26 MST