Programming

The history of HTTP and the stories behind status codes

Markus

Feb 17, 2024 — 18 min read

Ever been greeted by a "404 Not Found" message while browsing the web? It's one of the many status codes used by the web. 404 is self-explanatory - usually an indication that a resource or page was not found.

HTTP status codes are the numerical messages that web servers send back to browsers or other clients, indicating the outcome of a request. They are part of the HTTP protocol, which stands for Hypertext Transfer Protocol, the standard way of communicating on the web.

HTTP status codes are divided into five categories, based on the first digit of the code:

1xx: Informational responses, indicating that the request has been received and is being processed.
2xx: Success responses, indicating that the request has been successfully completed.
3xx: Redirection responses, indicating that the request needs to be redirected to another location or resource.
4xx: Client error responses, indicating that the request is invalid or cannot be fulfilled by the server.
5xx: Server error responses, indicating that the server encountered an error or is unable to handle the request.

But how did these codes come to be? Who invented them, and why? And what are some of the most mysterious or obscure codes that exist? In this article, we will explore the history of HTTP status codes, from their origins to their present-day usage.

The Origins of HTTP and Status Codes

The HTTP protocol was invented by Tim Berners-Lee, a British computer scientist who is widely regarded as the father of the World Wide Web. Berners-Lee was working at CERN, the European Organization for Nuclear Research, in the late 1980s and early 1990s, when he came up with the idea of creating a system that would allow researchers to share and access information across different computers and networks.

Berners-Lee designed the first version of HTTP, along with the concepts of URLs (Uniform Resource Locators), HTML (Hypertext Markup Language), and web servers and browsers. He also wrote the first web browser and web server software, and launched the first website in 1991.

The first version of HTTP, known as HTTP/0.9, was very simple and had only one method: GET. This method allowed clients to request a resource from a server, such as a web page or an image. The server would respond with either the requested resource, or an error message. There were no status codes in HTTP/0.9, only plain text messages.

For example, if a client requested a web page that existed on the server, the server would respond with something like:

<HTML>
<HEAD>
<TITLE>Example Page</TITLE>
</HEAD>
<BODY>
<H1>Hello, World!</H1>
</BODY>
</HTML>

If the client requested a web page that did not exist on the server, the server would respond with something like:

Bad request

As you can see, HTTP/0.9 was very limited and did not provide much information about the status of the request or the response. It also did not support other methods, such as POST, PUT, DELETE, or HEAD, which are used to send data, update or delete resources, or get metadata from the server.

The introduction of status codes & headers

HTTP/0.9 soon proved to be inadequate for the growing needs and complexity of the web. Therefore, Berners-Lee and other developers started working on a new version of HTTP, which would introduce more features and functionality. This version, known as HTTP/1.0, was officially released in 1996 as RFC 1945, a document that defines the specifications and standards of the protocol.

One of the major improvements of HTTP/1.0 was the introduction of status codes. Status codes are three-digit numbers that indicate the outcome of a request, and are accompanied by a short textual phrase that describes the meaning of the code. Status codes are intended to provide more information and feedback to the clients and the developers, and to enable more efficient and reliable communication between the servers and the clients.

The first version of HTTP/1.0 defined 14 status codes, divided into three categories:

2xx: Successful responses, indicating that the request has been successfully completed. The only code in this category was 200 OK, which means that the server has fulfilled the request and returned the requested resource.
3xx: Redirection responses, indicating that the request needs to be redirected to another location or resource. There were six codes in this category, such as 301 Moved Permanently, which means that the requested resource has been permanently moved to a new URL, or 304 Not Modified, which means that the requested resource has not changed since the last request and can be cached by the client.
4xx: Client error responses, indicating that the request is invalid or cannot be fulfilled by the server. There were seven codes in this category, such as 400 Bad Request, which means that the request is malformed or contains invalid syntax, or 404 Not Found, which means that the requested resource does not exist on the server.

HTTP/1.0 also introduced the concept of headers, which are additional information that can be sent along with the request or the response. Headers can provide metadata, such as the content type, the content length, the date, the server name, the client name, the cookies, the cache control, and so on. Headers can also affect the behavior of the request or the response, such as redirecting the client, negotiating the content format, or requiring authentication.

For example, a typical HTTP/1.0 request and response might look something like this:

GET /example.html HTTP/1.0
User-Agent: Mozilla/5.0
Host: www.example.com
Accept: text/html

HTTP/1.0 200 OK
Date: Sat, 17 Feb 2024 10:19:52 GMT
Server: Apache/2.4.46
Content-Type: text/html
Content-Length: 1024

<HTML>
<HEAD>
<TITLE>Example Page</TITLE>
</HEAD>
<BODY>
<H1>Hello, World!</H1>
</BODY>
</HTML>

As you can see, the request and the response have a status line, which contains the method, the URL, the protocol version, the status code, and the status phrase. They also have headers, which are separated by a blank line from the body, which contains the actual resource or data.

Further evolution - HTTP/1.1

HTTP/1.0 was a significant improvement over HTTP/0.9, but it still had some limitations and drawbacks. For instance, HTTP/1.0 did not support persistent connections, which means that each request and response required opening and closing a new TCP connection, which was inefficient and costly. HTTP/1.0 also did not support pipelining, which means that each request had to wait for the previous response to finish, which was slow and wasteful. HTTP/1.0 also did not support chunked encoding, which means that the server had to know the size of the response before sending it, which was impractical and restrictive.

Therefore, another version of HTTP was developed, which would address these issues and add more features and functionality. This version, known as HTTP/1.1, was officially released in 1997 as RFC 2068, and later updated in 1999 as RFC 2616. HTTP/1.1 is the most widely used version of HTTP today, and is considered the standard version of the protocol.

One of the major improvements of HTTP/1.1 was the support for persistent connections, also known as keep-alive connections. This means that the TCP connection between the client and the server can be reused for multiple requests and responses, without having to open and close it for each one. This reduces the overhead and latency of the communication, and improves the performance and efficiency of the web.

HTTP/1.1 also introduced the support for pipelining, which means that the client can send multiple requests without waiting for the previous response to finish. This allows the client to make better use of the bandwidth and the connection, and reduces the waiting time and the blocking of the communication.

Another new feature was chunked encoding, which means that the server can send the response in chunks, without having to know the size of the response beforehand. This allows the server to stream the response dynamically, and to send data as soon as it is available, without having to buffer it or delay it.

This version also added new request types - OPTIONS, TRACE, CONNECT, and PATCH, which are used to query the server, test the connection, establish a tunnel, or apply partial updates to resources. HTTP/1.1 also added more headers, such as Connection, Transfer-Encoding, Host, Expect, and Range, which are used to control the connection, the encoding, the host name, the expectations, and the partial requests.

HTTP/1.1 also added more status codes, bringing the total number to 41. The new status codes were divided into four categories:

1xx: Informational responses, indicating that the request has been received and is being processed. There were eight codes in this category, such as 100 Continue, which means that the client should continue with the request, or 101 Switching Protocols, which means that the server agrees to switch to a different protocol requested by the client.
2xx: Success responses, indicating that the request has been successfully completed. There were five codes in this category, such as 201 Created, which means that the server has created a new resource as a result of the request, or 206 Partial Content, which means that the server has returned only a part of the resource requested by the client.
4xx: Client error responses, indicating that the request is invalid or cannot be fulfilled by the server. There were 18 codes in this category, such as 401 Unauthorized, which means that the request requires authentication, or 418 I’m a teapot, which is an Easter egg code that means that the server is a teapot and cannot brew coffee.
5xx: Server error responses, indicating that the server encountered an error or is unable to handle the request. There were 10 codes in this category, such as 500 Internal Server Error, which means that the server has encountered an unexpected condition that prevents it from fulfilling the request, or 503 Service Unavailable, which means that the server is temporarily unable to handle the request due to overload or maintenance.

Moving to the modern age - HTTP/2

HTTP/1.1 was a major improvement over HTTP/1.0, and it solved many of the problems and limitations of the previous version. However, HTTP/1.1 still had some challenges and drawbacks. For instance, HTTP/1.1 did not support multiplexing, which means that multiple requests and responses could not share the same connection, which could cause head-of-line blocking, which means that one slow request or response could delay the others. HTTP/1.1 also did not support server push, which means that the server could not send resources to the client without the client requesting them, which could improve the performance and user experience of the web.

Therefore, another version of HTTP was developed, which would address these issues and add more features and functionality. This version, known as HTTP/2, was officially released in 2015 as RFC 7540, and is based on an experimental protocol called SPDY, which was created by Google. HTTP/2 is the latest version of HTTP, and is gradually being adopted by more and more web servers and browsers.

One of the major improvements of HTTP/2 is the support for multiplexing, which means that multiple requests and responses can be sent and received concurrently over the same connection, using streams, frames, and priorities. This reduces the overhead and latency of the communication, and eliminates the head-of-line blocking problem.

HTTP/2 also introduced the support for server push, which means that the server can send resources to the client before the client requests them, using push promises. This allows the server to anticipate the client’s needs, and to improve the performance and user experience of the web.

HTTP/2 also added more features, such as binary encoding, which means that the headers and the frames are encoded in binary format, instead of plain text, which reduces the size and the complexity of the messages. HTTP/2 also added more security, such as mandatory TLS, which means that the connection between the client and the server must be encrypted, using Transport Layer Security.

HTTP/2 also added more status codes, bringing the total number to 63. The new status codes were divided into five categories:

1xx: Informational responses, indicating that the request has been received and is being processed. There were no new codes in this category, but the existing codes were redefined to apply to HTTP/2 streams, instead of HTTP/1.1 connections.
2xx: Success responses, indicating that the request has been successfully completed. There were two new codes in this category, such as 226 IM Used, which means that the server has fulfilled the request and the response is a representation of the result of one or more instance manipulations applied to the current instance, or 208 Already Reported, which means that the server has already fulfilled the request and the response is a list of bindings that have already been reported in previous responses.
3xx: Redirection responses, indicating that the request needs to be redirected to another location or resource. There were two new codes in this category, such as 308 Permanent Redirect, which means that the requested resource has been permanently moved to a new URL, and the client should use that URL for future requests, or 307 Temporary Redirect, which means that the requested resource has been temporarily moved to a new URL, and the client should use that URL for this request only.
4xx: Client error responses, indicating that the request is invalid or cannot be fulfilled by the server. There were four new codes in this category, such as 429 Too Many Requests, which means that the client has sent too many requests in a given period of time, and the server is throttling the requests, or 451 Unavailable For Legal Reasons, which means that the server is denying access to the resource due to legal demands or censorship.
5xx: Server error responses, indicating that the server encountered an error or is unable to handle the request. There were four new codes in this category, such as 511 Network Authentication Required, which means that the client needs to authenticate with the network before accessing the resource, or 508 Loop Detected, which means that the server has detected an infinite loop while processing the request.

The future of the web - HTTP/3

HTTP/2 was a major improvement over HTTP/1.1, and it solved many of the challenges and drawbacks of the previous version. However, HTTP/2 still had some limitations and drawbacks. For instance, HTTP/2 did not support UDP, which means that the protocol still relied on TCP, which is a reliable but slow and heavy transport layer protocol, which could cause congestion, packet loss, and retransmissions. HTTP/2 also did not support QUIC, which is a new transport layer protocol that combines the features of TCP, UDP, and TLS, and provides faster, more secure, and more reliable communication.

Therefore, another version of HTTP is being developed, which will address these issues and add more features and functionality. This version, known as HTTP/3, is still in draft stage, and is based on an experimental protocol called QUIC, which was also created by Google. HTTP/3 is the future version of HTTP, and is expected to be released in the near future.

One of the major improvements of HTTP/3 is the support for UDP, which means that the protocol will use User Datagram Protocol instead of Transmission Control Protocol as the transport layer protocol. UDP is a fast and lightweight protocol that does not guarantee reliability or order of the packets, but allows for more flexibility and efficiency of the communication.

HTTP/3 also introduced the support for QUIC, which means that the protocol will use Quick UDP Internet Connections as the application layer protocol. QUIC is a new protocol that combines the features of TCP, UDP, and TLS, and provides faster, more secure, and more reliable communication. QUIC also supports multiplexing, server push, binary encoding, and mandatory encryption, like HTTP/2, but with improved performance and robustness.

HTTP/3 also added more features, such as 0-RTT, which means that the client and the server can exchange data without any round-trip time, using session resumption and early data. This reduces the latency and improves the user experience of the web.

HTTP/3 also added more status codes, bringing the total number to 65. The new status codes were divided into five categories:

1xx: Informational responses, indicating that the request has been received and is being processed. There was one new code in this category, which is 103 Early Hints, which means that the server is sending some preliminary information, such as headers or links, before the final response.
2xx: Success responses, indicating that the request has been successfully completed. There were no new codes in this category, but the existing codes were redefined to apply to HTTP/3 streams, instead of HTTP/2 frames.
3xx: Redirection responses, indicating that the request needs to be redirected to another location or resource. There were no new codes in this category, but the existing codes were redefined to apply to HTTP/3 streams, instead of HTTP/2 frames.
4xx: Client error responses, indicating that the request is invalid or cannot be fulfilled by the server. There were no new codes in this category, but the existing codes were redefined to apply to HTTP/3 streams, instead of HTTP/2 frames.
5xx: Server error responses, indicating that the server encountered an error or is unable to handle the request. There were no new codes in this category, but the existing codes were redefined to apply to HTTP/3 streams, instead of HTTP/2 frames.

HTTP/3 is the future version of HTTP, and is expected to be released in the near future.

The Origins Behind Some Status Codes

HTTP status codes are not only useful and informative, but also interesting and entertaining. Some status codes have fascinating arguments or stories behind them, and some status codes are humorous or mysterious.

200 OK

The most common and familiar status code is 200 OK, which means that the server has fulfilled the request and returned the requested resource. This code is also the oldest and the simplest status code, as it was the only code in the 2xx category in HTTP/0.9.

418 I’m a teapot

One of the most humorous and mysterious status codes is 418 I’m a teapot, which means that the server is a teapot and cannot brew coffee. This code is not part of the official HTTP standard, but it was defined as an April Fools’ joke in 1998 by the Hyper Text Coffee Pot Control Protocol (HTCPCP), which is an extension of HTTP for controlling, monitoring, and diagnosing.. coffee pots?

The origin of the code is a reference to a children’s book called The Little Teapot, which is about a teapot that is sad because it cannot brew coffee, but then learns that it can do other things, such as whistle and pour tea. The code is also a parody of the Internet of Things (IoT), which is the concept of connecting everyday objects and devices to the internet and enabling them to communicate and exchange data.

The code is not meant to be taken seriously, but it has been implemented by some web servers and frameworks as an Easter egg or a joke.

💡

If you try to request the URL https://www.google.com/teapot, you will get a response with the status code 418 and a picture of a teapot that tilts when you tilt your device 🍵

451 Unavailable For Legal Reasons

Another interesting and controversial status code is 451 Unavailable For Legal Reasons, which means that the server is denying access to the resource due to legal demands or censorship.

The origin of the code is a reference to a novel called Fahrenheit 451, which is written by Ray Bradbury and published in 1953. The novel is about a dystopian society where books are banned and burned by the government, and the title refers to the temperature at which paper ignites. The novel is a critique of censorship and authoritarianism, and a defense of freedom of expression and literature.

The code is meant to be used when the server is legally obliged to block or remove the resource, such as due to court orders, intellectual property rights, privacy laws, or national security. The code is also meant to inform the user of the reason and the authority behind the restriction, and to provide a link to more information or a way to challenge the decision.

The code is not widely used, but it has been implemented by some web servers and frameworks as a way to protest or raise awareness of censorship and internet freedom.

💡

If you try to request the Wikipedia URL about the Tiannamen Square protests from China, you will get a response with the status code 451 and a message that says "This page is not available in your region due to legal reasons".

420 Enhance Your Calm

One of the most humorous and mysterious status codes is 420 Enhance Your Calm, which means that the client has sent too many requests and needs to calm down. This code is not part of the official HTTP standard, but it was used by the initial version of the Twitter Search and Trends API, which is an API that allows developers to access and analyze Twitter data.

The origin of the code is a reference to the movie 10 Things I Hate About You, which is a romantic comedy film released in 1999. In the movie, there is a scene where a character named Kat is angry and frustrated, and another character named Patrick tries to calm her down by saying "Just calm down. Relax. Take it easy. Enhance your calm."

The code is also a reference to the number 420, which is a slang term for cannabis or marijuana, and is often associated with the subculture of cannabis users.

The code is not meant to be taken seriously, but it was used by Twitter to limit the number of requests that a client can make to the API, and to prevent abuse or overload of the service. The code was later replaced by the standard code 429 Too Many Requests, which has the same meaning but is more formal and less humorous.

402 Payment Required

Another intriguing and mysterious status code is 402 Payment Required, which means that the server requires payment to access the resource. This code is part of the official HTTP standard, but it was never fully defined or implemented by the RFC 1945.

The origin of the code is not very clear, but it is likely that it was intended for directing the user to complete digital payments, such as using credit cards, online wallets, or cryptocurrencies. However, the code was never used for this purpose, as there were no standard or secure ways to handle online payments at the time, and there were other methods and protocols that emerged later, such as SSL, TLS, HTTPS, and OAuth.

The code is not used, but it has been reserved for future use, in case there is a need or a demand for it. The code is also used by some web servers and frameworks as an Easter egg or a joke.

💡

If you try to request the URL https://http.cat/402, you will get a response with the status code 402 and a picture of a cat with a credit card.

530 Site is frozen

Another humorous and mysterious status code is 530 Site is frozen, which means that the site has been frozen due to inactivity or non-payment. This code is not part of the official HTTP standard, but it was used by some web servers.

The code is not widely used, but it has been implemented by some web servers and frameworks as a way to block or suspend the sites that are inactive or unpaid, such as free or trial sites, expired or cancelled sites, or abandoned or neglected sites.

Conclusion

I hope you've learned something new about the HTTP protocol, as well as discovered some obscure HTTP codes - even if some of them aren't in the official standard. Easter eggs are always fun!

I hope you enjoyed!