IETF 90 - Client-Initiated Content-Encoding

Julian Reschke, greenbytes

What problem does it solve?

HTTP/1.1 clients already can use content codings such as "gzip" in requests, but if a server doesn't play along, it's hard to understand what went wrong.

Status code 415 (Unsupported Media Type) can already be used, but the recipient wouldn't know whether the problem was caused by the media type or the content coding, and also would need information about what content codings are supported.

Proposed Solution

Extend "Accept-Encoding" header field to be usable in responses as well. When sent in a 415 response, it would indicate which content codings are supported.

See draft-reschke-http-cice-01.

This is a really a tiny, backwards compatible extension to RFC 7231; it might have been part of it if we had thought of it in time.

To Be Discussed

Also define use in OPTIONS response? Trouble is it might vary be request method.

Content codings can be seen as ugly workaround for transfer codings not implemented in practice. Should we try harder to fix that problem?

Working Group draft?

Once it's a Proposed Standard, it'll be a candidate for inclusion into RFC7231bis.