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
|
||||
code: 400
|
||||
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
|
||||
code: 401
|
||||
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
|
||||
code: 402
|
||||
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
|
||||
code: 403
|
||||
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
|
||||
code: 404
|
||||
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
|
||||
code: 405
|
||||
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
|
||||
code: 406
|
||||
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
|
||||
code: 407
|
||||
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
|
||||
code: 408
|
||||
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
|
||||
code: 409
|
||||
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
|
||||
code: 410
|
||||
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
|
||||
code: 411
|
||||
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
|
||||
code: 412
|
||||
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
|
||||
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
|
||||
code: 414
|
||||
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
|
||||
code: 415
|
||||
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
|
||||
code: 416
|
||||
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
|
||||
code: 417
|
||||
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
|
||||
code: 418
|
||||
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
|
||||
code: 421
|
||||
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
|
||||
code: 422
|
||||
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
|
||||
code: 423
|
||||
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
|
||||
code: 424
|
||||
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
|
||||
code: 426
|
||||
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
|
||||
---
|
||||
|
||||
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
|
||||
---
|
||||
|
||||
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
|
||||
---
|
||||
|
||||
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
|
||||
---
|
||||
|
||||
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