Most of us are familiar with the gut-wrenching, nerve-wracking error codes like 404 and 500. But did you know that not all HTTP status codes and server error messages are mean and scary? Although some of these numbers could appear in the tech remake of Nightmare on Elm Street, others should evoke a sense of excitement and jubilation! But these “good” status codes are rarely visible to the average Internet user.
So this leads us to one final question: How do all these status codes work?
In this guide you’ll find all the necessary information to understand the concepts behind HTTP status code messages. Whether you’re a designer, developer, or just a curious Internet fanatic, this information should be useful to people of all backgrounds. It is my goal to clarify the process of website requests and how the web server passes information to your machine.
What are Numeric Status Codes?
The acronym HTTP stands for Hypertext Transfer Protocol. It’s basically a set of rules and guidelines for how networking should work between systems that share information. HTTP is the backbone for our modern World Wide Web because it handles all communication. HTTP 1.1 has a number of response codes which are sent from the server to inform the client (your computer) what’s going on.
For example, the most common status code is 200. This occurs when a file or resource is accessed via HTTP without any problem. Code 200 specifically means that a URL/URI points to a tangible resource which has been successfully loaded and passed to your computer. Every time we visit a page we get lots of code 200 messages–one for the HTML page itself, and others for each individual resource (image, video, stylesheet, or JS script).
HTTP is not the only networking protocol used for connection over the Internet. Different protocols have other rules. For example File Transfer Protocol (FTP) runs over the Internet, but it’s not generally used through a web browser. So for this post, I’ll be focusing solely on HTTP status codes.
Also it’s important to remember that these error messages are sent from the server to your machine. The only errors which directly relate to you (the client) are in the 4xx category. However these 4xx errors are typically created by some action performed while accessing the website, as opposed to something wrong with your computer or web browser.
When developing or managing a website, you’ll run into many of these status codes. It may be frustrating, but keep in mind this system was created for your benefit. With specific error messages, the process of debugging becomes a heck of a lot quicker. And once you become familiar with the system, you’ll gain more confidence in problem solving and troubleshooting.
Status Code Breakdown
In the following sections, I’ve outlined all the major status code messages. The current HTTP/1.1 spec uses messages ranging from 1xx-5xx, and each category has a different purpose. I don’t think it’s worth memorizing this list unless you feel truly inclined to do so.
Otherwise I’d recommend glossing over the list for key phrases or status codes that you recognize. Some common ones might be 302, 401, or 502. When encountering one of these errors in the future, hit Google to see what else you can learn. There are decades of archives written about how to troubleshoot and detect patterns with status code errors.
Memorizing the definition of each error message can be useful (sometimes), but to solve mystifying server problems you really need to understand the context behind each error.
100 Class: Informational
There are only a couple 1xx codes which represent an operation during the connection phase. These status codes are sent during the interim of a connection, meaning they are not a final status for the connection. 1xx codes were not apart of HTTP 1.0 and have since been adopted into the 1.1 schema.
100 – Continue: This represents a midpoint response that the initial request has been received and will continue with the full request. It’s not usually part of debugging, but it is associated with most requests.
101 – Switching Protocols: By passing an Upgrade header, the server can switch protocols to a different version of HTTP. For example, there is a difference between TCP and websocket protocols.
200 Class: Successful
All of the 2xx codes represent a successful request. The server response will vary depending on what type of information was sent. But overall each response denotes a successful connection to the server and a successful receipt of information from the server.
200 – OK: This is by far one of the most common status messages. It simply means the request was successful and has connected perfectly with the server. Generally it’ll be set with a GET request to return some information (like an image, stylesheet, or Ajax response).
201 – Created: Going one step further, the 201 code represents a successful request after creating a new resource. This could be a new HTML webpage or another document altogether.
202 – Accepted: This code represents a successful connection to the server, but the response has not yet been processed. 202 is a somewhat equivocal status because it’s left open for other connections while the accepted response is being processed.
203 – Non-Authoritative Information: A 203 response is almost identical to the 200 OK response, except the return information is pulled from a different server. This may happen when pulling out API data or when running through a remote database/server farm.
204 – No Content: The 204 status is returned when information has been accepted by the server but there’s no return data. This can happen for one of many reasons, but all of the data transfer generally takes place in the meta header info.
205 – Reset Content: When a user submits content to the server, it’ll sometimes request the original document to reset. A 205 status code is sent from the server to the client when a document needs to be reset or updated.
206 – Partial Content: Returned information through a 206 status is considered a partial response. This is normally associated with cached page content where the user only needs part of a page to be refreshed.
300 Class: Redirection
Most of these 3xx status codes propose a connection refresh or update on the client’s side. Although this does pertain to your web browser, it’s typically an automatic refresh to adjust for new content or URI structures. In poorly-planned scenarios, these redirection statuses can lead to infinite loops which continue to refresh over and over until the server quits.
300 – Multiple Choices: If a specific resource has moved to many different locations, the 300 status code will appear. This offers a set list of options from which the user can obtain their requested resource or webpage.
301 – Moved Permanently: Most web developers have some foreknowledge of the 301 redirect code. A 301 status indicates that a resource has moved to a new location and passes the new location over to the client. For example, updating a WordPress URL places a permanent 301 redirect onto the old URL. If you have a Wordpress site, there are several tools to help you with managing 301 redirects in WordPress.
302 – Found: A 302 status is very similar to 301 except it’s just a temporary redirect. So when changing the URL for a webpage or resource the 302 redirect tells the client that it’s only temporary. This means the original URL is still considered active.
303 – See Other: Receiving a 303 code means that the request successfully connected to the resource, but the response is found at a different URI. Each 303 status code should include the response URI within the header.
304 – Not Modified: When loading a resource through cache, it will check if the document has been updated or re-cached since a certain period. If the document hasn’t changed, then a 304 status is returned and the cached content stays the same. This saves on bandwidth since cached resources aren’t continually sent over HTTP.
305 – Use Proxy: It may seem odd, but the 305 code represents a forced proxy connection. If a resource or webpage can only be accessed via proxy the 305 status will return with a Location header containing the proxy URI.
306 – Unused: This was originally used in older HTTP specs but currently serves no purpose.
307 – Temporary Redirect: The 307 redirect is very similar to the 302 status code. They both represent a resource that has temporarily changed locations with a new URI. It seems a 307 may be more apt to handle continual updates to new URIs on a frequent basis although a 302 code could also perform the same task. So from a general user’s perspective, they’re just about the same thing.
400 Class: Client-Side Error
Although the 4xx class may strike a sharp pang of fear, client-side errors are not always your fault. These errors generally indicate that something has gone wrong, and the fix is typically on the client’s side rather than the server’s side.
Most of these codes will also return information about the error, specifying which resource or page is causing the trouble. Also some messages could indicate if the problem seems temporary or permanent.
400 – Bad Request: The 400 status code is pretty straightforward and just means that the request itself could not be understood by the server. The culprit is usually a syntax error in the URI.
401 – Unauthorized: Some resources are protected by authorization through a username/password combo stored on the server itself. When accessing a resource such as this, you might be prompted to enter credentials, and if they don’t match up to an authorized account, you’ll get a 401 error.
402 – Payment Required: The 402 status code is currently unused and seems to be reserved for a future purpose.
403 – Forbidden: The 403 forbidden status code is much like the unauthorized code, except you cannot grant yourself authorization. When you get a 403 error, it means the request was acknowledged by the server, but you cannot access the response. This will sometimes happen when a webmaster blocks certain files or folders from visibility over HTTP.
404 – Not Found: When landing on a 404 error, it’s wise to pull out your gentleman’s pipe and magnifying glass, because there’s a mystery that needs a-solvin’! The 404 status code means that a resource or webpage cannot be found at the given URI and has no new redirect or known location.
405 – Method Not Allowed: The 405 status deals with request methods which are prominent in backend development. When you get a 405 error, it means that the request method cannot be accepted. There are plenty of examples, but the most common are POST and GET requests.
406 – Not Acceptable: This one’s a little tricky to understand, but it has to do with how data is returned. The 406 status means that information was accepted by the server, but the response data cannot be sent. It generally happens when a response type is not supported by the client (or your browser).
407 – Proxy Authentication Required: Very much like the 401 status code, the 407 status requires authentication through a proxy. They both operate in the same manner, but 407 runs through a proxy server.
408 – Request Timeout: Servers are programmed to only wait a certain amount of time for a client response. If the client’s connection takes too long, then you’ll get a 408 timeout error. This can sometimes be fixed by just waiting a bit and refreshing the page.
409 – Conflict: A 409 status code occurs when a requested resource needs to be edited but does not offer permission to do so. For example if a file is meant to be deleted or moved but the client’s connection does not have permission, it will result in a 409 conflict status.
410 – Gone: The 410 status code is like a more specific version of 404. It means that a resource has been moved permanently and is not expected to return to the current URI. However it does not give any indication of a new location.
411 – Length Required: Although certainly rare, the 411 status deals directly with the “Content-Length” header. Some return content may require a specified length before the request can be completed. To fix this error, you need to pass a Content-Length header into the request.
412 – Precondition Failed: If some information passed into the request-header is wrong, then you’ll get a 412 status code. The server evaluates this information and will often pass back a helpful message so you know where the problem occurred.
413 – Request Entity Too Large: If a request is larger than the server can handle, it will return a 413 error code. Most server setups have a configuration dictating the largest possible file size. If a form is submitted passing too much information, you may end up with a 413 error.
414 – Request URI Too Long: It’s also possible that the URI passed to the server is too long. Sometimes you’ll notice this happens when you have all those extra parameters on the end of a URL attached by ampersands (?val=1&other=2&long=yes). This is tricky to fix because it may be a problem with the website’s code and not something you can handle directly.
415 – Unsupported Media Type: When submitting content beyond just plaintext/HTML, you may run into this error. The 415 status code is rare but does appear when passing complex data which cannot be supported by the server. Unsupported audio or video file formats are one such example.
416 – Requested Range Not Satisfiable: The Range request-header can be passed to the server and pull out a certain part of the requested information. A 416 status code occurs when the response is too short and cannot access the full range of data. The error message should include information regarding how many bytes were returned or expected to be returned.
417 – Expectation Failed: Another request-header named Expect can cause a 417 status code. When the Expect field cannot be fulfilled by the server, it returns an expectation error. Most 417 responses are pretty vague, so it can be a difficult puzzle to solve.
500 Class: Server-Side Error
All errors in the 5xx class point towards an error on the server’s side of the connection. Some errors may come with additional information, but they’re not always corrigible from the user’s end. Think of 5xx errors as serious warnings to take up with the web hosting company or server administrator.
500 – Internal Server Error: I’m sure many Internet users have seen the 500 status code at some point. This is the most vague and general of all the 5xx class error messages. It means that the server has encountered an unknown error and is unable to complete the request.
501 – Not Implemented: If a request is sent to the server requiring some functionality which is not installed, you’ll get a 501 error in return. This can happen for any number of reasons including lack of modules, database software, or backend language(s).
502 – Bad Gateway: The 502 error is much more common in larger networks. When a particular server cannot be connected or is considered invalid, then it returns a 502 bad gateway. It’s a rather complicated subject which delves into networking and has nothing to do with the client. Take a peek at this Yahoo! Answers post which gives a little more detail.
503 – Service Unavailable: When you get a 503 error, it generally means the web server is overloaded or down for maintenance. It happens when a server receives too much traffic and has to refuse connection requests.
504 – Gateway Timeout: The 504 gateway is a timeout issue which slightly differs from the 502 invalid gateway. In the 504 status code, your connection is successfully accessing the remote server. But that server is acting like a gateway (or proxy), and the response is taking too long. This error can sometimes be fixed if you wait a little while and refresh the page.
505 – HTTP Version Not Supported: If you send a request using an unsupported version of HTTP, the server returns a 505 status code. This is an error rejecting the request because it can only support a certain version of HTTP. The 505 code should return a message explaining which version(s) are supported.
Analyzing HTTP Headers
Now that you understand more about the purpose of each status code, how can you incorporate them into your workflow? Well if you’re a designer, this may not become a remarkable part of your workflow, but it’s still good to have the ability to analyze header data. So how do you access the HTTP status code of each page and its resources?
Quite possibly the best solution is to install a browser extension which outputs HTTP headers. There are dozens of extensions available for free running the gamut of every major web browser on the market.
Firefox Browser Add-Ons
Every HTTP request includes information sent in a header which includes the content type, server OS, request expiry time, and plenty of other stuff. Most of it will seem like nonsense, but the juicy info pertaining to this article is the HTTP status code.
For example HTTP Response Browser is a free add-on for Mozilla Firefox. Once a page finishes loading, you can view information about the request such as page load time, source code, and certainly the status code. Most instances will give a 200 OK status, but you should recognize when a problem occurs.
Chrome Extensions
If you’re a Google Chrome user, there are a few different options. The developer who built Header Spy for FF also created a Google Chrome extension named HTTP Spy. Those who are looking for simplicity will really like this extension. All the information can be viewed from a popup bubble window, and it doesn’t force information overload.
But Chrome also has a default Network tab which catalogs every individual connection request. Tap F12 on Windows or SHIFT+CMD+I on Mac to view the network tab. In order to get results, you’ll need to refresh the page so each resource can be recorded as it loads.
After using Chrome for a while, I feel the Network tab can get very convoluted. Each individual item is given its own status code based on the HTTP request for that file. So it’s great when performing an in-depth analysis but not useful in every circumstance.
Internet Explorer Extensions
For the few die-hard fans currently sipping from their Bill Gates coffee mug, Internet Explorer also has a series of extensions. Unfortunately the browser has changed so much in the past few years that not every solution works for each version.
A common choice among developers is Fiddler since it’s free and open source. You can view a whole lot more than just HTTP status messages which gives this extension a life of its own.
Interestingly enough, IE has Developer Tools much like you find in Google Chrome. The Developer Tools panel also contains a Network tab which includes HTTP request information for each item (such as status code and latency). Microsoft has a detailed support page going over the process of how this works.
But for those of you who want to test older versions of IE, definitely check out DebugBar. Most web designers and developers recognize this site is home to IETester–a free program for testing every version of Internet Explorer down to IE5.5. They release great products, and I feel the same way about their DebugBar add-on as well.
Mac users who are on Safari will have a rougher time finding an extension. But Safari does have a series of developer tools just like Internet Explorer. By following these instructions in Safari, you can obtain HTTP status codes from any webpage, along with loaded resources and all that other sweet junk.
Opera Extensions
Last but certainly not least, I’d like to cover Opera. This is a lesser-used web browser, but the community is full of developers who release free extensions in their spare time. Since the community is so small, you’ll rarely find more than 2 or 3 different extensions for each extra bit of functionality.
After searching in Google, I found a couple different choices to assist with reading network information. The first is HTTP Header which displays HTTP info inside a popup bubble. The developer also created another version of the plugin for Firefox users.
The interface isn’t dolled up with ribbons and mascara but it still works great. The extension is completely free and installs a button in the top toolbar which you can use to check HTTP status information.
A slightly more detailed option would be Live HTTP Headers which looks an awful lot like typical developer tools. Each resource is loaded based on its status. The individual status numbers are colored differently based on their status code family (2xx, 3xx, 4xx, etc). It’s also completely free and a worthwhile choice for Opera lovers.
Applicable Status Codes
Learning how to read status codes will certainly prove useful at some point down the line. When troubleshooting your own website or researching on another site, HTTP status codes are always available.
One example is to check for any problems in your own web server. You may run into errors on your own page loading resources of CSS and JS files. But nowadays developers also link out to cloud-hosted storage for web fonts, JS libraries, and all sorts of similar resources.
Understanding why a certain file isn’t loading can save you endless hours of stress and head trauma from banging your face against the desk in frustration.
Similarly this knowledge is helpful as you push further into web development or if you work with a team of developers. Aside from typical HTTP GET requests, you’ll also have to deal with POST requests. Each request type represents submitted content sent to the server via a contact form, signup page, or anything similar. In fact Ajax requests often deal with status code messages to organize a better understanding of the data connection at each stage.
Error messages can be sent over HTTP through backend languages such as PHP or Ruby on Rails. If you’re not a developer, then these specific messages probably don’t apply to your line of work. But having the perspicacity to understand these status messages can give you a little more value to the development team.
Independent Research
One of the most important suggestions I can make is to be daring enough to search for a solution on your own. People who learn how to use Google are often more likely to find a solution and fix their own problem without bothering anyone else.
HTTP errors, programming errors, and server errors are some of the most common problems faced by people who build websites. Most people will start researching a problem by themselves, but eventually ask for help from others with more knowledge in order to avoid deleterious effects.
Who wants to blindly mess around with a server or website without actually understanding the problem?
So when you’re faced with an error message that you don’t understand, start with Google. You might be surprised how many results apply to your exact situation. It obviously helps to include search keywords related to the context of your situation. But for the most part, you’ll find a boatload of tech forums, blog posts, and social communities discussing your problem.
If you do some research and still find yourself completely stuck, then sign up for an account on a support forum and post a new thread detailing your conundrum. I would highly recommend the Stack Exchange community which is dedicated to Q&A problem solving. You might be surprised how many people are willing to help you out.
Final Wrap-up
Most designers probably won’t feel overly-concerned with status codes. But even the basic concepts are incredibly important to understand. If you primarily design pretty graphics, then you won’t be troubleshooting server error messages all too often. Yet if you do work in any online field, it’s worth understanding how the World Wide Web actually runs.
I certainly hope this guide can be of great value to designers, developers, or tech lovers of any kind. The Internet seems complex, but there are very logical rules governing each major process. Once you understand the bigger picture of networking over the Internet, web design and development should become a much less intimidating task.
Additional Learning
I certainly hope this guide can be of great value to designers, developers, or tech lovers of any kind. The Internet seems complex, but there are very logical rules governing each major process. Once you understand the bigger picture of networking over the Internet, web design and development should become a much less intimidating task.
A NICE GUIDE TO HTTP STATUS CODES AND SERVER ERROR MESSAGES
No comments:
Post a Comment