mirror of
https://github.com/rmaake1/httpstatuses.git
synced 2024-10-06 08:07:21 +02:00
fixed 2xx code source reference numbering
This commit is contained in:
parent
6b66663d04
commit
63a1095be6
@ -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>
|
@ -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
|
@ -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>
|
@ -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>
|
||||
[1]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
|
@ -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>
|
||||
|
@ -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>
|
||||
|
@ -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,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>
|
Loading…
Reference in New Issue
Block a user