What is the different HTTP response status codes mean?

In this blog post, we will discuss the meaning of HTTP response status codes that may appear in your browser window from the web server’s response, when a problem occurs loading a webpage. An error code and message will appear in the browser instead of the webpage. The error code (HTTP response status codes) and message that appears is determined by the type of error.

Typically, the error code consists of a three-digit number and a brief message describing the error. If they start with a “1” (1XX) then they are for your information. If they start with a “2” (2XX) then they are indicating a successful connection attempt. An error number beginning with “3” (3XX) means “redirection” – that you must do something else before you can do what you set out to. An error number beginning with “4” (4XX) means “Client Error”. This basically means there is a problem with your computer, rather than the server belonging to someone else. Finally, an error number beginning with “5” (5XX) means that there is a server error, and that the website you are currently trying to access is being affected by an internal server issue.

Client and Server Error Overview

Client errors, or HTTP response status codes from 400 to 499, are the result of HTTP requests sent by a user client (i.e., a web browser or other HTTP client). Even though these types of errors are client-related, it is often useful to know which error code a user is encountering to determine if the potential issue can be fixed by server configuration.

Server errors, or HTTP response status codes from 500 to 599, are returned by a web server when it is aware that an error has occurred or is otherwise not able to process the request.

General Troubleshooting Tips

When using a web browser to test a web server, refresh the browser after making server changes
Check server logs for more details about how the server is handling the requests. For example, web servers such as Apache or Nginx produce two files called access.log and error.log that can be scanned for relevant information.
Keep in mind that HTTP response status code definitions are part of a standard that is implemented by the application that is serving requests. This means that the actual status code that is returned depends on how the server software handles a particular error–this guide should generally point you in the right direction.

Continue

100 Continue.

Allows the client to determine if the origin server is willing to accept the request, for example, based on the request headers, before the client sends the request body. If the request is not accepted, the status code 406 is returned.

101 Switching protocols, or procedures.

Response from the httpd when an upgrade header is received and the requested protocol is supported by the httpd. Will be followed by an Upgrade header specifying the tokens of the protocol stack it is switching to.

102 Processing.

Part of the HTTP status code extensions for Distributed Authoring (WebDAV).

Should be sent to the HTTP client when a request takes a long period to complete. Will always be followed by the final response indicating either success or failure of the request. This status code can be used to avoid connection timeouts preventing the response from being successfully sent to the HTTP client.

Success

200 Action completed successfully.

The request has succeeded, and content is delivered normally.

201 Success! The request has been created following a POST command.

The request has succeeded and has resulted in a new resource being created. Usually, details on the resource such as its new URI and ETag information are included in the httpd response.

202 Your request has been accepted for processing, but the processing isn’t finished.

The request has been accepted for processing, but the processing has not been completed. This is used when a client sends a request to the httpd, but can or does not maintain a persistent connection long enough to await the final response. The response containing the 202-status code should also contain an entity describing a location where the status of the request can be monitored or some estimate of when the request can be expected to be fulfilled.

203 Computer only has partial information it needs to run.

The returned metainformation in the entity header is not the definitive set as available from the origin server but is gathered from a local or a third-party copy. The set presented MAY be a subset or superset of the original version. For example, including local annotation information about the resource might result in a superset of the metainformation known by the origin server. Use of this response code is not required and is only appropriate when the response would otherwise be 200.

204 The server has received your request but there is no information to send back.

The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. This response is primarily intended to allow input for actions to take place without causing a change to the user agent’s active document view.

205 Content has been reset.

The server has fulfilled the request and the user agent should reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate another input action.

206 Your requested file was partially sent because the web page likely crashed or refreshed.

The server has fulfilled the partial get request for the resource. The request must have included a Range header field indicating the desired range and may have included an If-Range header field to make the request conditional.

207 Multi-Status.

Part of the HTTP status code extensions for Distributed Authoring (WebDAV).

Used when a request to the httpd resulted in multiple non-1xx status codes being generated during the method invocation. The response body consists of an XML element ‘multistatus’ which contains multiple ‘response’ elements, each specifying a status code.

Redirection

300 There are multiple choices available.

The requested resource corresponds to any one of a set of representations, meaning Content Negotiation is in effect, on Apache HTTPD Server enabled by the Multiview’s option or a type-map file.

301 File has been moved permanently.

The requested resource has been assigned a new permanent URI.

302 Found.

The requested resource resides temporarily under a different URI. This is the default status code returned if the request matches a Redirect.

303 See Other.

The response to the request can be found under a different URI and should be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource.

304 Not Modified.

If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server should respond with this status code. The httpd response will include header fields informing the HTTP client about the requested resource. If this information is identical to the cached version of the resource, this cached version will be used by the HTTP client. Header fields that include such information are: Date, ETag, Content-Location, Cache-Control, Expires, and/or Vary.

305 A substitute file has been used (proxy).

The requested resource must be accessed through the proxy, which is given by the Location field in the httpd response. Usually, the HTTP client will immediately request the resource described in this Location field.

306 Was used in earlier versions of the RFC, currently unused.

307 Temporary Redirect.

Defined in the HTTP/1.1 specification as a more strict version of 302.

Client error

400 Bad requests.

The request could not be understood by the server due to malformed syntax. Usually, this is because of an error in the HTTP client itself or a plugin/addon/malware loaded in the HTTP client. You can inspect what request was being sent exactly by looking in the access logs. When using mod security, check if the request is matching a rule and being blocked. Very rarely caused by problems on the network layer, either client- or server-side, resulting in corrupted HTTP packets.

Note that there is a bug in IE5 and IE6 causing Bad Request errors to occur when using digest authentication. Apache HTTPD Server provides a workaround for this.

401 Unauthorized access.

When the HTTP client requests a resource that requires authentication, HTTP status code 401 is returned. The HTTP client will need to provide valid authentication details in the request in order to access the resource. If the HTTP client already sent the authentication details and the status code 401 is still returned, this means the authentication details were invalid. Possibly also caused by misconfigured authentication directives or invalid or corrupted password files.

402 Payment is required for access.

This status code is reserved for future use, currently not returned by Apache HTTPD Server.

403 Forbidden.

The server understood the request but is refusing to fulfill it. Common causes are:

* No index file and indexing is turned off
* Deny rule matching the request
* Resource cannot be modified (the default response to a PUT request)
* Filesystem permission problems ([|Logs)

404 Not found.

The server has not found anything matching the request URI. This is commonly caused by an erroneous hyperlink or when resources are moved without modifying references to them. Could also be caused by an invalid internal redirect or rewrite rule, check the access log, and/or rewrite log to see what resource was requested exactly.

Note that *nix operating systems are case-sensitive by default, so a request for /Foo while /foo was intended, will result in a 404-status code being returned.

410 Gone.

The requested resource is no longer available at the server and no forwarding address is known. This is the preferred way of letting the HTTP client know that a resource is permanently no longer available.

422 Unprocessable Entity.

Part of the HTTP status code extensions for Distributed Authoring (WebDAV).

Used to let the HTTP client know that the server understands the content type of the request entity but was unable to process the contained instructions.

423 Locked.

Part of the HTTP status code extensions for Distributed Authoring (WebDAV).

This means the source or destination resource of a method is locked.

424 Failed Dependency.

Part of the HTTP status code extensions for Distributed Authoring (WebDAV).

This means that the method could not be performed on the resource because the requested action depended on another action and that action failed.

426 Upgrade Required.

Part of the HTTP status code extensions for Upgrading to TLS Within HTTP/1.1.

Let the client know that TLS is required for the client request to be completed. This will be followed by an Upgrade header specifying the required TLS version.

Server error

500 Internal Server Error.

The server encountered an unexpected condition that prevented it from fulfilling the request. Basically, means that *something* went wrong on the server. You will need to consult the error log for what exactly went wrong.

501 Not implemented.

The server does not support the functionality required to fulfill the request. This is occasionally seen in cases where a malicious client tries to execute commands through the httpd. Requests like ‘\x05\x01’ arrive at the server, which is replied with a 501-status code.

502 Bad gateways.

The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request. This can happen when a backend processor is misconfigured or encounters an error. Also, the default behavior of mod proxy is to send the status code 502 if it receives syntactically invalid response header lines (i.e. containing no colon) from the origin server.

A bug causing Bad Gateway errors was fixed in 2.2.4, so if you encounter this error using an old version, please upgrade to the most recent version.

503 Out of resources.

The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. Check the current load of the server using for example mod status or your OS (for example top, PS, apache top). Could also be caused by misconfigured MPM settings.

504 Gateway timed-out.

The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the URI (e.g., HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request. You will need to check the status or logs on the backend side to find out what is causing the timeouts.

505 HTTP version is not supported.

The HTTP version used in the request is not supported by the httpd. Note that the Apache HTTPD Server is fully HTTP/1.1 compatible since version 1.2 (released June 1997), so this error will not likely be encountered unless a malformed version was specified in the request.

506 Variant Also Negotiates.

Part of the HTTP status code extensions for Transparent Content Negotiation in HTTP.

This indicates that the server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself and is therefore not a proper endpoint in the negotiation process.

507 Insufficient Storage.

Part of the HTTP status code extensions for Distributed Authoring (WebDAV).

This means the method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request. Also known to be used by other applications, such as Microsoft Exchange.