diff --git a/contents/codes/100.md b/contents/codes/100.md
index 184f149..0aa541d 100644
--- a/contents/codes/100.md
+++ b/contents/codes/100.md
@@ -4,4 +4,20 @@ code: 100
 title: Continue
 ---
 
-This is the content of the 100 status code
\ No newline at end of file
+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>
\ No newline at end of file
diff --git a/contents/codes/101.md b/contents/codes/101.md
index 7f681d7..305973c 100644
--- a/contents/codes/101.md
+++ b/contents/codes/101.md
@@ -4,4 +4,19 @@ code: 101
 title: Switching Protocols
 ---
 
-This is the contents of the 101 status code
\ No newline at end of file
+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>
\ No newline at end of file
diff --git a/contents/codes/102.md b/contents/codes/102.md
index c882c8c..cbb2edc 100644
--- a/contents/codes/102.md
+++ b/contents/codes/102.md
@@ -4,4 +4,21 @@ code: 102
 title: Processing
 ---
 
-This is the contents of the 102 status code
\ No newline at end of file
+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>
\ No newline at end of file