What HTTP Really Is

Here we'll warm up by taking a look at the protocol at a very high level, before delving into the details in subsequent lessons.

Learn To Speak (and Lie!) Fluently in HTTP

You're not just “browsing” a website. You're sending strings to a server and getting strings back. The browser turns that dialogue into buttons, tabs, and popups and pretends it all makes sense. It auto-fills headers, stores secrets, follows redirects, hides failures, and fakes continuity. It is translator, choreographer, and liar-in-chief.

You're not here to learn a "protocol", you're here to learn a language: the actual language web applications speak.

HTTP may feel like it has a mystique about it. Its details may seem like highly technical magic or, worse, someone else's problem. But it's not like that at all. It's simply a back-and-forth composed of structured, human-readable text. A dialogue. A performance. No secrets, no magic. Just a conversation you've never been privy to... until now.

You're not here to memorize rules. You're here to learn to speak fluently. To understand the rhythm between client and server, how requests make claims, how responses signal belief, and how a single well-crafted string can shift the entire balance of trust.

And once you learn the language, you can ask for anything.

Or claim you already have it. And someone might just believe you...

So let's start at the beginning: what exactly is this language we're learning to speak?

Note: This course teaches HTTP/1.1 because it's the clearest for learning the protocol's structure and trust model. HTTP/2 and HTTP/3 are largely performance enhancements that don't change the semantics, just the format. Worry about that later.

What HTTP Really is

HTTP, or HyperText Transfer Protocol, is how clients (like browsers, mobile apps, or other software) and servers exchange requests and responses to one another for content. When you visit a website, your browser (the "frontend") sends HTTP requests to a server (the "backend") requesting specific content, and the server responds with HTML, CSS, JavaScript, or other data such as files.

The frontend requests data and decides how to display it. The backend decides what to send in response to each request. HTTP is the delivery system connecting the two, the dialogue that makes the web happen.

HTTP is a Conversation

A GET request politely asks the server for something, a POST request sends it something new, a DELETE request asks it to delete a particular resource. There, you've already learned three of the five most common HTTP Verbs! This isn't so hard...

Every HTTP Request Is a Question or a Command:

GET /about HTTP/1.1
Host: server.com

Client: "Hey server.com, can I GET your about page? I speak HTTP version 1.1, if that's alright with you."

Every HTTP Response is an answer, complete with tone (status codes) and content (the body):

HTTP/1.1 200 OK
Content-Type: text/html

<html>
    <body>
        <h1>About Us</h1>
        <p>Welcome to our website!</p>
    </body>
</html>

Server: "I also speak HTTP/1.1! Status code: OK, here's the content (HTML) of that page you requested."

Client: "Hey server.com, I'm POSTing some contact form data to you, 25 bytes worth, to be exact. Someone named Alice wants to say hello!"

POST /contact HTTP/1.1
Host: server.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 25

name=Alice&message=hello!

Server: "Got it! Here's a 201 Created status (meaning I successfully created something new) and a thank you page."

HTTP/1.1 201 Created
Content-Type: text/html

<html>
    <body>
        <h1>Thank you!</h1>
        <p>Your message has been received.</p>
    </body>
</html>

The Browser is a Translator

The browser is a remarkable translator and assistant. It handles the HTTP conversation for you, but it also hides the details. Once you peek behind the curtain, you realize the web isn't magic. It's just structured messages between computers.

One page, many requests:

Loading a single web page isn't just one request, it's often dozens. The browser first sends a GET request for the HTML page. Then, as it reads through that HTML, it discovers more resources it needs: stylesheets, JavaScript files, images, fonts, and favicons. Each triggers a separate HTTP request.

For example, visiting a news homepage might generate:

  • 1 request for the HTML
  • 3 requests for CSS files
  • 5 requests for JavaScript files
  • 20+ requests for images
  • 2 requests for fonts
📙 Caching
Sometimes the browser skips requests entirely thanks to caching. If it already has a fresh copy of a file, why ask for it again?

HTTP messages are Just Strings

No binary voodoo. No special formatting tricks. Just plain text.

You can write an HTTP request by hand in a terminal using telnet, curl, netcat, or craft one with a simple Python script. It's just like writing a letter, except with a very picky pen pal.

Just as it's easy to write, it's also easy to manipulate. Changing headers, modifying request data, or crafting unusual inputs becomes trivial once you realize it's all just text. Want to pretend you're using a different browser? Just change the User-Agent header. Want to test how a server handles weird input? Just type it in.

Nearly every web security vulnerability you've ever heard of began as a lie in a string.

📙 A Quick Note on "Just Strings"

HTTP messages themselves are always text - the headers, status codes, and structure are all human-readable. But the *content* being delivered can be anything: images, videos, executables, or any other binary data.

When binary data travels over HTTP, it gets encoded (often as base64) or transmitted as raw bytes in the message body. So while a JPEG image isn't text, the HTTP response carrying that JPEG is still a text-based message with binary content attached. Think of it like a text letter with a photo taped inside the envelope.

HTTP is a Language With No Memory

HTTP doesn't remember you. Not who you are, not what you just said, or why you're here again. The protocol is "stateless". Every request is a blank slate — a stranger at the door, knocking politely (or not!), saying: "Show me this page," or "Here's my data." The server answers based only on what that one request says — nothing more.

How do websites seem to remember us if HTTP itself is stateless? The answer is that state gets stored elsewhere. In cookies, session databases, or tokens that travel with each request. We'll explore these mechanisms soon, but the key insight is that the protocol itself provides no memory.

And here's where things get interesting: since HTTP forgets everything, it's up to applications to create the illusion of memory. That layer of artificial state? It's where many vulnerabilities hide. Because once you realize HTTP forgets everything, you also realize it's up to you to remind it... or mislead it.