Elf Qrin's Cyber Lab

since 1999

HTTP Status Codes
v1.0 r01Jan2001 fr01Jan001
by Elf Qrin

These are the standard status codes returned by a web server when we ask for a resource. Normally, when the server give us the resource we requested, we get a "200" (OK) status code, even if the browser doesn't show it because it shows the requested document instead.
When something goes wrong, we receive an error message, tipically "404" (Page not Found), when the server can't find the resource we asked at that specific location (path). Yet, many "404" should actually be reported as "410" (Gone), which means that the document we requested was actually there once, but it has been deleted, or "301" (Moved Permanently) or "302" (Moved Temporarily) when it has been moved elsewhere.

Such information about HTTP status codes comes from the RFC2616 (Jun1999) (which obsoletes RFC2068 (Jan1997) and it's updated by RFC2817 (May2000)), Paragraph 6.1.1: Status Code and Reason Phrase, and are explained in detail in Chapter 10: Status Code Definitions.

The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason-Phrase.

The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. There are 5 values for the first digit:

  • 1xx: Informational - Request received, continuing process
  • 2xx: Success - The action was successfully received, understood, and accepted
  • 3xx: Redirection - Further action must be taken in order to complete the request
  • 4xx: Client Error - The request contains bad syntax or cannot be fulfilled
  • 5xx: Server Error - The server failed to fulfill an apparently valid request
The individual values of the numeric status codes defined for HTTP/1.1, and an example set of corresponding Reason-Phrase's, are presented below. The reason phrases listed here are only recommended -- they may be replaced by local equivalents without affecting the protocol, yet phrases must contain text only, without CR and LF characters.

100 : Continue
101 : Switching Protocols
200 : OK
201 : Created
202 : Accepted
203 : Non-Authoritative Information
204 : No Content
205 : Reset Content
206 : Partial Content
300 : Multiple Choices
301 : Moved Permanently
302 : Moved Temporarily
303 : See Other
304 : Not Modified
305 : Use Proxy
307 : Temporary Redirect
400 : Bad Request
401 : Unauthorized
402 : Payment Required
403 : Forbidden
404 : Not Found
405 : Method Not Allowed
406 : Not Acceptable
407 : Proxy Authentication Required
408 : Request Time-out
409 : Conflict
410 : Gone
411 : Length Required
412 : Precondition Failed
413 : Request Entity Too Large
414 : Request-URI Too Large
415 : Unsupported Media Type
416 : Requested range not satisfiable
417 : Expectation Failed
500 : Internal Server Error
501 : Not Implemented
502 : Bad Gateway
503 : Service Unavailable
504 : Gateway Time-out
505 : HTTP Version not supported

HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response MUST NOT be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents SHOULD present to the user the entity returned with the response, since that entity is likely to include human readable information which will explain the unusual status.