pelicin › web › HTTP

HTTP Response Status Codes

HTTP status codes indicate the status of an HTTP request (e.g. succesful, error, etc.). They are grouped into five classes:

  • 1xx — Informational
  • 2xx — Succesful
  • 3xx — Redirection
  • 4xx — Client Error
  • 5xx — Server Error

This page lists some of them, based on RFC 7231.

1xx: Informational

100 Continue

Everything is good so far, and the client can continue (by sending another request). The server would send the final response once the full request have been received and processed.

Sample usage: Using Expect: 100-continue request header to check before sending a large message body. The server would respond by 100 (Continue) or 417 (Expectation Failed). (See: Status code 100 example: large message body.)

101 Switching Protocol

The server agrees to switch protocol listed on the Upgrade request header. (The response will also have the Upgrade response header, mentioning the protocol the server is switching to.)

Sample usage: Switching protocol to websocket

2xx: Succesful

200 OK

The request has succeeded.

201 Created

The request has succeeded, and has resulted in new resource(s) being created. You can send the newly created resource in the response body, or using the Location response header.

202 Accepted

The request has been accepted for processing, but the processing itself has not been completed or has not been started (i.e. "in queue").

203 Non-Authoritative Information

The request has succeeded, but the response body has been modified by a proxy from the original 200 (OK) response.

204 No Content

The request has succeeded, and there's no content to send in the response body. This hints the user agent to not navigate away from the current page (and give the indication of succcess somehow).

Sample usage: "Save and continue editing" functionality for a wiki site.

205 Reset Content

The request has succeeded, and the user agent should reset the document view (e.g. to reset a form, UI, or canvas state).

206 Partial Content

The request has succeeded, and the response body contains the requested range of data as described in the Range request header. (See: Range request header, e.g. Range: bytes=200-1000, 2000-6576, 19000-.)

3xx: Redirection

300 Multiple Choices

Indicates the request has more than one possible responses (listed in the response body), and the user agent should pick one of them. If the server has a preferred choice, it should generate a Location response header.

Rarely used because of lack of standardization (MDN).

301 Moved Permanently

Indicates permanent redirection to the location pointed by the Location response header.

For historical reasons, some browsers may change the method used to hit the new URI with a GET method (RFC 7231). To keep using the original method, use 308 (Permanent Redirect) instead.

Warning: The user agent will usually remember this redirection and will not hit the old URI again. (You will need to delete the browser's preference to undo this.)

302 Found

Indicates temporary redirection to the location pointed by the Location response header.

For historical reasons, some browsers may change the method used to hit the new URI with a GET method (RFC 7231). To keep using the original method, use 307 (Temporary Redirect). If you want the method to be changed to GET, use 303 (See Other) instead.

303 See Other

Indicates that the server is redirecting the user agent to a different resource (e.g. a confirmation page, an upload progress page, or a representation of the actual resource being requested).

304 Not Modified

Indicates that there is no need to retransmit the requested resources (just use the cached version).

307 Temporary Redirect

Like 302 (Found), but does not allow changing the request method to GET.

308 Permanent Redirect

Like 301 (Moved Permanently), but does not allow changing the request method to GET.

4xx: Client Error

400 Bad Request

The request cannot be processed because of a client error (e.g. invalid request or malformed syntax). The client should not repeat the request without modification.

401 Unauthorized

The request cannot be processed because the client lacks authentication credentials (i.e. not logged in). The response "must" include WWW-Authenticate response header signifying how to how to authorize correctly.

Note: If you use form-based authentication (e.g. you have your own login page), just violate the spec (by not sending the WWW-Authenticate header since nothing is appropriate) OR supply a custom value for WWW-Authenticate (e.g. FormBased). (See: HTTP 401 – What's an appropriate WWW-Authenticate header value?)

402 Payment Required

Reserved for future use.

403 Forbidden

The server understood the request, but refuses to allow it (e.g. a default logged in user is trying to access an admin-only page). The server can include the reason why the request is forbidden, in the response body.

Note: An server that wishes to "hide" the existence of a forbidden target resource may instead respond with 404 (Not Found).

404 Not Found

The server is unable to find the requested resource (or is not willing to disclose whether or not it exists).

This does not indicate if the resource is temporarily or permanently missing. If it's permanently removed, 410 (Gone) should be used instead.

405 Method Not Allowed

Indicates that the HTTP method of the request can't be used on the target resource. The server must include Allow response header indicating which HTTP methods can be used on the resource.

406 Not Acceptable

Indicates that the server can't provide a representation of the target resource that is acceptable to the user agent, and the server is unwilling to supply a default representation.

In other words, the server can't satisfy the content negotiation request headers (e.g. Accept, Accept-Encoding, Accept-Language).

The server should generate a response body containing a list of available representation of the resource.

407 Proxy Authentication Required

Similar to 401 (Unauthorized), but indicates that the client needs to authenticate itself for a proxy server between the client and the target server. The proxy server must send the Proxy-Authenticate response header signifying how to how to authorize correctly.

408 Request Timeout

Indicates that the server didn't receive a complete request message within the time it was prepared to wait (i.e., it would like to close the idle connection). The server should send the Connection: close request header.

Note: Some servers just shut down the connection without sending this response.

409 Conflict

The request cannot be processed because of a conflict with the current state of the target resource (e.g. uploading an older file than the one on the server). The server should generate a request body explaining the source of conflict.

410 Gone

Like 404 (Not Found), but the resource is likely to be gone permanently.

411 Length Required

Indicates that the server refuses to accept the request without a defined Content-Length request header.

412 Precondition Failed

Indicates that one or more conditions given in the request header (e.g. If-Unmodified-Since or If-None-Match) evaluated to false when tested on the server.

Sample usage: Preventing POST operation on ETag mismatch

413 Payload Too Large

The request cannot be processed because the request payload is too large. The server may close the connection to prevent the client from continuing the request. If the condition is temporary, the server may send a Retry-After response header.

414 URI Too Long

The request cannot be processed because the URI is too long (e.g. the query string is too long).

415 Unsupported Media Type

The request cannot be processed because the payload format is not supported (can be indicated by the Content-Type or Content-Encoding request header).

416 Range Not Satisfiable

The request cannot be processed because of invalid Range request header (e.g. the resource doesn't contain such range, or the range does not make sense).

When this status code is generated in response to a byte-range request, the sender should generate a Content-Range response header field specifying the current length of the selected representation (e.g. Content-Range: bytes */47022).

417 Expectation Failed

Indicates that the expectation given in the Expect request header (e.g. Expect: 100-continue) could not be met.

426 Upgrade Required

The server refuses to perform the request using the current protocol, but might be willing to do so after the client upgrades to a different protocol listed on the Upgrade response header.

5xx: Server Error

500 Internal Server Error

The server encountered an unexpected condition that prevented it from fulfilling the request. This is a generic "catch-all" response for server-side errors.

501 Not Implemented

The server doesn't support the functionality required to fulfill the request (e.g. in the case of unrecognized HTTP method).

502 Bad Gateway

The server (while acting as a gateway/proxy) received an invalid response from the target server (e.g. the target server is down).

503 Service Unavailable

The server is not ready to handle the request (e.g. it's overloaded or is down for maintenance). The server may send a Retry-After response header to suggest an appropriate amount of time for the client to wait before retrying the request.

504 Gateway Timeout

The server (while acting as a gateway/proxy) did not receive a timely response from the target server.

505 HTTP Version Not Supported

The server does not support, or refuses to support, the major version of HTTP that was used in the request.

References