HTTP in plain English: requests, responses and status codes

On Day 1 we followed a page load from the moment you press Enter. Step 3 of that journey was the browser “asking for the page”. Today we slow that step right down, because almost everything a website does, good or bad, travels over it.

That conversation is called HTTP, the Hypertext Transfer Protocol. It sounds technical, but it’s really just a polite, very strict exchange of short text messages. Once you can read it, a lot of web security stops being mysterious.

A conversation in two halves

Every HTTP exchange has exactly two parts:

The browser sends a request: “Please give me this thing.”
The server sends back a response: “Here it is”, or “No”, or “Look over there instead.”

Then the conversation is over. HTTP has no memory of its own. The next request starts from zero, which is why sites need cookies to remember who you are. That’s Day 3.

What a request looks like

Here is a simplified request your browser might send when you open a blog post:

GET /blog/http-in-plain-english/ HTTP/2
Host: cybersearch.in
User-Agent: Mozilla/5.0 (Windows NT 10.0) Chrome/130
Accept: text/html
Accept-Language: en-IN,en
Cookie: theme=dark

Line by line:

GET is the method, the kind of request. GET means “give me something”. POST means “here is some data”, for example a login form or a comment.
/blog/http-in-plain-english/ is the path, the exact thing being asked for.
Host says which website you want, because one server often hosts many sites.
User-Agent describes your browser.
Accept and Accept-Language say what formats and languages you’d like back.
Cookie carries the small tokens this site gave you earlier.

Why it matters for security: every one of these lines is written by the browser, which means a person with the right tools can write any of them. The server can’t trust that a request really came from its own page, or that a hidden form field wasn’t changed, or that the User-Agent is honest. This is the root of the rule we’ll come back to all through the series: never trust input from the client.

What a response looks like

The server answers with something like this:

HTTP/2 200
Content-Type: text/html; charset=utf-8
Cache-Control: max-age=600
Strict-Transport-Security: max-age=31536000
Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Lax

<!DOCTYPE html> ... the page itself ...

It has three parts:

The status code (200 here), a three-digit number that sums up the result.
The headers, instructions for the browser about how to treat what follows.
The body, the actual page, image or data.

Status codes, decoded

You don’t need to memorise them. The first digit tells you the story:

Range	Meaning	Common examples
2xx	It worked	200 OK, 204 No Content
3xx	Look elsewhere	301 Moved Permanently, 302 Found
4xx	The request was the problem	401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests
5xx	The server had a problem	500 Internal Server Error, 503 Service Unavailable

A few of these have a security side:

301 and 302 redirects are how a site sends plain http:// visitors to https://. If a site doesn’t redirect, people can end up on the unprotected version.
401 vs 403: 401 means “I don’t know who you are, please log in”. 403 means “I know who you are, and you’re not allowed”. Getting these right is part of access control, which has its own day later on.
429 is a site defending itself against too many requests, for example someone trying thousands of passwords. We cover rate limiting on Day 9.
500 errors should show a plain apology page. If yours shows a stack trace, file paths or database messages, it’s giving away a map of your system.

The headers that protect you

Headers are where a site quietly tells your browser how careful to be. Two from the example above:

Strict-Transport-Security (HSTS) says: “For the next year, only ever talk to me over HTTPS, even if someone types http://.”
Set-Cookie with Secure; HttpOnly; SameSite says: “Only send this cookie over HTTPS, don’t let scripts read it, and don’t attach it to requests started by other sites.”

There are more, like Content Security Policy and frame protection. Day 22 goes through them one by one. For now, the point is that a lot of security is just the server sending the right few lines of text.

See it yourself in two minutes

Every modern browser can show you this conversation. In Chrome, Edge or Firefox:

Open any website and press F12 (or right-click and choose Inspect).
Click the Network tab, then reload the page.
Click the first row. You’ll see the request headers, the response headers and the status code.

Try it on a site you use every day. Look for the strict-transport-security header, and look at how many other domains the page talks to. It’s often more than you’d expect.

Common misunderstandings

“POST is more secure than GET.” Not really. POST keeps data out of the address bar and server logs, which is good for passwords, but it isn’t encrypted any more than GET is. HTTPS is what protects both.
“Hidden form fields can’t be changed.” They can. Anything sent to the browser can be edited before it’s sent back.
“A 404 means the file isn’t there.” Usually, but some sites return 404 for things that exist and are simply private, on purpose, so outsiders can’t tell them apart.

What you can do today

If you browse the web:

Open the Network tab once on a site you trust, just to see what normal looks like.
Notice when a site loads over http:// without the padlock, and don’t log in there.

If you run a website:

Check that http://yoursite redirects to https://yoursite with a 301.
Make sure your error pages never show stack traces or file paths to visitors.
Check your response headers with a free scanner such as securityheaders.com, and read MDN’s guide to HTTP if you want to go deeper.
Treat every value in a request, including headers and hidden fields, as untrusted until your server has checked it.

Coming up next

On Day 3 we’ll look at cookies and sessions: how a website that has no memory still knows you’re logged in, and why that small token is one of the most valuable things in web security.