HTTP is defined as stateless; a server MUST NOT assume two requests on the same connection are from the same user agent unless the connection is secured and specific to that agent. This statelessness enables proxy connection reuse, load balancing, and independent request processing.

http

The userinfo subcomponent is prohibited from appearing in http URI references sent in messages because it may expose credentials and is commonly used to obscure authority for phishing attacks. A sender MUST NOT generate userinfo in an http URI within a message.

http, security

Transfer-Encoding is explicitly designed as a property of the message rather than the representation (unlike Content-Encoding) so that it can be safely stripped or added by any recipient along the chain; it serves message framing rather than payload characterization.

http

For robustness against older HTTP/1.0 clients that send an extra CRLF after POST, a server SHOULD ignore at least one empty line (CRLF) received prior to the request-line. An HTTP/1.1 user agent MUST NOT preface or follow a request with an extra CRLF.

http

Obsolete header line folding (obs-fold, a field-value preceded by CRLF + whitespace) is deprecated except within message/http media type. Servers MUST reject or unfold obs-fold in requests; proxies/gateways MUST discard and replace or unfold; user agents MUST unfold.

http

The Set-Cookie header field violates the prohibition on multiple header fields with the same field name because it appears multiple times without using list syntax; recipients should handle Set-Cookie as a special case that cannot be combined into a single field-value.

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 field-value must be identical to that authority component.

http

A message with multiple Content-Length fields having differing values, or a single Content-Length with an invalid value, constitutes an unrecoverable framing error. Servers MUST respond with 400 and close; proxies MUST close and send 502; user agents MUST close and discard.

http, security

A recipient MUST be able to parse the chunked transfer coding because it is crucial for framing messages when payload body size is unknown in advance. A sender MUST NOT apply chunked more than once; chunked MUST be the final transfer coding when any other coding is applied to a request payload.

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 Unicode characters without regard for encoding creates security vulnerabilities from invalid multibyte sequences containing LF.

http, security

A sender MUST NOT generate BWS (bad whitespace) in messages; BWS is optional whitespace allowed only for historical reasons. A recipient MUST parse for such bad whitespace and remove it before interpreting the protocol element.

http

A sender MUST NOT send a Content-Length header field in any message that contains a Transfer-Encoding header field.

http

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

http, security

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

http

Intermediaries that process HTTP messages MUST send their own HTTP-version in forwarded messages rather than blindly forwarding the received version, to ensure downstream recipients use accurate capability information.

http

When both Transfer-Encoding and Content-Length are present, Transfer-Encoding overrides Content-Length. A sender MUST remove the received Content-Length field prior to forwarding such a message, as it may indicate request smuggling or response splitting.

http, security

The Content-Length header field provides the anticipated size, as a decimal number of octets (`1*DIGIT`), for the message body. It provides framing information used to determine where the body ends when Transfer-Encoding is absent.

http

The http URI scheme identifies resources by authority (host + optional TCP port), hierarchical path, and optional query. The default TCP port is 80. A sender MUST NOT generate an http URI with an empty host identifier.

http

The https URI scheme is identical to http except the default TCP port is 443 and the user agent MUST ensure end-to-end strong encryption via TLS before sending the first request. http and https resources sharing the same authority are distinct namespaces.

http, tls

The Transfer-Encoding header field lists the ordered sequence of transfer codings applied to form the message body from the payload body. It is a property of the message, not the representation; any recipient along the chain MAY decode or add transfer codings.

http

The IANA Message Headers registry is updated with header fields defined by this document, including Content-Length, Transfer-Encoding, Via, Host, Connection, Upgrade, and Trailer. All defined header fields ought to be registered there.

http, registry

The Transfer Coding Registry is updated by this document with initial registrations for chunked, compress, deflate, gzip, and identity. New entries require IETF Review; registrations include the coding name, description, and pointer to specification.

http, registry

The Upgrade Token Registry is established by this document to track protocol names for use in the Upgrade header field. New entries require IETF Review and must include the token name, description, expected use, and reference.

http, registry

Establishing authority over an HTTP resource depends solely on DNS and TCP control; without TLS, there is no authentication of the origin server. The https scheme with TLS provides the authentication necessary to establish authority securely.

http, security, tls

Request smuggling exploits discrepancies in message framing interpretation between an intermediary and a downstream server, particularly through conflicting Transfer-Encoding and Content-Length fields or through lenient whitespace parsing that differs between implementations.

http, security

Response splitting occurs when user-supplied data is embedded in response header fields without adequate sanitization, allowing an attacker to inject a fabricated response. Implementations must sanitize all data inserted into header field values.

http, security

Risks from intermediaries include network-level interception proxies that violate HTTP semantics and act indistinguishably from man-in-the-middle attacks, introducing security flaws or interoperability problems. Interception proxies differ from HTTP proxies in not being selected by the client.

http, security

Server log information including IP addresses, request URIs, and header fields such as Referer may contain private information about users. Server operators should consider access controls, anonymization, and log retention policies.

http, privacy, security

Message body length is determined by a precedence-ordered algorithm: (1) HEAD/1xx/204/304 responses have no body; (2) 2xx CONNECT responses switch to tunnel; (3) chunked Transfer-Encoding decodes to termination; (4) non-chunked Transfer-Encoding with no final chunked reads until connection close; (5) invalid/conflicting Content-Length is an unrecoverable error; (6) valid Content-Length defines length; (7) request with no indicator has zero-length body; (8) response body ends at connection close.

http

A header field is encoded as `field-name ":" OWS field-value OWS`. The field-name token is case-insensitive; no whitespace is permitted between the field-name and the colon.

http

A request-line has the form `method SP request-target SP HTTP-version CRLF`. The method token is case-sensitive; no whitespace is permitted within any of the three components.

http

A status-line has the form `HTTP-version SP status-code SP reason-phrase CRLF`, where status-code is a 3-digit integer. The reason-phrase exists solely for human readability; clients SHOULD ignore it.

http

An HTTP/1.1 message consists of a start-line, zero or more header fields each terminated by CRLF, an empty line (CRLF), and an optional message body: `HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body ]`.

http

HTTP-version is encoded as the case-sensitive literal `HTTP-name "/" DIGIT "." DIGIT` (e.g., `HTTP/1.1`). The major digit indicates messaging syntax; the minor digit indicates the highest compatible minor version the sender conforms to.

http