Improves 1xx class of status codes with references

contents/codes/100.md

@@ -6,20 +6,22 @@ references:
     "Rails HTTP Status Symbol": ":continue"
 ---
 
-The 100 Continue status code indicates that the initial part of a request has
+The initial part of a request has been received and has not yet been rejected by
-been received and has not yet been rejected by the server. The server intends to
+the server. The server intends to send a final response after the request has
-send a final response after the request has been fully received and acted upon.
+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
+request payload body<sup>[1](#ref-1)</sup>. The client ought to continue sending
-[RFC7231 Section 5.1.1][2]. The
+the request and discard the 100 response.
-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>

contents/codes/101.md

@@ -6,21 +6,23 @@ references:
     "Rails HTTP Status Symbol": ":switching_protocols"
 ---
 
-The 101 Switching Protocols status code indicates that the server understands
+The server understands and is willing to comply with the client's request, via
-and is willing to comply with the client's request, via the Upgrade header field
+the Upgrade header field<sup>[1](#ref-1)</sup>, for a change in the application
-([Section 6.7 of RFC7230][2]), for a change in the application protocol being
+protocol being used on this connection.
-used on this connection.
 
-The server MUST generate an Upgrade header field in the
+The server MUST generate an Upgrade header field in the response that indicates
-response that indicates which protocol(s) will be switched to immediately after
+which protocol(s) will be switched to immediately after the empty line that
-the empty line that terminates the 101 response.
+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>

contents/codes/102.md

@@ -6,13 +6,12 @@ references:
     "Rails HTTP Status Symbol": ":processing"
 ---
 
-The 102 Processing status code is an interim response used to inform the
+An interim response used to inform the client that the server has accepted the
-client that the server has accepted the complete request, but has not yet
+complete request, but has not yet completed it.
-completed it.
 
-This status code SHOULD only be sent when the server has a
+This status code SHOULD only be sent when the server has a reasonable
-reasonable expectation that the request will take significant time to complete.
+expectation that the request will take significant time to complete. As
-As guidance, if a method is taking longer than 20 seconds (a reasonable, but
+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>