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

Re: Content encoding problem...

From: Roy T. Fielding <fielding@kiwi.ICS.UCI.EDU>
Date: Wed, 19 Feb 1997 08:38:11 -0800
To: Henrik Frystyk Nielsen <frystyk@w3.org>
Cc: http-wg@cuckoo.hpl.hp.com
Message-Id: <9702190838.aa12317@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2465
>>When I first started testing HTTP/1.0 clients, almost all of them understood
>>Content-Encoding.  Are you saying that they have digressed?  Are you sure
>>that the tests were not faulty (i.e., was the server output checked to
>>be sure that it was actually sending the correct content-type and
>>content-encoding headers)?  Or do the failures only apply when "deflate"
>>is used as the Content-Encoding?  Note that most current clients will
>>only accept "x-gzip" and "x-compress", if anything.
>This is not entirely correct. The only reason why the clients that I have
>tested look like they understand content encoding is that it always has
>been followed by a "application/octet stream" content type which is handled
>by dumping it to disk. If you have content type "text/html" which is the
>situation in our tests then most clients pass it right through.

Then it sounds like they have digressed, because all of my tests were
with text/html content with both "x-gzip" and "x-compress" encoding.
The browsers would retrieve the content and decompress it before
rendering.  The only ones which did not do so were the Mac-based clients
which did not (at that time) have a library for gzip decompression.
This was two years ago (decades in web-years), but I am surprised that
things would change so much in an incompatible way.

>>Transfer-Encoding, on the other hand, represents HTTP-level encodings.
>>If we want to support HTTP-level compression, it must be done at that
>No, as an origin server I want to compress the data once and for all,
>compute my hash and other things that depend on the hash like signatures,
>PICS labels etc. I can see special cases where compression at the transfer
>level is convenient - for example allowing proxies to compress it on the
>fly etc. but the first usage is not less important.

What you describe is clearly a Content-Encoding, but that is already
taken care of in the protocol -- we don't need to change HTTP to make use
of it.  So now I am totally confused: what is the point of this discussion?

Received on Wednesday, 19 February 1997 09:09:24 UTC

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