So at lunch today myself, Isaac and a bunch of other co-workers who would probably prefer to remain nameless were having one of those free-flowing, ultra-nerdy conversations that you only get when you concentrate a bunch of incredibly technical people in one place and then prevent them, through social convention, from talking about work. These are pretty much a daily occurrence at Yahoo! at lunch time.

The conversation somehow turned -- I think it was Isaac's idea, so perhaps he can illuminate us as to his inspiration -- to the idea of simplifying conversation by referring to common workplace situations by their equivalent HTTP status codes. This turned out to be incredibly easy, and possibly even useful.

For the non-nerdy, a brief explanation: HTTP is the language your web browser uses to speak to web servers to request your pages. It's how the web server knows which content (such as a web page) you want to see. This happens before HTML or any other language gets involved, and it's used whether the content you're requesting is a web page, a picture, a movie or a file to download. The status codes are how the web server tells your browser (aka your client) roughly how things went -- so your browser knows whether the page you're seeing is the page you asked for, or whether it's an error page, or any number of other things.

This maps pretty well to a conversation between a programmer and a normal person. The normal person -- a manager, or a product person, or a marketroid -- wants something from the programmer, and the programmer needs to tell them what's going on, and often they can't just do that by giving them exactly what they asked for. And since programmers are notably bad at communicating with normal people but notably good at being very accurate about codes, this translation guide can help.

I'm not sure how often we will end up actually using these in real life -- although people occasionally use 404 already, and I am absolutely positive that 502 is going to come in handy -- but they at the very least serve as a very quick way of reminding you what the codes mean, if you happen to be building a web service. And if you're me, you're building a new web service every other bloody day, because that's all they want these days, another goddamn web service. Ahem.

Without further ado:

Interesting side note: even at the protocol level, the programmer's expectation that it is nearly always the client's fault and hardly ever the programmer's fault is obvious.

These codes and their definitions are based on the HTTP 1.1 specification. We welcome suggestions for further refinement.