mirror of
https://github.com/rmaake1/httpstatuses.git
synced 2024-10-06 08:07:21 +02:00
Adds 1xx Informational class codes using latest description from the standards
This commit is contained in:
parent
615cb0ef43
commit
6e3e0dd158
@ -4,4 +4,20 @@ code: 100
|
|||||||
title: Continue
|
title: Continue
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the content of the 100 status code
|
The 100 (Continue) status code indicates that the initial part of a request has
|
||||||
|
been received and has not yet been rejected by the server. The server intends to
|
||||||
|
send a final response after the request has been fully received and acted upon.
|
||||||
|
|
||||||
|
When the request contains an Expect header field that includes a 100-continue
|
||||||
|
expectation, the 100 response indicates that the server wishes to receive the
|
||||||
|
request payload body, as described in
|
||||||
|
[RFC7231 Section 5.1.1][1]. The
|
||||||
|
client ought to continue sending the request and discard the 100 response.
|
||||||
|
|
||||||
|
If the request did not contain an Expect header field containing the
|
||||||
|
100-continue expectation, the client can simply discard this interim response.
|
||||||
|
|
||||||
|
Source: [RFC7231 Section 6.1.1][2]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc7231#section-5.1.1>
|
||||||
|
[2]: <http://tools.ietf.org/html/rfc7231#section-6.2.1>
|
@ -4,4 +4,19 @@ code: 101
|
|||||||
title: Switching Protocols
|
title: Switching Protocols
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 101 status code
|
The 101 (Switching Protocols) status code indicates that the server understands
|
||||||
|
and is willing to comply with the client's request, via the Upgrade header field
|
||||||
|
([Section 6.7 of [RFC7230]][1]), for a change in the application protocol being
|
||||||
|
used on this connection. The server MUST generate an Upgrade header field in the
|
||||||
|
response that indicates which protocol(s) will be switched to immediately after
|
||||||
|
the empty line that terminates the 101 response.
|
||||||
|
|
||||||
|
It is assumed that the server will only agree to switch protocols when it is
|
||||||
|
advantageous to do so. For example, switching to a newer version of HTTP might
|
||||||
|
be advantageous over older versions, and switching to a real-time, synchronous
|
||||||
|
protocol might be advantageous when delivering resources that use such features.
|
||||||
|
|
||||||
|
Source: [RFC7231 Section 6.2.2][2]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc7230#section-6.7>
|
||||||
|
[2]: <http://tools.ietf.org/html/rfc7231#section-6.2.2>
|
@ -4,4 +4,21 @@ code: 102
|
|||||||
title: Processing
|
title: Processing
|
||||||
---
|
---
|
||||||
|
|
||||||
This is the contents of the 102 status code
|
The 102 (Processing) status code is an interim response used to inform the
|
||||||
|
client that the server has accepted the complete request, but has not yet
|
||||||
|
completed it. This status code SHOULD only be sent when the server has a
|
||||||
|
reasonable expectation that the request will take significant time to complete.
|
||||||
|
As guidance, if a method is taking longer than 20 seconds (a reasonable, but
|
||||||
|
arbitrary value) to process the server SHOULD return a 102 (Processing)
|
||||||
|
response. The server MUST send a final response after the request has been
|
||||||
|
completed.
|
||||||
|
|
||||||
|
Methods can potentially take a long period of time to process, especially
|
||||||
|
methods that support the Depth header. In such cases the client may time-out the
|
||||||
|
connection while waiting for a response. To prevent this the server may return a
|
||||||
|
102 (Processing) status code to indicate to the client that the server is still
|
||||||
|
processing the method.
|
||||||
|
|
||||||
|
Source: [RFC2518 Section 10.1][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc2518#section-10.1>
|
Loading…
Reference in New Issue
Block a user