RFC 9110 deliberately separates HTTP semantics (this document) from HTTP/1.1 messaging syntax ([HTTP/1.1]) and caching ([CACHING]), so that each specification and each major HTTP version can progress independently while sharing the same authoritative definition of core semantics.

http

The 'https' scheme does not rely on the TCP port number to associate authority because the port is outside the secured communication channel and cannot be trusted as definitive. Authority is established solely by TLS certificate verification, allowing HTTPS to operate over any secured transport, not just TCP.

http, tls, security

HTTP/1.1, HTTP/2, and HTTP/3 all rely on the same semantics defined in RFC 9110. HTTP/2 adds multiplexed sessions over TLS+TCP with header compression; HTTP/3 uses QUIC over UDP. None of these versions obsoletes the others since each has distinct benefits depending on deployment context.

http, quic, tls

The 'Set-Cookie' header field commonly appears across multiple field lines in responses and does not use list syntax, violating the general requirement against duplicate field names with non-combinable values. Recipients must handle 'Set-Cookie' as a special case since its values cannot be combined into a single field value.

http

A client MUST ensure that its HTTP requests for an 'https' resource are secured prior to being communicated, and that it only accepts secured responses to those requests.

http, tls, security

A proxy MUST forward unrecognized header fields unless the field name is listed in the Connection header or the proxy is specifically configured to block them. Other recipients SHOULD ignore unrecognized header and trailer fields, enabling HTTP extensibility without updating deployed intermediaries.

http

A recipient MUST accept all three HTTP-date formats (IMF-fixdate, RFC 850, and ANSI C asctime). A sender generating a field containing timestamps MUST generate those timestamps in the IMF-fixdate format.

http

A recipient of CR, LF, or NUL within a field value MUST either reject the message or replace each of those characters with SP before further processing or forwarding. These characters are invalid and dangerous due to the varying ways implementations might parse them.

http, security

A sender MUST NOT generate an 'http' or 'https' URI with an empty host identifier, and a recipient that processes such a URI reference MUST reject it as invalid.

http

A sender MUST NOT generate multiple field lines with the same field name in a message unless the field's definition allows comma-separated recombination. A proxy MUST NOT change the order of field line values when forwarding a message.

http

A sender MUST NOT generate the userinfo subcomponent (and its '@' delimiter) in 'http' or 'https' URI references within messages. A recipient SHOULD parse for userinfo and treat its presence as an error, as it is likely used to obscure the authority for phishing attacks.

http, security, privacy

A server MUST NOT apply a request to the target resource until it receives the entire request header section, since later header fields might include conditionals, authentication credentials, or deliberately misleading duplicate fields that could impact request processing.

http, security

A server MUST NOT assume that two requests on the same connection are from the same user agent unless the connection is secured and specific to that agent, since HTTP is defined as a stateless protocol.

http, security

A server that receives a request header field line, field value, or set of fields larger than it wishes to process MUST respond with an appropriate 4xx (Client Error) status code; ignoring such fields would increase vulnerability to request smuggling attacks.

http, security

All senders and recipients SHOULD support, at a minimum, URIs with lengths of 8000 octets in protocol elements. A recipient MUST be able to parse and process protocol element lengths at least as long as the values it generates for those same elements in other messages.

http

To establish a secured connection for an 'https' URI, a client MUST verify the service's identity using the process defined in RFC 6125 Section 6. A reference identity of type CN-ID MUST NOT be used; the client MUST construct either an IP-ID or DNS-ID from the host. Automated clients that cannot verify MUST log the error and SHOULD terminate the connection.

http, tls, security, pkix

URIs must not carry sensitive information such as session tokens or personal data because they appear in Referer headers, server logs, and browser history. The Referer field discloses the URI of the referring page to the target server, potentially leaking sensitive data embedded in the originating URI.

http, privacy

Conditional request preconditions—If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since, and If-Range—allow clients to make requests contingent on the current state of a resource as identified by ETags (strong or weak validators) or Last-Modified timestamps.

http

Content negotiation fields—Accept (media types with quality values), Accept-Encoding (content codings), Accept-Language (natural languages)—let clients express preferences; the Vary response header indicates which request fields the server used in representation selection.

http

HTTP authentication uses a challenge/response framework: servers issue 401 or 407 responses with WWW-Authenticate or Proxy-Authenticate challenges listing one or more schemes and parameters; clients respond with Authorization or Proxy-Authorization credentials.

http, security

HTTP defines eight standard request methods: GET (transfer current representation), HEAD (same as GET without content), POST (perform resource-specific processing), PUT (replace target resource), DELETE (remove target resource), CONNECT (establish tunnel), OPTIONS (describe communication options), and TRACE (loop-back test). Method tokens are case-sensitive.

http

HTTP status codes are three-digit integers divided into five classes: 1xx Informational, 2xx Successful, 3xx Redirection, 4xx Client Error, and 5xx Server Error. An unrecognized status code MUST be treated as the x00 code of its class (e.g., 499 treated as 400).

http

Safe methods (GET, HEAD, OPTIONS, TRACE) are those whose semantics are read-only; the client does not request or expect any state change on the origin server. Idempotent methods (safe methods plus PUT and DELETE) produce the same result when applied multiple identical times.

http

The 'origin' of a URI is the triple {scheme, host, port} after normalizing scheme and host to lowercase and removing leading zeros from the port. Two origins are distinct if they differ in any of the three components, even when the same entity controls both.

http, security

RFC 9110 creates or updates seven IANA registries: HTTP Method Registry (§16.1.1), HTTP Status Code Registry (§16.2.1), HTTP Field Name Registry (§16.3.1), HTTP Authentication Scheme Registry (§16.4.1), HTTP Range Unit Registry (§16.5.1), HTTP Content Coding Registry (§16.6.1), and HTTP Upgrade Token Registry (§16.7).

http, registry

Credentials conveyed in Authorization header fields are highly sensitive and MUST NOT be sent over connections that are not end-to-end secured. HTTP clients should not reuse credentials across different protection spaces (realms), and servers should not expose credentials in response fields.

http, security

HTTP servers and applications must guard against command injection, code injection, and query injection when request data (path, query, headers, field values) is used to construct system calls, database queries, or scripts. Client-side script injection (XSS) arises when user-supplied content is reflected in responses without sanitization.

http, security

Network intermediaries that act on lower layers without the client's knowledge are indistinguishable from on-path attackers at the protocol level and often introduce security flaws or interoperability problems by mistakenly violating HTTP semantics. Interception proxies are semantically equivalent to active attackers.

http, security

The preferred HTTP-date format is IMF-fixdate: a fixed-length single-zone format such as 'Sun, 06 Nov 1994 08:49:37 GMT'. Senders MUST generate IMF-fixdate; recipients MUST accept all three legacy formats. Two-digit year rfc850-dates appearing more than 50 years in the future MUST be interpreted as the most recent past year with the same last two digits.

http