Re: [squid-users] "Accept-Encoding" header

Both are fully compatible with all forms of server driven content
negotiation (file type, encoding, compression etc), as long as you
send a proper Vary header indicating such negotiation is taking
place.

Squid-2.4 and earlier won't be able to cache the reply as Squid-2.4
and earlier can only support up to one entity version per URL.

Squid-2.5 will cache the reply if possible, and honors the entity
variance indicated by Vary.

Squid-2.6 will most likely also support ETag, allowing Squid to ask
the server which if any of the variants it already has is suitable
for satisfying the new request type. In Squid-2.5 each request type
is cached individually.

Regards
Henrik

On Friday 14 June 2002 02:43, Slava Bizyayev wrote:
> Should we consider the Squid-2.4 the only version compatible with
> content compression (as long as it denies to cache anything
> accomplished with Vary header)?
> Please, could you specify the earliest version, which is working
> this way? Am I understand correctly that we should refrain from
> doing the content compression on httpd when the request is coming
> through the Squid-2.5 (even we reply with Vary)?
>
> Thanks,
> Slava
>
> From: "Henrik Nordstrom" <hno@marasystems.com>
> Sent: Thursday, June 13, 2002 7:15 PM
> Subject: Re: [squid-users] "Accept-Encoding" header
>
> > Squid-2.5 and later supports caching of objects having the Vary
> > header.
> >
> > Squid-2.4 and earlier denies caching of such objects as it cannot
> > support more than one entity per URL.
> >
> > There is a known Accept* bug in Squid and that is that Squid does
> > not care about Accept* headers when selecting the content type
> > and encoding of FTP replies, instead only basing this on the
> > extensions of the ftp://server/path/to/file.some.type URL.
Received on Thu Jun 13 2002 - 19:15:33 MDT