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

Oooops, I'm very sorry. Henrik is absolutely right about Content-Encoding in
HTTP/1.0,
and it makes sense. I've just double-checked
http://ftp.ics.uci.edu/pub/ietf/http/history/draft-ietf-http-v10-spec-00.txt
and have to change my approach appropriately. In fact, I'm very happy with
that.

Thank you very much!
Slava

From: "Henrik Nordstrom" <hno@squid-cache.org>

> On Friday 21 June 2002 23.17, Slava Bizyayev wrote:
>
> > Unfortunately, it's not that simple. Content compression has not
> > been introduced at all in HTTP/1.0, and Content-Encoding was used
> > by Netscape mainly for their early experiments with content
> > compression. Some of that old browsers are still in use, but they
> > are buggy usually.
>
> Does not change my point a bit, and is in fact false. Content-Encoding
> is well defined in HTTP/1.0. It is Transfer-Encoding that is new in
> HTTP/1.1 and also the directory of standard encoding names is cleaner
> in HTTP/1.1 than in the HTTP/1.0 specification but fully compatible
> provided the browser is at least HTTP/1.0 compliant...
>
> Content-Encoding is a End-To-End property. If the server identifies
> the receiving end as capable of receiving the reply encoded in
> certain manner then it is fully safe to do so over HTTP/1.0 provided
> the reply is correcly protected from any HTTP/1.0 caches that may not
> know about Vary.
>
> You cannot safely respond with a specific Content-Encoding other than
> identity unless you have positively identified the receiver as
> capable of receiving the selected encoding. This is true independent
> of the signalled HTTP version.
>
> Regards
> Henrik
>
Received on Fri Jun 21 2002 - 22:01:04 MDT