HTTP, from the request line: what a message means, and how it travels

Every HTTP exchange is two messages, a request and a response, and since June 2022 the standard describes them in two layers: what a message means (methods, status codes, header fields), defined once for every version, and how its bytes travel, defined for each version on its own. The map of the HTTP series: which article reads which part of a message, and in what order.

HTTP looks like a long list of things to learn: the methods, dozens of status codes, a long registry of header fields, cookies, proxies, five versions. It is smaller than the list. Every exchange is one request and one response, and every item on the list is either a part of those two messages or a way of carrying them.

One exchange, two messages

The standard puts the whole protocol in one sentence: "HTTP is a stateless request/response protocol for exchanging 'messages' across a connection" ( 9110, section 3.4). A client sends a request: a method that says what it wants done, the target it wants it done to, header fields that qualify the request, and sometimes a body. The server answers with a status code that says how it went, header fields of its own, and usually a body.

That is also the order in which to learn it. Read a request from the top, the way a server does: the request line (the method and the target), then the fields, then the body and the point where it ends. Read the response the same way: the status, then its fields. The series follows that order, then turns to the layers around the messages.

Two layers since June 2022

For most of its life the standard for HTTP/1.1 mixed two kinds of rule. Some say what a message means: what a GET promises, what a 304 obliges a cache to do, what the Host field is for. Others say how a message is laid out as bytes: text lines that end in a carriage return and a line feed, and a length or a chunked coding that shows where the body stops.

In June 2022 the Internet Engineering Task Force () republished HTTP with the two kinds separated. RFC 9110, HTTP Semantics, "defines aspects of the protocol that are shared by all versions": the methods, the status codes, the fields. Each version then has a document of its own for the wire: RFC 9112 for the text messages of HTTP/1.1, RFC 9113 for the binary frames and multiplexed streams of , and RFC 9114 for , which runs over the QUIC transport instead of TCP.

The split is the most useful idea in the series. A 404 means the same thing over HTTP/1.1 and over HTTP/3, and a GET makes the same promises in both; what differs is how the bytes that carry them are framed. When something breaks, ask which layer it broke in. A server that answers 403 to a request it should allow has a problem of meaning. Two devices that disagree about where a message ends have a problem of framing, and that disagreement is where request smuggling lives.

What HTTP leaves to others

HTTP is stateless by design: each request stands on its own, and the server owes it no memory of the last one. State was added on top. A server sets a cookie with the Set-Cookie header field and the browser returns it with the Cookie field, on the requests the cookie's scope allows (RFC 6265).

The path is rarely direct either. "HTTP enables the use of intermediaries to satisfy requests through a chain of connections", and the standard names three common forms: proxy, gateway and tunnel (RFC 9110, section 3.7). Most of what an operator runs between a browser and a server is one of them, a forward proxy at the office's edge or a reverse proxy in front of the servers, and each one reads, and may rewrite, the messages it relays.

The newest method

The list of methods grew in June 2026. defines QUERY: "As with POST, the input to the query operation is passed as the content of the request rather than as part of the request URI", yet "QUERY requests are safe with regard to the target resource" and "QUERY requests are idempotent". A search too large to fit in an address can now be sent as a body and still be retried, and its response cached, the way a GET's can.

This series, in order

Ten parts: the message read from the top, then the layers around it, then a coda.

Reading a raw HTTP request, and turning it back into something you can run. The message as it actually arrives, request line, fields and body, and the three traps in replaying one.
HTTP Methods: The Verbs of the Web. The first word of the request line, and the two properties, safe and idempotent, that caches, retries and crawlers act on.
HTTP Status Codes: The Five Families. The first digit of the answer does most of the work; then the codes an operator actually meets.
HTTP Headers: The Anatomy of the Metadata. The fields both messages carry: their four working roles, the Host field, and the split between end to end and hop by hop.
HTTP Cookies: State Over a Stateless Protocol. Two header fields that give a stateless protocol a memory, and the rules for when the note travels.
Where an HTTP/1.1 message ends: Content-Length, chunked, and the eight rules. The framing layer: how a receiver knows where one message stops and the next begins, and what smuggling exploits.
HTTP Proxies: Forward vs Reverse, Explicit vs Transparent. The intermediaries: which side a proxy works for, whether the client knows it is there, and the fields that record its passage.
HTTP/0.9 vs 1.0 vs 1.1 vs 2 vs 3: Five Versions of the Web's Protocol. The same meanings carried five ways, from a one-line GET to multiplexed streams over QUIC.
HTTP QUERY: the read that finally carries a body. The newest method: what it fixes, how its responses are cached, and what every layer of infrastructure must check.
Hidden messages in HTTP headers: tributes, jokes and job offers in the overhead. A coda: what people have written into the fields almost nobody reads.