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

I would say your server isn't fully complying to HTTP specifications
on how to indicate that there was server driven negotiation in
determining the exact entity to respond with. See RFC 2616 "14.44
Vary" and "12.1 Server-driven Negotiation". Note that Squid is a
cache, not a server.

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.

Regards
Henrik

On Friday 14 June 2002 00:13, Mike Mitchell wrote:
> Squid isn't honoring "Accept" headers when retrieving items from
> the cache. The original request might go through with a "gzip"
> encoding, but then another browser might not accept that type of
> encoding when the page is loaded from the cache. This happens when
> a modern browser requests a page that gets cached, then an older
> browser such as IE 5 asks for the same page. The IE 5 browsers
> present a download prompt to the user instead of displaying the
> page.
>
> I've looked through the squid source code and I didn't see any
> place where any "Accept" headers were checked. It looks like the
> proper place is in client_side.c, in the clientCacheHit() routine.
> After reading the appropriate parts of RFC 2616 (sections 14.1
> through 14.4) I can see why "Accept" processing was left out.
>
> Are there plans for "Accept" processing in version 2.6? Does
> anyone have a feel for which "Accept" header will help the most?
> Is handling "Accept-Encoding" sufficient, or do we have to handle
> all "Accept" headers?
Received on Thu Jun 13 2002 - 18:24:02 MDT