Course outline · 0% complete

0/25 lessons0%

Course overview →

Anatomy of an HTTP request

lesson 4-1 · ~11 min · 10/25

Quiz

Warm-up from lesson 1-2: in the URL https://example.com/about, which piece tells the server which resource you want?

HTTP is just text

Once the TCP connection from unit 3 is open, the browser speaks HTTP (HyperText Transfer Protocol). The surprise for most beginners: an HTTP request is plain, readable text. That fact is worth the whole unit: because requests are text, you can read them in debugging tools, write them by hand, and reason about them directly — no decompiling, no magic. Here is a complete real one:

GET /about HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0

Three parts, always in this order:

  1. Request line: METHOD PATH VERSION. Here: the method GET ("give me"), the path /about, and the protocol version.
  2. Headers: one Name: value per line. Extra information about the request. Host says which site you want (one server can host many sites), User-Agent says what kind of client is asking.
  3. A blank line, which means "headers are done". Requests that upload data (like form submissions) put a body after the blank line. A GET has no body.

On the wire each line ends with the two characters \r\n (carriage return + newline), a detail you will see again when reading raw traffic.

Code exercise · bash

Run this. It builds the exact text of an HTTP GET request from three variables. There is no magic: what a browser sends is a string you could type by hand.

Code exercise · bash

Your turn, go the other direction. Given a raw request line, split it into its three parts and print them. Use the space-trimming pattern from lesson 1-2: ${request%% *} keeps everything before the first space, ${request#* } removes through the first space.

Quiz

What does the blank line in an HTTP request mean?