Status 599

Recently, I’ve been seeing ads on the Metro targeting the military-industrial complex. While I didn’t find them terribly interesting per se ¹, they did do their job and somehow still ended up catching my attention.

The Ad

Each ad prominently features an HTTP error message plastered on a backdrop of military personnel along with some rhetoric for the viewer to buy the product/service advertised or else face implied dire technical consequences.

I’ve only seen two overall variants so far. The first one features the standard Status 404 that everyone knows and loves ².

The second one, however, features an error code I have never seen before: Status 599.

What in the world is Status 599?

Despite working with web APIs every day, this was the first time I had ever heard of a 599 error code. What exactly is it? And why did the makers of this ad choose that code specifically?

For starters, Status 599 seems to be non-standard. It does not appear to be documented in any RFC and neither Rust nor Go include it as a constant in their list of status codes.

A cursory Google search indicates that Status 599 is supposedly shown when a request made to a proxy gets timed out by the upstream service that the proxy is calling. However, the truth of this is difficult to verify as several sources making this claim this seem to circularly refer to each other.

Becoming ever more curious, I dug a bit deeper and tried to find exactly what software products and what kind of situations people encountered Status 599 in. One source says that Status 599 has been seen among Microsoft HTTP proxies but did not mention any specific products. Searches across forums also show this error showing up in a few other products including SAP Crystal Reports, Cisco CUCM, Shadow PC, Proxmox, and OwnCloud. A few of these do seem to corroborate the proxy timeout definition, relating to connectivity issues with dependencies. Others, not so much. OwnCloud appears to respond with Status 599 when something has gone so horribly wrong that the server can’t even log the error that got thrown. Cisco CUCM’s usage is even more odd, showing Status 599 when the AXL version used by the client is unsupported, a client error that doesn’t seem even remotely related to timeouts or 5xx server errors at all.

What exactly Status 599 means remains ambiguous, and its varied usage across actual software products doesn’t help clear much of that fog. Status 599 still seems like an enigma to me, and I feel like that it is precisely the reason why it was chosen for this ad. Just imagine paying for a piece of software, getting an error message that is effectively gibberish while using it, spending week after week digging through forums and customer support to try to figure out what is wrong, and finally turning up with absolutely nothing. That is extremely frustrating, and perhaps it is that very frustration that this ad hopes to conjure up, rudely resurfacing dreadful memories buried deep in the minds of random IT folks during their otherwise uneventful commutes, all to get their attention.

Appendix: Proxy vs Reverse Proxy

Other than sounding like an epic battle of grand proportions concocted and debated by only the biggest and baddest of nerds, proxy vs reverse proxy is a question I often find myself asking and answering again and again (mostly due to my poor memory).

In short, both are man-in-the-middle components used for forwarding requests. The main difference is that a proxy forwards requests from a private intranet out to the Internet while a reverse proxy forwards requests from the Internet to a private intranet.

A proxy makes sense when you have callers sending requests out into the Internet. For example, let’s say you are a web administrator for a public school. You want to prevent kids from watching anime on their school laptops. You could install a content filter on the laptops that intercepts every outbound HTTP request, checks the origin, and blocks the request if it matches a blocklisted origin. In this case, the content filter is a proxy. It controls which requests from the student can make it out into the external Internet.

On the other hand, a reverse proxy makes sense when you have services that receive requests within your intranet. For example, if you are hosting a server for a web API, you most likely want to have something like NGINX only route requests for certain paths to be handled by your application. In this case, NGINX is a reverse proxy. It controls which requests from the external Internet can make it into your application.