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
@ -21,4 +21,4 @@ protocol might be advantageous when delivering resources that use such features.
|
|||||||
Source: [RFC7231 Section 6.2.2][1]
|
Source: [RFC7231 Section 6.2.2][1]
|
||||||
|
|
||||||
[1]: <http://tools.ietf.org/html/rfc7231#section-6.2.2>
|
[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>
|
@ -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
|
A 200 response is cacheable by default; i.e., unless otherwise indicated by the
|
||||||
method definition or explicit cache controls
|
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>
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.3.1>
|
||||||
[2]: <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.
|
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)
|
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
|
purpose of validator header fields, such as ETag and Last-Modified, in a 201
|
||||||
response.
|
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>
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.3.2>
|
||||||
[2]: <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
|
The 203 (Non-Authoritative Information) status code indicates that the request
|
||||||
was successful but the enclosed payload has been modified from that of the
|
was successful but the enclosed payload has been modified from that of the
|
||||||
origin server's [200 (OK)](/200) response by a transforming proxy
|
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
|
recipients when a transformation has been applied, since that knowledge might
|
||||||
impact later decisions regarding the content. For example, future cache
|
impact later decisions regarding the content. For example, future cache
|
||||||
validation requests for the content might only be applicable along the same
|
validation requests for the content might only be applicable along the same
|
||||||
request path (through the same proxies).
|
request path (through the same proxies).
|
||||||
|
|
||||||
The 203 response is similar to the Warning code of 214 Transformation Applied
|
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.
|
responses with any status code.
|
||||||
|
|
||||||
A 203 response is cacheable by default; i.e., unless otherwise indicated by the
|
A 203 response is cacheable by default; i.e., unless otherwise indicated by the
|
||||||
method definition or explicit cache controls
|
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>
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.3.4>
|
||||||
[2]: <http://tools.ietf.org/html/rfc7234#section-5.5>
|
[2]: <http://tools.ietf.org/html/rfc7230#section-5.7.2>
|
||||||
[3]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
|
[3]: <http://tools.ietf.org/html/rfc7234#section-5.5>
|
||||||
[4]: <http://tools.ietf.org/html/rfc7231#section-6.3.4>
|
[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
|
A 204 response is cacheable by default; i.e., unless otherwise indicated by the
|
||||||
method definition or explicit cache controls
|
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>
|
@ -7,7 +7,7 @@ title: Partial Content
|
|||||||
The 206 (Partial Content) status code indicates that the server is successfully
|
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
|
fulfilling a range request for the target resource by transferring one or more
|
||||||
parts of the selected representation that correspond to the satisfiable ranges
|
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
|
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
|
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
|
If multiple parts are being transferred, the server generating the 206 response
|
||||||
MUST generate a "multipart/byteranges" payload, as defined in
|
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
|
multipart/byteranges media type and its required boundary parameter. To avoid
|
||||||
confusion with single-part responses, a server MUST NOT generate a Content-Range
|
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
|
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.
|
[200 (OK)](/200) response to the same request.
|
||||||
|
|
||||||
A 206 response is cacheable by default; i.e., unless otherwise indicated by
|
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>
|
[1]: <http://tools.ietf.org/html/rfc7233#section-4.1>
|
||||||
[2]: <http://tools.ietf.org/html/rfc7233#appendix-A>
|
[2]: <http://tools.ietf.org/html/rfc7233#section-3.1>
|
||||||
[3]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
|
[3]: <http://tools.ietf.org/html/rfc7233#appendix-A>
|
||||||
[4]: <http://tools.ietf.org/html/rfc7233#section-4.1>
|
[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
|
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,
|
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.
|
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
|
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'
|
2\. For PROPFIND and PROPPATCH, the format has been extended using the 'propstat'
|
||||||
element instead of 'status', providing information about individual properties
|
element instead of 'status', providing information about individual properties
|
||||||
of a resource. This format is specific to PROPFIND and PROPPATCH, and is
|
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>
|
[1]: <http://tools.ietf.org/html/rfc4918#section-13>
|
||||||
[2]: <http://tools.ietf.org/html/rfc2616#section-10>
|
[2]: <http://tools.ietf.org/html/rfc4918#section-9.6.2>
|
||||||
[3]: <http://tools.ietf.org/html/rfc4918#section-9.1>
|
[3]: <http://tools.ietf.org/html/rfc2616#section-10>
|
||||||
[4]: <http://tools.ietf.org/html/rfc4918#section-9.2>
|
[4]: <http://tools.ietf.org/html/rfc4918#section-9.1>
|
||||||
[5]: <http://tools.ietf.org/html/rfc4918#section-13>
|
[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
|
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
|
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
|
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
|
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
|
For backward compatibility with clients not aware of the 208 status code
|
||||||
appearing in multistatus response bodies, it SHOULD NOT be used unless the
|
appearing in multistatus response bodies, it SHOULD NOT be used unless the
|
||||||
client has signaled support for this specification using the "DAV" request
|
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
|
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
|
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
|
response, or in the middle of a multistatus, if it discovers it in the middle of
|
||||||
streaming out a multistatus response.
|
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>
|
[1]: <http://tools.ietf.org/html/rfc5842#section-7.1>
|
||||||
[2]: <http://tools.ietf.org/html/rfc5842#section-8.2>
|
[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
|
by combining this response with other previous or future responses, as
|
||||||
appropriate for the specific instance-manipulation(s). If so, the headers of the
|
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
|
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 HTTP/1.1 specification [10].
|
||||||
|
|
||||||
The request MUST have included an A-IM header field listing at least
|
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
|
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
|
cache and used in reply to a subsequent request, subject to the HTTP
|
||||||
expiration mechanism and any Cache-Control headers, and to the
|
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,
|
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
|
in conjunction with a cache entry for the base instance, to create a
|
||||||
cache entry for the current instance.
|
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>
|
[1]: <http://tools.ietf.org/html/rfc3229#section-10.4.1>
|
||||||
[2]: <http://tools.ietf.org/html/rfc3229#section-10.6>
|
[2]: <http://tools.ietf.org/html/rfc3229#section-13.5.3>
|
||||||
[3]: <http://tools.ietf.org/html/rfc3229#section-10.4.1>
|
[3]: <http://tools.ietf.org/html/rfc3229#section-10.6>
|
Loading…
Reference in New Issue
Block a user