>>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? .....RoyReceived 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