Web · foundation
HTTP request and response
HTTP is a stateless application protocol in which a client sends a request containing a method, target, fields, and optional content, and a server returns a response containing a status code, fields, and optional content.
Why it matters
Reading both sides of the exchange turns vague web failures into concrete questions about method semantics, authentication headers, content negotiation, redirects, status codes, and response bodies.
Mental model
How to reason about http request and response
One logical HTTP exchange is a typed request followed by a typed response. Its message semantics are distinct from the underlying connection, which may be reused, multiplexed, closed, or implemented over different transport versions.
Analogy
An HTTP exchange resembles a structured service ticket: the request names an action and target with supporting fields, and the response records an outcome code, metadata, and possibly a result document.
Examples
See the boundary, not just the happy path
Worked example · Inspect response fields and content
curl -i https://example.com/-i includes the response status line and header fields before the body. A 200 status describes the response semantics; it does not guarantee that the body contains the data an application expected.
Worked example · Send conditional request metadata
curl -i -H 'If-None-Match: "abc123"' https://example.com/itemThe client supplies a validator. If the current representation matches it, the server can respond 304 without representation content, saving transfer while preserving HTTP cache semantics.
Useful contrast · HTTP exchange versus TCP connection
Several HTTP requests can share one connectionAn HTTP request is not synonymous with opening a TCP connection. HTTP/1.1 can reuse connections, while HTTP/2 and HTTP/3 can multiplex concurrent exchanges.
Common mistakes
Misconceptions to remove early
Treating every non-200 status as a transport failure
A 404 or 500 is a successfully received HTTP response describing an application-level outcome. DNS, connection, and TLS failures occur before an HTTP response exists.
Assuming stateless means no session behavior
HTTP messages do not inherently retain conversational state, but applications build sessions with cookies, tokens, URLs, and server-side data. The application state is explicit around the protocol.
Quick check
Can you predict the result?
1. A server returns HTTP 404. Which layer completed successfully enough to report that result?
- • The HTTP exchange completed and returned an application-level response.
- • DNS necessarily failed before a connection was attempted.
- • No response bytes reached the client.
2. Why is one HTTP request not the same thing as one TCP connection?
Keep building