How HTTP requests actually work
An HTTP request is the unit of work behind a page load, an API call and most browser driven application behaviour. It looks simple from application code, but it crosses DNS, trans…
An HTTP request is the unit of work behind a page load, an API call and most browser driven application behaviour. It looks simple from application code, but it crosses DNS, transport, TLS, HTTP semantics, caches, redirects, content negotiation and server routing before a response reaches the caller. This post walks the whole chain end to end, and points to deeper posts on the layers that deserve their own treatment.
The request starts with a URL
A browser or HTTP client starts with a URL. The URL identifies the scheme, host, optional port, path, query string and fragment. The fragment is not sent to the server because it is client side state.
For an HTTPS URL, the client needs a network route to the host and a secure connection before it can send the HTTP message. For an HTTP URL, the request is sent without TLS protection and can be observed or changed by parties on the network.
DNS resolves the host name
The host name must be resolved to an address before the client can connect. The client normally asks a recursive resolver, which may answer from cache or query authoritative DNS servers. The answer can include IPv4 addresses, IPv6 addresses or aliases that lead to other records.
DNS answers have a time to live. The TTL controls how long resolvers are expected to cache the answer. A low TTL can make planned changes reach users sooner, but it does not force every resolver to discard old answers instantly. For how resolution actually behaves in practice, see dns-for-developers.
The client opens a transport connection
Most HTTP traffic uses TCP or QUIC as the transport. HTTP/1.1 and HTTP/2 commonly run over TCP. HTTP/3 runs over QUIC, which uses UDP.
With TCP, the client opens a connection to the server address and port. For HTTPS, port 443 is the conventional default. For plain HTTP, port 80 is the conventional default. A URL can override the port.
TLS protects HTTPS
For HTTPS over TCP, the TLS handshake happens before the HTTP request is sent. The server presents a certificate chain for the requested host name. The client validates that the certificate is trusted, unexpired, not rejected by policy and valid for the host name.
The handshake also negotiates cryptographic parameters and establishes keys, after which HTTP bytes are protected for confidentiality and integrity on the network path. For how certificates and chains are validated, see understanding-tls-and-certificates.
The HTTP message has method, target, fields and content
An HTTP request carries a method, a request target, header fields and optional content. The method says what the client wants to do. Common methods include GET, HEAD, POST, PUT, PATCH and DELETE.
Header fields carry metadata. Examples include Accept, Content-Type, Authorization, Cookie, If-None-Match and Cache-Control. A request can also carry content, for example a JSON document in a POST request or form data from a browser submission.
HTTP semantics are shared across protocol versions. HTTP/1.1, HTTP/2 and HTTP/3 encode messages differently on the wire, but the meaning of methods, status codes, header fields and content is defined at the semantic layer.
The server selects a handler
The server receives the request and maps it to application behaviour. That mapping can use the host, path, method, headers, authenticated identity and content. A reverse proxy, load balancer, CDN or application gateway may process the request before the application sees it.
The application should not treat the method as decoration. A GET request should be safe to make without changing server state. A POST request is normally used when the request asks the server to process submitted content or create a subordinate resource.
The response tells the client what happened
The response has a status code, header fields and optional content. Status codes are grouped by class. A 2xx status means success, a 3xx status means redirection, a 4xx status means a client side problem and a 5xx status means a server side problem.
The response headers describe how the client should handle the content. Content-Type identifies the media type. Cache-Control controls caching behaviour. Set-Cookie asks the browser to store a cookie. Location is used with redirects and some creation responses.
Redirects can trigger more requests
A 3xx response can point the client at another URL. The client may then issue a follow up request. Redirect handling is part of the total request cost because each redirect can require extra DNS, connection and TLS work unless an existing connection can be reused.
Use redirects deliberately. They are useful for canonical URLs and migrations, but chains of redirects add latency and make failure modes harder to diagnose.
Caches can answer without the origin
A request may be satisfied by a browser cache, service worker cache, proxy cache or CDN cache. A cache can reuse a stored response when it is still fresh, or when validation with the origin confirms it is still current.
Validation commonly uses ETag with If-None-Match or Last-Modified with If-Modified-Since. If the origin returns 304 Not Modified, the client reuses the stored response body and applies updated response metadata. For freshness rules and cache layering, see a-practical-guide-to-caching-on-the-web.
Connection reuse matters
Modern clients avoid opening a new connection for every request when they can. HTTP/1.1 can reuse a TCP connection for multiple requests. HTTP/2 and HTTP/3 can multiplex multiple streams over one connection.
Connection reuse reduces repeated DNS, transport and TLS cost. It also means one page view can share infrastructure work across many assets and API calls.
How to debug a request
Start by separating the layers. Check DNS resolution first. Then check whether a connection can be opened. Then check TLS certificate validation. Then inspect the HTTP request and response, including method, URL, status code, headers and body.
Browser developer tools are enough for many frontend issues. For service, proxy and API issues, compare the browser view with server logs and a command line client. Differences often come from cookies, credentials, headers, redirects, content negotiation or cache state.
Conclusion
An HTTP request is not just a line of application code. It is a chain of resolution, connection setup, optional TLS negotiation, HTTP semantics, server routing, cache decisions and response handling. Debugging gets easier when each layer is checked separately and the request is treated as a complete exchange rather than a single function call.