RFC 9110: HTTP Semantics Deep Dive

Why RFC 9110 Matters

In 2022, the IETF published a landmark revision of HTTP standards. The previous monolith RFC 7230–7235 (2014) was split into two orthogonal documents:

RFC 9110 — HTTP Semantics (the *what*: methods, status codes, headers, content negotiation)
RFC 9112 — HTTP/1.1 Message Syntax (the *how* for HTTP/1.1)

RFC 9110 is version-agnostic. Its semantics apply equally to HTTP/1.1, HTTP/2, and HTTP/3. Understanding it means understanding HTTP at its core, not tied to any wire format.

HTTP's Layered Architecture

RFC 9110 formalizes HTTP as a transfer protocol layered on top of a lower-level messaging substrate (TCP, QUIC). The key architectural elements:

Resources — anything identifiable by a URI
Representations — a view of a resource's current or desired state (bytes + metadata: content type, encoding, language)
Messages — requests and responses carrying representations
Connections — transport-layer channels carrying messages

This layering enables the same HTTP semantics to work over different transports (TCP in HTTP/1.1+2, QUIC in HTTP/3) without changing what methods mean or how status codes behave.

Methods and Their Semantics

RFC 9110 defines nine standard methods with precise semantic properties:

Method	Safe	Idempotent	Body in Request
`GET`	Yes	Yes	Not recommended
`HEAD`	Yes	Yes	No
`OPTIONS`	Yes	Yes	Optional
`TRACE`	Yes	Yes	No
`POST`	No	No	Yes
`PUT`	No	Yes	Yes
`PATCH`	No	No	Yes
`DELETE`	No	Yes	Optional
`CONNECT`	No	No	No

Safe means the method has no observable side effects on the server. Clients may call safe methods freely (prefetch, retry). Idempotent means multiple identical requests have the same effect as one — safe to retry after network failure.

RFC 9110 also clarifies that PATCH is neither safe nor idempotent. A PATCH applying an increment (qty += 1) applied twice has a different result than applied once.

Status Code Semantics

RFC 9110 Section 15 provides authoritative definitions for each status code class:

1xx Informational — provisional responses; processing continues
2xx Successful — the request was received, understood, and accepted
3xx Redirection — further action needed to complete the request
4xx Client Error — the request contains bad syntax or cannot be fulfilled
5xx Server Error — the server failed to fulfill a valid request

Key clarifications in RFC 9110 compared to earlier RFCs:

301/302 redirects may change the method to GET (historically broken behavior now formally recognized)
307/308 preserve the method through redirects
303 See Other is specifically for POST→GET redirect after form processing
422 Unprocessable Content (formerly Unprocessable Entity) is now in the core spec, not just WebDAV

Content Negotiation Framework

RFC 9110 Section 12 formalizes proactive (server-driven) and reactive (agent-driven) negotiation, plus the newer transparent negotiation by proxies.

The Accept-* header family:

Accept: application/json, text/html;q=0.9, */*;q=0.5
Accept-Language: en-US, en;q=0.9, fr;q=0.7
Accept-Encoding: gzip, br, zstd

When no acceptable representation exists, the correct response is 406 Not Acceptable. The Vary header must list all headers that influence content selection so intermediate caches store separate copies.

Conditional Requests

RFC 9110 Section 13 defines conditional request headers that enable efficient cache revalidation and optimistic concurrency:

Header	Mechanism	Use Case
`If-None-Match`	ETag comparison	Cache revalidation (GET)
`If-Match`	ETag comparison	Optimistic locking (PUT/PATCH)
`If-Modified-Since`	Date comparison	Cache revalidation (GET)
`If-Unmodified-Since`	Date comparison	Optimistic locking (PUT)

When conditions fail: If-None-Match returns 304, If-Match returns 412 Precondition Failed.

Range Requests

RFC 9110 Section 14 standardizes partial content retrieval — essential for video streaming and resumable downloads:

GET /video.mp4 HTTP/1.1
Range: bytes=0-1048575

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-1048575/52428800
Accept-Ranges: bytes

Servers signal range support with Accept-Ranges: bytes. Without this header, clients must not issue range requests.

Connection Management

RFC 9110 deliberately keeps connection management abstract — the specifics belong in RFC 9112 (HTTP/1.1) and RFC 9113 (HTTP/2). What RFC 9110 *does* define is that HTTP is stateless: each request carries all context needed for the server to respond. Sessions, authentication tokens, and preferences must be in request headers or the body — not implicit connection state.