10 HTTP status codes that sound like relationship problems
Time to read: 6 minutes
404 Not Found and
500 Server Error are probably the most famous HTTP status codes, but many others exist.
For some reason, a lot of the lesser-known HTTP status codes sound like descriptors of relationship problems. In this post we’ll explore them.
If you’re already familiar with how HTTP response cycles work, you can skip HTTP Requests 101 and head straight to the good stuff in the next section.
HTTP requests involve at least two computers. The computer asking for the data is called the client, and the computer sending the data back is known as a server. This dance is called the request-response cycle.
When the server returns a response, it also sends back a status code to provide more information. The status codes are grouped into buckets based on their starting digit.
- 1xx indicates a status update on a request that’s still in progress.
- 2xx is the “it’s all good ” of response codes, indicating that the request was completed successfully.
- 3xx responses are redirects. That is, the client ends up with a different resource than what they had originally requested. A resource, BTW, is the content that lives at a particular URL.
- 4xx responses are errors that are the client’s fault.
- 5xx responses are errors that are the server’s fault.
With that, let’s move on to relationshippy status codes in numerical order.
At some point, we’ve all ignored early evidence that dating somebody was a terrible idea. Especially, y’know, TSwift.
Early Hints is an experimental status code that cuts response times by allowing clients to start downloading resources such as stylesheets while the server is still processing.
Don’t let yourself be used! Self-respect is a foundational aspect of healthy relationships.
Some servers support a new feature called Delta Encoding which allows clients to request just the parts of a page that have changed. The process of client-server negotiation about these partial requests is known as Instance Manipulation, or IM.
The client and server communicate about Instance Manipulation via HTTP headers. Headers are a way of sending extra information between client and server during the request-response cycle. Headers are formatted as key-value pairs. For a deeper dive, check out this post on HTTP headers for the responsible developer.
If the client wants to make a partial request, it will specify which IM format it wants via the
A-IM header. If the server supports Delta Encoding, it will send back the partial response with the 226 status code.
Seeing others can definitely cause relationship probs.
See Other is a 3xx we know it’s some flavor of redirect. Specifically, See Other is used after you send a PUT or POST request and want to redirect to a page other than the newly created or updated resource. For example, if the POST request might take awhile you could redirect users to a loading indicator.
403 Forbidden: the “you shall not pass” of error codes. How is Forbidden different from
401 Unauthorized? Unauthorized should be issued if credentials are required. For example, an unauthenticated user trying to access a page that requires login.
403 Forbidden is for more general situations such as:
- Your IP has been banned due to rate limiting
- You’re trying to upload a file to a folder that doesn’t exist
- Encryption is required but you’re not using it
Some behaviors, like referring to pizza as ‘za, are just plain unacceptable and grounds for immediate breakup. 🍕🚮
Content negotiation sounds like a marketing buzzword, but it’s actually a way for servers to determine which version of a resource to send back to the client. This communication is accomplished by, you guessed it, headers.
For example, you have a page available in Yoruba and English. The client can send the
Accept-Language header with their response to say they’d prefer to be served in Yoruba:
In addition to language, other headers used for content negotiation are:
- User-Agent (although it’s not a best practice)
Sometimes the server doesn’t offer a version of the resource that satisfies the client’s constraints. In that case, the server would return a Not Acceptable response code.
As a conflict-averse soul, I try to avoid having needs at all. Unfortunately, computers have no such compunction. When clients send a request that cannot be fulfilled, conflict ensues.
If you’re a programmer, you may have experienced the joy of merge conflicts, where two people have tried to update the same piece of code in an incompatible way. Similarly, conflicts can happen during HTTP requests if two clients make conflicting PUT requests to update the same resource.
What makes 409 a 409 is that under different circumstances the request would be fine.
Resolution follows conflict, or at least we hope. As a best practice, servers should send clients information on what to do differently next time to avoid or resolve the conflict.
Gone is returned when a resource no longer exists, forever. Bask in the obvious relationship parallels here. If you anticipate maybe getting together with your ex at some point, use a
404 Not Found error instead.
The price of admission for being in love is occasionally lowering your expectations.
The expect header is sent from the client to the server when the client has a request it’s unsure the server can fulfill. For example, pretend I’m a client who wants to upload a three terabyte unicorn makeup tutorial video. I’m REALLY into high-res glitter, don’t judge me. ✨ I might send something like this first:
PUT /unicorn/makeup HTTP/1.1
When the server receives my PUT, she checks in with herself so she can decide “do I really want to deal with your request today?” If yes, she sends back
100 Continue. If not, she sends
417 Expectation Failed. I’m really glad servers are also practicing self-care in these uncertain times. Saying no to requests is important!
Relationships can only blossom if timing is right for all parties involved. HTTP requests can also be finicky about timing.
There are two types of HTTP requests: they can be either encrypted or unencrypted. Unencrypted requests are sent in plain text, which means an attacker could see exactly what data is requested and returned.
Encrypted requests are sent securely via transport-level security (TLS). Only the client and server can decode the requests and responses. An attacker intercepting encrypted traffic would only see seemingly random strings of characters.
When the client initiates an encrypted request, the client and server go through a (sometimes slow) dance known as the TLS handshake. Servers can optionally support early data, or sending data before the TLS handshake has been completed. However, it might not always be safe to send early data -- it’s the server’s call. If not, it will send the
425 Too Early response code so the client can try again later.
I truly hope you are not experiencing relationship problems that require lawyers.
This error code number is a reference to Fahrenheit 451, a science fiction novel about censorship. Error code 451 comes into play when a request cannot be fulfilled because of a government mandate.
This response might not come directly from the origin server. Often legal filtering happens at the ISP level.
Ideally the response will supply a reason why the request can’t be fulfilled. Something like the following:
HTTP/1.1 451 Unavailable For Legal Reasons
Link: <https://volksverhetzung.de>; rel="blocked-by"
<title>Unavailable For Legal Reasons</title>
<h1>Unavailable For Legal Reasons</h1>
<p>This request may not be serviced in Germany due to Strafgesetzbuch section 86a, which disallows "use of symbols of unconstitutional organizations".</p>
From APIs to SDKs to sample apps
API reference documentation, SDKs, helper libraries, quickstarts, and tutorials for your language and platform.
The latest ebooks, industry reports, and webinars
Learn from customer engagement experts to improve your own communication.
Twilio's developer community hub
Best practices, code samples, and inspiration to build communications and digital engagement experiences.