As a typical Internet user, nothing is more frustrating than waiting for a web page to display, only to receive a “Page Not Found” 404 error status code. Sure, we try reloading the page, and sometimes that gets the gremlins to start working, but most times, the issue is out of our hands. For all of us typical users, we either go onto the next thing or find a different site. There’s a lot going on in the background that most of us are completely unaware of. However, for web developers, HTTP status code errors can be downright annoying.
According to Internet Engineering Task Force (IEFT), the organization that develops and promotes Internet standards, there are over 60 different HTTP status codes. HTTP status codes are classified into the following five groups:
- 1xx Informational Response. Request received and understood. Request processing continues.
- 2xx Success. The action was successfully received, understood, and accepted.
- 3xx Redirection. Further action must be taken by the client to complete the request.
- 4xx Client Errors. An error may have been caused by the client. The request contains bad syntax or cannot be fulfilled.
- 5xx Server Errors. The server has encountered an error and failed to fulfill the request.
It’s important to note that not all of these status codes are considered “errors,” some are just information, or responses to an action, and don’t require troubleshooting or remediation. Here are the 10 most common HTTP status code and what they mean.
Common HTTP Status Codes
- Status Code 200 – This is the standard “OK” status code for a successful HTTP request. The response that is returned is dependent on the request. For example, for a GET request, the response will be included in the message body. For a PUT/POST request, the response will include the resource that contains the result of the action.
- Status Code 201 – This is the status code that confirms that the request was successful and, as a result, a new resource was created. Typically, this is the status code that is sent after a POST/PUT request.
- Status Code 204 – This status code confirms that the server has fulfilled the request but does not need to return information. Examples of this status code include delete requests or if a request was sent via a form and the response should not cause the form to be refreshed or for a new page to load.
- Status Code 304 – The is status code used for browser caching. If the response has not been modified, the client/user can continue to use the same response/cached version. For example, a browser can request if a resource has been modified since a specific time. If it hasn’t, the status code 304 is sent. If it has been modified, a status code 200 is sent, along with the resource.
- Status Code 400 – The server cannot understand and process a request due to a client error. Missing data, domain validation, and invalid formatting are some examples that cause the status code 400 to be sent.
- Status Code 401 – This status code request occurs when authentication is required but has failed or not been provided.
- Status Code 403 – Very similar to status code 401, a status code 403 happens when a valid request was sent, but the server refuses to accept it. This happens if a client/user requires the necessary permission or they may need an account to access the resource. Unlike a status code 401, authentication will not apply here.
- Status Code 404 – The most common status code the average user will see. A status code 404 occurs when the request is valid, but the resource cannot be found on the server. Even though these are grouped in the Client Errors “bucket,” they are often due to improper URL redirection.
- Status Code 409 – A status code 409 is sent when a request conflicts with the current state of the resource. This is usually an issue with simultaneous updates, or versions, that conflict with one another.
- Status Code 500 – Another one of the more commonly seen status codes by users, the 500 series codes are similar to the 400 series codes in that they are true error codes. The status code 500 happens when the server cannot fulfill a request due to an unexpected issue. Web developers typically have to comb through the server logs to determine where the exact issue is coming from.
Monitoring HTTP/S Web Server Performance
Issues can happen at any time. Minimize downtime and customer frustration with the Dotcom-Monitor monitoring platform. HTTP/S web server monitoring checks for availability, performance, content, broken links, and more. With support for cookies, form submissions, custom headers, password secured sites, and timeout thresholds, you won’t get caught off guard. Setup custom alerts and filters to instantly detect and correct web server problems, ensuring your web pages are always accessible to your users, from around the world.