Mirrors/httpstatuses
1
0
Fork 0
mirror of https://github.com/rmaake1/httpstatuses.git synced 2024-10-02 22:27:21 +02:00
Code Issues Packages Projects Releases Wiki Activity

Improves 1xx class of status codes with references

Browse Source
This commit is contained in:
Samuel Ryan 2015-11-08 22:48:01 +00:00
parent e219d76d13
commit a2b46df2a5
3 changed files with 28 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
contents/codes/100.md
View File

@ -6,20 +6,22 @@ references:
"Rails HTTP Status Symbol": ":continue"
---
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.
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][2]. The
client ought to continue sending the request and discard the 100 response.
request payload body<sup>[1](#ref-1)</sup>. 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][1]
---
* <span id="ref-1"><sup>1</sup> As described in [RFC7231 Section 5.1.1][2]</span>
* Source: [RFC7231 Section 6.1.1][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.2.1>
[2]: <http://tools.ietf.org/html/rfc7231#section-5.1.1>

18
contents/codes/101.md
View File

@ -6,21 +6,23 @@ references:
"Rails HTTP Status Symbol": ":switching_protocols"
---
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][2]), for a change in the application protocol being
used on this connection.
The server understands and is willing to comply with the client's request, via
the Upgrade header field<sup>[1](#ref-1)</sup>, 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.
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][1]
---
* <span id="ref-1"><sup>1</sup> As described in [Section 6.7 of RFC7230][2]</span>
* Source: [RFC7231 Section 6.2.2][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.2.2>
[2]: <http://tools.ietf.org/html/rfc7230#section-6.7>

17
contents/codes/102.md
View File

@ -6,13 +6,12 @@ references:
"Rails HTTP Status Symbol": ":processing"
---
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.
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
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.
@ -20,9 +19,11 @@ 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
102 Processing status code to indicate to the client that the server is still
processing the method.
Source: [RFC2518 Section 10.1][1]
---
* Source: [RFC2518 Section 10.1][1]
[1]: <http://tools.ietf.org/html/rfc2518#section-10.1>