Mirrors/httpstatuses
1
0
Fork 0
mirror of https://github.com/rmaake1/httpstatuses.git synced 2024-07-08 12:58:26 +02:00
Code Issues Packages Projects Releases Wiki Activity

fixed 2xx code source reference numbering

Browse Source
This commit is contained in:
Samuel Ryan 2015-11-07 03:03:35 +00:00
parent 6b66663d04
commit 63a1095be6
9 changed files with 50 additions and 49 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
contents/codes/101.md
View File

@ -21,4 +21,4 @@ protocol might be advantageous when delivering resources that use such features.
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>
[2]: <http://tools.ietf.org/html/rfc7230#section-6.7>

8
contents/codes/200.md
View File

@ -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]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
[2]: <http://tools.ietf.org/html/rfc7231#section-6.3.1>
[1]: <http://tools.ietf.org/html/rfc7231#section-6.3.1>
[2]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>

8
contents/codes/201.md
View File

@ -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]: <http://tools.ietf.org/html/rfc7231#section-7.2>
[2]: <http://tools.ietf.org/html/rfc7231#section-6.3.2>
[1]: <http://tools.ietf.org/html/rfc7231#section-6.3.2>
[2]: <http://tools.ietf.org/html/rfc7231#section-7.2

16
contents/codes/203.md
View File

@ -9,23 +9,23 @@ references:
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][1]). This status code allows the proxy to notify
([Section 5.7.2 of RFC7230][2]). 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][2]), which has the advantage of being applicable to
([Section 5.5 of RFC7234][3]), 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][3]).
(see [Section 4.2.2 of RFC7234][4]).
Source: [RFC7231 Section 6.3.4][4]
Source: [RFC7231 Section 6.3.4][1]
[1]: <http://tools.ietf.org/html/rfc7230#section-5.7.2>
[2]: <http://tools.ietf.org/html/rfc7234#section-5.5>
[3]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
[4]: <http://tools.ietf.org/html/rfc7231#section-6.3.4>
[1]: <http://tools.ietf.org/html/rfc7231#section-6.3.4>
[2]: <http://tools.ietf.org/html/rfc7230#section-5.7.2>
[3]: <http://tools.ietf.org/html/rfc7234#section-5.5>
[4]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>

8
contents/codes/204.md
View File

@ -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]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
[2]: <http://tools.ietf.org/html/rfc7231#section-6.3.5>
[2]: <http://tools.ietf.org/html/rfc7231#section-6.3.5>
[1]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>

16
contents/codes/206.md
View File

@ -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]: <http://tools.ietf.org/html/rfc7233#section-3.1>
[2]: <http://tools.ietf.org/html/rfc7233#appendix-A>
[3]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
[4]: <http://tools.ietf.org/html/rfc7233#section-4.1>
[1]: <http://tools.ietf.org/html/rfc7233#section-4.1>
[2]: <http://tools.ietf.org/html/rfc7233#section-3.1>
[3]: <http://tools.ietf.org/html/rfc7233#appendix-A>
[4]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>

18
contents/codes/207.md
View File

@ -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]: <http://tools.ietf.org/html/rfc4918#section-9.6.2>
[2]: <http://tools.ietf.org/html/rfc2616#section-10>
[3]: <http://tools.ietf.org/html/rfc4918#section-9.1>
[4]: <http://tools.ietf.org/html/rfc4918#section-9.2>
[5]: <http://tools.ietf.org/html/rfc4918#section-13>
[1]: <http://tools.ietf.org/html/rfc4918#section-13>
[2]: <http://tools.ietf.org/html/rfc4918#section-9.6.2>
[3]: <http://tools.ietf.org/html/rfc2616#section-10>
[4]: <http://tools.ietf.org/html/rfc4918#section-9.1>
[5]: <http://tools.ietf.org/html/rfc4918#section-9.2>

11
contents/codes/208.md
View File

@ -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]: <http://tools.ietf.org/html/rfc5842#section-2.2>
[2]: <http://tools.ietf.org/html/rfc5842#section-8.2>
[1]: <http://tools.ietf.org/html/rfc5842#section-7.1>
[2]: <http://tools.ietf.org/html/rfc5842#section-2.2>
[3]: <http://tools.ietf.org/html/rfc5842#section-8.2>

12
contents/codes/226.md
View File

@ -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]: <http://tools.ietf.org/html/rfc3229#section-13.5.3>
[2]: <http://tools.ietf.org/html/rfc3229#section-10.6>
[3]: <http://tools.ietf.org/html/rfc3229#section-10.4.1>
[1]: <http://tools.ietf.org/html/rfc3229#section-10.4.1>
[2]: <http://tools.ietf.org/html/rfc3229#section-13.5.3>
[3]: <http://tools.ietf.org/html/rfc3229#section-10.6>