HTTP, the Hypertext Transfer Protocol, is the stateless request and response protocol that browsers, APIs and servers use to exchange web resources. Its semantics are defined in RFC 9110, and plain http URLs use TCP port 80 by default. HTTP itself sends everything unencrypted; the encrypted variant is HTTPS.
How it works
A client sends a request message and the server answers with one response message. In HTTP/1.1 (RFC 9112) both are plain text: a start line, zero or more header lines, an empty line, then an optional body. Every line ends with CRLF.
- Request line: a method, a request target and a version, such as
GET /hello HTTP/1.1. Methods are case-sensitive and, by convention, uppercase.
- Status line: the version, a three-digit status code and a reason phrase. The first digit sets the class: 1xx informational, 2xx success, 3xx redirection, 4xx client error, 5xx server error.
- Methods: RFC 9110 defines eight: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS and TRACE. All general-purpose servers must support GET and HEAD.
- Stateless: each request must be understandable on its own. State such as a login is carried in each request, for example in an Authorization header, not by the connection.
- Host header: HTTP/1.1 clients must send one, and servers reject none or several. It lets one IP address serve many sites.
This exchange was sent by a Python socket to a local Node.js server. The empty line ends the header section.
GET /hello HTTP/1.1
Host: localhost:8081
Connection: close
HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Date: Mon, 05 Oct 2026 09:19:21 GMT
Connection: close
Content-Length: 6
hello
What port does HTTP use?
HTTP uses TCP port 80 by default when a URL starts with http and gives no port. An explicit port, as in http://example.com:8080/, overrides it. HTTP/3 is different: it runs over QUIC on UDP, and a server may use any UDP port, announced to clients through the Alt-Svc header.
What is the difference between HTTP/1.1, HTTP/2 and HTTP/3?
All three carry the same semantics from RFC 9110, so methods, status codes and headers mean the same thing. Only the wire format changes.
- HTTP/1.1 (RFC 9112): text messages, answered strictly in order on each connection, so browsers open several TCP connections.
- HTTP/2 (RFC 9113): binary frames, many concurrent streams on one TCP connection, and HPACK header compression. Over TLS it is selected with the ALPN identifier
h2. A lost TCP packet still stalls every stream.
- HTTP/3 (RFC 9114): the same model over QUIC on UDP, with QPACK compression and ALPN identifier
h3. QUIC recovers loss per stream, so one lost packet need not stall the others.
HTTP/2 and HTTP/3 drop the request line and use pseudo-header fields instead: :method, :scheme, :authority and :path. Header names are lowercase.
Common pitfalls
- Missing Host header: an HTTP/1.1 request without Host must be rejected with 400 Bad Request. Local Node.js 22 returned exactly that.
- Treating http as private: every network device on the path can read or change plain HTTP. Passwords and tokens belong on HTTPS only.
- State-changing GET requests: GET is defined as safe, and crawlers, link prefetchers and caches assume it. A
GET /delete?id=7 link will eventually be fetched by a bot. Use POST, PUT or DELETE.
- Assuming header case: HTTP/1.1 field names are case-insensitive, but HTTP/2 and HTTP/3 send them lowercase. Code that compares
Content-Type exactly breaks.
- Assuming one connection means one user: HTTP/1.1 reuses connections, but a server must not assume two requests on one connection come from the same user agent.
Related terms
- HTTPS — HTTP carried over a TLS connection, using port 443 by default
- TLS — the protocol that adds encryption beneath HTTPS
- REST — an API style built on HTTP methods and status codes
- Idempotent — the property that decides which HTTP methods are safe to retry
- CORS — browser rules that restrict cross-origin HTTP requests
- WebSocket — a protocol that starts as an HTTP request and then upgrades
See also