diff --git a/contents/codes/200.md b/contents/codes/200.md index 123229b..caea02a 100644 --- a/contents/codes/200.md +++ b/contents/codes/200.md @@ -3,38 +3,36 @@ set: 2 code: 200 title: OK references: - "Rails HTTP Status Symbol": ":not_found" + "Rails HTTP Status Symbol": ":ok" --- -The 200 OK status code indicates that the request has succeeded. The payload -sent in a 200 response depends on the request method. +The request has succeeded. -For the methods defined by this specification, the intended meaning of the -payload can be summarized as: +The payload sent in a 200 response depends on the request method. For the +methods defined by this specification, the intended meaning of the payload can +be summarized as: -GET a representation of the target resource +* `GET` a representation of the target resource +* `HEAD` the same representation as `GET`, but without the representation data +* `POST` a representation of the status of, or results obtained from, the action; + * `PUT` `DELETE` a representation of the status of the action; + * `OPTIONS` a representation of the communications options; + * `TRACE` a representation of the request message as received by the end server. -HEAD the same representation as GET, but without the representation data - -POST a representation of the status of, or results obtained from, the action; - -PUT, DELETE a representation of the status of the action; - -OPTIONS a representation of the communications options; - -TRACE a representation of the request message as received by the end server. - -Aside from responses to CONNECT, a 200 response always has a payload, though an -origin server MAY generate a payload body of zero length. If no payload is -desired, an origin server ought to send [204 (No Content)](/204) instead. For -CONNECT, no payload is allowed because the successful result is a tunnel, which +Aside from responses to CONNECT, a 200 response always has a payload, though an +origin server MAY generate a payload body of zero length. If no payload is +desired, an origin server ought to send [204 No Content](/204) instead. For +CONNECT, no payload is allowed because the successful result is a tunnel, which 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][2]). +A 200 response is cacheable by default; i.e., unless otherwise indicated by the +method definition or explicit cache controls[1](#ref-1). -Source: [RFC7231 Section 6.3.1][1] +--- + +* 1 Calculating Heuristic Freshness +[Section 4.2.2 of RFC7234][2] +* Source: [RFC7231 Section 6.3.1][1] [1]: [2]: \ No newline at end of file diff --git a/contents/codes/201.md b/contents/codes/201.md index 6d4a7a2..3100aa0 100644 --- a/contents/codes/201.md +++ b/contents/codes/201.md @@ -6,19 +6,21 @@ references: "Rails HTTP Status Symbol": ":created" --- -The 201 Created status code indicates that the request has been fulfilled and -has resulted in one or more new resources being created. +The request has been fulfilled and has resulted in one or more new resources +being created. -The primary resource -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 primary resource 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][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][1] +--- + +* Source: [RFC7231 Section 6.3.2][1] [1]: [2]: \ No newline at end of file diff --git a/contents/codes/203.md b/contents/codes/203.md index f33e2b3..51141fe 100644 --- a/contents/codes/203.md +++ b/contents/codes/203.md @@ -6,25 +6,31 @@ references: "Rails HTTP Status Symbol": ":non_authoritative_information" --- -The 203 Non-Authoritative Information status code indicates that the request -was successful but the enclosed payload has been modified from that of the -origin server's [200 (OK)](/200) response by a transforming proxy -([Section 5.7.2 of RFC7230][2]). +The request was successful but the enclosed payload has been modified from that +of the origin server's [200 OK](/200) response by a transforming +proxy[1](#ref-1). This status code allows the proxy to notify recipients when a transformation has been applied, since that knowledge might impact later decisions regarding the content. For example, future cache validation requests for the content might only be applicable along the same request path (through the same proxies). -The 203 response is similar to the Warning code of 214 Transformation Applied -([Section 5.5 of RFC7234][3]), which has the advantage of being applicable to +The 203 response is similar to the Warning code of 214 Transformation +Applied[2](#ref-2), which has the advantage of being applicable to responses with any status code. A 203 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][4]). +method definition or explicit cache controls[2](#ref-3). -Source: [RFC7231 Section 6.3.4][1] +--- + + +* 1 Transformations +[Section 5.7.2 of RFC7230][2] +* 2 Warning [Section 5.5 of RFC7234][3] +* 3 Calculating Heuristic Freshness +[Section 4.2.2 of RFC7234][4] +* Source: [RFC7231 Section 6.3.4][1] [1]: [2]: diff --git a/contents/codes/204.md b/contents/codes/204.md index d99a9c4..d49841e 100644 --- a/contents/codes/204.md +++ b/contents/codes/204.md @@ -6,9 +6,8 @@ references: "Rails HTTP Status Symbol": ":no_content" --- -The 204 No Content status code indicates that the server has successfully -fulfilled the request and that there is no additional content to send in the -response payload body. +The server has successfully fulfilled the request and that there is no +additional content to send in the response payload body. Metadata in the response header fields refer to the target resource and its selected representation after the requested action was applied. @@ -35,10 +34,13 @@ A 204 response is terminated by the first empty line after the header fields 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][2]). +method definition or explicit cache controls[1](#ref-1). -Source: [RFC7231 Section 6.3.5][1] +--- -[2]: -[1]: \ No newline at end of file +* 1 Calculating Heuristic Freshness +[Section 4.2.2 of RFC7234][2] +* Source: [RFC7231 Section 6.3.5][1] + +[1]: +[2]: \ No newline at end of file diff --git a/contents/codes/205.md b/contents/codes/205.md index 979c176..2c1374b 100644 --- a/contents/codes/205.md +++ b/contents/codes/205.md @@ -6,10 +6,9 @@ references: "Rails HTTP Status Symbol": ":reset_content" --- -The 205 Reset Content status code indicates that the server has fulfilled the -request and desires that the user agent reset the "document view", which caused -the request to be sent, to its original state as received from the origin -server. +The server has fulfilled the request and desires that the user agent reset the +"document view", which caused the request to be sent, to its original state as +received from the origin server. This response is intended to support a common data entry use case where the user receives content that supports data entry (a form, notepad, canvas, etc.), @@ -26,6 +25,8 @@ Transfer-Encoding header field with a value of chunked and a message body consisting of a single chunk of zero-length; or, c) close the connection immediately after sending the blank line terminating the header section. -Source: [RFC7231 Section 6.3.6][1] +--- + +* Source: [RFC7231 Section 6.3.6][1] [1]: \ No newline at end of file diff --git a/contents/codes/206.md b/contents/codes/206.md index 8e728e9..4e5fd9a 100644 --- a/contents/codes/206.md +++ b/contents/codes/206.md @@ -2,12 +2,14 @@ set: 2 code: 206 title: Partial Content +references: + "Rails HTTP Status Symbol": ":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][2]). +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[1](#ref-1). 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 @@ -26,17 +28,16 @@ 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][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 -will be sent in each part instead). +MUST generate a "multipart/byteranges" payload[2](#ref-2), 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 will be sent in each part instead). Within the header area of each body part in the multipart payload, the server MUST generate a Content-Range header field corresponding to the range being enclosed in that body part. If the selected representation would have had a -Content-Type header field in a [200 (OK)](/200) response, the server SHOULD +Content-Type header field in a [200 OK](/200) response, the server SHOULD generate that same Content-Type field in the header area of each body part. For example: @@ -88,7 +89,7 @@ order that it requested. When a 206 response is generated, the server MUST generate the following header fields, in addition to those required above, if the field would have been sent -in a [200 (OK)](/200) response to the same request: Date, Cache-Control, ETag, +in a [200 OK](/200) response to the same request: Date, Cache-Control, ETag, Expires, Content-Location, and Vary. If a 206 is generated in response to a request with an If-Range header field, @@ -96,12 +97,19 @@ the sender SHOULD NOT generate other representation header fields beyond those required above, because the client is understood to already have a prior response containing those header fields. Otherwise, the sender MUST generate all of the representation header fields that would have been sent in a -[200 (OK)](/200) response to the same request. +[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][4]). +explicit cache controls[3](#ref-3). -Source: [RFC7233 Section 4.1][1] +--- + +* 1 Range [RFC7233 Section 3.1][2] +* 2 Internet Media Type multipart/byteranges +[RFC7233 Appendix A][3] +* 3 Calculating Heuristic Freshness +[Section 4.2.2 of RFC7234][4] +* Source: [RFC7233 Section 4.1][1] [1]: [2]: diff --git a/contents/codes/207.md b/contents/codes/207.md index 9e0a0b5..bfc0fd4 100644 --- a/contents/codes/207.md +++ b/contents/codes/207.md @@ -27,8 +27,8 @@ A Multi-Status response uses one out of two distinct formats for representing 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][2]). Some method definitions provide information +of the message execution for the identified resource as a +whole[1](#ref-1). 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][3]. @@ -38,7 +38,10 @@ 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][4] and [RFC4918 9.2][5]. -Source: [RFC4918 Section 13][1] +--- + +* 1 Example - DELETE [RFC4918 Section 9.6.2][2] +* Source: [RFC4918 Section 13][1] [1]: [2]: diff --git a/contents/codes/208.md b/contents/codes/208.md index 631a94f..6ab6928 100644 --- a/contents/codes/208.md +++ b/contents/codes/208.md @@ -4,9 +4,8 @@ code: 208 title: Already Reported --- -The 208 Already Reported status code can be used inside a DAV: propstat -response element to avoid enumerating the internal members of multiple bindings -to the same collection repeatedly. +Used inside a DAV: propstat response element to avoid enumerating the internal +members of multiple bindings to the same collection repeatedly. For each binding to a collection inside the request's scope, only one will be reported with a 200 status, while subsequent DAV:response elements for all other @@ -15,7 +14,7 @@ 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][2]. +a bind loop as discussed in [RFC5842][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 @@ -24,13 +23,17 @@ 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 [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 +header[1](#ref-1). Instead, a [508 Loop Detected](/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][1] +--- + +* 1 'DAV' Request Header +[RFC5842Section 8.2][3] +* Source: [RFC5842 Section 7.1][1] [1]: [2]: diff --git a/contents/codes/226.md b/contents/codes/226.md index cdfd4dd..f80b4d8 100644 --- a/contents/codes/226.md +++ b/contents/codes/226.md @@ -13,9 +13,9 @@ 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][2] of the -HTTP/1.1 specification [10]. +are the result of combining the headers from the 226 response and the other +instances, following the rules in [section 13.5.3][2] of the +HTTP/1.1 specification. The request MUST have included an A-IM header field listing at least one instance-manipulation. The response MUST include an Etag header @@ -30,8 +30,10 @@ 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][1] +--- + +* Source: [RFC3229 Section 10.4.1][1] [1]: -[2]: +[2]: [3]: \ No newline at end of file