How HTTP Request and Response Work, Step by Step

Every web page, image and API call on the internet travels over HTTP, the Hypertext Transfer Protocol. A client sends a request that names an action and a resource. A server reads that request and sends back a response that carries a status code, headers and, usually, a body. The pattern is simple, and nearly every web tool, from browsers to command-line utilities, is built around it.

This article explains each part of the exchange, lists the methods and status codes you will see most often, and shows what happens between typing a URL and seeing a page. It describes the widely used protocol versions as they are standardized, without relying on any single product.

The steps behind one page load

Entering a URL such as https://example.com/articles/42 starts a chain of steps. The browser first resolves the host name to an IP address through DNS. It then opens a TCP connection to the server, usually on port 443 for HTTPS or port 80 for plain HTTP. For HTTPS it runs a TLS handshake to agree on encryption keys and to verify the server certificate. Only after that does it send the HTTP request.

The server processes the request and returns a response. The browser then parses the body, which is often HTML, and requests further resources such as stylesheets, scripts and images. Each of those requests follows the same request and response pattern.

Understanding this order helps with debugging. A slow page may be caused by DNS lookup time, connection setup, server processing, or the size of the response, and each of those has different fixes.

Anatomy of a request

An HTTP request has three parts. The request line states the method, the path and the protocol version. The headers follow as name and value pairs, and they describe the client, the content it accepts and any credentials or cookies. An optional body carries data, for example the fields of a submitted form or a JSON document.

Important request headers include Host, which names the site when several sites share one IP address, and Accept, which tells the server which content types the client can handle. Authorization carries credentials, and Cookie carries values the server previously set for this browser. Content-Type describes the format of the body when one is present.

Common methods and what they mean

The method states the intent of the request. Two properties matter in practice. A safe method is meant only to read data and should not change server state. An idempotent method produces the same result when repeated, so a client can retry it after a network failure without causing duplicate effects.

Method	Typical use	Safe	Idempotent
GET	Read a resource	Yes	Yes
HEAD	Read headers only	Yes	Yes
POST	Create a resource or submit data	No	No
PUT	Replace a resource entirely	No	Yes
PATCH	Change part of a resource	No	Not always
DELETE	Remove a resource	No	Yes
OPTIONS	Ask which methods are allowed	Yes	Yes

These properties come from the HTTP specification. A server that performs a deletion on a GET request breaks caches, crawlers and prefetchers, which assume that GET is safe. Following the method semantics keeps the whole web working as expected.

Anatomy of a response

A response begins with a status line that gives the protocol version, a three-digit status code and a short reason phrase. Headers follow, and then the body. Response headers control caching, content type, cookies and security policies. Content-Type tells the browser whether the body is HTML, JSON or an image. Cache-Control states how long the response may be stored. Set-Cookie asks the client to store a cookie.

The body is optional. A 204 No Content response, for example, confirms success without sending any data, and a HEAD response has headers only.

Status codes you will meet every day

Status codes are grouped by their first digit. The groups are simple, and the specific codes inside them are worth memorizing because they tell you what to fix.

Range	Meaning	Examples
1xx	Informational	100 Continue, 101 Switching Protocols
2xx	Success	200 OK, 201 Created, 204 No Content
3xx	Redirection	301 Moved Permanently, 302 Found, 304 Not Modified
4xx	Client error	400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found
5xx	Server error	500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable

A 401 means the request lacks valid credentials, while a 403 means the server understood the request and refuses it. A 301 tells clients to use the new address permanently, which search engines also learn from. A 304 is the cheap answer to a conditional request: the cached copy is still valid, so no body is sent.

Protocol versions

HTTP/1.1, standardized in its modern form in RFC 9112, sends text messages over a connection and can reuse that connection for several requests in turn. Browsers open several connections per host to load resources in parallel, because each connection handles one response at a time.

HTTP/2, defined in RFC 9113, uses a binary framing layer and multiplexes many requests over one connection. It also compresses headers. Server push, one of its features, was dropped by Chrome in 2022, but multiplexing remains the main improvement.

HTTP/3, defined in RFC 9114, runs over QUIC, which uses UDP as its transport. QUIC integrates encryption and avoids some stalls that occur when one lost packet blocks an entire TCP connection. The semantics of methods, headers and status codes are the same across all three versions, so application code rarely needs to change.

Designing a request-friendly API

Good HTTP design follows the same rules that clients expect. Use GET only for reads, return 201 with a Location header after creating a resource, and return 404 when the resource does not exist. Return 422 or 400 for invalid input, depending on your conventions, and document which one you use.

Caching headers pay off quickly. An ETag or Last-Modified value lets a client send a conditional request and receive a 304 when nothing changed. Setting Cache-Control on static assets lets browsers reuse them across page loads.

Debugging with the tools you already have

Browser developer tools show the request line, headers, status and timing for every resource on a page. Command-line tools such as curl can print response headers with a flag, which is useful for checking redirects and caching behavior without a browser. Comparing what you expect with the raw headers quickly reveals missing content types, wrong status codes and cookies that never arrived.

Key takeaways

HTTP is a request and response protocol. A client names a method and a resource, and the server replies with a status code, headers and an optional body. Methods carry meaning through safety and idempotence, and status codes group every outcome into five classes.

Protocol versions change how bytes move across the network, but the vocabulary stays the same. Learning the request line, the common headers and the status code ranges gives you a reliable way to reason about almost any web problem.