ietf-corpus

rfc-7694

Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding

J. Reschke
date2015-11 streamIETF areawit wghttpbis statusPROPOSED STANDARD pages7 canonicalhttps://www.rfc-editor.org/rfc/rfc7694 doi10.17487/RFC7694
In HTTP, content codings allow for payload encodings such as for compression or integrity checks. In particular, the "gzip" content coding is widely used for payload data sent in response messages. Content codings can be used in request messages as well; however, discoverability is not on par with response messages. This document extends the HTTP "Accept-Encoding" header field for use in responses, to indicate the content codings that are supported in requests.

obsoleted by

Extracted elements (10)

design-rationale §1

Content codings can be used in request messages, but discoverability was not on par with response messages. This specification solves that by reusing the existing 'Accept-Encoding' header in responses, avoiding a new header, and also updates the 415 status code definition to recommend inclusion of the field.

http

design-rationale §3

The most common expected use of 'Accept-Encoding' in responses is with a 415 status code, in reply to a client's optimistic use of a content coding. The header can also be included in 2xx responses to proactively inform clients that compression is supported when the request payload was large enough to warrant it.

http

interoperability-note §3

An 'Accept-Encoding' field value in a response that only contains 'identity' implies that no content codings are supported for the associated request. The set of supported encodings is specific to the associated request and may differ for other resources or over time.

http

interoperability-note §5

Servers that do not support any content codings in requests only need to add 'Accept-Encoding: identity' to their existing 415 responses; no other behavioral change is required, making backward-compatible deployment straightforward.

http

normative-requirement §3 SHOULD

Servers that fail a request due to an unsupported content coding ought to respond with a 415 status and ought to include an 'Accept-Encoding' header field in that response, allowing clients to distinguish content coding problems from media type problems.

http

normative-requirement §3 MUST NOT

Servers that fail a request with a 415 (Unsupported Media Type) status for reasons unrelated to content codings MUST NOT include the 'Accept-Encoding' header field in the response, to avoid confusion with media type issues.

http

protocol-element §3

The 'Accept-Encoding' header field, previously defined only as a request header, is extended to also be used as a response header field. When present in a response, it indicates what content codings the resource was willing to accept in the associated request.

http

registry §7.2

The 'HTTP Status Codes' registry entry for status code 415 (Unsupported Media Type) is updated to additionally reference Section 3 of this document, reflecting the new guidance to include 'Accept-Encoding' in 415 responses where appropriate.

http, registry

registry §7.1

The 'Permanent Message Header Field Names' registry entry for 'Accept-Encoding' is updated to reference both Section 5.3.4 of RFC 7231 and Section 3 of this document, reflecting its new use as a response header field.

http, registry

security-consideration §6

This specification does not introduce new security considerations beyond those in HTTP/1.1 (RFC 7231 Section 9) and HTTP/2 (RFC 7540 Section 10). However, improved discoverability may increase use of compression codings over secure channels, which can enable side-channel attacks such as BREACH; at publication time it was unclear how BREACH-like attacks apply to request compression.

http, security, privacy