HTTP Protocol — Trivia & Interesting Facts¶
Surprising, historical, and little-known facts about the Hypertext Transfer Protocol.
HTTP/0.9 was a single line: GET /page.html¶
Tim Berners-Lee's original HTTP (1991) supported only one method (GET), had no headers, no status codes, and could only transfer HTML. The entire protocol was: send GET /path, receive an HTML document, connection closes. Everything we associate with HTTP today — headers, POST, cookies, caching, content negotiation — was added later. HTTP/1.0 (RFC 1945, 1996) formalized the protocol five years after it was already in widespread use.
The 418 "I'm a teapot" status code is from a real RFC¶
RFC 2324, "Hyper Text Coffee Pot Control Protocol" (HTCPCP), was published on April 1, 1998, as an April Fools' joke. It defined status code 418 "I'm a teapot" for servers that refuse to brew coffee because they are teapots. Despite being a joke, the code has persisted in popular culture and was implemented in Google's infrastructure. There was a serious effort to remove it from Node.js in 2017 that generated fierce community resistance.
HTTP Keep-Alive was the single biggest performance improvement in web history¶
HTTP/1.0 opened a new TCP connection for every single request — every image, CSS file, and JavaScript file required a fresh three-way handshake. HTTP/1.1 (RFC 2068, 1997) made persistent connections the default, allowing multiple requests over one connection. This single change reduced page load times by 30-50% and dramatically decreased server load. Before keep-alive, a page with 30 images required 31 TCP connections.
HTTP/2 was based on Google's SPDY protocol¶
Google developed SPDY (pronounced "speedy") in 2009 as an experimental replacement for HTTP/1.1, deploying it across Google's properties. The IETF used SPDY as the starting point for HTTP/2 (RFC 7540, 2015). SPDY introduced multiplexing, header compression, and server push — all features that made it into HTTP/2. Google deprecated SPDY in 2016 once HTTP/2 was standardized.
HEAD-of-line blocking plagued HTTP for 25 years¶
In HTTP/1.1, if you send multiple requests on one connection, the responses must come back in order. A slow response blocks all subsequent responses — this is head-of-line (HOL) blocking. HTTP/2's multiplexing fixed HOL blocking at the application layer, but TCP's in-order delivery reintroduced it at the transport layer. It took HTTP/3 (based on QUIC over UDP) to finally eliminate HOL blocking entirely.
The Referer header has a permanent typo¶
The HTTP Referer header was misspelled in the original HTTP specification — the correct English spelling is "referrer" with two r's. By the time anyone noticed, the typo was embedded in thousands of implementations. It has remained "Referer" for over 30 years. The newer Referrer-Policy header uses the correct spelling, creating an inconsistency that will exist forever.
Chunked transfer encoding was invented because servers didn't know the response size¶
Before chunked encoding (HTTP/1.1), the server had to know the Content-Length before sending the first byte, which meant buffering the entire response in memory. Chunked encoding lets the server send data in pieces, each prefixed with its size, terminated by a zero-length chunk. This enabled streaming responses, server-sent events, and dynamic content generation without massive memory buffers.
HTTP/3 runs over UDP, not TCP — and this was controversial¶
HTTP/3 (RFC 9114, 2022) uses QUIC, which runs over UDP instead of TCP. This was driven by the realization that TCP's head-of-line blocking, slow handshakes, and ossification (middleboxes breaking new TCP features) were unfixable. Running over UDP let the QUIC designers build a new reliable transport protocol that includes built-in encryption (TLS 1.3), 0-RTT connection establishment, and per-stream flow control.
Cookies were invented by a Netscape engineer in 1994 and caused an immediate privacy crisis¶
Lou Montulli invented HTTP cookies at Netscape in 1994 to solve the shopping cart problem — HTTP is stateless, so there was no way to remember a user between requests. Within two years, cookies were being used for cross-site tracking by advertising networks, sparking the first Internet privacy debates. The tension between cookies-as-session-state and cookies-as-tracking-mechanism has been unresolved for 30 years.
The 301 vs 302 redirect confusion broke the web for years¶
RFC 2616 defined 301 as "Moved Permanently" and 302 as "Found" (temporary redirect). Both should preserve the original HTTP method (POST should remain POST after redirect), but every browser implemented 302 by changing POST to GET. This de facto behavior was so entrenched that the IETF eventually created 307 (Temporary Redirect, preserves method) and 308 (Permanent Redirect, preserves method) to fix the ambiguity — effectively admitting the original spec was unimplementable.
HTTP CONNECT is how every HTTPS request through a proxy actually works¶
When your browser makes an HTTPS request through a corporate proxy, it first sends an HTTP CONNECT request asking the proxy to establish a raw TCP tunnel to the destination. The proxy returns "200 Connection Established" and then blindly forwards bytes in both directions. The proxy cannot see the encrypted traffic — unless it performs TLS interception with its own certificate, which is exactly what corporate proxies do.