Recommended response behavior when identity encoding is unacceptable

[gibson042]

RFC 2616 specified that identity content-coding could be made unacceptable (e.g., indicating very strong preference for response compression) by means of an Accept-Encoding request header field value like identity;q=0 or *;q=0 without an identity-specific preference, and then recommended that the server SHOULD respond with 406 (Not Acceptable) when it cannot send an acceptable response. But RFC 7231 and the current draft update that last point to "SHOULD send a response without any content-coding", presumably primarily intended to avoid sending 406 (Not Acceptable) when the acceptability of identity content-coding is unspecified. The text still includes a description of when identity content-coding is unacceptable and still accommodates a "compression is mandatory" interpretation of Accept-Encoding: gzip, identity;q=0, but seems to strongly discourage it in the sense of RFC 2119 ("there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course").

I suspect this to be unintentional, and would propose clarification in semantics:

    An Accept-Encoding header field with a field value that is empty
    implies that the user agent does not want any content coding in response.
    If an Accept-Encoding header field is present in a request and none of the
    available representations for the response have a content coding that
    is listed as acceptable, the origin server &SHOULD; send a response
-   without any content coding.
+   without any content coding unless absence of content coding is itself
+   unacceptable (in which case the origin server &SHOULD; honor that
+   preference).

In the absence of such clarification, the text describing when identity content-coding is unacceptable seems to be largely pointless.

[reschke]

I agree that this is not optimal, but the proposed text would change the protocol from what is has been since RFC 7231.

Given that the current draft is approved and in the publication queue, I don't think that a change is possible or even desirable.

[royfielding]

The move away from sending 406 was intentional in RFC7231. There is no implementation support for identity;q=0 overriding basic interoperability (200 response without encoding), unlike Accept for unwanted media types, because encodings are often applied late in the request handling process based on the server's analysis of whether they are efficient/possible. Hence, clients simply list the acceptable encodings and variance in the field values cause unwanted cache misses. The feature only made sense for non-compression encodings.

This does not prevent a server from responding with 406, but doing so is less interoperable (without some additional knowledge about why the client is asking for that) than sending no encoding.

[gibson042]

If it is indeed intentional for absence of content coding to always be considered acceptable, then what is the purpose of keeping text that implies otherwise (emphasis mine)?

If the representation has no content coding, then it is acceptable by default unless specifically excluded by the Accept-Encoding header field stating either "identity;q=0" or "*;q=0" without a more specific entry for "identity".

[royfielding]

I meant that the move away from 406 was intentional. Suggesting that "identity;q=0" not be respected was not intentional, but is also not implemented AFAIK (It only makes sense for encryption-related encodings).

I would suggest a less normative fix, like

An Accept-Encoding header field with a field value that is empty implies that the user agent does not want any content coding in response. If a non-empty Accept-Encoding header field is present in a request and none of the available representations for the response have a content coding that is acceptable, the origin server &SHOULD; send a response without any content coding unless the identity coding is indicated as unacceptable.

and just send that now to the RFC editor as a clarification.

[gibson042]

Great, thanks!

[reschke]

@royfielding - are you going to create a PR for this?