What is HTTP? The Hypertext Transfer Protocol explained

02What does an HTTP request and response look like?

The quickest way to see HTTP is curl -v, which prints what it sends after > and what it receives after <. The transcript below is HTTP/1.1, where messages are plain text lines, from a small test server.

• Request line: the method (GET), the target (/) and the version (HTTP/1.1).
• Request headers: Host names the site, so one server can host many, and RFC 9112 makes it mandatory in HTTP/1.1. User-Agent and Accept describe the client.
• A blank line ends the headers. A GET normally carries no body; a POST would send one here.
• Status line: the version, the status code 200 and the reason phrase OK.
• Response headers describe the body: type, length, last change, and an ETag the client can send back to ask whether it changed.
• Then the body itself, here 74 bytes of HTML.

$ curl -v --http1.1 https://example.test/
* ALPN: offers http/1.1
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server accepted http/1.1
> GET / HTTP/1.1
> Host: example.test
> User-Agent: curl/7.88.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.22.1
< Date: Sat, 24 Oct 2026 12:14:52 GMT
< Content-Type: text/html
< Content-Length: 74
< Last-Modified: Sat, 24 Oct 2026 12:11:23 GMT
< Connection: keep-alive
< ETag: "6adca06b-4a"
< Accept-Ranges: bytes
<
<!doctype html>
<title>Test page</title>
<p>Hello from a test server.</p>

03What are the HTTP methods?

The method says what the client wants done. RFC 9110 defines eight and requires every general-purpose server to support GET and HEAD. PATCH comes from RFC 5789, and QUERY, published as RFC 10008 in June 2026, adds a safe way to send a query in a request body. Three properties decide how a method may be treated.

• Safe: the client asks for no change on the server, so crawlers and prefetchers may send it freely.
• Idempotent: sending it twice has the same intended effect as sending it once, so a client may retry it automatically after a dropped connection.
• Cacheable: a cache may store the response and reuse it.

04What do HTTP status codes mean?

Every response carries a three-digit status code, and the first digit is its class. RFC 9110 requires clients to understand the class even when they do not know the code, treating an unknown code as the x00 code of its class: an unknown 471 is handled like a 400.

05Which HTTP headers matter most?

Headers carry everything except the content: who is asking, what they accept, how long a response may be cached and what state to send back. Header names are case-insensitive, and HTTP/2 and HTTP/3 send them in lower case. A separate group of response headers tells the browser how to protect a page; the security headers guide lists them.

06How do HTTP/1.1, HTTP/2 and HTTP/3 differ?

All three versions carry the same methods, status codes and headers, defined once in RFC 9110. What differs is the wire format and the transport, which changes performance and failure modes, not meaning.

The HTTP/2 transcript of the same request shows it: curl negotiates h2 in the TLS handshake, sends pseudo-headers such as :method and :path, and prints header names in lower case. The status line has no reason phrase, because HTTP/2 has no field for one.

There is no HTTP/3 transcript: the curl 7.88.1 package in Debian 12 is built without HTTP/3. Sites that offer it advertise it in a header such as alt-svc: h3=":443"; ma=86400, which example.com sent on 24 October 2026, and a client that supports HTTP/3 may then try QUIC for later requests.

$ curl -v --http2 https://example.test/
* ALPN: offers h2,http/1.1
* ALPN: server accepted h2
* using HTTP/2
* h2h3 [:method: GET]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: example.test]
> GET / HTTP/2
< HTTP/2 200
< server: nginx/1.22.1
< content-type: text/html
< content-length: 74
< etag: "6adca06b-4a"

07What happens to an HTTP request behind a reverse proxy?

On most production sites the browser never talks to the application server directly. A reverse proxy, load balancer or CDN edge accepts the connection, terminates TLS and opens a second, separate connection to the origin, which can use a different HTTP version and scheme.

The test below sends an HTTP/2 request over TLS to a proxy whose origin echoes what it received. The origin got HTTP/1.1 over plain HTTP, saw the proxy as the connecting address, and learnt the visitor's address and scheme only from headers the proxy added. RFC 7239 standardised this as the Forwarded header; many proxies still send the older X-Forwarded names.

# visitor to proxy: HTTP/2 over TLS
> GET /hello HTTP/2
> Host: example.test
< HTTP/2 200

# proxy to origin, as echoed back by the origin
protocol: HTTP/1.1
host: example.test
x-forwarded-for: 127.0.0.1
x-forwarded-proto: https

08A short history of HTTP, with dates

HTTP has changed its wire format three times but kept its core model, a method, a target, headers and a status code, since the mid-1990s.