HTTP

HTTP audio micro-course (transcript)

Three short podcasts about “HTTP”. Listen with the interactive player.

Podcast 1 — Introduction & meaning

Narrator: There are four letters that underpin almost every interaction you have with the modern internet. They appear at the start of web addresses so consistently that many users never think about what they mean. Those four letters are HTTP.

Narrator: HTTP stands for HyperText Transfer Protocol, pronounced aitch-tee-tee-PEE — /ˌeɪtʃ tiː tiː ˈpiː/. It is the foundation-level protocol that governs how data — particularly the web pages and resources that make up the World Wide Web — is requested and delivered between a web server and a browser.

Narrator: HTTP was designed and implemented by Tim Berners-Lee at CERN in Geneva between 1989 and 1991, alongside the URL addressing system and HTML, as part of a project to create a distributed information management system for the physics research community. The original HTTP specification was remarkably brief — a single page describing how a client could request a document from a server.

Narrator: The first version formalised for broad use, HTTP 1.0, arrived in 1996, establishing the familiar request-response model: a client sends a request with a method — GET to read, POST to submit — and the server replies with a status code. Two hundred for success. Four hundred and four for not found. Five hundred for server error. These codes became the shared vocabulary of the web.

Narrator: HTTP 1.1 in 1997 introduced persistent connections, allowing multiple requests over a single TCP connection. HTTP 2 in 2015 added multiplexing — sending multiple requests simultaneously without waiting. HTTP 3, ratified in 2022, replaced the underlying TCP transport with QUIC, built on UDP, dramatically improving performance on unreliable mobile networks.

Narrator: HTTPS — the S standing for Secure — wraps HTTP inside a TLS encryption layer, protecting the content of requests and responses from interception. Today, HTTPS is the baseline expectation for any site handling personal or financial data. The padlock icon in your browser confirms that HTTP is running inside an encrypted tunnel.

Narrator: HTTP: the quiet infrastructure that makes the web possible, first sketched on paper in Geneva and now carrying trillions of requests every single day.

Speaker A: HTTP is one of those acronyms most web users see every day without thinking about what it actually stands for or what it does.

Speaker B: Right — it has become invisible through familiarity. But understanding what HTTP is matters the moment you start building anything for the web. At its core, HTTP is a conversation between a client and a server. The client asks for something, the server answers.

Speaker A: Can you walk me through what that conversation looks like in practice?

Speaker B: Sure. The browser sends an HTTP request. That request has a method — GET if you're just retrieving a page, POST if you're submitting a form, PUT or PATCH if you're updating data, DELETE if you're removing something. The server receives that, processes it, and sends back an HTTP response with a status code. Two hundred means all is well. Four hundred and four means the thing you asked for doesn't exist. Five hundred means the server itself had a problem.

Speaker A: And HTTPS — that really is just HTTP with encryption on top?

Speaker B: Exactly. HTTPS runs HTTP inside a TLS tunnel, so the content of every request and response is encrypted between your browser and the server. No one in between can read what's being sent. It's what makes it safe to submit card details online. HTTP without the S sends everything in plain text, which is why you should never enter sensitive information on a page that is still using plain HTTP today.

Speaker A: What is the most common mistake developers make when working with HTTP?

Speaker B: Misusing status codes — particularly returning a two hundred response with an error message in the body. That is unfortunately very common. If something went wrong, the HTTP status code must say so. Four hundred if the client sent invalid data. Four hundred and one if authentication is missing. Four hundred and three if they're authenticated but not permitted. Five hundred if the server broke. Getting those status codes right makes your API dramatically easier to work with and debug.

Speaker B: HTTP is one of the most precise technical terms you can use in development prompts. It immediately tells the model you are working at the web networking layer, and the vocabulary around it — methods, status codes, headers, endpoints — drives very specific and high-quality outputs.

Speaker A: So mentioning HTTP-specific terminology in a prompt focuses the model on the exact layer of the stack we need.

Speaker B: Exactly. First prompt — a REST API with semantically correct HTTP:

Speaker B: Build a Node.js Express REST API for a product catalogue using correct HTTP semantics throughout. Use GET for retrieving products and categories, POST for creating new products, PUT for full product replacement, PATCH for partial updates such as price or stock changes, and DELETE for removing discontinued products. Return 201 on successful creation, 404 when a product is not found, and 422 for validation failures.

Speaker A: Specifying each HTTP method and its matching status code in the prompt — the model produces precisely mapped routes rather than defaulting everything to POST with a blanket two hundred response.

Speaker B: Second — an HTTP request logging middleware:

Speaker B: Create a Node.js Express middleware that logs every incoming HTTP request to a PostgreSQL table. Log the HTTP method, full request URL, query parameters as JSON, response status code, and response time in milliseconds. Add a composite index on method and status_code. Expose a GET admin endpoint at slash admin slash logs returning the fifty most recent entries with cursor-based pagination.

Speaker A: The composite index on method and status_code — the model will create it as a multi-column index so the admin logs view can filter by specific HTTP methods or error ranges very efficiently without scanning the full table.

Speaker B: Third — an HTTP caching middleware:

Speaker B: Design a Node.js caching middleware for an Express API that caches HTTP GET responses in Redis for five minutes. The middleware must skip caching for any non-GET HTTP method, respect incoming Cache-Control headers from the client, set Cache-Control and ETag headers on cached responses, and invalidate relevant cache keys when a POST, PUT, PATCH, or DELETE request targets the same resource path.

Speaker A: Invalidating cache on write HTTP methods — the model will detect non-GET methods in the middleware and use Redis DEL or pattern-matched key deletion against keys matching the affected resource path, ensuring stale data cannot be served after a write.

Speaker B: Fourth — an HTTP health monitoring dashboard:

Speaker B: Build a React dashboard that monitors the HTTP health of a suite of internal APIs. Poll each registered endpoint every thirty seconds, display its current HTTP status code, response time, and thirty-day uptime percentage. Colour-code endpoints green for 2xx, amber for 3xx or responses above one second, and red for 4xx or 5xx. Show a twenty-four-hour status code history chart per endpoint.

Speaker A: Colour-coding by HTTP status code range — the model will implement a classification function that reads the first digit of the status code and maps it to a CSS class, keeping the colour logic independent of specific codes so it handles any valid HTTP response correctly.

Speaker B: Fifth — an HTTPS security audit tool:

Speaker B: Create a Node.js command-line tool that audits a list of URLs for HTTP security best practices. For each URL, verify that HTTP redirects to HTTPS, check TLS certificate validity and days until expiry, and check for the presence of Strict-Transport-Security, Content-Security-Policy, and X-Frame-Options HTTP response headers. Output a structured JSON report with a pass or fail result for each check per URL.

Speaker A: Checking security HTTP response headers alongside TLS — a full two-layer audit covering both the transport encryption and the browser-level security policies that headers enforce, giving a complete picture of the site's HTTP security posture.

Speaker B: Sixth — a webhook delivery system with HTTP retry logic:

Speaker B: Build a Node.js webhook delivery system that sends HTTP POST requests to registered subscriber URLs on application events. Retry failed deliveries on non-2xx HTTP responses at one minute, five minutes, and thirty minutes. Store each attempt in a PostgreSQL webhook_deliveries table with target URL, HTTP response status, response body snippet, attempt number, and timestamp. Expose an admin endpoint with delivery success rates per subscriber.

Speaker A: Retry logic keyed on non-2xx HTTP responses — the model will check the response status code after each POST and schedule the next retry only when status is outside the 2xx range, making the retry condition exactly aligned with the HTTP semantics.

Speaker B: HTTP in development prompts is uniquely powerful because it activates the model's knowledge of an entire protocol ecosystem — methods, status codes, headers, caching, security — producing outputs that are technically precise, interoperable, and immediately usable in production web systems.