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

fixes 1xx code source reference numbering

Browse Source 
For the sake of consistency and future proofing (there may be a
scenario in future where we need to access the source URL for each
status code programmatically) it makes sense to have them consistently
numbered. The source document will always be reference link ID 1.
This commit is contained in:
Samuel Ryan 2015-11-07 02:59:14 +00:00
parent ed94ac1966
commit 6b66663d04
2 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
contents/codes/100.md
View File

@ -13,13 +13,13 @@ 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
[RFC7231 Section 5.1.1][2]. 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]
Source: [RFC7231 Section 6.1.1][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-5.1.1>
[2]: <http://tools.ietf.org/html/rfc7231#section-6.2.1>
[1]: <http://tools.ietf.org/html/rfc7231#section-6.2.1>
[2]: <http://tools.ietf.org/html/rfc7231#section-5.1.1>

8
contents/codes/101.md
View File

@ -8,7 +8,7 @@ references:
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
([Section 6.7 of RFC7230][2]), 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.
@ -18,7 +18,7 @@ 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]
Source: [RFC7231 Section 6.2.2][1]
[1]: <http://tools.ietf.org/html/rfc7230#section-6.7>
[2]: <http://tools.ietf.org/html/rfc7231#section-6.2.2>
[1]: <http://tools.ietf.org/html/rfc7231#section-6.2.2>
[2]: <http://tools.ietf.org/html/rfc7230#section-6.7>