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:
- Request line:
METHOD PATH VERSION. Here: the methodGET("give me"), the path/about, and the protocol version. - Headers: one
Name: valueper line. Extra information about the request.Hostsays which site you want (one server can host many sites),User-Agentsays what kind of client is asking. - A blank line, which means "headers are done". Requests that upload data (like form submissions) put a body after the blank line. A
GEThas 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?