EMZETT.HTTP
In short: Hypertext Transfer Protocol — the protocol through which browsers and servers exchange web pages and other resources, unencrypted.
In more detail: Works on the request-response principle: the client sends a request (e.g. GET /page), and the server answers with a status code and content. Builds on TCP. Since everything is transmitted in plain text (including passwords and cookies), it has largely been replaced by HTTPS today.
In Depth
Structure of request and response
A typical HTTP request and the corresponding response look (simplified) like this:
GET /index.html HTTP/1.1
Host: emzett-digital.com
User-Agent: Mozilla/5.0
--- Response ---
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234
<html>...</html>
Both request and response consist of a start line, several header fields (metadata such as content type or cache instructions) and optionally a body with the actual payload. The Host header is essential here: since several websites are often hosted on a single server with the same IP address (virtual hosting), only this header reveals which of the websites is meant.
HTTP methods
HTTP works with a handful of standardised methods, each expressing a particular intention: GET (retrieve a resource without side effects — should be repeatable any number of times without changing anything), POST (create/send new data, typically with side effects), PUT/PATCH (completely replace or partially change existing data), DELETE (delete a resource). This distinction is more than just convention — browsers and intermediaries (proxies, caches) rely on a GET never changing data and cache the corresponding responses aggressively, which can lead to unwanted repetitions with a deleting endpoint wrongly implemented using GET.
Status codes
The response always carries a three-digit status code whose first digit reveals the category: 1xx (informational, rarely visible), 2xx (success, e.g. 200 “OK” or 201 “Created”), 3xx (redirect, e.g. 301 for a permanent redirect), 4xx (client error, e.g. 404 “Not Found” or 401 “Unauthorized”), 5xx (server error, e.g. 500 “Internal Server Error” when the application crashes unexpectedly). This rough division allows clients to react sensibly to unknown new status codes — a client seeing a 4xx code it doesn’t know at least knows that it’s an error on its own side, not a server error.
Statelessness and its consequences
It’s important that HTTP is stateless by design: for the server, every request is independent of all previous ones — the server doesn’t “remember” by itself that the same client is currently logged in or has already put something in the cart. Stateful functions such as staying logged in therefore run via additional mechanisms such as cookies or session tokens, which the client has to send again with every request so that the server can restore the context.
Development over the versions
Since HTTP/2 (2015), several requests also run in parallel over a single TCP connection (multiplexing), instead of opening a new connection for each request as with HTTP/1.1 or relying on a limited number of parallel connections per domain — this has considerably improved the loading times of modern web pages with many resources (images, scripts, stylesheets). HTTP/3 goes a step further and replaces TCP completely with QUIC (based on UDP) to avoid so-called “head-of-line blocking”, in which a single lost packet in TCP blocks all subsequent requests, even if their data had long since arrived.