Mirrors/httpstatuses
1
0
Fork 0
mirror of https://github.com/rmaake1/httpstatuses.git synced 2024-07-08 12:58:26 +02:00
Code Issues Packages Projects Releases Wiki Activity

Adds 1xx Informational class codes using latest description from the standards

Browse Source
This commit is contained in:
Samuel Ryan 2015-11-07 00:28:15 +00:00
parent 615cb0ef43
commit 6e3e0dd158
3 changed files with 51 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
contents/codes/100.md
View File

@ -4,4 +4,20 @@ code: 100
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>

17
contents/codes/101.md
View File

@ -4,4 +4,19 @@ code: 101
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>

19
contents/codes/102.md
View File

@ -4,4 +4,21 @@ code: 102
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>