HTTP requests and responses

Why this matters

On Day 1 you drew an arrow between the browser and the server and labelled it "request". This week you find out what actually travels along that arrow, and it turns out to be something reassuringly plain: text, in a fixed layout, that you can read. By the end of the hour you can look at any HTTP exchange and name every part of it — method, path, headers, body, status — and say which side made which decision.

That is the skill every backend day this week rests on. You cannot build a server if you cannot read what a server receives and sends.

An HTTP exchange is two blocks of text

HTTP (HyperText Transfer Protocol) is the agreed set of rules browsers and servers use to talk. An exchange is always exactly two messages, in order: the client sends a request, the server sends back one response. One request, one response, then it's over. The server never speaks first.

Both messages have the same three-part shape:

<start line>
<header>: <value>
<header>: <value>

<optional body>

The start line says what this message is. Then any number of headers, one per line, each a name and a value. Then a blank line — this is not decoration, it is the marker that says "headers are finished". Then the optional body, the actual payload.

Methods and URLs

The request's start line has three pieces: the method, the path, and the protocol version.

GET /equipment/eq-002 HTTP/1.1

The method (also called the verb) states the intent of the request. There are a handful you will use constantly:

Method	Means	Has a body?
GET	Fetch a thing. Change nothing.	No
POST	Create a new thing, or submit data for processing.	Yes
PUT	Replace a thing entirely with what I send.	Yes
PATCH	Change part of a thing.	Yes
DELETE	Remove a thing.	Usually not
HEAD	Like GET, but send me only the headers.	No

Two properties matter. GET and HEAD are safe: they are only supposed to read, never change anything. GET, PUT, and DELETE are idempotent: sending the identical request five times leaves the server in the same state as sending it once. POST is neither — five identical POST requests usually create five records. That single fact is why refreshing a page after submitting a form makes browsers nervous.

The URL says which thing you mean. Every part has a job:

https://api.example.com/equipment?status=down&limit=10
\___/   \_____________/\________/ \___________________/
scheme       host         path         query string

The scheme picks the protocol, the host picks the machine, the path picks the resource on that machine, and the query string — everything after ?, as name=value pairs joined by & — carries extra options like filters. Only the path and query string travel inside the request; the host is sent separately in a Host: header.

Headers and bodies

Headers are metadata about the message, never the content itself. A few you will meet today:

• Host: — which site on this server the request is for.
• Content-Type: — what format the body is in, for example application/json or text/html.
• Content-Length: — how many bytes the body is, so the receiver knows when it has all of it.
• Accept: — what formats the client can handle in the response.
• User-Agent: — what program is asking.

The body is the payload. Requests that send data (POST, PUT, PATCH) carry one; GET requests normally do not. This week's bodies are almost always JSON — the text format you met on Day 27 — and when they are, Content-Type: application/json must say so. A server that is told nothing about the format will not guess.

Status code families

The response's start line carries a three-digit status code and a short reason phrase:

HTTP/1.1 404 Not Found

The first digit is the family, and the family alone tells you where to look next.

Family	Meaning	You will see
1xx	Informational — still processing. Rare.	100 Continue
2xx	Success. It worked.	200 OK, 201 Created, 204 No Content
3xx	Redirection — the thing is somewhere else.	301 Moved Permanently, 304 Not Modified
4xx	Client error — the request was wrong.	400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 405 Method Not Allowed, 409 Conflict
5xx	Server error — the request was fine, the server broke.	500 Internal Server Error, 503 Service Unavailable

Learn the 4xx/5xx split above everything else. 4xx — the 400-level family — means the caller made the mistake: bad data, wrong path, no permission, and repeating the identical request will fail identically. 5xx means the server made the mistake and the same request might succeed later. Getting that boundary right in your own API is what makes it debuggable by someone else.

Walkthrough: three real exchanges

curl is a command-line HTTP client. The -v flag prints the raw exchange: lines starting > are what curl sent, lines starting < are what came back. --http1.1 asks for the older protocol version, whose text form is easier to read.

curl -v --http1.1 https://example.com -o /dev/null

Among the output you will see the request and response (the * lines are curl's own commentary):

> GET / HTTP/1.1
> Host: example.com
> User-Agent: curl/8.7.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 03 Aug 2026 13:50:11 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< Server: cloudflare

Your run will show a few extra response headers — caching and CDN headers vary by site and by minute — but the shape is fixed. Method GET, path /, no request body, status 200 OK, response body is HTML. Now ask for a path that does not exist:

curl -v --http1.1 https://example.com/nope -o /dev/null

> GET /nope HTTP/1.1
< HTTP/1.1 404 Not Found

Same method, different path, 4xx — your fault, the path is wrong. Now keep the path and change the method. -X POST sets the method and -d supplies a body:

curl -v --http1.1 -X POST https://example.com -d 'a=1' -o /dev/null

> POST / HTTP/1.1
> Content-Length: 3
> Content-Type: application/x-www-form-urlencoded
>
< HTTP/1.1 405 Method Not Allowed

Notice curl added Content-Length and Content-Type for you the moment there was a body. And the resource exists — it just does not accept POST. That is precisely what 405 means, and it is a different failure from 404.

How to use AI today

Today's mode is tutor: ask for explanation and practice, not answers. A tutor-style request explains the concept, gives one small example, then lets you attempt it — you should be able to predict an answer before you are shown one.

Your turn

Produce two annotated HTTP exchanges in a file notes/day-36-http.md.

1. Pick any real site and run curl -v --http1.1 <url> -o /dev/null. Copy the > and < lines into your notes.
2. Annotate the request: label the method, the path, and two headers, writing what each one is for in your own words.
3. Annotate the response: label the status code, name its family, and say whose fault a failure in that family would be.
4. Now capture a POST. Open DevTools (Day 6), go to the Network tab, tick Preserve log, and submit a form on a real site — a search box or a login page you own. Find the request whose method column reads POST and open it.
5. From the Headers panel copy the request method, the path, Content-Type, and the response status. From the Payload (or Request) panel copy what was sent as the body.
6. Annotate this second exchange the same way, and add one line answering: why is this a POST and not a GET?
7. Finish with a short table of the five status families and one sentence each.

Common pitfalls

• Confusing 4xx and 5xx. 400 and 404 say you sent something wrong. 500 says the server fell over. Reporting a client mistake as 500 sends the next debugger hunting in the wrong program entirely.
• Expecting a request body on GET. GET carries its options in the query string, not a body. If you need to send a record, that is a POST.
• Forgetting Content-Type. A JSON body with no Content-Type: application/json is just bytes, and servers routinely ignore it. You will hit this for real on Day 40.
• Reading HTTP/2 output and expecting the same shapes. Over HTTP/2 curl shows header names in lowercase and HTTP/2 200 with no reason phrase. Same information, different spelling. Use --http1.1 while learning.

Verify it yourself

Open today's reference, MDN's Overview of HTTP, and find its sections on HTTP messages and response status codes.

1. This lesson listed six methods. Find one MDN describes that is not in the table above, and write down what it is for.
2. Find MDN's own wording for the 4xx family. Does it agree the fault lies with the client? Quote the sentence into your notes.
3. This lesson said POST is not idempotent. Find where MDN confirms or contradicts that.

Add all three answers to notes/day-36-http.md. Checking a lesson's claims against the specification is how you will settle arguments about APIs for the rest of your career.