Home / MAD1 / Week 1

Week 1 · How the web works: clients, servers, URLs and HTTP

The one-minute story

By the end of this week you can:

• explain what happens between typing a URL and seeing a page;
• split any URL into scheme, host, port, path, query string and fragment;
• read an HTTP request and response and name the method, headers, body and status code;
• choose the right HTTP method and status code for a situation;
• calculate requests per second, bandwidth (Mbps) and RAM needs, which the papers love;
• predict what a tiny Flask route returns for a given URL (200, 404, 405 or 400).

Words you need

Idea 1: Internet, web, clients and servers

The internet is the physical and logical network (cables, routers, IP). The web is one service that runs on it. Email and file transfer also use the internet but are not "the web".

A client starts the conversation and a server answers. These are roles, not machines: your laptop can run a Flask server and a browser at the same time, and then talk to itself.

What happens when you type http://example.com/hello and press Enter?

1. The browser asks DNS for the IP address of example.com.
2. It opens a connection to that IP address on the right port (80 for http, 443 for https).
3. It sends an HTTP request: "GET /hello".
4. The server runs some code (or reads a file) and sends an HTTP response: status, headers, body.
5. The browser reads the HTML body, finds more files it needs (CSS, images, JavaScript), requests those too, and renders the page.

Web server versus web application. A web server (Apache, Nginx) accepts connections and serves files. A web application (your Flask code) decides what to send. Flask ships with a small development server so you can test locally; real sites put it behind a stronger one.

Static versus dynamic.

You can serve static files with one command in a folder that has index.html:

python -m http.server 8000

Now open http://localhost:8000/ in the browser. Python sends index.html for /, and any other file by its path. Press Ctrl+C to stop. The server prints one line per request, for example "GET /index.html HTTP/1.1" 200 -.

Idea 2: Anatomy of a URL

Take this URL:

https://shop.example.com:8443/books/list?genre=sci-fi&page=2#reviews

Python can split a URL for you, which is a safe way to check your answer:

from urllib.parse import urlparse, parse_qs

u = urlparse("https://shop.example.com:8443/books/list?genre=sci-fi&page=2#reviews")
print(u.scheme, u.hostname, u.port)
print(u.path)
print(parse_qs(u.query))
print(u.fragment)

Output:

https shop.example.com 8443
/books/list
{'genre': ['sci-fi'], 'page': ['2']}
reviews

Notice that every query value is a string ('2', not 2), and a key can repeat (?tag=a&tag=b), so parse_qs gives lists.

Path parameter versus query parameter. These are two different ways to send a value, and the exam tests the difference constantly. In Flask:

from flask import Flask, request
app = Flask(__name__)

@app.route("/greet/<name>")          # value lives in the PATH
def greet(name):
    return f"Hi {name}"

@app.route("/search")                # value lives in the QUERY STRING
def search():
    return "q=" + request.args.get("q", "nothing")

I ran this app. The results:

Idea 3: HTTP request and response

An HTTP message is plain text. A request has a start line, headers, an empty line, and an optional body:

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Cookie: session=abc123

uname=ria&pwd=secret

A response looks similar, with a status line first:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: theme=dark; Path=/
Content-Length: 31

<h1>Welcome, ria</h1>

Content-Type is the label on the parcel. text/html means "show it as a page"; application/json means "this is data". Flask's jsonify(...) returns status 200 and the mimetype application/json, which is a favourite exam fact.

Try it with curl, a command-line client (-i shows the headers, -X picks the method, -H adds a header, -d sends a body):

curl -i http://127.0.0.1:5000/api/courses
curl -X POST http://127.0.0.1:5000/api/course -H "Content-Type: application/json" -d '{"id": "CS1001"}'

HTTP methods

Status code families

I checked these in Flask: redirect(url_for("home")) gives 302 with a Location: / header; abort(403) gives 403; a missing route gives 404; calling a POST-only route with GET gives 405; returning "saved", 201 gives 201.

from flask import Flask, abort

app = Flask(__name__)
users = ["admin", "user_1"]

@app.route("/home/<username>", methods=["POST"])
def home(username):
    if username in users:
        return f"Hello {username}"
    abort(407)

@app.errorhandler(404)
def nf(e):
    return "The user you are looking for is invalid."

@app.errorhandler(405)
def bad_method(e):
    return "Please check the web request."

abort and errorhandler. abort(400, "message") stops the function and sends that error. @app.errorhandler(404) replaces the default error page for that code. When the argument is missing, Flask raises 400 for request.args["uid"] (dictionary-style access) but returns None for request.args.get("uid").

from flask import Flask, request
valid = [{"uid": "student", "pwd": "12345"},
         {"uid": "professor", "pwd": "54321"}]
app = Flask(__name__)

@app.route("/signin")
def login():
    args = request.args
    for vu in valid:
        if vu["uid"] == args["uid"] and vu["pwd"] == args["pwd"]:
            return "You are authorized!!"
        else:
            return "You are unauthorized!!"

Idea 4: Stateless HTTP and cookies

Each request is independent: the server does not remember that you logged in one second ago. To fake memory, the server sends a cookie in a Set-Cookie response header. The browser stores it and sends it back in a Cookie header on every later request to that site. The cookie usually holds a short session id, and the real data stays on the server.

from flask import Flask, make_response, request
app = Flask(__name__)

@app.route("/set")
def set_it():
    r = make_response("ok")
    r.set_cookie("theme", "dark")
    return r

@app.route("/get")
def get_it():
    return request.cookies.get("theme", "none")

The first route sends Set-Cookie: theme=dark; Path=/. After the browser has that cookie, /get shows dark; in a fresh browser it shows none.

Idea 5: How a browser renders and what developer tools show

After the HTML arrives the browser parses it into a tree called the DOM (Document Object Model), applies the CSS to each node, works out the layout and paints the pixels. Each new file it discovers (image, stylesheet, script) is another request.

Press F12 (or right-click, Inspect) to open the developer tools:

• Elements tab: the live DOM and the CSS applied to the selected element. You can edit text and styles to experiment; the change lives only in your browser and vanishes on reload.
• Network tab: one row per request, with method, URL, status code, type, size and time. Click a row to see request and response headers. This is where you check that your form sent POST and what status came back.
• Console tab: JavaScript messages and errors.

View Source (Ctrl+U) shows the HTML the server sent; Elements shows the page after the browser and JavaScript have worked on it.

Server-side versus client-side rendering. With Jinja2 (week 3) the server builds the full HTML and the browser just shows it. That gives a fast first view and works well with search engines. In client-side rendering the server sends data (JSON) and JavaScript builds the page in the browser (that is the MAD2 way, with Vue). Jinja2 server-side rendering does not remove the need for later fetches when the user interacts; it just makes the first load simple.

Idea 6: Bandwidth, latency and counting requests

Papers set small arithmetic problems. Memorise these facts and units.

Memory and concurrency. If each connected viewer needs 3 GB and at most 1,900 viewers are online at the busiest minute, the server must hold 3 GB x 1,900 = 5,700 GB = 5.7 TB (the real paper reads the peak from a graph and asks exactly this; use the highest point, not the average, because everyone may be there at once). Watch the unit: 1,900 x 3 GB is in GB, so convert before choosing GB or TB.

Scale up versus scale out. Scale up (vertical) means a stronger machine. Scale out (horizontal) means more machines behind a load balancer. Scale out when one machine's CPU, memory or network is the bottleneck; scale up when one machine has room and a bigger one is simpler. Caching (keeping a copy of a response near the client) reduces load and latency; it never "degrades service quality".

Cloud service models (a small recurring question): IaaS gives you raw machines and networks; PaaS gives a ready platform (language runtime, web server, database) so you only bring your code; SaaS gives a finished application (Gmail). A developer who wants a ready environment without managing servers wants PaaS.

Idea 7: MVC in one page

Most web apps split their code in three, so each part has one job:

A request flows: browser, controller (route), model (data), back to the controller, view (template), response. Keep SQL out of templates and HTML out of models.

Exam radar

Quick quiz

Viva: say it out loud

Recap

Practise with real exam questions

These come straight from past papers (with the real figures and the official answer key). Open 60 real questions on this week   All Quiz 1 papers