| HTTP |
|---|
| |
| Request methods |
| Header fields |
| Response status codes |
| Security access control methods |
| Security vulnerabilities |
This article lists standard and notable non-standard HTTP response status codes. Standardized codes are defined by IETF as documented in Request for Comments (RFC) publications and maintained by the IANA. [1] Other, non-standard values are used by various servers. The descriptive text after the numeric code – the reason phrase– is shown here with typical value, but in practice, can be different or omitted.
Status codes defined by IETF are listed below. Emphasized terms must, must not and should are interpretation guidelines as given by RFC 2119.
An informational response indicates that the request was received and understood and is being processed. It alerts the client to wait for a final response. The message does not contain a body. As the HTTP/1.0 standard did not define any 1xx status codes, servers must not send a 1xx response to an HTTP/1.0 compliant client except under experimental conditions.
Expect: 100-continue as a header in its initial request and receive a 100 Continue status code in response before sending the body. If the client receives an error code such as 403 (Forbidden) or 405 (Method Not Allowed) then it should not send the request's body. The response 417 Expectation Failed indicates that the request should be repeated without the Expect header as it indicates that the server does not support expectations (this is the case, for example, of HTTP/1.0 servers). [2] : §10.1.1 A success status indicates that the action requested by the client was received, understood, and accepted. [1]
A 3xx status indicates that the client must take additional action, generally URL redirection, to complete the request. [1] A user agent may carry out the additional action with no user interaction if the method used in the additional request is GET or HEAD. A user agent should prevent cyclical redirects. [2] : §15.4
A 4xx status code is for situations in which an error seems to have been caused by the client. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents should display any included entity to the user.
5xx status indicates that the server is aware that it has encountered an error or is otherwise incapable of performing the request. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and indicate whether it is a temporary or permanent condition. Likewise, user agents should display any included entity to the user. These response codes are applicable to any request method.
The following codes are used by various web servers but not specified by an IETF standard.
Microsoft's Internet Information Services (IIS) web server expands the 4xx error space to signal errors with the client's request. IIS sometimes uses additional decimal sub-codes for more specific information, [34] however these sub-codes only appear in the response payload and in documentation, not in the place of an actual HTTP status code.
The nginx web server software expands the 4xx error space to signal issues with the client's request. [40] [41]
Cloudflare's reverse proxy service expands the 5xx series of errors space to signal issues with the origin server. [43]
Amazon Web Services' Elastic Load Balancing adds a few custom return codes to signal issues either with the client request or with the origin server. [56]
Used by Apache HTTP Server.
ProxyErrorOverride setting is enabled. It is displayed in this situation instead of a 4xx or 5xx error message. [57] Used by Laravel Framework.
Used by Spring Framework.
Used by Twitter.
Used by Shopify.
Used by ArcGIS Server.
Used by cPanel.
Used by Qualys in the SSLLabs server testing API.
Used by the Pantheon Systems web platform.
Used by LinkedIn.
The following caching related warning codes were specified under RFC 7234. Unlike the other status codes above, these were not sent as the response status in the HTTP protocol, but as part of the "Warning" HTTP header. [71] [72]
Since this "Warning" header is often neither sent by servers nor acknowledged by clients, this header and its codes were obsoleted by the HTTP Working Group in 2022 with RFC 9111. [73]
Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout.