1st Principles
Menu

Web · 34 min read

HTTP

The application protocol of the web: structured requests and responses for transferring documents and calling APIs, including methods, status codes, and caching metadata.

Why this exists

Browsers and servers needed a shared language for 'give me this resource' and 'here is the result.' Without a common request/response shape, every site would invent a private dialect.

HTTP is that language, evolved from simple document fetch into the backbone of APIs, apps, and intermediaries (caches, proxies, CDNs).

Learning HTTP well pays off twice: you can read the Network panel like a story, and you can design APIs that intermediaries and clients can handle safely.

Axioms & primitives

  1. 01A request targets a resource with a method and optional body.
  2. 02A response carries a status, headers, and optional body.
  3. 03Headers are metadata that shape caching, content type, auth, and more.
  4. 04Methods carry intent; safety and idempotence matter for retries.
  5. 05HTTP semantics can ride on different transports (TCP, QUIC) without changing the meaning of methods and status codes.
  6. 06Intermediaries may store and forward responses when headers allow.

Learning objectives

After this lesson you should be able to:

  • Read a raw request/response and explain method, path, status, and two headers.
  • Choose GET vs POST for a scenario and justify using safety/idempotence.
  • Explain what a redirect accomplishes in the client.
  • Locate where HTTP ends and TLS begins in an HTTPS fetch.
  • Compare Cache-Control choices for a static asset versus a private page.

Progressive depth

Read the layers in order for a full explanation. Or open the layer you need.

01

Intuition

When you open a page, your browser sends a carefully phrased ask: GET this path, accept these formats, here is my language preference. The server answers with a status (200, 404, 500) and bytes to interpret as HTML, JSON, image, or other.

That conversation is HTTP. Everything flashy in web apps still rests on these messages.

Intermediaries can participate: a CDN may answer from cache without waking the origin if headers permit. HTTP was designed knowing middleboxes would exist.

02

Formal shape

HTTP/1.1 messages are text-framed; HTTP/2 and HTTP/3 multiplex binary frames for efficiency. Methods (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS) convey intent.

Idempotent methods can be retried without changing meaning beyond the first application (with caveats). Safe methods should not change server state.

Caching semantics (Cache-Control, ETag, Last-Modified, Vary) are first-class performance tools. Content negotiation uses Accept headers. Authentication can use Authorization headers or cookies.

Status classes: 1xx informational, 2xx success, 3xx redirect, 4xx client errors, 5xx server errors. Precise codes guide clients and operators.

03

Worked examples

Fetching /styles.css is usually a GET returning Content-Type: text/css. Submitting a form may POST a body. An API might return 401 with a WWW-Authenticate challenge.

Redirects (301/302/307/308) tell the client to try another URL: built-in indirection for renames and login flows. Method preservation differs among redirect codes; that detail bites API designers.

DevTools Network panel shows timing: DNS, TCP, TLS, request, waiting (TTFB), download. Those phases are how you debug 'slow.'

Minimal request shape: GET /hello HTTP/1.1 plus Host: example.com plus Accept. Host matters because many sites share IPs.

04

Edge cases

Proxies and CDNs rewrite and cache. Mixed content blocks HTTP resources on HTTPS pages. Streaming, WebSockets, and server-sent events stretch the request-response mold.

HTTP/3 runs over QUIC to reduce handshake latency and head-of-line blocking. Version negotiation and fallback still surprise operators.

Idempotency keys for POST make retries safe when the protocol method alone cannot.

Hop-by-hop headers versus end-to-end headers matter when proxies are involved; not every header should be forwarded blindly.

Mental models

  • Order slip and receipt

    Request is the order slip (method, path, headers). Response is the receipt (status) plus the goods (body).

  • Stateless clerk

    Classic HTTP: each request carries what the server needs; session affinity is layered on with cookies or tokens.

  • Shared library rules

    Caches and proxies understand HTTP metadata so they can store and reuse responses safely when headers allow.

  • Verbs with contracts

    Methods are not decoration. GET should be safe to retry; inventing private meanings for verbs creates retry landmines.

Common misconceptions

  • Myth

    HTTP is inherently insecure; HTTPS is a different application protocol.

    Reality

    HTTPS is HTTP over a TLS-protected connection. Same messages, encrypted transport.

  • Myth

    REST is synonymous with HTTP.

    Reality

    HTTP is a protocol. REST is an architectural style that often uses HTTP idioms but is not identical to any JSON over HTTP.

  • Myth

    A 404 means the server is down.

    Reality

    404 means the server responded: the resource was not found. Down is usually a connection failure or timeout.

  • Myth

    POST is always 'the secure method.'

    Reality

    Security comes from TLS and auth design. POST is not encrypted by virtue of being POST.

Exercises

Work these without looking up answers first. Check yourself against the intent notes.

  1. Exercise 01

    Write a minimal HTTP/1.1 GET request for https://example.com/hello (show Host and one Accept header). Then interpret a 301 response with Location: /hello/.

    What good looks like

    Shows request line, Host required, and client follow of redirect.

  2. Exercise 02

    A client retries a POST after a timeout and creates two orders. Which HTTP property was violated in the client's assumption, and what status/design might help?

    What good looks like

    POST not idempotent; use idempotency keys or PUT-style design; 409/replay handling.

  3. Exercise 03

    Why might a CDN serve a stale CSS file after you deploy, and which headers would you inspect first?

    What good looks like

    Cache-Control/Expires/ETag/Surrogate keys; CDN TTL; discuss purge vs shorter TTL tradeoff.

Sources & further reading

External references. Prefer primary documents and clear explainers.

Go deeper on your own

These picks go past the foundation in this lesson. Use them when you want a primary spec, official docs, or a longer walkthrough.

  • RFC 9110: HTTP SemanticsPaper

    Normative meaning of methods, status codes, and headers. Open it when MDN summaries are not enough.

  • RFC 9112: HTTP/1.1Paper

    Wire format for HTTP/1.1 messages. Read it when you need to parse or craft raw request lines.

  • RFC 9114: HTTP/3Paper

    HTTP over QUIC. Read it when you want the next transport story after HTTP/1.1 semantics.