Last year, I wrote an article on how we might be using some of the HTTP status codes wrong, and this time I discovered some HTTP status codes that we don't use that commonly, but they can have fascinating use cases.
So, in this article, we will discuss some HTTP status codes that will make you think. Let's get started!
It would be more fun if try to guess what the status code means while you read the heading! 😉
103 Early Hints 🫣
The 103 Early Hints HTTP status code is a bit unusual but pretty interesting. It's like a friendly advance notice from a web server to your browser. When a server sends a 103 code, it's saying, "Hey, I'm going to send you a bunch of stuff, and here's a sneak peek to get you started."
It's kind of like when you're at a restaurant, and the chef sends out a little appetizer before your main course. In this case, the server is letting your browser know that more data is on the way, so your browser can start preparing to receive it. It's all about optimizing the loading process and making your web experience smoother.
Its benefits include:
Faster Loading: Provides early hints to browsers, allowing them to start fetching critical resources sooner, leading to faster page rendering.
Enhanced User Experience: Reduces perceived loading times, resulting in a better user experience and higher engagement.
Optimized Resource Fetching: Prioritizes essential assets, optimizing the loading of above-the-fold content.
Reduced Round-Trips: Minimizes the need for additional requests, reducing latency and loading times.
Bandwidth Savings: Avoids fetching unnecessary resources, saving bandwidth for both users and servers.
Read here for more info.
300 Multiple Choices
The HTTP status code 300, "Multiple Choices," is used to indicate that the requested resource has multiple representations available, each with its own specific location (URI), and the user or client must choose one.
When a server returns a 300 status code, it typically includes a "Location" header in the response with a list of URIs for the alternative representations of the resource. The client can then decide which URI to follow based on user preferences or application logic.
For example, if a client requests a resource like a document, and the server has multiple versions of that document in different formats (e.g., HTML, PDF, plain text), it can respond with a 300 status code and provide URIs for each version. The client can then prompt the user to choose the preferred format, or it can use its own logic to make the selection.
The 300 status code is relatively rare in typical web interactions and is mainly used in scenarios where content negotiation is necessary to determine the best representation of a resource based on user or application requirements.
Read here for more info.
303 See Other 👀
The HTTP status code 303 See Other is a redirection status code used to instruct a web client (usually a web browser) to perform a GET request to a different URI. It indicates that the resource the client requested can be found at a different location, and the client should retrieve it from there.
This status code is like a signpost that says, "You asked for something, but it's not here. Go check somewhere else!" It's a way for a web server to tell your browser that the resource you're looking for can be found at a different location or URL.
Wait, doesn't that sound a lot like HTTP status code 302 Found?
HTTP status codes 302 and 303 both deal with redirection, but they serve different purposes. The key distinction lies in the nature of the redirection. The 302 status code indicates a temporary redirection, where the requested resource is temporarily available at a different URI.
In contrast, the 303 status code signifies a more explicit redirection, instructing the client to make a new GET request to the alternative URI for the requested resource.
While 302 implies that future requests may still be directed to the original URI, 303 is often used when you want to ensure that subsequent requests for the same resource always go to the new URI, making it particularly useful for certain web forms and data submissions.
For example, after successfully submitting a form on a website, the server might respond with a 303 code and a "Location" header pointing to a new URI that displays a thank-you message or a confirmation page. This ensures that refreshing the confirmation page won't result in a duplicate form submission. The client is instructed to make a GET request to the new URI to retrieve the result or view the confirmation, decoupling it from the initial POST request.
Read here for more info.
406 Not Acceptable ❌
The HTTP status code 406 Not Acceptable is returned by a web server when a client's request specifies certain response criteria, such as acceptable media types (content types), languages, or character sets, that the server cannot fulfill based on the available resources. In other words, the server cannot provide a response that matches the client's specified preferences.
For example, if a client sends an HTTP request header indicating that it only accepts responses in a particular language or content type, and the server does not have the requested content in that language or format, it would respond with a 406 status code.
The 406 status code is essentially a way for the server to communicate to the client that it cannot meet the specific content requirements specified in the request, and the client may need to adjust its preferences or handle the situation accordingly, such as by requesting a different content type or language.
Sounds a lot like 404 Not Found no? No, it doesn't, if you read it carefully, the 406 status code is about the server having the resource but not in the requested format, while the 404 status code is about the server not finding the resource at all.
Read here for more info.
409 Conflict ⚔️
The HTTP status code 409, "Conflict," is used to indicate that the request could not be completed due to a conflict with the current state of the target resource. This status code typically arises in scenarios involving concurrent updates or conflicting changes to a resource.
For example, if two users attempt to modify the same piece of data simultaneously, a conflict can occur. In this case, the server may respond with a 409 status code to inform the clients that their requests cannot be processed because of the conflicting changes.
The response often includes additional information or guidance on how to resolve the conflict, such as which resource state caused the conflict or how clients can retry their requests after addressing the conflict. It is commonly used in web applications, especially those with collaborative editing or version control features, to manage data consistency in situations where multiple parties can modify the same resource.
Did you think of 400 Bad Request while reading the above case? Well, to clarify that, while a 400 error points to issues with the request itself, a 409 error points to conflicts arising from the state of the resource being modified.
Read here for more info.
410 Gone 🪄
The HTTP status code 410, "Gone," is used to indicate that a previously available resource on the server is no longer accessible and has been intentionally removed or permanently deleted. Unlike the 404 status code, which simply indicates that a resource is not found, the 410 status code explicitly conveys that the resource existed in the past but has now been deliberately taken down, and there is no expectation of it becoming available again in the future.
Website administrators and developers may use the 410 status code when they want to inform both clients and search engines that a resource, such as a webpage or an API endpoint, has been permanently discontinued. This can be useful for maintaining the accuracy of search engine results and informing users that the resource they were seeking is no longer accessible.
Read here for more info.
417 Expectation Failed 😞
The HTTP status code 417, "Expectation Failed," is used to indicate that a server cannot meet the client's expectations specified in the "Expect" request header of the HTTP request.
The "Expect" header is typically used to define certain expectations the client has about how the server should handle the request, such as requesting that the server respond with a specific status code or comply with certain protocol extensions.
When a server encounters an "Expect" header that it cannot fulfill, it responds with a 417 status code. This can happen, for example, if the client expects the server to support a specific authentication method or protocol extension, but the server cannot meet that expectation.
The 417 status code is relatively rare and may not be encountered in everyday web browsing.
Read here for more info.
418 I'm a teapot 🫖
HTTP status code 418, "I'm a teapot," is an April Fools' joke and is not a standard HTTP status code. It was introduced in RFC 2324, a document titled "Hyper Text Coffee Pot Control Protocol," which is not a serious HTTP specification but rather a humorous and playful one.
This status code was intended to be a joke and not meant for actual use in web development or communication between servers and clients. It is not recognized or implemented by web servers or browsers for practical purposes.
So, if you encounter the "418 I'm a teapot" status code in any context, it's likely being used for fun or as a humorous way to communicate that the request is not valid or should not be taken seriously.
Read here for more info.
422 Unprocessable Content 😵💫
You might know about the HTTP status code 400, "Bad Request," which indicates that the server cannot process the client's request due to issues with the request itself, such as malformed syntax or missing required parameters. It signifies that the server does not understand or cannot fulfill the request due to client errors.
On the other hand, HTTP status code 422, "Unprocessable Entity," is used when the server can understand the client's request but cannot process it because the request's content, such as data or input, is semantically incorrect, syntactically invalid, or violates validation rules set by the server. It specifically addresses issues with the request's content, making it a more suitable choice when the request entity is problematic but not due to generic syntax errors.
Read here for more info.
451 Unavailable For Legal Reasons 👩⚖️
The HTTP status code 451, "Unavailable For Legal Reasons," is used to indicate that a server has received a request for a resource, but it refuses to fulfill the request due to legal restrictions or legal censorship.
This status code is typically used when a government or legal authority has mandated the removal or blocking of specific content, and the server must comply with these legal requirements.
The name "451" is a reference to Ray Bradbury's novel "Fahrenheit 451," in which books are banned and burned by the government. The choice of this status code name symbolizes the idea of content being "unavailable for legal reasons."
When a server responds with a 451 status code, it may also include additional information in the response, such as a description of the legal restrictions or a reference to the relevant laws or regulations.
The 451 status code is relatively recent in the HTTP standard and reflects the growing awareness of legal and censorship-related issues on the internet. Its use is typically associated with cases where access to certain online content is restricted due to legal compliance.
Read here for more info.
Conclusion
There are a lot more HTTP status codes that we don't really use commonly but they exist for specific purposes. I hope that you found this article helpful.
Do let me know if you used any of the above HTTP status codes in any interesting use case.
Keep reading! 👋
Top comments (14)
You could serve every language under the same url and then use content-negotiation of the Accept-Language header, but I wouldn't recommend that.
I would rather suggest that on your web sites root url, you issue a redirect (303 - See Other) to a language sub page (E.g. /en). When you do that, respond with a Vary header, that specifies Accept-Language (And any other relevant headers, such as Cookie). That way, any intermediaries (proxies, caches) will be able to cache the response. I would specifically not issue a 301, since you still want links to point to the root url. On the language-specific page, I would put a rel="canonical" to the root url.
Regards: how to enable repost on tiktok
Thanks for this article.
I am so glad that you found this interesting. Thank you so much for reading it through😁
I think the only one that I've ever seen before is 300! I can't believe that there are so many!
Yeah, exactly how I felt when I was reading about these status codes!
I have almost never seen these status codes being used, but their use cases are so interesting.
Nice article. Really loved the detailed explanation.
Some more information for the same here
Nice Article
Nice article! Very informative
I am glad you found it helpful. 😁
Nice job. Thanks for sharing
I am glad you found it helpful. 😁
My Apache server is often throwing 406 from oddball hacking attempts to compromise it. Never really paid much attention to what the request headers look like to throw it but take satisfaction in the server being safe from such attempts.
418 is part of the standard.
Yes, but I meant to say that it's not an industry standard, as it has no practical use case and is merely a humorous existence.