A colleague of mine stumbled upon a HTTP status code that the team wasn’t sure of: 207. When I took a look I stumbled across a few others I hadn’t really been made aware of throughout my 4 year developer career.
Lets go through some interesting codes…
A status code sent to represent information about multiple resources where appropriate.
Imagine you have an aggregation layer that might make calls against multiple APIs to collate & process the data and return a JSON payload. If one of the calls succeeds and several others fail what’s the API to do?
It’s not a 4xx, the resource was found; it’s not a 300, there’s no redirect; it’s not a 5xx, the aggregation server didn’t fail to handle something and explode so it’s technically a 200 in the eyes of the app server.
207 is clever; if implemented properly it’ll give you an XML payload with a description of the information about the success or failure of the layered calls — each element must contain a href to identify the resource. It’s up to the consumer to handle what happens next.
When a server refuses to accept the request without a explicitly defined Content-Length.
Simple and makes sense but not the most common code you might see.
A status code sent to deny access to a resource as a consequence of a legal demand.
A 451 response body should include an explanation of the legal demand, the party making it, the applicable legislation or regulation and what classes of person and resource it applies to.
Interestingly a 451 doesn’t necessarily mean that the resource being requested exists — if the legal reasoning behind denying it were removed, the resource might still not be there.
Yeah you read that right. This client error responds to indicate that the server refuses to brew coffee because it is a teapot.
Relax, It’s an April fools joke from 1998.
Read more about it on the official Request for Comments.
506 can be used to state that the server has an internal configuration error in which the chosen resource is configured to engage in a transparent content call itself, thus it’s not a proper end point in the negotiation process.
Occurs when a server has encountered an infinite loop while processing a request — this is sent to indicate that the operation has failed.
I personally haven’t seen this often as I find that when people detect infinite loops in their code they fix them or they’re uncaught leading to a timeout.
There you have it, sort of interesting right?