Re: Content encoding problem...

[Sigh.  I tried to kill this meme already, but let's try again...]

Dave Kristol:
>
>    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.

The current wording already allows unencoded responses if an Accept-Encoding
header is present!

Quoting from the spec:

|14.3 Accept-Encoding
|
|   The Accept-Encoding request-header field is similar to Accept, but
|   restricts the content-coding values (section 14.12) which are
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
|   acceptable in the response.

An *un*encoded response has _no_ content-coding values.  It is therefore
_always_ acceptable according to the Accept-Encoding header.

Compare: an image/gif response has _no_ charset values.  It is therefore
_always_ acceptable according to the Accept-Charset header.

Look at the following quotes:

quote 1: 
|   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.

quote 2: 
|   If an Accept-Charset header is present, and if the server cannot
|   send a response which is acceptable according to the
|   Accept-Charset header, then the server SHOULD send an error
|   response with the 406 (not acceptable) status code, [...]

Does quote 2 imply that I an image/gif is not acceptable according to
`Accept-Charset: iso-8859-5, unicode-1-1;q=0.8'?  I don't think so.

There is no problem with quote 1, except maybe that it is easy to
misinterpret.  So stop being so gloomy about this.

Koen.

Received on Saturday, 22 February 1997 05:28:44 UTC