mirror of
https://github.com/rmaake1/httpstatuses.git
synced 2024-10-04 15:17:23 +02:00
Adds 4xx Client Error class status codes descriptions from latest standards
This commit is contained in:
parent
aed3e7179d
commit
689f94a4bb
@ -2,6 +2,15 @@
|
|||||||
set: 4
|
set: 4
|
||||||
code: 400
|
code: 400
|
||||||
title: Bad Request
|
title: Bad Request
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": "bad_request"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 400 status code
|
The 400 (Bad Request) status code indicates that the server cannot or will not
|
||||||
|
process the request due to something that is perceived to be a client error
|
||||||
|
(e.g., malformed request syntax, invalid request message framing, or deceptive
|
||||||
|
request routing).
|
||||||
|
|
||||||
|
Source: [RFC7231 Section 6.5.1][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.1>
|
@ -2,6 +2,26 @@
|
|||||||
set: 4
|
set: 4
|
||||||
code: 401
|
code: 401
|
||||||
title: Unauthorized
|
title: Unauthorized
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": ":unauthorized"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 401 status code
|
The 401 (Unauthorized) status code indicates that the request has not been
|
||||||
|
applied because it lacks valid authentication credentials for the target
|
||||||
|
resource. The server generating a 401 response MUST send a WWW-Authenticate
|
||||||
|
header field ([RFC7235 Section 4.1][2]) containing at least one challenge
|
||||||
|
applicable to the target resource.
|
||||||
|
|
||||||
|
If the request included authentication credentials, then the 401 response
|
||||||
|
indicates that authorization has been refused for those credentials. The user
|
||||||
|
agent MAY repeat the request with a new or replaced Authorization header field
|
||||||
|
([RFC7235 Section 4.2][3]). If the 401 response contains the same challenge as
|
||||||
|
the prior response, and the user agent has already attempted authentication at
|
||||||
|
least once, then the user agent SHOULD present the enclosed representation to
|
||||||
|
the user, since it usually contains relevant diagnostic information.
|
||||||
|
|
||||||
|
Source: [RFC7235 Section 3.1][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc7235#section-3.1>
|
||||||
|
[2]: <http://tools.ietf.org/html/rfc7235#section-4.1>
|
||||||
|
[3]: <http://tools.ietf.org/html/rfc7235#section-4.2>
|
@ -2,6 +2,12 @@
|
|||||||
set: 4
|
set: 4
|
||||||
code: 402
|
code: 402
|
||||||
title: Payment Required
|
title: Payment Required
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": ":payment_required"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 402 status code
|
The 402 (Payment Required) status code is reserved for future use.
|
||||||
|
|
||||||
|
Source: [RFC7231 Section 6.5.2][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.2>
|
@ -2,6 +2,24 @@
|
|||||||
set: 4
|
set: 4
|
||||||
code: 403
|
code: 403
|
||||||
title: Forbidden
|
title: Forbidden
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": ":forbidden"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 403 status code
|
The 403 (Forbidden) status code indicates that the server understood the request
|
||||||
|
but refuses to authorize it. A server that wishes to make public why the request
|
||||||
|
has been forbidden can describe that reason in the response payload (if any).
|
||||||
|
|
||||||
|
If authentication credentials were provided in the request, the server considers
|
||||||
|
them insufficient to grant access. The client SHOULD NOT automatically repeat
|
||||||
|
the request with the same credentials. The client MAY repeat the request with
|
||||||
|
new or different credentials. However, a request might be forbidden for reasons
|
||||||
|
unrelated to the credentials.
|
||||||
|
|
||||||
|
An origin server that wishes to "hide" the current existence of a forbidden
|
||||||
|
target resource MAY instead respond with a status code of
|
||||||
|
[404 (Not Found)](/404).
|
||||||
|
|
||||||
|
Source: [RFC7231 Section 6.5.3][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.3>
|
@ -2,6 +2,22 @@
|
|||||||
set: 4
|
set: 4
|
||||||
code: 404
|
code: 404
|
||||||
title: Not Found
|
title: Not Found
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": ":not_found"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 404 status code
|
The 404 (Not Found) status code indicates that the origin server did not find a
|
||||||
|
current representation for the target resource or is not willing to disclose
|
||||||
|
that one exists. A 404 status code does not indicate whether this lack of
|
||||||
|
representation is temporary or permanent; the [410 (Gone)](/410) status code is
|
||||||
|
preferred over 404 if the origin server knows, presumably through some
|
||||||
|
configurable means, that the condition is likely to be permanent.
|
||||||
|
|
||||||
|
A 404 response is cacheable by default; i.e., unless otherwise indicated by the
|
||||||
|
method definition or explicit cache controls
|
||||||
|
(see [Section 4.2.2 of RFC7234][2]).
|
||||||
|
|
||||||
|
Source: [RFC7231 6.5.4][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.4>
|
||||||
|
[2]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
|
@ -2,6 +2,19 @@
|
|||||||
set: 4
|
set: 4
|
||||||
code: 405
|
code: 405
|
||||||
title: Method Not Allowed
|
title: Method Not Allowed
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": ":method_not_allowed"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 405 status code
|
The 405 (Method Not Allowed) status code indicates that the method received in
|
||||||
|
the request-line is known by the origin server but not supported by the target
|
||||||
|
resource. The origin server MUST generate an Allow header field in a 405
|
||||||
|
response containing a list of the target resource's currently supported methods.
|
||||||
|
|
||||||
|
A 405 response is cacheable by default; i.e., unless otherwise indicated by the
|
||||||
|
method definition or explicit cache controls (see [Section 4.2.2 of RFC7234][2]).
|
||||||
|
|
||||||
|
Source: [RFC7231 Section 6.5.5][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.5>
|
||||||
|
[2]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
|
@ -2,6 +2,25 @@
|
|||||||
set: 4
|
set: 4
|
||||||
code: 406
|
code: 406
|
||||||
title: Not Acceptable
|
title: Not Acceptable
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": ":not_acceptable"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 406 status code
|
The 406 (Not Acceptable) status code indicates that the target resource does not
|
||||||
|
have a current representation that would be acceptable to the user agent,
|
||||||
|
according to the proactive negotiation header fields received in the request
|
||||||
|
([RFC7231 Section 5.3][2]), and the server is unwilling to supply a default
|
||||||
|
representation.
|
||||||
|
|
||||||
|
The server SHOULD generate a payload containing a list of available
|
||||||
|
representation characteristics and corresponding resource identifiers from which
|
||||||
|
the user or user agent can choose the one most appropriate. A user agent MAY
|
||||||
|
automatically select the most appropriate choice from that list. However, this
|
||||||
|
specification does not define any standard for such automatic selection, as
|
||||||
|
described in [RFC7231 Section 6.4.1][3].
|
||||||
|
|
||||||
|
Source: [RFC7231 Section 6.5.6][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.6>
|
||||||
|
[2]: <http://tools.ietf.org/html/rfc7231#section-5.3>
|
||||||
|
[3]: <http://tools.ietf.org/html/rfc7231#section-6.4.1>
|
@ -2,6 +2,20 @@
|
|||||||
set: 4
|
set: 4
|
||||||
code: 407
|
code: 407
|
||||||
title: Proxy Authentication Required
|
title: Proxy Authentication Required
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": ":proxy_authentication_required"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 407 status code
|
The 407 (Proxy Authentication Required) status code is similar to
|
||||||
|
[401 (Unauthorized)](/401), but it indicates that the client needs to
|
||||||
|
authenticate itself in order to use a proxy. The proxy MUST send a
|
||||||
|
Proxy-Authenticate header field ([Section 4.3][2]) containing a challenge
|
||||||
|
applicable to that proxy for the target resource. The client MAY repeat the
|
||||||
|
request with a new or replaced Proxy-Authorization header field
|
||||||
|
([Section 4.4][3]).
|
||||||
|
|
||||||
|
Source: [RFC7235 Section 3.2][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc7235#section-3.2>
|
||||||
|
[2]: <http://tools.ietf.org/html/rfc7235#section-4.3>
|
||||||
|
[3]: <http://tools.ietf.org/html/rfc7235#section-4.4>
|
@ -2,6 +2,18 @@
|
|||||||
set: 4
|
set: 4
|
||||||
code: 408
|
code: 408
|
||||||
title: Request Timeout
|
title: Request Timeout
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": ":request_timeout"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 408 status code
|
The 408 (Request Timeout) status code indicates that the server did not receive
|
||||||
|
a complete request message within the time that it was prepared to wait. A
|
||||||
|
server SHOULD send the "close" connection option ([Section 6.1 of RFC7230][2])
|
||||||
|
in the response, since 408 implies that the server has decided to close the
|
||||||
|
connection rather than continue waiting. If the client has an outstanding
|
||||||
|
request in transit, the client MAY repeat that request on a new connection.
|
||||||
|
|
||||||
|
Source: [RFC7231 Section 6.5.7][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.7>
|
||||||
|
[2]: <http://tools.ietf.org/html/rfc7230#section-6.1>
|
@ -2,6 +2,23 @@
|
|||||||
set: 4
|
set: 4
|
||||||
code: 409
|
code: 409
|
||||||
title: Conflict
|
title: Conflict
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": ":conflict"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 409 status code
|
The 409 (Conflict) status code indicates that the request could not be completed
|
||||||
|
due to a conflict with the current state of the target resource. This code is
|
||||||
|
used in situations where the user might be able to resolve the conflict and
|
||||||
|
resubmit the request. The server SHOULD generate a payload that includes enough
|
||||||
|
information for a user to recognize the source of the conflict.
|
||||||
|
|
||||||
|
Conflicts are most likely to occur in response to a PUT request. For example, if
|
||||||
|
versioning were being used and the representation being PUT included changes to
|
||||||
|
a resource that conflict with those made by an earlier (third-party) request,
|
||||||
|
the origin server might use a 409 response to indicate that it can't complete
|
||||||
|
the request. In this case, the response representation would likely contain
|
||||||
|
information useful for merging the differences based on the revision history.
|
||||||
|
|
||||||
|
Source: [RFC7231 Section 6.5.8][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.8>
|
@ -2,6 +2,30 @@
|
|||||||
set: 4
|
set: 4
|
||||||
code: 410
|
code: 410
|
||||||
title: Gone
|
title: Gone
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": ":gone"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 410 status code
|
The 410 (Gone) status code indicates that access to the target resource is no
|
||||||
|
longer available at the origin server and that this condition is likely to be
|
||||||
|
permanent. If the origin server does not know, or has no facility to determine,
|
||||||
|
whether or not the condition is permanent, the status code
|
||||||
|
[404 (Not Found)](/404) ought to be used instead.
|
||||||
|
|
||||||
|
The 410 response is primarily intended to assist the task of web maintenance by
|
||||||
|
notifying the recipient that the resource is intentionally unavailable and that
|
||||||
|
the server owners desire that remote links to that resource be removed. Such an
|
||||||
|
event is common for limited-time, promotional services and for resources
|
||||||
|
belonging to individuals no longer associated with the origin server's site. It
|
||||||
|
is not necessary to mark all permanently unavailable resources as "gone" or to
|
||||||
|
keep the mark for any length of time -- that is left to the discretion of the
|
||||||
|
server owner.
|
||||||
|
|
||||||
|
A 410 response is cacheable by default; i.e., unless otherwise indicated by the
|
||||||
|
method definition or explicit cache controls
|
||||||
|
(see [Section 4.2.2 of RFC7234][2]).
|
||||||
|
|
||||||
|
Source: [RFC7231 Section 6.5.9][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.9>
|
||||||
|
[2]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
|
@ -2,6 +2,17 @@
|
|||||||
set: 4
|
set: 4
|
||||||
code: 411
|
code: 411
|
||||||
title: Length Required
|
title: Length Required
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": ":length_required"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 411 status code
|
The 411 (Length Required) status code indicates that the server refuses to
|
||||||
|
accept the request without a defined Content-Length
|
||||||
|
([Section 3.3.2 of RFC7230][2]). The client MAY repeat the request if it adds a
|
||||||
|
valid Content-Length header field containing the length of the message body in
|
||||||
|
the request message.
|
||||||
|
|
||||||
|
Source: [RFC7231 Section 6.5.10][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.10>
|
||||||
|
[2]: <http://tools.ietf.org/html/rfc7230#section-3.3.2>
|
@ -2,6 +2,17 @@
|
|||||||
set: 4
|
set: 4
|
||||||
code: 412
|
code: 412
|
||||||
title: Precondition Failed
|
title: Precondition Failed
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": ":precondition_failed"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 412 status code
|
The 412 (Precondition Failed) status code indicates that one or more conditions
|
||||||
|
given in the request header fields evaluated to false when tested on the server.
|
||||||
|
This response code allows the client to place preconditions on the current
|
||||||
|
resource state (its current representations and metadata) and, thus, prevent the
|
||||||
|
request method from being applied if the target resource is in an unexpected
|
||||||
|
state.
|
||||||
|
|
||||||
|
Source: [RFC7232 Section 4.2][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc7232#section-4.2>
|
@ -1,7 +1,20 @@
|
|||||||
---
|
---
|
||||||
set: 4
|
set: 4
|
||||||
code: 413
|
code: 413
|
||||||
title: Request Entity Too Large
|
title: Payload Too Large
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": ":request_entity_too_large"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 413 status code
|
The 413 (Payload Too Large) status code indicates that the server is refusing
|
||||||
|
to process a request because the request payload is larger than the server is
|
||||||
|
willing or able to process. The server MAY close the connection to prevent the
|
||||||
|
client from continuing the request.
|
||||||
|
|
||||||
|
If the condition is temporary, the server SHOULD generate a Retry-After header
|
||||||
|
field to indicate that it is temporary and after what time the client MAY try
|
||||||
|
again.
|
||||||
|
|
||||||
|
Source: [RFC7231 Section 6.5.11][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.11>
|
@ -2,6 +2,25 @@
|
|||||||
set: 4
|
set: 4
|
||||||
code: 414
|
code: 414
|
||||||
title: Request-URI Too Long
|
title: Request-URI Too Long
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": ":request_uri_too_long"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 414 status code
|
The 414 (URI Too Long) status code indicates that the server is refusing to
|
||||||
|
service the request because the request-target ([Section 5.3 of RFC7230][2]) is
|
||||||
|
longer than the server is willing to interpret. This rare condition is only
|
||||||
|
likely to occur when a client has improperly converted a POST request to a GET
|
||||||
|
request with long query information, when the client has descended into a "black
|
||||||
|
hole" of redirection (e.g., a redirected URI prefix that points to a suffix of
|
||||||
|
itself) or when the server is under attack by a client attempting to exploit
|
||||||
|
potential security holes.
|
||||||
|
|
||||||
|
A 414 response is cacheable by default; i.e., unless otherwise indicated by the
|
||||||
|
method definition or explicit cache controls
|
||||||
|
(see [Section 4.2.2 of RFC7234][3]).
|
||||||
|
|
||||||
|
Source: [RFC7231 Section 6.5.12][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.12>
|
||||||
|
[2]: <http://tools.ietf.org/html/rfc7231#section-5.3>
|
||||||
|
[3]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
|
@ -2,6 +2,16 @@
|
|||||||
set: 4
|
set: 4
|
||||||
code: 415
|
code: 415
|
||||||
title: Unsupported Media Type
|
title: Unsupported Media Type
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": ":unsupported_media_type"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 415 status code
|
The 415 (Unsupported Media Type) status code indicates that the origin server is
|
||||||
|
refusing to service the request because the payload is in a format not supported
|
||||||
|
by this method on the target resource. The format problem might be due to the
|
||||||
|
request's indicated Content-Type or Content-Encoding, or as a result of
|
||||||
|
inspecting the data directly.
|
||||||
|
|
||||||
|
Source: [RFC7231 Section 6.5.13][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.13>
|
@ -2,6 +2,41 @@
|
|||||||
set: 4
|
set: 4
|
||||||
code: 416
|
code: 416
|
||||||
title: Requested Range Not Satisfiable
|
title: Requested Range Not Satisfiable
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": ":requested_range_not_satisfiable"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 416 status code
|
The 416 (Range Not Satisfiable) status code indicates that none of the ranges in
|
||||||
|
the request's Range header field ([RFC7233 Section 3.1][2]) overlap the current
|
||||||
|
extent of the selected resource or that the set of ranges requested has been
|
||||||
|
rejected due to invalid ranges or an excessive request of small or overlapping
|
||||||
|
ranges.
|
||||||
|
|
||||||
|
For byte ranges, failing to overlap the current extent means that the
|
||||||
|
first-byte-pos of all of the byte-range-spec values were greater than the
|
||||||
|
current length of the selected representation. When this status code is
|
||||||
|
generated in response to a byte-range request, the sender SHOULD generate a
|
||||||
|
Content-Range header field specifying the current length of the selected
|
||||||
|
representation ([RFC7233 Section 4.2][3]).
|
||||||
|
|
||||||
|
For example:
|
||||||
|
|
||||||
|
```
|
||||||
|
HTTP/1.1 416 Range Not Satisfiable
|
||||||
|
Date: Fri, 20 Jan 2012 15:41:54 GMT
|
||||||
|
Content-Range: bytes */47022
|
||||||
|
```
|
||||||
|
|
||||||
|
Note: Because servers are free to ignore Range, many implementations will simply
|
||||||
|
respond with the entire selected representation in a [200 (OK)](/200) response.
|
||||||
|
That is partly because most clients are prepared to receive a [200 (OK)](/200)
|
||||||
|
to complete the task (albeit less efficiently) and partly because clients might
|
||||||
|
not stop making an invalid partial request until they have received a complete
|
||||||
|
representation. Thus, clients cannot depend on receiving a
|
||||||
|
416 (Range Not Satisfiable) response even when it is most appropriate.
|
||||||
|
|
||||||
|
Source: [RFC7233 Section 4.4][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc7233#section-4.4>
|
||||||
|
[2]: <http://tools.ietf.org/html/rfc7233#section-3.1>
|
||||||
|
[3]: <http://tools.ietf.org/html/rfc7233#section-4.2>
|
@ -2,6 +2,15 @@
|
|||||||
set: 4
|
set: 4
|
||||||
code: 417
|
code: 417
|
||||||
title: Expectation Failed
|
title: Expectation Failed
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": ":expectation_failed"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 417 status code
|
The 417 (Expectation Failed) status code indicates that the expectation given in
|
||||||
|
the request's Expect header field ([RFC7231 Section 5.1.1][2]) could not be met
|
||||||
|
by at least one of the inbound servers.
|
||||||
|
|
||||||
|
Source: [RFC7231 Section 6.5.14][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.14>
|
||||||
|
[2]: <http://tools.ietf.org/html/rfc7231#section-5.1.1>
|
@ -2,6 +2,13 @@
|
|||||||
set: 4
|
set: 4
|
||||||
code: 418
|
code: 418
|
||||||
title: I'm a teapot
|
title: I'm a teapot
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": ":i'm_a_teapot"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 418 status code
|
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.
|
||||||
|
|
||||||
|
Source: [RFC2324 Section 2.3.2][1]
|
||||||
|
|
||||||
|
[1]: <https://tools.ietf.org/html/rfc2324#section-2.3.2>
|
@ -2,6 +2,30 @@
|
|||||||
set: 4
|
set: 4
|
||||||
code: 421
|
code: 421
|
||||||
title: Misdirected Request
|
title: Misdirected Request
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": ":misdirected_request"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 421 status code
|
The 421 (Misdirected Request) status code indicates that the request was
|
||||||
|
directed at a server that is not able to produce a response. This can be sent by
|
||||||
|
a server that is not configured to produce responses for the combination of
|
||||||
|
scheme and authority that are included in the request URI.
|
||||||
|
|
||||||
|
Clients receiving a 421 (Misdirected Request) response from a server MAY retry
|
||||||
|
the request -- whether the request method is idempotent or not -- over a
|
||||||
|
different connection. This is possible if a connection is reused
|
||||||
|
([RFC7540 Section 9.1.1][2]) or if an alternative service is selected
|
||||||
|
[ALT-SVC][3].
|
||||||
|
|
||||||
|
This status code MUST NOT be generated by proxies.
|
||||||
|
|
||||||
|
A 421 response is cacheable by default, i.e., unless otherwise indicated by the
|
||||||
|
method definition or explicit cache controls
|
||||||
|
(see [Section 4.2.2 of RFC7234][4]).
|
||||||
|
|
||||||
|
Source: [RFC7540 Section 9.1.2][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc7540#section-9.1.2>
|
||||||
|
[2]: <http://tools.ietf.org/html/rfc7540#section-9.1.1>
|
||||||
|
[3]: <http://tools.ietf.org/html/rfc7540#ref-ALT-SVC>
|
||||||
|
[4]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
|
@ -2,6 +2,18 @@
|
|||||||
set: 4
|
set: 4
|
||||||
code: 422
|
code: 422
|
||||||
title: Unprocessable Entity
|
title: Unprocessable Entity
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": ":unprocessable_entity"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 422 status code
|
The 422 (Unprocessable Entity) status code means the server understands the
|
||||||
|
content type of the request entity (hence a [415 (Unsupported Media Type)](/415)
|
||||||
|
status code is inappropriate), and the syntax of the request entity is correct
|
||||||
|
(thus a [400 (Bad Request)](/400) status code is inappropriate) but was unable
|
||||||
|
to process the contained instructions. For example, this error condition may
|
||||||
|
occur if an XML request body contains well-formed (i.e., syntactically correct),
|
||||||
|
but semantically erroneous, XML instructions.
|
||||||
|
|
||||||
|
Source: [RFC4918 Section 11.2][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc4918#section-11.2>
|
@ -2,6 +2,14 @@
|
|||||||
set: 4
|
set: 4
|
||||||
code: 423
|
code: 423
|
||||||
title: Locked
|
title: Locked
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": ":locked"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 423 status code
|
The 423 (Locked) status code means the source or destination resource of a
|
||||||
|
method is locked. This response SHOULD contain an appropriate precondition or
|
||||||
|
postcondition code, such as 'lock-token-submitted' or 'no-conflicting-lock'.
|
||||||
|
|
||||||
|
Source: [RFC4918 Section 11.3][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc4918#section-11.3>
|
@ -2,6 +2,16 @@
|
|||||||
set: 4
|
set: 4
|
||||||
code: 424
|
code: 424
|
||||||
title: Failed Dependency
|
title: Failed Dependency
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": "failed_dependency"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 418 status code
|
The 424 (Failed Dependency) status code means that the method could not be
|
||||||
|
performed on the resource because the requested action depended on another
|
||||||
|
action and that action failed. For example, if a command in a PROPPATCH method
|
||||||
|
fails, then, at minimum, the rest of the commands will also fail with
|
||||||
|
424 (Failed Dependency).
|
||||||
|
|
||||||
|
Source: [RFC4918 Section 11.4][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc4918#section-11.4>
|
@ -2,6 +2,29 @@
|
|||||||
set: 4
|
set: 4
|
||||||
code: 426
|
code: 426
|
||||||
title: Upgrade Required
|
title: Upgrade Required
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": ":upgrade_required"
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 426 status code
|
The 426 (Upgrade Required) status code indicates that 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. The server MUST send an
|
||||||
|
Upgrade header field in a 426 response to indicate the required protocol(s)
|
||||||
|
(Section 6.7 of RFC7230][2]).
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
```
|
||||||
|
HTTP/1.1 426 Upgrade Required
|
||||||
|
Upgrade: HTTP/3.0
|
||||||
|
Connection: Upgrade
|
||||||
|
Content-Length: 53
|
||||||
|
Content-Type: text/plain
|
||||||
|
|
||||||
|
This service requires use of the HTTP/3.0 protocol.
|
||||||
|
```
|
||||||
|
|
||||||
|
Source: [RFC7231 Section 6.5.15][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.15>
|
||||||
|
[2]: <http://tools.ietf.org/html/rfc7230#section-6.7>
|
@ -4,4 +4,33 @@ code: 428
|
|||||||
title: Precondition Required
|
title: Precondition Required
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 428 status code
|
The 428 status code indicates that the origin server requires the request to be
|
||||||
|
conditional.
|
||||||
|
|
||||||
|
Its typical use is to avoid the "lost update" problem, where a client GETs a
|
||||||
|
resource's state, modifies it, and PUTs it back to the server, when meanwhile a
|
||||||
|
third party has modified the state on the server, leading to a conflict. By
|
||||||
|
requiring requests to be conditional, the server can assure that clients are
|
||||||
|
working with the correct copies.
|
||||||
|
|
||||||
|
Responses using this status code SHOULD explain how to resubmit the request
|
||||||
|
successfully. For example:
|
||||||
|
|
||||||
|
```
|
||||||
|
HTTP/1.1 428 Precondition Required
|
||||||
|
Content-Type: text/html
|
||||||
|
|
||||||
|
<html>
|
||||||
|
<head>
|
||||||
|
<title>Precondition Required</title>
|
||||||
|
</head>
|
||||||
|
<body>
|
||||||
|
<h1>Precondition Required</h1>
|
||||||
|
<p>This request is required to be conditional; try using "If-Match".</p>
|
||||||
|
</body>
|
||||||
|
</html>
|
||||||
|
```
|
||||||
|
|
||||||
|
Responses with the 428 status code MUST NOT be stored by a cache.
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc6585#section-3>
|
@ -4,4 +4,40 @@ code: 429
|
|||||||
title: Too Many Requests
|
title: Too Many Requests
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 429 status code
|
The 429 status code indicates that the user has sent too many requests in a
|
||||||
|
given amount of time ("rate limiting").
|
||||||
|
|
||||||
|
The response representations SHOULD include details explaining the condition,
|
||||||
|
and MAY include a Retry-After header indicating how long to wait before making a
|
||||||
|
new request.
|
||||||
|
|
||||||
|
For example:
|
||||||
|
|
||||||
|
```
|
||||||
|
HTTP/1.1 429 Too Many Requests
|
||||||
|
Content-Type: text/html
|
||||||
|
Retry-After: 3600
|
||||||
|
|
||||||
|
<html>
|
||||||
|
<head>
|
||||||
|
<title>Too Many Requests</title>
|
||||||
|
</head>
|
||||||
|
<body>
|
||||||
|
<h1>Too Many Requests</h1>
|
||||||
|
<p>I only allow 50 requests per hour to this Web site per
|
||||||
|
logged in user. Try again soon.</p>
|
||||||
|
</body>
|
||||||
|
</html>
|
||||||
|
```
|
||||||
|
|
||||||
|
Note that this specification does not define how the origin server identifies
|
||||||
|
the user, nor how it counts requests. For example, an origin server that is
|
||||||
|
limiting request rates can do so based upon counts of requests on a per-resource
|
||||||
|
basis, across the entire server, or even among a set of servers. Likewise, it
|
||||||
|
might identify the user by its authentication credentials, or a stateful cookie.
|
||||||
|
|
||||||
|
Responses with the 429 status code MUST NOT be stored by a cache.
|
||||||
|
|
||||||
|
Source: [RFC6585 Section 4][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc6585#section-4>
|
@ -4,4 +4,33 @@ code: 431
|
|||||||
title: Request Header Fields Too Large
|
title: Request Header Fields Too Large
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 431 status code
|
The 431 status code indicates that the server is unwilling to process the
|
||||||
|
request because its header fields are too large. The request MAY be resubmitted
|
||||||
|
after reducing the size of the request header fields.
|
||||||
|
|
||||||
|
It can be used both when the set of request header fields in total is too large,
|
||||||
|
and when a single header field is at fault. In the latter case, the response
|
||||||
|
representation SHOULD specify which header field was too large.
|
||||||
|
|
||||||
|
For example:
|
||||||
|
|
||||||
|
```
|
||||||
|
HTTP/1.1 431 Request Header Fields Too Large
|
||||||
|
Content-Type: text/html
|
||||||
|
|
||||||
|
<html>
|
||||||
|
<head>
|
||||||
|
<title>Request Header Fields Too Large</title>
|
||||||
|
</head>
|
||||||
|
<body>
|
||||||
|
<h1>Request Header Fields Too Large</h1>
|
||||||
|
<p>The "Example" header was too large.</p>
|
||||||
|
</body>
|
||||||
|
</html>
|
||||||
|
```
|
||||||
|
|
||||||
|
Responses with the 431 status code MUST NOT be stored by a cache.
|
||||||
|
|
||||||
|
Source: [RFC6585 Section 5][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc6585#section-5>
|
@ -6,4 +6,11 @@ code: 499
|
|||||||
title: Client Closed Request
|
title: Client Closed Request
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 499 status code
|
The 499 Client Closed Request status is a non-standard status code introduced by
|
||||||
|
[nginx][2] for the case when a client closes the connection while nginx is
|
||||||
|
processing the request.
|
||||||
|
|
||||||
|
Source: [nginx][1]
|
||||||
|
|
||||||
|
[1]: <http://lxr.nginx.org/source/src/http/ngx_http_request.h#0120>
|
||||||
|
[2]: <http://nginx.org>
|
Loading…
Reference in New Issue
Block a user