Re: Content encoding problem...

Henrik Frystyk Nielsen <> wrote:
  > Sorry for the confusion - let me try and rephrase what I mean:
  > The current HTTP/1.1 spec introduces the "deflate" encoding as a possible
  > content-encoding. In order to advertize that the libwww HTTP/1.1 client
  > understands this particular encoding, I include "Accept-Encoding: deflate"
  > in the request. Jeff Mogul pointed out that the current wording in the spec
  > says that:
  >     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 an error
  >     response with the 406 (Not Acceptable) status code.
  > and that this will lead servers to send back a "406 Not Acceptable" return
  > code. The only way to avoid an extra RRT would be not to include the
  > accept-encoding header in which case it would probably never get used.

Yes, I think I see the problem(s) now.  The first problem is that that
section's wording should probably be changed to allow the server to
send a resource without any Content-Encoding if it can't match any of
the Accept-Coding's.  That is, Accept-Coding should be advice about
acceptable encodings, not a demand to use one of them.  And the notion
of "acceptable according to the Accept-Encoding header" should include
the possibility of no encoding.

The second problem is that few clients and few servers understand
"deflate" yet.
  > However, if there is _no_ "Accept-Encoding" then the spec allows HTTP/1.1
  > servers to generate any content encoding they like. I tried this and made
  > Jigsaw generate a response with content-type "text/html" and
  > content-encoding "deflate" and the result is a I have described that client
  > do _not_ handle it: the end user sees the encoded data parsed as HTML.

Yes, that's surely a client that doesn't understand "deflate".
  > [...]
  > In order to avoid the problem with HTTP/1.0 clients, the solution would be
  > _NOT_ to send any other encodings (unless explicitly asked for) than gzip
  > and compress.

That's no doubt true for 1.0 clients.  I think my proposed change will
help avoid garbage on the screen, although it won't help reduce the
number of bytes transmitted.

Dave Kristol

Received on Wednesday, 19 February 1997 12:12:35 UTC