Skip to content

Week 11: Networks and HTTP basics

~9 min

This week's goal

This week you learn how one computer sends a message to another, and what a web request and response look like on the wire. You make requests from Python, read the status codes and headers, and run a small server on your own machine. By the end you can explain what happens between typing a web address and seeing a page, and you can show it with a script.

The main texts are the computer networks page and the HTTP request lifecycle lesson from the Python course.

Day-by-day (about 1.5-2 hours per day)

Day 1. Read the first half of the computer networks page. Focus on the layers: an application message such as HTTP is carried inside TCP, which is carried over IP. Draw the layers on paper. Then read the MDN page on what a URL is to see how a URL is split into parts.

Day 2. Read the HTTP overview on MDN. Note the parts of a request: a method, a path, headers, and sometimes a body. Then read the methods page. Write down what GET and POST are for, and why GET should only read data.

Day 3. Read the status codes page. Learn the groups: 2xx means success, 3xx means redirect, 4xx means the client made a mistake, and 5xx means the server failed. Then run curl -i https://example.com in the terminal. Find the status line and the Content-Type header in the output.

Day 4. Read the HTTP request lifecycle lesson from the Python course. Then write fetch.py. It uses urllib.request.urlopen to fetch a page you choose, prints the status code, prints the Content-Type header, and prints the first 200 characters of the body. Use the urllib.request documentation to check the names.

Day 5. Start a small server with the http.server module. Write server.py that answers every request with a short text message. Run it, open http://localhost:8000 in your browser, and then fetch the same address with fetch.py from a second terminal window. Compare the two responses.

Day 6. Read the cookies guide on MDN and the short summary in RFC 9110, which describes HTTP semantics. Then write three sentences in your notes that explain why HTTP is described as stateless, and how cookies let a site remember you. Check your sentences against the MDN page before you save them.

Day 7 is a rest day.

Deliverable

Two files. fetch.py fetches a page and prints its status code, its Content-Type, and the first 200 characters of its body. server.py runs a local server that answers with a short message. Your notes contain the three sentences about statelessness and cookies, and a drawing of the layers from day 1.

Check yourself

  1. What is the difference between a method and a status code?
  2. What do the headers in a request or response carry?
  3. What does a 404 status mean, and what does a 500 mean?
  4. Why does HTTP need TCP underneath it?
  5. What does it mean that HTTP is stateless?
Answers
  1. A method is what the client asks for, such as GET or POST. A status code is the result the server reports back, such as 200 or 404.
  2. Headers carry extra information about the message, such as the content type, the length, and cookies. They are read by the client and the server, and they are not usually shown on the page.
  3. A 404 means the server did not find the resource. A 500 means the server ran into an error while it handled the request. A 404 is a client-side problem in the sense that the address is wrong, and a 500 is a problem on the server.
  4. HTTP sends its messages as data over a connection. TCP provides a reliable, ordered stream of bytes between two computers, and HTTP uses it to carry its requests and responses.
  5. Each request is handled on its own. The server does not keep state from one request to the next unless the client sends something back, such as a cookie, that lets it link them.

Sources