mirror of
https://github.com/rmaake1/httpstatuses.git
synced 2024-10-04 15:17:23 +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
|
||||
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
|
||||
|
||||
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.
|
||||
* `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.
|
||||
|
||||
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
|
||||
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]).
|
||||
method definition or explicit cache controls<sup>[1](#ref-1)</sup>.
|
||||
|
||||
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>
|
||||
[2]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
|
@ -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]: <http://tools.ietf.org/html/rfc7231#section-6.3.2>
|
||||
[2]: <http://tools.ietf.org/html/rfc7231#section-7.2
|
@ -6,13 +6,12 @@ references:
|
||||
"Rails HTTP Status Symbol": ":accepted"
|
||||
---
|
||||
|
||||
The 202 Accepted status code indicates that the request has been accepted for
|
||||
processing, but the processing has not been completed. The request might or
|
||||
might not eventually be acted upon, as it might be disallowed when processing
|
||||
actually takes place.
|
||||
The request has been accepted for processing, but the processing has not been
|
||||
completed. The request might or might not eventually be acted upon, as it might
|
||||
be disallowed when processing actually takes place.
|
||||
|
||||
There is no facility in HTTP for re-sending a status code
|
||||
from an asynchronous operation.
|
||||
There is no facility in HTTP for re-sending a status code from an asynchronous
|
||||
operation.
|
||||
|
||||
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
|
||||
@ -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
|
||||
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>
|
@ -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<sup>[1](#ref-1)</sup>.
|
||||
|
||||
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<sup>[2](#ref-2)</sup>, 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<sup>[2](#ref-3)</sup>.
|
||||
|
||||
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>
|
||||
[2]: <http://tools.ietf.org/html/rfc7230#section-5.7.2>
|
||||
|
@ -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<sup>[1](#ref-1)</sup>.
|
||||
|
||||
Source: [RFC7231 Section 6.3.5][1]
|
||||
---
|
||||
|
||||
[2]: <http://tools.ietf.org/html/rfc7231#section-6.3.5>
|
||||
[1]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
|
||||
* <span id="ref-1"><sup>1</sup> Calculating Heuristic Freshness
|
||||
[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"
|
||||
---
|
||||
|
||||
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]: <http://tools.ietf.org/html/rfc7231#section-6.3.6>
|
@ -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<sup>[1](#ref-1)</sup>.
|
||||
|
||||
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<sup>[2](#ref-2)</sup>, 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<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>
|
||||
[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:
|
||||
|
||||
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<sup>[1](#ref-1)</sup>. 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]
|
||||
---
|
||||
|
||||
* <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>
|
||||
[2]: <http://tools.ietf.org/html/rfc4918#section-9.6.2>
|
||||
|
@ -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<sup>[1](#ref-1)</sup>. 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]
|
||||
---
|
||||
|
||||
* <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>
|
||||
[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
|
||||
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]: <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>
|
Loading…
Reference in New Issue
Block a user