Old-School Networking

• Shape — first line, headers, a blank line, body. The submission is a 149-byte header plus a 54-byte body (measured)
• Methods and status — what to do, and what happened. We made the server return ten different codes (measured)
• Speed-ups — 304 sends a 0-byte body, gzip turns 2 MB into 6 KB, HTTP/2 runs requests together on one connection (measured)
• Developer pitfalls — the three cookie flags, and who fixes a CORS error

In TCP/IP terms HTTP is layer 7, the topmost agreement in the application layer. The practice network is the same as in part 9: a PC, and across part 6's mischief wire (20 ms each way) the expense server, written in Node.js. It listens for HTTP (port 3000), HTTPS (port 3443, both HTTP/1.1 and HTTP/2) and unencrypted HTTP/2 (port 3080, for observation).

To see inside, we sent the submission over plain, unlocked HTTP and recorded it with curl -v and Wireshark (the Wireshark window is the cover picture).

# Request: first line (method, path, version), headers, a blank line, the body
    POST /api/expenses HTTP/1.1
    Host: expenses.example:3000
    User-Agent: curl/8.5.0
    Accept: */*
    Content-Type: application/json
    Content-Length: 54
    
    {"date":"2026-10-25","item":"交通費","amount":1280}
# Response: first line (version, status code), headers, a blank line, the body
    HTTP/1.1 201 Created
    Location: /api/expenses/EXP-2026-0012
    Content-Type: application/json
    Content-Length: 43
    Date: Sun, 25 Oct 2026 00:28:31 GMT
    Connection: keep-alive
    Keep-Alive: timeout=5
    
    {"id":"EXP-2026-0012","status":"submitted"}

The request's first line says what (POST), where (/api/expenses) and which version (HTTP/1.1). The headers that follow are “name: value” lines. Host names the destination (one server answers for many names, so it's required), Content-Type gives the kind of body, and Content-Length its length. A blank line ends the headers, and the 54 bytes of JSON follow.

Part 6 said TCP is a “stream” with no boundaries, so the layer above has to decide where one submission ends. Here is the answer: everything up to the blank line is headers, and the next Content-Length bytes are the body. That rule is how the server cuts up the stream.

The response's first line is version, status code and a short description. 201 Created means “made it”, and Location gives the new submission's address. The closing Connection: keep-alive and Keep-Alive: timeout=5 mean “I'll keep this connection open for five seconds; feel free to use it for your next request.” The connection reuse from parts 6 and 8, which skips the TCP and TLS greetings, is agreed right here.

The first word of the first line is the method. On the same /api/expenses, GET means “show me the list” and POST means “file a new submission”.

The column that matters is the second from the right: idempotent. It means “sending the same request any number of times has the same effect as sending it once.” The HTTP specification (RFC 9110) makes the safe methods such as GET, HEAD and OPTIONS idempotent, along with PUT and DELETE. With an idempotent request, if the reply never comes and you time out, you can safely send it again.

We deliberately sent the practice server all sorts of requests and lined up the first lines of the replies.

# Replies from the same API to different requests (status line and relevant headers)
    GET /api/expenses                  → 200 OK
    POST /api/expenses (JSON)          → 201 Created Location: /api/expenses/EXP-2026-0013
    POST (broken JSON)                 → 400 Bad Request
    POST (Content-Type: text/plain)    → 415 Unsupported Media Type
    POST (amount is a string)          → 422 Unprocessable Entity
    PUT /api/expenses                  → 405 Method Not Allowed Allow: GET, POST
    GET /expenses (old URL)            → 301 Moved Permanently Location: /api/expenses
    GET /api/expenses/EXP-2026-9999    → 404 Not Found
    DELETE (no key)                    → 401 Unauthorized WWW-Authenticate: Bearer
    DELETE (with key)                  → 204 No Content

The first digit of the three gives the class: 2xx success, 3xx “go elsewhere”, 4xx “your request was wrong”, 5xx “the server failed”. A 4xx is for the sender (the front end) to fix; a 5xx is for the server side. In an outage, that one digit is the first thing to look at.

Within 4xx there are distinctions. 400: the JSON is broken and can't be read. 415: “I only take JSON, and you sent text/plain.” 422: “I could read it, but the amount is a string, so the content is wrong.” 401 means “I don't know who you are (show me a key)”, with WWW-Authenticate naming the kind of key. Knowing who you are and still saying “not for you” is 403.

Most times you open the expense list, the same content comes back. Carrying all of it every time is a waste, so the server sends the list along with a tag for its contents, the ETag.

# 1st: the list comes back with a fingerprint of its contents (ETag)
pc$ curl -D - http://expenses.example:3000/api/expenses
    HTTP/1.1 200 OK
    ETag: "41dc1e7dc5a9"
    Cache-Control: no-cache
    (body: 153 bytes)
# 2nd: ask again, saying “I already have the one with this ETag”
pc$ curl -D - -H 'If-None-Match: "41dc1e7dc5a9"' http://expenses.example:3000/api/expenses
    HTTP/1.1 304 Not Modified
    ETag: "41dc1e7dc5a9"
    (body: 0 bytes)

The second time, If-None-Match says “I already have the one with this tag”, and since nothing had changed the server replied 304 Not Modified with a 0-byte body. The number of round trips is the same, but the bigger the list, the more it saves. Browsers do this automatically without being asked.

Despite its name, Cache-Control: no-cache doesn't mean “don't store this”. It means “you may store it, but check with the server before every use” (RFC 9111). To really forbid storing, use no-store. max-age=600 means “use it for ten minutes without asking”, and during that time even the round trip disappears.

Once a request is done, HTTP forgets everything (it's stateless). So how does it remember that you're logged in? From here on we tried things over HTTPS (port 3443).

# Ask “who am I?” before logging in
pc$ curl https://expenses.example:3443/api/me
    {"error":"login required"}
# Log in, and the server hands over a cookie
pc$ curl -c jar.txt -X POST … https://expenses.example:3443/login
    HTTP/2 200 
    set-cookie: sid=480df7…; Path=/; HttpOnly; Secure; SameSite=Lax
# Ask again with the cookie attached
pc$ curl -b jar.txt https://expenses.example:3443/api/me
    {"user":"arai"}

On login the server hands over a numbered ticket (sid) with Set-Cookie. The PC keeps it and attaches it as a Cookie to every later request to the same server, and the server looks the number up: “ah, Arai.” HTTP stays forgetful; cookies let it act as if it remembers. The “session management” job of OSI layer 5, which we met in part 8, is in practice done right here.

The three flags after the ticket are what developers worry about most. HttpOnly hides it from JavaScript, Secure sends it only over HTTPS, and SameSite=Lax leaves it off most requests that arrive from other sites. The ticket is the key itself, so it should be hard to steal and hard to misuse.

Say the page lives at https://app.expenses.example and the API at https://expenses.example:3443. The names differ, so they are different origins (the combination of http/https, name and port). Normally a browser won't let one page's JavaScript read replies from another origin. CORS is the agreement by which the API answers whether that's allowed.

When POSTing JSON, the browser first sends an OPTIONS “preflight” before the real request. We reproduced that preflight with curl.

# Preflight: may a page on https://app.expenses.example POST here?
    OPTIONS /api/expenses
    Origin: https://app.expenses.example
    Access-Control-Request-Method: POST
    Access-Control-Request-Headers: content-type
  →
    HTTP/2 204 
    access-control-allow-origin: https://app.expenses.example
    access-control-allow-methods: GET, POST, DELETE
    access-control-allow-headers: Content-Type, Authorization
    access-control-max-age: 600
# From an unknown Origin (https://other.example), no permission headers come back
  →
    HTTP/2 204 

An allowed origin gets Access-Control-Allow-Origin and friends; an unknown origin gets nothing. Both replies are 204, so note that the server never says “no”. It's the browser that stops it. Without the permission headers the browser doesn't send the real request and prints a CORS error in the developer tools' Console.

We exported the expense CSV (2 MB) over a wire throttled to 10 Mbit/s.

# A 2 MB CSV, as is and gzipped (10 Mbit/s, 20 ms each way)
pc$ curl https://expenses.example:3443/api/export.csv
    2,097,152 bytes   1.934 s
pc$ curl --compressed …   (Accept-Encoding: deflate, gzip, br, zstd → Content-Encoding: gzip)
        6,179 bytes   0.142 s

The PC says “I can read these encodings” with Accept-Encoding, and the server compresses and replies with Content-Encoding: gzip. 2,097,152 bytes became 6,179, and 1.934 seconds became 0.142. Browsers do this automatically too.

This CSV, though, is one line repeated, so it shrank absurdly. A 2 MB CSV with varied numbers, dates and amounts, compressed the same way, came to 428,597 bytes, about a fifth. Text (HTML, JSON, CSV) compresses well; JPEGs and video, already compressed, barely shrink at all.

A single page usually takes dozens of requests. We fetched six reports that each take 100 ms, over HTTPS, and compared.

# Six reports that each take 100 ms (HTTPS, 20 ms each way)
    HTTP/1.1, one by one   0.953 s   1 connection(s)
    HTTP/1.1, in parallel  0.246 s   6 connection(s)
    HTTP/2, in parallel    0.245 s   1 connection(s)

HTTP/1.1 handles only one request at a time per connection. One after another took 0.953 s, even reusing the connection. The only way to speed up is more connections: six took 0.246 s. Browsers open around six connections to each server for the same reason, which also means six rounds of TCP and TLS greetings.

HTTP/2 numbers the requests on a single connection (streams) and runs them together (multiplexing): 0.245 s on one connection. The text lines became binary frames, but methods, status codes and headers mean exactly the same.

Over HTTPS, the version is settled in passing during the TLS handshake (ALPN: the Client Hello from part 8 carries a note saying “I speak h2 too”). Browsers use HTTP/2 only over HTTPS; the unencrypted HTTP/2 in the picture is a special setup for observation.

HTTP/2 still had a weak spot. TCP underneath is a single stream, so when one packet is lost, unrelated streams wait for the resend too (part 7's head-of-line blocking). So HTTP/3 moved onto QUIC, on top of UDP. QUIC keeps order per stream and has TLS 1.3 built in. Browsers learn that a server also speaks HTTP/3 from an Alt-Svc header in a reply or a DNS HTTPS record (part 9), and switch over from then on.

Start by opening a site you use every day and watching the Network tab. You'll see how many requests one page makes, which version they use and how much they were compressed.