Builder · Lesson 13

How does HTTP turn a request into a web response?

HTTP (Hypertext Transfer Protocol) gives a client and server a shared language for resources, metadata, representation, caching, and application outcomes. HTTPS adds TLS protection around that exchange.

The central problem

Give a web exchange precise meaning.

TCP or QUIC can carry bytes, but they do not say which resource a client wants, whether a response is fresh, or whether a server understood the operation. HTTP defines those application-level messages and the rules for interpreting them.

HTTPS is HTTP protected by TLS.TLS protects confidentiality, integrity, and server identity; it does not replace HTTP methods, headers, status codes, or caching rules.

Open the complete HTTP status-code reference

Request message

A request names an operation and its target.

In HTTP/1.1, a request contains a method, request target, and protocol version, followed by headers and an optional body. A typical request might use GET /articles/42 HTTP/1.1, then identify the host, accepted representations, cookies, or conditional state.

01

GET

Retrieve a representation without asking the server to create a new resource.

02

POST

Submit data for processing, often creating a subordinate resource or triggering an action.

03

PUT and PATCH

Replace a resource or apply a partial modification, depending on the method semantics.

04

HEAD and OPTIONS

Inspect response metadata or discover supported methods and communication options.

DELETE asks the server to remove a resource. Method meaning matters: a client should not treat every request as interchangeable, and a server should document whether an operation is safe, idempotent, or cacheable.

Response message

A response reports an outcome and a representation.

A response contains a status code, headers, and an optional body. The first digit groups the result: informational 1xx, successful 2xx, redirection 3xx, client error 4xx, or server error 5xx.

01

200 OK

The request succeeded and the body can represent the result.

02

201 Created

The request created a resource, often with a Location header.

03

301 and 302

The client is told that a resource or route has another location or temporary target.

04

304 Not Modified

A conditional request can reuse a fresh cached representation.

Common failures include 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 405 Method Not Allowed, 429 Too Many Requests, and 500 Internal Server Error. A status code is evidence about the HTTP exchange, not proof that every upstream network layer worked perfectly.

Web resources

A web page is assembled from several HTTP responses.

HTML (Hypertext Markup Language) provides the document structure. CSS (Cascading Style Sheets) describes presentation such as layout, colors, typography, and responsive rules. JavaScript adds executable behavior. They are different resources and can be requested, cached, compressed, secured, and invalidated independently.

01

HTML

The browser parses the document structure and discovers linked stylesheets, scripts, images, and other resources.

02

CSS

A stylesheet is commonly fetched with an HTTP GET and served with Content-Type: text/css. The browser applies its rules to the document.

03

JavaScript

A script can modify the document, request more resources, and react to user input after the initial response.

04

Cache identity

URLs, validators, Cache-Control, and versioned filenames influence whether the browser reuses or refetches an asset.

CSS is part of the web application, not a network layer.HTTP delivers the stylesheet; the browser interprets CSS. A successful CSS response proves delivery of the resource, not that every visual rule is valid or applied.

Metadata and state

Headers connect one exchange to the next.

Content-Type describes the representation, Content-Length or transfer framing describes its size, and Accept lets a client express preferred formats. Location carries a redirect or newly created resource. Authorization carries credentials according to the selected authentication scheme.

HTTP is stateless by default: each request carries the context needed to interpret it. Cookies add application-managed state with Set-Cookie and Cookie; secure deployments should consider Secure, HttpOnly, SameSite, expiration, and scope. Cookies do not make a connection encrypted, and authentication design still belongs to the application.

Caches use freshness information such as Cache-Control and validators such as ETag or Last-Modified. A client can send If-None-Match or If-Modified-Since and receive 304 when its stored representation remains valid. A CDN may serve a cache hit without contacting the origin.

Evolution

The semantics remain familiar while the wire transport evolves.

01

HTTP/1.0

Typically used one request and response per connection, with limited reuse.

02

HTTP/1.1

Added persistent connections, Host, chunked transfer, caching controls, and a richer method model.

03

HTTP/2

Uses binary framing, multiplexed streams, header compression, and stream prioritization over a connection.

04

HTTP/3

Maps HTTP semantics onto QUIC, using independent streams to reduce transport-level head-of-line blocking.

HTTP/2 and HTTP/3 change framing and connection behavior, not the fundamental meaning of methods, status codes, headers, and representations. HTTPS normally means HTTP carried through TLS; HTTP/3 uses QUIC's integrated cryptographic handshake and cannot be reduced to simply changing a port.

Mini investigation

Inspect a response clue

Select the observation and identify the strongest next check.

NEXT CHECK304 Not Modified

The server accepted a conditional request and says the cached representation remains valid.

Inspect ETag, Last-Modified, Cache-Control, and the request validator.

Knowledge check

Test your HTTP model

Answer ten questions.

0 / 10