W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1997

Re: Content encoding problem...

From: Koen Holtman <koen@win.tue.nl>
Date: Sun, 16 Feb 1997 18:02:48 +0100 (MET)
Message-Id: <199702161702.SAA26722@wsooti08.win.tue.nl>
To: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
Cc: jg@zorch.w3.org, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2397
Roy T. Fielding:
>Jeff said:
>>although I'd suggest thinking about changing the whole sentence
>>to read something like:
>>    If an Accept-Encoding header is present, and if the server cannot
>>    send a response which is acceptable according to the
>>    Accept-Encoding header, then the server SHOULD send a response
>>    using the default (identity) encoding.
>I like this new wording, regardless.

I don't think the existing wording is broken.  A response with _no_ encoding
is _always_ `acceptable according to the Accept-Encoding header'.  At least
that was my interpretation when I last reviewed this stuff.  The header
limits the use of encodings, but not the non-use of encodings.

> Content-Encoding is a property of the resource (i.e., only the origin
>server is capable of adding or removing it on the server-side, and only
>the user agent is capable of removing it on the client-side).

Not under 1.1 it isn't.  If no no-transform directive is present, caches may
change the type or encoding of the response.  See sections 13.5.2 and 14.9.5.

And yes, I complained when this change was made.  Skimming the archives, I
see that you were against it too, but I recall that it was decided to allow
it in the end.


Received on Sunday, 16 February 1997 09:08:58 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:01 UTC