- 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
>>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 >>level. > >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? .....Roy
Received on Wednesday, 19 February 1997 09:09:24 UTC