Requiring Clients to support content-codings

[mnot]

HTTP/2 requires clients to support the gzip content-coding.

The justification for this has always been that it helps avoid intermediaries and other interposed software (e.g., virus filters) that strip Accept-Encoding to avoid the pain of decompressing responses.

However, it has been pointed out that doing so means that intermediaries that translate from 1 to 2 are now required to synthesise new entity tags for decompressed responses, breaking semantic transparency and/or losing significant HTTP functionality.

[mnot]

See also #404.

[reschke]

It also requires to rewrite ETags in request headers (conditional ones), which is an open-ended list. Furthermore, ETags also appear in payloads (WebDAV properties, for instance).

[phluid61]

The outcome of this issue also affects #424

[mnot]

Discussed in NYC; will remove implicit gzip from spec; may create new content-coding required status code or other strategy (non-blocking).