HTTP & Web Protocols

HTTP looks deceptively simple — a text request line, key: value headers, a blank line, and a body. That simplicity is why people learn it as a bag of acronyms and then fail the very first question: "what happened between pressing Enter and the response arriving?" The real subject of this topic is the stack: the name is resolved to an address via DNS, the kernel opens a socket, TCP establishes a connection with a three-way handshake, TLS negotiates keys, and only on top of all that does HTTP text travel. Each layer solves exactly one problem and hands its abstraction upward — break the chain anywhere and the symptom shows up far from the cause.

Python is convenient here because the standard library exposes every layer separately: socket is the raw transport, ssl the handshake and certificate verification, http.client the message parser, urllib.request the redirect and client policy, wsgiref the server side. Any claim from theory can be checked by hand in five lines. Four traps are worth naming upfront. The first is confusing safety with idempotency: GET is safe, PUT and DELETE are idempotent but not safe, and POST is neither. The second is 301 versus 307, which differ not only in permanence but in whether the client may change the method. The third is that HTTPS encrypts the body and headers but does not hide the IP or the hostname carried in SNI. The fourth is that REST is a set of architectural constraints, not "JSON over HTTP".

Topic map

• The network stack — which layer is responsible for what, and what really happens between curl and the server's reply.
• Sockets — a socket as a transport endpoint and a file descriptor, SOCK_STREAM versus SOCK_DGRAM.
• TCP — the three-way handshake, numbered segments, ACK, retransmission, the sliding window and congestion control.
• UDP — a connectionless, unacknowledged datagram, and why DNS, video and games choose it.
• DNS — the resolution order, record types, TTL, and the fallback from UDP/53 to TCP.
• The HTTP protocol — text, statelessness, the start line, headers, the blank line and the body.
• HTTP methods — method semantics and the key distinction of the topic, safe versus idempotent.
• Status codes — the meaning lives in the first digit, and why validation is 4xx, not 5xx.
• Redirects — Location plus a 3xx, and how 301, 302, 307 and 308 differ on the method.
• Caching — freshness via Cache-Control versus revalidation via a validator.
• ETag and conditional requests — If-None-Match, an empty 304, strong versus weak validators.
• HTTP versus HTTPS — what exactly TLS adds and what it does not conceal.
• REST — the constraints of the style, not the data format, and an honest comparison with SOAP.
• CGI — process-per-request as a historical model and why WSGI and ASGI replaced it.

Common mistakes and traps

What interviews check

The topic almost always opens with one question — "what happens when you run curl https://example.com". It probes your model, not your trivia: the interviewer listens for DNS before the connection, the TCP handshake before TLS, TLS before the first HTTP byte, and for whether you understand that a request descends through layers rather than "flying to the server". Every follow-up grows from there — where a reverse proxy sits, what changes for http://, why keep-alive saves precisely the handshake. The second mandatory block is methods and codes, and it holds the most-failed point of the topic: safe versus idempotent. GET and HEAD are safe, PUT and DELETE are idempotent yet mutate state, POST has neither property. Answering "idempotent means read-only" has already said the important thing about the candidate.

Then come the details that separate practice from documentation. The difference between 301, 302, 307 and 308 is not "permanent or temporary" but whether the client may switch the method to GET. Caching is examined in two steps — freshness first (Cache-Control, max-age), revalidation second (ETag, If-None-Match, a 304) — and the difference between no-cache and no-store is the standard follow-up. On HTTPS the expected answer is not "it's encrypted" but the three guarantees — confidentiality, integrity, server authentication by certificate — plus the honest admission that the domain in SNI is visible to an observer. On REST the interviewer checks whether you name the constraints rather than the format; "REST means JSON instead of XML" closes the question against you. CGI wraps the topic up — it is asked to hear whether you understand why WSGI and ASGI came to exist.