HTTP response codes are being received by your browser all the time. Most of the time, these will be successful and pretty much hidden from the user (you!) unless you go digging for them.
The ones that you are likely more familiar with are called client errors – such as HTTP 404 (Page Not Found) and server errors such as HTTP 500 (Internal Server Error).
Let’s take a brief look at the different categories of HTTP response codes.
HTTP 100 to HTTP 199 – Informational Response Codes
These response codes are returned to a web browser for information only. You’re probably least familiar with these and essentially are just providing mini-updates to your browser that don’t necessarily require it to do anything.
For example HTTP 100 – or ‘continue’ is basically saying ‘keep on doing what you’re doing, everything’s OK so far’.
HTTP 200 to HTTP 299 – Successful Response Codes
We’re likely not familiar seeing these displaying on our screen because success is success. You requested a page and now it’s displayed (HTTP 200 – ‘OK’ in techie terms). It’s likely that only uber geeky people are going to be even remotely interested in knowing this. If everything’s OK, just show me the “okness!”.
Nethertheless, it’s important for browsers to know that a request has been successfully completed otherwise, who knows? Maybe you’re staring at a blank screen and the browser is none the wiser!
HTTP 300 to HTTP 399 – Redirection Response Codes
You’ll come across these fairly frequently, but similar to successful response codes, you’ll likely never ‘see’ them in your day to day browsing.
For example, HTTP 301 is ‘Moved Permanently’. Picture the scene – you’ve navigated from Google search results to a blog post that you might have found interesting. You’ve clicked on that blog post and the site owner has done a restructure (careful with SEO!) and it no longer ‘lives’ there. The site owner pre-empts this by setting up a response that says ‘hey, this post doesn’t live here any more, it’s over there’.
The upshot? Rather than showing you a message saying it’s moved, it triggers the browser to do the helpful thing which is to send you to its new location. After a very brief delay, the intended blog article is displayed to you. You may notice a different address in the address bar if you’re eagle-eyed, but otherwise it’ll be like nothing that happened.
After all, how many of us focus on every part of the link before we’ve clicked on the search result? Answer: no one.
HTTP 400 to HTTP 499 – Client Error Responses
Houston, we have a problem. And it’s on your end. You are the client so essentially you’ve done something wrong – potentially.
The most common HTTP 4xx error encountered is HTTP 404 – Page Not Found. Now technically, the problem always lies with you. You’ve requested something that doesn’t exist. The server isn’t at fault. However, if you’ve just clicked through from Google to a blog post (using the same example as above) then it might not actually be you in the truest sense. However, what it is trying to say is that, even by proxy, you have requested something that doesn’t exist. Sometimes these errors are caused when we try to type out a link and make a few mistakes – these ones are easier to conceptualise as ‘our’ fault but the technical process (and therefore blame!) is the same – the client has done something that the server isn’t expecting it to do.
HTTP 500 to HTTP 599 – Server Error Responses
Now these are the ones that aren’t you. You’ve requested the blog post by clicking the link on Google and the server is down – cue a HTTP 500 Internal Server Error. Essentially, that’s the server telling your web browser that it doesn’t have a Scooby Doo what to do. Server upgrade gone bad? Dodgy coding making a site fall over? Victim of a server hack? Accidental deletion of mission critical website files? Whatever it is, there’s nothing you can do about it from your side except maybe report it to the website owner.
Remember those ‘contact the webmaster on…’ messages? They’re not as common anymore – there’s so many uptime and website monitoring systems in place nowadays – even many free ones – the website owner likely already knows there’s a problem moments after you’ve encountered it yourself. Smart eh?
Maybe give them a little bit of time and try visiting again later!
And… that’s it!
Hopefully that whirlwind tour of HTTP status codes has been interesting. Any questions, throw them in the comments below!