diff --git a/contents/codes/101.md b/contents/codes/101.md index 9eadf4d..dec8010 100644 --- a/contents/codes/101.md +++ b/contents/codes/101.md @@ -21,4 +21,4 @@ protocol might be advantageous when delivering resources that use such features. Source: [RFC7231 Section 6.2.2][1] [1]: -[2]: +[2]: \ No newline at end of file diff --git a/contents/codes/200.md b/contents/codes/200.md index 0248bd4..92fb870 100644 --- a/contents/codes/200.md +++ b/contents/codes/200.md @@ -30,9 +30,9 @@ begins immediately after the 200 response header section. A 200 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls -(see [Section 4.2.2 of RFC7234][1]). +(see [Section 4.2.2 of RFC7234][2]). -Source: [RFC7231 Section 6.3.1][2] +Source: [RFC7231 Section 6.3.1][1] -[1]: -[2]: \ No newline at end of file +[1]: +[2]: \ No newline at end of file diff --git a/contents/codes/201.md b/contents/codes/201.md index 707f0d0..121af8e 100644 --- a/contents/codes/201.md +++ b/contents/codes/201.md @@ -12,11 +12,11 @@ created by the request is identified by either a Location header field in the response or, if no Location field is received, by the effective request URI. The 201 response payload typically describes and links to the resource(s) -created. See [Section 7.2 of RFC7231][1] for a discussion of the meaning and +created. See [Section 7.2 of RFC7231][2] for a discussion of the meaning and purpose of validator header fields, such as ETag and Last-Modified, in a 201 response. -Source: [RFC7231 Section 6.3.2][2] +Source: [RFC7231 Section 6.3.2][1] -[1]: -[2]: \ No newline at end of file +[1]: +[2]: -[2]: -[3]: -[4]: \ No newline at end of file +[1]: +[2]: +[3]: +[4]: \ No newline at end of file diff --git a/contents/codes/204.md b/contents/codes/204.md index 798cf6e..f10e479 100644 --- a/contents/codes/204.md +++ b/contents/codes/204.md @@ -35,9 +35,9 @@ because it cannot contain a message body. A 204 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls -(see [Section 4.2.2 of RFC7234][1]). +(see [Section 4.2.2 of RFC7234][2]). -Source: [RFC7231 Section 6.3.5][2] +Source: [RFC7231 Section 6.3.5][1] -[1]: -[2]: \ No newline at end of file +[2]: +[1]: \ No newline at end of file diff --git a/contents/codes/206.md b/contents/codes/206.md index 35efb23..3869266 100644 --- a/contents/codes/206.md +++ b/contents/codes/206.md @@ -7,7 +7,7 @@ title: Partial Content The 206 (Partial Content) status code indicates that the server is successfully fulfilling a range request for the target resource by transferring one or more parts of the selected representation that correspond to the satisfiable ranges -found in the request's Range header field (see [RFC7233 Section 3.1][1]). +found in the request's Range header field (see [RFC7233 Section 3.1][2]). If a single part is being transferred, the server generating the 206 response MUST generate a Content-Range header field, describing what range of the @@ -27,7 +27,7 @@ Content-Type: image/gif If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in -[RFC7233 Appendix A][2], and a Content-Type header field containing the +[RFC7233 Appendix A][3], and a Content-Type header field containing the multipart/byteranges media type and its required boundary parameter. To avoid confusion with single-part responses, a server MUST NOT generate a Content-Range header field in the HTTP header section of a multiple part response (this field @@ -99,11 +99,11 @@ of the representation header fields that would have been sent in a [200 (OK)](/200) response to the same request. A 206 response is cacheable by default; i.e., unless otherwise indicated by -explicit cache controls (see [Section 4.2.2 of RFC7234][3]). +explicit cache controls (see [Section 4.2.2 of RFC7234][4]). -Source: [RFC7233 Section 4.1][4] +Source: [RFC7233 Section 4.1][1] -[1]: -[2]: -[3]: -[4]: \ No newline at end of file +[1]: +[2]: +[3]: +[4]: diff --git a/contents/codes/207.md b/contents/codes/207.md index 9655f30..3c3504f 100644 --- a/contents/codes/207.md +++ b/contents/codes/207.md @@ -27,20 +27,20 @@ the status: 1\. A 'status' element as child of the 'response' element indicates the status of the message execution for the identified resource as a whole (for instance, -see [RFC4918 Section 9.6.2][1]). Some method definitions provide information +see [RFC4918 Section 9.6.2][2]). Some method definitions provide information about specific status codes clients should be prepared to see in a response. However, clients MUST be able to handle other status codes, using the generic -rules defined in [Section 10 of RFC2616][2]. +rules defined in [Section 10 of RFC2616][3]. 2\. For PROPFIND and PROPPATCH, the format has been extended using the 'propstat' element instead of 'status', providing information about individual properties of a resource. This format is specific to PROPFIND and PROPPATCH, and is -described in detail in [RFC4918 Sections 9.1][3] and [RFC4918 9.2][4]. +described in detail in [RFC4918 Sections 9.1][4] and [RFC4918 9.2][5]. -Source: [RFC4918 Section 13][5] +Source: [RFC4918 Section 13][1] -[1]: -[2]: -[3]: -[4]: -[5]: +[1]: +[2]: +[3]: +[4]: +[5]: diff --git a/contents/codes/208.md b/contents/codes/208.md index 9965265..903d6f6 100644 --- a/contents/codes/208.md +++ b/contents/codes/208.md @@ -13,7 +13,7 @@ DAV:response elements for their descendants are included. Note that the 208 status will only occur for "Depth: infinity" requests, and that it is of particular importance when the multiple collection bindings cause -a bind loop as discussed in [RFC5842 Section 2.2][1]. +a bind loop as discussed in [RFC5842 Section 2.2][2]. A client can request the DAV:resource-id property in a PROPFIND request to guarantee that they can accurately reconstruct the binding structure of a @@ -22,13 +22,14 @@ collection with multiple bindings to a single resource. For backward compatibility with clients not aware of the 208 status code appearing in multistatus response bodies, it SHOULD NOT be used unless the client has signaled support for this specification using the "DAV" request -header (see [RFC5842 Section 8.2][2]). Instead, a 508 status should be +header (see [RFC5842Section 8.2][3]). Instead, a 508 status should be returned when a binding loop is discovered. This allows the server to return the 508 as the top-level return status, if it discovers it before it started the response, or in the middle of a multistatus, if it discovers it in the middle of streaming out a multistatus response. -Source: [RFC5842 Section 7.1](http://tools.ietf.org/html/rfc5842#section-7.1) +Source: [RFC5842 Section 7.1][1] -[1]: -[2]: +[1]: +[2]: +[3]: \ No newline at end of file diff --git a/contents/codes/226.md b/contents/codes/226.md index 49b8fcc..ec3ce86 100644 --- a/contents/codes/226.md +++ b/contents/codes/226.md @@ -12,7 +12,7 @@ the current instance. The actual current instance might not be available except by combining this response with other previous or future responses, as appropriate for the specific instance-manipulation(s). If so, the headers of the resulting instance are the result of combining the headers from the status-226 -response and the other instances, following the rules in [section 13.5.3][1] of +response and the other instances, following the rules in [section 13.5.3][2] of the HTTP/1.1 specification [10]. The request MUST have included an A-IM header field listing at least @@ -22,14 +22,14 @@ field giving the entity tag of the current instance. A response received with a status code of 226 MAY be stored by a cache and used in reply to a subsequent request, subject to the HTTP expiration mechanism and any Cache-Control headers, and to the -requirements in [section 10.6][2]. +requirements in [section 10.6][3]. A response received with a status code of 226 MAY be used by a cache, in conjunction with a cache entry for the base instance, to create a cache entry for the current instance. -Source: [RFC3229 Section 10.4.1][3] +Source: [RFC3229 Section 10.4.1][1] -[1]: -[2]: -[3]: +[1]: +[2]: +[3]: \ No newline at end of file