Transfer-Encoding is defined as overriding Content-Length rather than being mutually incompatible because early implementations occasionally sent both chunked transfer coding and an estimated Content-Length for progress bars. This historical practice necessitated a defined precedence rule rather than prohibiting coexistence.

http

Transfer-Encoding was added in HTTP/1.1; implementations advertising only HTTP/1.0 support are assumed not to understand transfer-encoded content. A client MUST NOT send Transfer-Encoding unless it knows the server handles HTTP/1.1; a server MUST NOT send a Transfer-Encoding response unless the request indicates HTTP/1.1 or later.

http

A client MUST NOT send the chunked transfer coding name in the TE field; chunked is always acceptable for HTTP/1.1. A sender of TE MUST also send a "TE" connection option in the Connection header to prevent forwarding by intermediaries that do not support TE semantics.

http

A client MUST send a Host header field in all HTTP/1.1 request messages. If the target URI includes an authority component, the Host value MUST be identical to that authority component excluding any userinfo subcomponent.

http

A pipelining server MAY process safe-method requests in parallel but MUST send responses in the same order the requests were received. A client that pipelines MUST NOT pipeline immediately after reconnection to avoid losing error responses from the prior pipeline.

http

A recipient MUST be able to parse and decode the chunked transfer coding. A sender MUST NOT apply chunked more than once; if any non-chunked transfer coding is applied to a request, chunked MUST be the final coding to ensure proper framing.

http

A recipient MUST parse an HTTP message as a sequence of octets in an encoding that is a superset of US-ASCII. Parsing as a stream of Unicode characters creates security vulnerabilities due to varying handling of invalid multibyte sequences containing LF (%x0A).

http, security

A recipient that receives whitespace between the start-line and the first header field MUST either reject the message as invalid or consume each whitespace-preceded line without further processing, to prevent misinterpretation enabling request smuggling or response splitting.

http, security

A sender MUST NOT generate a bare CR within any protocol elements other than the content. A recipient of a bare CR MUST consider that element invalid or replace each bare CR with SP before processing or forwarding.

http, security

A sender MUST NOT generate a message that includes obsolete line folding (obs-fold) unless the message is intended for packaging within the "message/http" media type. Servers receiving obs-fold in requests MUST either reject with 400 or replace with SP octets.

http

A sender MUST NOT send a Content-Length header field in any message that contains a Transfer-Encoding header field. A server receiving both MUST close the connection after responding to avoid potential smuggling attacks.

http, security

A server MUST read the entire request message body or close the connection after sending its response to prevent remaining data being misinterpreted as the next request. A client MUST read the entire response body if it intends to reuse the connection.

http

A server MUST reject with 400 (Bad Request) any request message that contains whitespace between a header field name and colon. A proxy MUST remove any such whitespace from a response before forwarding downstream.

http, security

A server MUST respond with 400 (Bad Request) to any HTTP/1.1 request that lacks a Host header field, contains more than one Host field line, or has an invalid Host field value.

http

All HTTP data over TLS MUST be sent as TLS "application data". Clients MUST send a closure alert before closing the connection. Servers MUST attempt to initiate an exchange of closure alerts before closing, to avoid the TCP reset problem.

http, tls

All HTTP senders and recipients are RECOMMENDED to support, at a minimum, request-line lengths of 8000 octets. A server receiving a request-target longer than any URI it wishes to parse MUST respond with 414 (URI Too Long).

http

If a message is received with both Transfer-Encoding and Content-Length, Transfer-Encoding overrides. An intermediary that forwards such a message MUST first remove the Content-Length field and process the Transfer-Encoding prior to forwarding.

http, security

If a message is received without Transfer-Encoding and with an invalid Content-Length, the framing is invalid and the recipient MUST treat it as an unrecoverable error; a server MUST respond with 400 and close the connection.

http

Intermediaries that process HTTP messages MUST send their own HTTP-version in forwarded messages, unless purposefully downgraded as a workaround for an upstream issue. Blindly forwarding the start-line version can cause communication errors with downstream recipients.

http

When encountering a TLS incomplete close, a client SHOULD treat as complete all requests for which it received data up to Content-Length or the terminal zero-length chunk. A response with neither chunked nor Content-Length is complete only if a valid TLS closure alert was received.

http, tls, security

When the "close" connection option is received, a server MUST initiate closure after sending the final response and MUST NOT process further requests. A client MUST cease sending requests and close the connection after reading the response containing "close".

http

A trailer section (trailer-section = *( field-line CRLF )) allows the sender to include additional fields at the end of a chunked message for dynamically generated metadata. A recipient MUST NOT merge a trailer field into the header section unless the field definition explicitly permits it.

http

Chunk extensions allow per-chunk metadata (chunk-ext = *( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val ])). They are connection-specific and likely removed by intermediaries; a recipient MUST ignore unrecognized chunk extensions.

http

HTTP/1.1 defaults to persistent connections. A recipient determines persistence based on protocol version and Connection header: HTTP/1.1 is persistent by default; HTTP/1.0 is persistent only if "keep-alive" option is present; "close" option terminates persistence.

http

Message body length is determined by a strict precedence: (1) HEAD/1xx/204/304 responses have no body; (2) 2xx to CONNECT implies tunnel; (3) Transfer-Encoding overrides Content-Length; (4) chunked determines length by decoding; (5) valid Content-Length defines exact length; (6) connection close for responses without either.

http

The Transfer-Encoding header field lists transfer codings applied to the content to form the message body (e.g., "gzip, chunked"). It is a property of the message, not the representation, and overrides Content-Length when both are present.

http

IANA registers field names Close (reserved, Section 9.6), MIME-Version (Section B.1), and Transfer-Encoding (Section 6.1) as permanent entries in the HTTP Field Name Registry.

http, registry

IANA registers the ALPN Protocol ID "http/1.1" (byte sequence 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31) in the TLS ALPN Protocol IDs registry, enabling protocol negotiation during TLS handshake.

http, tls, registry

The "HTTP Transfer Coding Registry" at IANA defines the namespace for transfer coding names. Registrations require IETF Review, must include Name, Description, and specification pointer. Transfer coding names MUST NOT overlap with content coding names unless the transformation is identical.

http, registry

HTTP does not define a specific message integrity mechanism; it relies on transport error detection and length/chunk-delimited framing. The "https" scheme provides authenticated encryption, but care is needed to ensure TLS connection closure cannot be used to truncate messages.

http, security, tls

Request smuggling exploits differences in protocol parsing among multiple recipients to hide additional requests within an apparently harmless request. New message-framing requirements in Section 6.3—particularly Transfer-Encoding overriding Content-Length and mandatory connection closure on conflict—are intended to reduce its effectiveness.

http, security

Response splitting (CRLF injection) exploits the line-based nature of HTTP framing by injecting encoded CRLF octets into echoed parameters, making one response appear as two. The most effective mitigation is preventing anything other than core protocol libraries from emitting CR or LF within the header section.

http, security

A request-line = method SP request-target SP HTTP-version. The request-target has four forms: origin-form (absolute-path ["?" query]), absolute-form (absolute-URI), authority-form (uri-host ":" port, CONNECT only), and asterisk-form ("*", OPTIONS only).

http

An HTTP/1.1 message consists of a start-line followed by CRLF, zero or more field-line CRLF pairs, an empty line (CRLF), and an optional message-body. The grammar is: HTTP-message = start-line CRLF *( field-line CRLF ) CRLF [ message-body ].

http

Chunked body format: chunked-body = *chunk last-chunk trailer-section CRLF. Each chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF, where chunk-size is 1*HEXDIG. The last-chunk has chunk-size of zero. Recipients MUST anticipate large hex numerals to prevent integer overflow.

http

The HTTP version is indicated by HTTP-version = HTTP-name "/" DIGIT "." DIGIT, where HTTP-name = %s"HTTP" (case-sensitive). This specification defines version "1.1".

http

The status-line = HTTP-version SP status-code SP [ reason-phrase ], where status-code is a 3-digit integer (3DIGIT) and reason-phrase = 1*( HTAB / SP / VCHAR / obs-text). The space between status-code and reason-phrase MUST be sent even when the reason-phrase is absent.

http