HTTP Status Code confusions..

Recently, we were working with Microsoft BOT connector and a few other libraries on Microsoft Stack.

We were continuously getting 403 Forbidden returned from server.

Of the course, the naive person that I am, googled what all it could mean. Since, I had already given the right keys and access and it matched all the other code samples available on the internet for accessing the said image content from an URL from Slack, FB and skype, I had to check all the headers and the whether I have used the right ones.

After numerous hits and trials, we stumbled on a solution which told us, that Skype needed login and details, FB messenger and Slack needed Accept Header telling the Content Type for the respective Bot platforms to send image back.

More about this issue and how to handle in the next post on Bot messenger and sending images to your chat bot.

Going back to our case here, I was wondering why was it that all three messenger platforms were giving me confusing responses which had nothing to do with the issue causing it. After a few searches I ended up this blog piece – Choosing a HTTP Status Code.

It is extremely important that servers send the right error code and we act according to the expected error code.

In our case had we got either 406 or 415, we would have found out the issue much earlier!

The website gives the following reasons to use the right elaborated status codes.

1. Clients already handle (or could easily be extended to handle) different codes with special behavior:

   • 301 Moved Permanently vs 302 Found has SEO implications with Google and others
   • 301 Moved Permanently is implicitly cacheable, while 429 Too Many Requests is implicitly not-cacheable, and so on
   • A client library could handle 429 Too Many Requests by backing off and retrying the request after a delay
   • A client library could handle 503 Service Unavilable similarly

2. Even though not exhaustive for modern requirements, many status codes represent cases still worth handling with a special response (so why not use the standard code?)

   • APIs that return 404 in place of 405 Method Not Allowed drive me crazy wondering, “did I just fat-finger the URL or am I sending the wrong HTTP method?”
   • I can tell you we would have saved hours upon hours of debugging time if only we had distinguished 502 Bad Gateway (an upstream problem) instead of confusing it with 500 Internal Server Error

3. Believe it or not, a convention is being established among widely used APIs to return status codes like 201 Created, 429 Too Many Requests, and 503 Service Unavilable. If you follow that convention, users will find it that much easier to use your website/API and troubleshoot any issues they may run into.