RFC 9110 · June 2022 · Internet Standard

What HTTP means, no matter how it travels.

The official title is "HTTP Semantics." What it actually settles: the meaning of HTTP itself, its methods, status codes and header fields, lifted out of any single version so that HTTP/1.1, HTTP/2 and HTTP/3 can all point back to one definition.

Status: ✓ Still current
Also known as: STD 97
Replaces: RFC 2818, RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694
Updates: RFC 3864

Written by Noel Lang · IT trainer

TL;DR

RFC 9110 defines the semantics of HTTP: what methods (GET, POST, …), status codes (200, 404, …) and header fields mean, independent of any version. Published in June 2022 as STD 97, it consolidated the scattered 723x series (and the long-dead RFC 2616) into one document. It is now the single definition HTTP/1.1, HTTP/2 and HTTP/3 all point back to. When someone says “the HTTP spec” today, this is it.

The problem it solves

For most of HTTP’s life, its meaning and its wire format were welded together in one document. RFC 2616 from 1999 described HTTP/1.1 as a single thing: what a GET means and how to type it out on a TCP connection, all in the same paragraphs.

That was fine until HTTP stopped being one thing. HTTP/2 arrived in 2015 with a completely different, binary wire format, and HTTP/3 later moved off TCP onto QUIC entirely. All three carry the same methods, the same status codes, the same headers. But there was no clean document that defined that shared meaning on its own. Every new version had to re-reference or re-explain the parts that never changed.

RFC 9110 untangles it. It pulls the version-independent semantics into one place, and leaves each version to define only how its bytes go on the wire: RFC 9112 for HTTP/1.1, RFC 9113 for HTTP/2, RFC 9114 for HTTP/3. The result is that “what a 404 means” is written down exactly once, and every version borrows it.

The great re-sorting

Think of 25 years of HTTP knowledge as a house that kept getting extensions bolted on. RFC 2616 was one big room where the dictionary sat on the same shelf as the plumbing manual. In 2014 the room was split into six (the 723x series), which helped, but the dictionary and the plumbing were still tangled across them.

The 2022 rewrite finally sorted the shelves properly. Everything that is meaning, the words HTTP speaks, went into RFC 9110. Everything that is mechanism, how a particular version moves bytes, went into its own transport document. Caching, big enough to stand alone, got its own book ( RFC 9111 ). Nothing about how HTTP behaves changed. The knowledge was just filed where you can find it.

The practical upshot: if you are reading about a method or a status code, you want RFC 9110, and only 9110. You almost never need to open 9112, 9113 or 9114 unless you are writing a server or a client library.

The HTTP family, after 2022

One document defines the meaning; the transport specs sit on top and define the bytes. The old all-in-one specs are kept only for history.

Semantics at the base, transports on top. That vertical split is the whole idea of the 2022 rewrite.

Semantics versus syntax, in one example

The word “semantics” does a lot of work here, so it helps to see it. Semantics is the meaning: a GET requests a representation of a resource, safely, with no side effects. Syntax is how a particular version writes that request down in actual bytes.

In HTTP/1.1, a request is human-readable text: a request line, then header lines, each ending in a carriage return and line feed. In HTTP/3, the same request is a compressed set of fields inside a binary QUIC frame, unreadable without tooling. Different bytes, byte for byte nothing alike. Same GET, same target, same meaning. RFC 9110 is the document that says what that meaning is, so both wire formats can agree on it without repeating themselves.

One GET, two wire formats

The same request expressed by two versions. The syntax is unrecognizable across them; the semantics, defined once in RFC 9110, are identical.

If you can read the left box, you are reading syntax. What both boxes share is semantics.

The methods, and the promises they make

Two properties decide almost every design argument. Safe means read-only, no intended change. Idempotent means repeating the request lands on the same end state. This table is the one interviewers keep asking about:

Method	What it guarantees
GET	Safe and idempotent. Fetch a representation, change nothing. Because it changes nothing, the answer can be cached and prefetched. Never put side effects behind a GET.
HEAD	Safe and idempotent. Like GET, but only the headers come back, no body. Used to check size or freshness cheaply.
POST	Neither safe nor idempotent. Submit data to be processed. Sending it twice may create two orders. This is the one method with no repeat guarantee.
PUT	Idempotent, not safe. Replace the resource at this URI with what you send. Do it once or ten times, the end state is identical.
DELETE	Idempotent, not safe. Remove the resource. Deleting an already-deleted thing still leaves it deleted, so repeating is harmless.
OPTIONS	Safe and idempotent. Ask what a resource or server supports. The backbone of CORS preflight checks.
TRACE	Safe and idempotent. A loopback diagnostic that echoes the request back. Often disabled for security.
CONNECT	Neither safe nor idempotent. Establish a tunnel through a proxy, the mechanism behind HTTPS via an HTTP proxy.

Status codes, by first digit

You do not memorize 60-plus codes, you learn what the first digit promises. RFC 9110 defines five classes:

1xx Informational

Hold on, still working. A provisional signal that the request was received and the process continues. Rare in daily life: 100 Continue, 101 Switching Protocols (the WebSocket upgrade), 103 Early Hints.
2xx Successful

It worked. The request was received, understood and accepted. 200 OK, 201 Created after a successful POST, 204 No Content when there is nothing to send back.
3xx Redirection

Look elsewhere. More action is needed to finish the request, usually following a new location. 301 Moved Permanently, 304 Not Modified (your cached copy is still fresh), 308 Permanent Redirect.
4xx Client error

You messed up. The request was malformed or not allowed. 400 Bad Request, 401 Unauthorized, 403 Forbidden, and the famous 404 Not Found.
5xx Server error

We messed up. The request looked fine, but the server failed to handle it. 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable.

Which RFC is HTTP, really?

This is the question the spec text never answers cleanly, and the reason people end up citing dead documents. HTTP is not one RFC. Since June 2022 it is a small family, and which one you want depends on what you mean.

The short version: for meaning, you want RFC 9110, always. For a specific version’s wire format, you want 9112, 9113 or 9114. And whatever you do, do not reach for RFC 2616: it lost its authority in 2014 and was superseded again in 2022, yet it is still the top search result, which is exactly how outdated advice spreads.

Which document to cite

A lookup table for the eternal confusion:

If you mean	The document, and whether it is current
"HTTP", the meaning	RFC 9110 (2022). Methods, status codes, headers. Current, STD 97. This is what people should mean today.
HTTP/1.1, the wire format	RFC 9112 (2022). The text-line syntax. Current, STD 99. It obsoleted RFC 7230.
HTTP/2	RFC 9113 (2022). Binary framing and multiplexing over one TCP connection. Current, obsoleted RFC 7540.
HTTP/3	RFC 9114 (2022). The same semantics carried over QUIC instead of TCP. Current.
HTTP caching	RFC 9111 (2022). Split out from semantics into its own document, STD 98. It obsoleted RFC 7234.
"The HTTP/1.1 RFC" (2616)	Obsolete since 2014, superseded again in 2022. Historical only. Do not cite it for current behavior.

What RFC 9110 actually says

The document is long (around 200 pages) because it absorbed several older ones. The map, in case you visit:

Section	In plain words
2–3 · Architecture & terms	Clients, servers, intermediaries, resources, representations. The shared vocabulary every version inherits.
4 · URIs (http and https)	What the http and https schemes mean, built on the URI syntax of RFC 3986. Where HTTPS is anchored.
5–8 · Fields, content, negotiation	How header fields work, what a message body is, and how client and server agree on format and language.
9 · Methods	The eight methods and their properties: which are safe, which are idempotent, which are cacheable.
10–14 · Selected header fields	Referer, Allow, conditional requests, range requests, authentication. The parts the 723x series covered separately.
15 · Status codes	The five classes and every registered code, including 418, reserved but unused, kept so nobody assigns it by accident.

Things people get wrong

"RFC 2616 is the HTTP spec."

It was, until 2014. RFC 2616 (1999) has been obsolete for over a decade: first replaced by the six-document 723x series, then reorganized again in 2022 into RFC 9110 and the transport specs. Citing 2616 today points people at a document that has been wrong on the details for years. The current answer is RFC 9110.
"HTTP/2 and HTTP/3 added new methods."

They did not. Methods and status codes live in RFC 9110 and are shared by every version. What HTTP/2 and HTTP/3 changed is purely the wire format: binary frames, multiplexing, header compression, and for HTTP/3 a move from TCP to QUIC. A GET means exactly the same thing in all three.
"RFC 9110 defines HTTPS."

Only the outer shell. RFC 9110 defines the https URI scheme and absorbed the old RFC 2818, so this is where HTTPS is anchored. But it does not define the encryption. That is TLS, a completely separate protocol (RFC 8446 for TLS 1.3). HTTPS is simply HTTP semantics carried over a TLS connection.
"PUT versus POST is a matter of taste."

No, RFC 9110 gives them different, testable properties. PUT is idempotent: sending it twice leaves the same end state. POST is not: sending it twice may create two records. PUT replaces a resource at a URI you already know; POST hands data to an endpoint to process however it likes. The choice is defined behavior, not style.

Where you'll meet RFC 9110

You rarely read it, but you rely on it constantly. A field guide:

You see	You're relying on 9110 for
MDN method and status pages	Every MDN reference for a method or status code links back to its RFC 9110 definition as the normative source.
A REST API design argument	When someone insists PUT must be idempotent or POST must not be cached, they are quoting 9110, whether they name it or not.
curl -X and -I	The methods curl sends and the headers it prints are exactly the ones 9110 defines. HEAD behind -I, methods behind -X.
A Problem Details JSON body	RFC 9457 pairs a 9110 status code with a structured explanation. The status code half is pure 9110 vocabulary.
A 100 Continue in an upload	That provisional 1xx handshake before a large PUT or POST body is defined in 9110, section 15.

Questions people actually ask

What is the difference between RFC 9110 and RFC 9112? +

RFC 9110 defines what HTTP means: methods, status codes and headers, the same across every version. RFC 9112 defines only how HTTP/1.1 puts that meaning on the wire, as text lines ending in CRLF with chunked transfer encoding. 9110 is the vocabulary, 9112 is one way of speaking it. HTTP/2 and HTTP/3 reuse the same 9110 vocabulary with their own wire formats (9113 and 9114).

What is the difference between RFC 9110 and RFC 2616? +

RFC 2616 (1999) was the single all-in-one HTTP/1.1 specification and has been obsolete since 2014. Its content was first split into the 723x series, then reorganized again in 2022 so that meaning (RFC 9110) is separated from wire format (RFC 9112). For anything current, cite 9110, never 2616.

Is RFC 2616 still valid? +

No. RFC 2616 was declared obsolete in June 2014 and again superseded in June 2022. It is kept online for historical reference only. The living definition of HTTP is now split across RFC 9110 (semantics) and the version-specific specs 9112, 9113 and 9114.

Does RFC 9110 replace RFC 7231? +

Yes. RFC 9110 obsoletes the semantics half of the 723x series (7230, 7231, 7232, 7233, 7235) along with several smaller HTTP RFCs, and rolls them into one document. It is now STD 97. Caching, which was RFC 7234, moved separately into RFC 9111.

What does "HTTP semantics" actually mean? +

The parts of HTTP that stay the same no matter the version: what GET, POST and DELETE mean, what a 404 or 301 signals, how header fields like Content-Type work. RFC 9110 defines those, while separate RFCs define how the bytes are framed on the wire for each version.

Did HTTP/2 and HTTP/3 add new methods or status codes? +

No. Methods and status codes are defined once, in RFC 9110, and shared by every version. HTTP/2 and HTTP/3 changed only the wire format (binary framing, multiplexing, header compression). A GET is still a GET and a 404 is still a 404, whether it arrives as HTTP/1.1 text or an HTTP/3 QUIC frame.

What was HTTP/0.9? +

The original 1991 version of HTTP: a single request line like GET /page, with no headers, no status codes and no version number. It was never published as an RFC of its own. Everything that came after, up to RFC 9110, is the story of adding the meaning that 0.9 lacked.

Does RFC 9110 define HTTPS? +

Partly. RFC 9110 defines the https URI scheme and absorbed the old RFC 2818 ("HTTP over TLS"), so it is where HTTPS is anchored. But it does not define the encryption itself: that is TLS, a separate protocol (RFC 8446 for TLS 1.3). HTTPS is HTTP semantics carried over a TLS connection.

Referenced by

Other explainers on this site that point back to this RFC:

How RFC 9110 connects

What came before

RFC 2616 (1999) was the HTTP/1.1 document for 15 years. Obsolete since 2014, superseded again in 2022. When people say "the HTTP RFC" and mean 2616, they are citing a decade-dead document.