mirror of
https://github.com/rmaake1/httpstatuses.git
synced 2024-10-06 08:07:21 +02:00
Improves 2xx class of status codes with references
This commit is contained in:
parent
035ca67ac3
commit
196d9c67ce
@ -3,38 +3,36 @@ set: 2
|
|||||||
code: 200
|
code: 200
|
||||||
title: OK
|
title: OK
|
||||||
references:
|
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
|
The request has succeeded.
|
||||||
sent in a 200 response depends on the request method.
|
|
||||||
|
|
||||||
For the methods defined by this specification, the intended meaning of the
|
The payload sent in a 200 response depends on the request method. For the
|
||||||
payload can be summarized as:
|
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
|
||||||
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;
|
||||||
POST a representation of the status of, or results obtained from, the action;
|
* `OPTIONS` a representation of the communications options;
|
||||||
|
* `TRACE` a representation of the request message as received by the end server.
|
||||||
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
|
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
|
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
|
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
|
CONNECT, no payload is allowed because the successful result is a tunnel, which
|
||||||
begins immediately after the 200 response header section.
|
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<sup>[1](#ref-1)</sup>.
|
||||||
(see [Section 4.2.2 of RFC7234][2]).
|
|
||||||
|
|
||||||
Source: [RFC7231 Section 6.3.1][1]
|
---
|
||||||
|
|
||||||
|
* <span id="ref-1"><sup>1</sup> Calculating Heuristic Freshness
|
||||||
|
[Section 4.2.2 of RFC7234][2]</span>
|
||||||
|
* Source: [RFC7231 Section 6.3.1][1]
|
||||||
|
|
||||||
[1]: <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>
|
[2]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
|
@ -6,19 +6,21 @@ references:
|
|||||||
"Rails HTTP Status Symbol": ":created"
|
"Rails HTTP Status Symbol": ":created"
|
||||||
---
|
---
|
||||||
|
|
||||||
The 201 Created status code indicates that the request has been fulfilled and
|
The request has been fulfilled and has resulted in one or more new resources
|
||||||
has resulted in one or more new resources being created.
|
being created.
|
||||||
|
|
||||||
The primary resource
|
The primary resource created by the request is identified by either a Location
|
||||||
created by the request is identified by either a Location header field in the
|
header field in the response or, if no Location field is received, by the
|
||||||
response or, if no Location field is received, by the effective request URI.
|
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][2] 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][1]
|
---
|
||||||
|
|
||||||
|
* Source: [RFC7231 Section 6.3.2][1]
|
||||||
|
|
||||||
[1]: <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
|
[2]: <http://tools.ietf.org/html/rfc7231#section-7.2
|
@ -6,13 +6,12 @@ references:
|
|||||||
"Rails HTTP Status Symbol": ":accepted"
|
"Rails HTTP Status Symbol": ":accepted"
|
||||||
---
|
---
|
||||||
|
|
||||||
The 202 Accepted status code indicates that the request has been accepted for
|
The request has been accepted for processing, but the processing has not been
|
||||||
processing, but the processing has not been completed. The request might or
|
completed. The request might or might not eventually be acted upon, as it might
|
||||||
might not eventually be acted upon, as it might be disallowed when processing
|
be disallowed when processing actually takes place.
|
||||||
actually takes place.
|
|
||||||
|
|
||||||
There is no facility in HTTP for re-sending a status code
|
There is no facility in HTTP for re-sending a status code from an asynchronous
|
||||||
from an asynchronous operation.
|
operation.
|
||||||
|
|
||||||
The 202 response is intentionally noncommittal. Its purpose is to allow a server
|
The 202 response is intentionally noncommittal. Its purpose is to allow a server
|
||||||
to accept a request for some other process (perhaps a batch-oriented process
|
to accept a request for some other process (perhaps a batch-oriented process
|
||||||
@ -22,6 +21,8 @@ representation sent with this response ought to describe the request's current
|
|||||||
status and point to (or embed) a status monitor that can provide the user with
|
status and point to (or embed) a status monitor that can provide the user with
|
||||||
an estimate of when the request will be fulfilled.
|
an estimate of when the request will be fulfilled.
|
||||||
|
|
||||||
Source: [RFC7231 Section 6.3.3][1]
|
---
|
||||||
|
|
||||||
|
* Source: [RFC7231 Section 6.3.3][1]
|
||||||
|
|
||||||
[1]: <http://tools.ietf.org/html/rfc7231#section-6.3.3>
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.3.3>
|
@ -6,25 +6,31 @@ references:
|
|||||||
"Rails HTTP Status Symbol": ":non_authoritative_information"
|
"Rails HTTP Status Symbol": ":non_authoritative_information"
|
||||||
---
|
---
|
||||||
|
|
||||||
The 203 Non-Authoritative Information status code indicates that the request
|
The request was successful but the enclosed payload has been modified from that
|
||||||
was successful but the enclosed payload has been modified from that of the
|
of the origin server's [200 OK](/200) response by a transforming
|
||||||
origin server's [200 (OK)](/200) response by a transforming proxy
|
proxy<sup>[1](#ref-1)</sup>.
|
||||||
([Section 5.7.2 of RFC7230][2]).
|
|
||||||
|
|
||||||
This status code allows the proxy to notify recipients when a transformation has
|
This status code allows the proxy to notify recipients when a transformation has
|
||||||
been applied, since that knowledge might impact later decisions regarding the
|
been applied, since that knowledge might impact later decisions regarding the
|
||||||
content. For example, future cache validation requests for the content might
|
content. For example, future cache validation requests for the content might
|
||||||
only be applicable along the same request path (through the same proxies).
|
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
|
The 203 response is similar to the Warning code of 214 Transformation
|
||||||
([Section 5.5 of RFC7234][3]), which has the advantage of being applicable to
|
Applied<sup>[2](#ref-2)</sup>, 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<sup>[2](#ref-3)</sup>.
|
||||||
(see [Section 4.2.2 of RFC7234][4]).
|
|
||||||
|
|
||||||
Source: [RFC7231 Section 6.3.4][1]
|
---
|
||||||
|
|
||||||
|
|
||||||
|
* <span id="ref-1"><sup>1</sup> Transformations
|
||||||
|
[Section 5.7.2 of RFC7230][2]</span>
|
||||||
|
* <span id="ref-2"><sup>2</sup> Warning [Section 5.5 of RFC7234][3]</span>
|
||||||
|
* <span id="ref-3"><sup>3</sup> Calculating Heuristic Freshness
|
||||||
|
[Section 4.2.2 of RFC7234][4]</span>
|
||||||
|
* Source: [RFC7231 Section 6.3.4][1]
|
||||||
|
|
||||||
[1]: <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>
|
[2]: <http://tools.ietf.org/html/rfc7230#section-5.7.2>
|
||||||
|
@ -6,9 +6,8 @@ references:
|
|||||||
"Rails HTTP Status Symbol": ":no_content"
|
"Rails HTTP Status Symbol": ":no_content"
|
||||||
---
|
---
|
||||||
|
|
||||||
The 204 No Content status code indicates that the server has successfully
|
The server has successfully fulfilled the request and that there is no
|
||||||
fulfilled the request and that there is no additional content to send in the
|
additional content to send in the response payload body.
|
||||||
response payload body.
|
|
||||||
|
|
||||||
Metadata in the response header fields refer to the target resource and its
|
Metadata in the response header fields refer to the target resource and its
|
||||||
selected representation after the requested action was applied.
|
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.
|
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<sup>[1](#ref-1)</sup>.
|
||||||
(see [Section 4.2.2 of RFC7234][2]).
|
|
||||||
|
|
||||||
Source: [RFC7231 Section 6.3.5][1]
|
---
|
||||||
|
|
||||||
[2]: <http://tools.ietf.org/html/rfc7231#section-6.3.5>
|
* <span id="ref-1"><sup>1</sup> Calculating Heuristic Freshness
|
||||||
[1]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
|
[Section 4.2.2 of RFC7234][2]</span>
|
||||||
|
* Source: [RFC7231 Section 6.3.5][1]
|
||||||
|
|
||||||
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.3.5>
|
||||||
|
[2]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
|
@ -6,10 +6,9 @@ references:
|
|||||||
"Rails HTTP Status Symbol": ":reset_content"
|
"Rails HTTP Status Symbol": ":reset_content"
|
||||||
---
|
---
|
||||||
|
|
||||||
The 205 Reset Content status code indicates that the server has fulfilled the
|
The server has fulfilled the request and desires that the user agent reset the
|
||||||
request and desires that the user agent reset the "document view", which caused
|
"document view", which caused the request to be sent, to its original state as
|
||||||
the request to be sent, to its original state as received from the origin
|
received from the origin server.
|
||||||
server.
|
|
||||||
|
|
||||||
This response is intended to support a common data entry use case where the user
|
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.),
|
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
|
consisting of a single chunk of zero-length; or, c) close the connection
|
||||||
immediately after sending the blank line terminating the header section.
|
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]: <http://tools.ietf.org/html/rfc7231#section-6.3.6>
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.3.6>
|
@ -2,12 +2,14 @@
|
|||||||
set: 2
|
set: 2
|
||||||
code: 206
|
code: 206
|
||||||
title: Partial Content
|
title: Partial Content
|
||||||
|
references:
|
||||||
|
"Rails HTTP Status Symbol": ":partial_content"
|
||||||
---
|
---
|
||||||
|
|
||||||
The 206 Partial Content status code indicates that the server is successfully
|
The server is successfully fulfilling a range request for the target resource by
|
||||||
fulfilling a range request for the target resource by transferring one or more
|
transferring one or more parts of the selected representation that correspond to
|
||||||
parts of the selected representation that correspond to the satisfiable ranges
|
the satisfiable ranges found in the request's Range header
|
||||||
found in the request's Range header field (see [RFC7233 Section 3.1][2]).
|
field<sup>[1](#ref-1)</sup>.
|
||||||
|
|
||||||
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
|
||||||
@ -26,17 +28,16 @@ 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<sup>[2](#ref-2)</sup>, and a
|
||||||
[RFC7233 Appendix A][3], and a Content-Type header field containing the
|
Content-Type header field containing the multipart/byteranges media type and its
|
||||||
multipart/byteranges media type and its required boundary parameter. To avoid
|
required boundary parameter. To avoid confusion with single-part responses, a
|
||||||
confusion with single-part responses, a server MUST NOT generate a Content-Range
|
server MUST NOT generate a Content-Range header field in the HTTP header section
|
||||||
header field in the HTTP header section of a multiple part response (this field
|
of a multiple part response (this field will be sent in each part instead).
|
||||||
will be sent in each part instead).
|
|
||||||
|
|
||||||
Within the header area of each body part in the multipart payload, the server
|
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
|
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
|
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.
|
generate that same Content-Type field in the header area of each body part.
|
||||||
For example:
|
For example:
|
||||||
|
|
||||||
@ -88,7 +89,7 @@ order that it requested.
|
|||||||
|
|
||||||
When a 206 response is generated, the server MUST generate the following header
|
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
|
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.
|
Expires, Content-Location, and Vary.
|
||||||
|
|
||||||
If a 206 is generated in response to a request with an If-Range header field,
|
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
|
required above, because the client is understood to already have a prior
|
||||||
response containing those header fields. Otherwise, the sender MUST generate all
|
response containing those header fields. Otherwise, the sender MUST generate all
|
||||||
of the representation header fields that would have been sent in a
|
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][4]).
|
explicit cache controls<sup>[3](#ref-3)</sup>.
|
||||||
|
|
||||||
Source: [RFC7233 Section 4.1][1]
|
---
|
||||||
|
|
||||||
|
* <span id="ref-1"><sup>1</sup> Range [RFC7233 Section 3.1][2]</span>
|
||||||
|
* <span id="ref-2"><sup>2</sup> Internet Media Type multipart/byteranges
|
||||||
|
[RFC7233 Appendix A][3]</span>
|
||||||
|
* <span id="ref-3"><sup>3</sup> Calculating Heuristic Freshness
|
||||||
|
[Section 4.2.2 of RFC7234][4]</span>
|
||||||
|
* Source: [RFC7233 Section 4.1][1]
|
||||||
|
|
||||||
[1]: <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>
|
[2]: <http://tools.ietf.org/html/rfc7233#section-3.1>
|
||||||
|
@ -27,8 +27,8 @@ A Multi-Status response uses one out of two distinct formats for representing
|
|||||||
the status:
|
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
|
||||||
see [RFC4918 Section 9.6.2][2]). Some method definitions provide information
|
whole<sup>[1](#ref-1)</sup>. 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][3].
|
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
|
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].
|
described in detail in [RFC4918 Sections 9.1][4] and [RFC4918 9.2][5].
|
||||||
|
|
||||||
Source: [RFC4918 Section 13][1]
|
---
|
||||||
|
|
||||||
|
* <span id="ref-1"><sup>1</sup> Example - DELETE [RFC4918 Section 9.6.2][2]</span>
|
||||||
|
* Source: [RFC4918 Section 13][1]
|
||||||
|
|
||||||
[1]: <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>
|
[2]: <http://tools.ietf.org/html/rfc4918#section-9.6.2>
|
||||||
|
@ -4,9 +4,8 @@ code: 208
|
|||||||
title: Already Reported
|
title: Already Reported
|
||||||
---
|
---
|
||||||
|
|
||||||
The 208 Already Reported status code can be used inside a DAV: propstat
|
Used inside a DAV: propstat response element to avoid enumerating the internal
|
||||||
response element to avoid enumerating the internal members of multiple bindings
|
members of multiple bindings to the same collection repeatedly.
|
||||||
to the same collection repeatedly.
|
|
||||||
|
|
||||||
For each binding to a collection inside the request's scope, only one will be
|
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
|
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
|
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][2].
|
a bind loop as discussed in [RFC5842][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
|
||||||
@ -24,13 +23,17 @@ 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 [RFC5842Section 8.2][3]). Instead, a 508 status should be
|
header<sup>[1](#ref-1)</sup>. Instead, a [508 Loop Detected](/508) status should
|
||||||
returned when a binding loop is discovered. This allows the server to return the
|
be returned when a binding loop is discovered. This allows the server to return
|
||||||
508 as the top-level return status, if it discovers it before it started the
|
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][1]
|
---
|
||||||
|
|
||||||
|
* <span id="ref-1"><sup>1</sup> 'DAV' Request Header
|
||||||
|
[RFC5842Section 8.2][3]</span>
|
||||||
|
* Source: [RFC5842 Section 7.1][1]
|
||||||
|
|
||||||
[1]: <http://tools.ietf.org/html/rfc5842#section-7.1>
|
[1]: <http://tools.ietf.org/html/rfc5842#section-7.1>
|
||||||
[2]: <http://tools.ietf.org/html/rfc5842#section-2.2>
|
[2]: <http://tools.ietf.org/html/rfc5842#section-2.2>
|
||||||
|
@ -13,9 +13,9 @@ the current instance.
|
|||||||
The actual current instance might not be available except by combining this
|
The actual current instance might not be available except by combining this
|
||||||
response with other previous or future responses, as appropriate for the
|
response with other previous or future responses, as appropriate for the
|
||||||
specific instance-manipulation(s). If so, the headers of the resulting instance
|
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
|
are the result of combining the headers from the 226 response and the other
|
||||||
other instances, following the rules in [section 13.5.3][2] of the
|
instances, following the rules in [section 13.5.3][2] of the
|
||||||
HTTP/1.1 specification [10].
|
HTTP/1.1 specification.
|
||||||
|
|
||||||
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
|
||||||
one instance-manipulation. The response MUST include an Etag header
|
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
|
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][1]
|
---
|
||||||
|
|
||||||
|
* Source: [RFC3229 Section 10.4.1][1]
|
||||||
|
|
||||||
[1]: <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>
|
[2]: <http://tools.ietf.org/html/rfc2616#section-13.5.3>
|
||||||
[3]: <http://tools.ietf.org/html/rfc3229#section-10.6>
|
[3]: <http://tools.ietf.org/html/rfc3229#section-10.6>
|
Loading…
Reference in New Issue
Block a user