mirror of
https://github.com/rmaake1/httpstatuses.git
synced 2024-10-04 15:17:23 +02:00
Adds 2xx Success class codes using latest descriptions from standards
This commit is contained in:
Samuel Ryan
parent
ebc0fb8a8a
commit
5c9aa2e2e8
@ -2,6 +2,37 @@
|
||||
set: 2
|
||||
code: 200
|
||||
title: OK
|
||||
references:
|
||||
"Rails HTTP Status Symbol": ":not_found"
|
||||
---
|
||||
|
||||
This is the contents of the 200 status code
|
||||
The 200 (OK) status code indicates that the request has succeeded. 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.
|
||||
|
||||
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
|
||||
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][1]).
|
||||
|
||||
Source: [RFC7231 Section 6.3.1][2]
|
||||
|
||||
[1]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
|
||||
[2]: <http://tools.ietf.org/html/rfc7231#section-6.3.1>
|
||||
@ -2,6 +2,21 @@
|
||||
set: 2
|
||||
code: 201
|
||||
title: Created
|
||||
references:
|
||||
"Rails HTTP Status Symbol": ":created"
|
||||
---
|
||||
|
||||
This is the contents of the 201 status code
|
||||
The 201 (Created) status code indicates that 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 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
|
||||
purpose of validator header fields, such as ETag and Last-Modified, in a 201
|
||||
response.
|
||||
|
||||
Source: [RFC7231 Section 6.3.2][2]
|
||||
|
||||
[1]: <http://tools.ietf.org/html/rfc7231#section-7.2>
|
||||
[2]: <http://tools.ietf.org/html/rfc7231#section-6.3.2>
|
||||
@ -2,6 +2,24 @@
|
||||
set: 2
|
||||
code: 202
|
||||
title: Accepted
|
||||
references:
|
||||
"Rails HTTP Status Symbol": ":accepted:
|
||||
---
|
||||
|
||||
This is the contents of the 202 status code
|
||||
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. 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
|
||||
that is only run once per day) without requiring that the user agent's
|
||||
connection to the server persist until the process is completed. The
|
||||
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]
|
||||
|
||||
[1]: <http://tools.ietf.org/html/rfc7231#section-6.3.3>
|
||||
@ -1,7 +1,31 @@
|
||||
---
|
||||
set: 2
|
||||
code: 203
|
||||
title: Non-authorative Information
|
||||
title: Non-authoritative Information
|
||||
references:
|
||||
"Rails HTTP Status Symbol": ":non_authoritative_information"
|
||||
---
|
||||
|
||||
This is the contents of the 203 status code
|
||||
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
|
||||
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
|
||||
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]).
|
||||
|
||||
Source: [RFC7231 Section 6.3.4][4]
|
||||
|
||||
[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>
|
||||
@ -2,6 +2,42 @@
|
||||
set: 2
|
||||
code: 204
|
||||
title: No Content
|
||||
references:
|
||||
"Rails HTTP Status Symbol": ":no_content"
|
||||
---
|
||||
|
||||
This is the contents of the 204s status code
|
||||
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. Metadata in the response header fields refer to the
|
||||
target resource and its selected representation after the requested action was
|
||||
applied.
|
||||
|
||||
For example, if a 204 status code is received in response to a PUT request and
|
||||
the response contains an ETag header field, then the PUT was successful and the
|
||||
ETag field-value contains the entity-tag for the new representation of that
|
||||
target resource.
|
||||
|
||||
The 204 response allows a server to indicate that the action has been
|
||||
successfully applied to the target resource, while implying that the user agent
|
||||
does not need to traverse away from its current "document view" (if any). The
|
||||
server assumes that the user agent will provide some indication of the success
|
||||
to its user, in accord with its own interface, and apply any new or updated
|
||||
metadata in the response to its active representation.
|
||||
|
||||
For example, a 204 status code is commonly used with document editing interfaces
|
||||
corresponding to a "save" action, such that the document being saved remains
|
||||
available to the user for editing. It is also frequently used with interfaces
|
||||
that expect automated data transfers to be prevalent, such as within distributed
|
||||
version control systems.
|
||||
|
||||
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][1]).
|
||||
|
||||
Source: [RFC7231 Section 6.3.5][2]
|
||||
|
||||
[1]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
|
||||
[2]: <http://tools.ietf.org/html/rfc7231#section-6.3.5>
|
||||
@ -2,6 +2,30 @@
|
||||
set: 2
|
||||
code: 205
|
||||
title: Reset Content
|
||||
references:
|
||||
"Rails HTTP Status Symbol": ":reset_content"
|
||||
---
|
||||
|
||||
This is the contents of the 205 status code
|
||||
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.
|
||||
|
||||
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.),
|
||||
enters or manipulates data in that space, causes the entered data to be
|
||||
submitted in a request, and then the data entry mechanism is reset for the next
|
||||
entry so that the user can easily initiate another input action.
|
||||
|
||||
Since the 205 status code implies that no additional content will be provided, a
|
||||
server MUST NOT generate a payload in a 205 response. In other words, a server
|
||||
MUST do one of the following for a 205 response: a) indicate a zero-length body
|
||||
for the response by including a Content-Length header field with a value of 0;
|
||||
b) indicate a zero-length payload for the response by including a
|
||||
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]
|
||||
|
||||
[1]: <http://tools.ietf.org/html/rfc7231#section-6.3.6>
|
||||
@ -4,4 +4,106 @@ code: 206
|
||||
title: Partial Content
|
||||
---
|
||||
|
||||
This is the contents of the 206 status code
|
||||
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]).
|
||||
|
||||
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
|
||||
selected representation is enclosed, and a payload consisting of the range. For
|
||||
example:
|
||||
|
||||
```
|
||||
HTTP/1.1 206 Partial Content
|
||||
Date: Wed, 15 Nov 1995 06:25:24 GMT
|
||||
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
|
||||
Content-Range: bytes 21010-47021/47022
|
||||
Content-Length: 26012
|
||||
Content-Type: image/gif
|
||||
|
||||
... 26012 bytes of partial image data ...
|
||||
```
|
||||
|
||||
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
|
||||
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
|
||||
generate that same Content-Type field in the header area of each body part.
|
||||
For example:
|
||||
|
||||
```
|
||||
HTTP/1.1 206 Partial Content
|
||||
Date: Wed, 15 Nov 1995 06:25:24 GMT
|
||||
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
|
||||
Content-Length: 1741
|
||||
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
|
||||
|
||||
--THIS_STRING_SEPARATES
|
||||
Content-Type: application/pdf
|
||||
Content-Range: bytes 500-999/8000
|
||||
|
||||
...the first range...
|
||||
--THIS_STRING_SEPARATES
|
||||
Content-Type: application/pdf
|
||||
Content-Range: bytes 7000-7999/8000
|
||||
|
||||
...the second range
|
||||
--THIS_STRING_SEPARATES--
|
||||
```
|
||||
|
||||
When multiple ranges are requested, a server MAY coalesce any of the ranges that
|
||||
overlap, or that are separated by a gap that is smaller than the overhead of
|
||||
sending multiple parts, regardless of the order in which the corresponding
|
||||
byte-range-spec appeared in the received Range header field. Since the typical
|
||||
overhead between parts of a multipart/byteranges payload is around 80 bytes,
|
||||
depending on the selected representation's media type and the chosen boundary
|
||||
parameter length, it can be less efficient to transfer many small disjoint parts
|
||||
than it is to transfer the entire selected representation.
|
||||
|
||||
A server MUST NOT generate a multipart response to a request for a single range,
|
||||
since a client that does not request multiple parts might not support multipart
|
||||
responses. However, a server MAY generate a multipart/byteranges payload with
|
||||
only a single body part if multiple ranges were requested and only one range was
|
||||
found to be satisfiable or only one range remained after coalescing. A client
|
||||
that cannot process a multipart/byteranges response MUST NOT generate a request
|
||||
that asks for multiple ranges.
|
||||
|
||||
When a multipart response payload is generated, the server SHOULD send the parts
|
||||
in the same order that the corresponding byte-range-spec appeared in the
|
||||
received Range header field, excluding those ranges that were deemed
|
||||
unsatisfiable or that were coalesced into other ranges. A client that receives a
|
||||
multipart response MUST inspect the Content-Range header field present in each
|
||||
body part in order to determine which range is contained in that body part; a
|
||||
client cannot rely on receiving the same ranges that it requested, nor the same
|
||||
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,
|
||||
Expires, Content-Location, and Vary.
|
||||
|
||||
If a 206 is generated in response to a request with an If-Range header field,
|
||||
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.
|
||||
|
||||
A 206 response is cacheable by default; i.e., unless otherwise indicated by
|
||||
explicit cache controls (see [Section 4.2.2 of RFC7234][3]).
|
||||
|
||||
Source: [RFC7233 Section 4.1][4]
|
||||
|
||||
[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>
|
||||
@ -2,6 +2,45 @@
|
||||
set: 2
|
||||
code: 207
|
||||
title: Multi-Status
|
||||
references:
|
||||
"Rails HTTP Status Symbol": ":multi_status"
|
||||
---
|
||||
|
||||
This is the contents of the 207 status code
|
||||
A Multi-Status response conveys information about multiple resources in
|
||||
situations where multiple status codes might be appropriate. The default
|
||||
Multi-Status response body is a text/xml or application/xml HTTP entity with a
|
||||
'multistatus' root element. Further elements contain 200, 300, 400, and 500
|
||||
series status codes generated during the method invocation. 100 series status
|
||||
codes SHOULD NOT be recorded in a 'response' XML element.
|
||||
|
||||
Although '207' is used as the overall response status code, the recipient needs
|
||||
to consult the contents of the multistatus response body for further information
|
||||
about the success or failure of the method execution. The response MAY be used
|
||||
in success, partial success and also in failure situations.
|
||||
|
||||
The 'multistatus' root element holds zero or more 'response' elements in any
|
||||
order, each with information about an individual resource. Each 'response'
|
||||
element MUST have an 'href' element to identify the resource.
|
||||
|
||||
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][1]). 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].
|
||||
|
||||
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].
|
||||
|
||||
Source: [RFC4918 Section 13][5]
|
||||
|
||||
[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>
|
||||
|
||||
@ -4,4 +4,31 @@ code: 208
|
||||
title: Already Reported
|
||||
---
|
||||
|
||||
This is the contents of the 208 status code
|
||||
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. 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 bindings will use the 208 status, and no
|
||||
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 client can request the DAV:resource-id property in a PROPFIND request to
|
||||
guarantee that they can accurately reconstruct the binding structure of a
|
||||
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
|
||||
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)
|
||||
|
||||
[1]: <http://tools.ietf.org/html/rfc5842#section-2.2>
|
||||
[2]: <http://tools.ietf.org/html/rfc5842#section-8.2>
|
||||
|
||||
@ -2,6 +2,34 @@
|
||||
set: 2
|
||||
code: 226
|
||||
title: IM Used
|
||||
references:
|
||||
"Rails HTTP Status Symbol": ":im_used"
|
||||
---
|
||||
|
||||
This is the contents of the 226 status code
|
||||
The server has fulfilled a GET request for the resource, and the response is a
|
||||
representation of the result of one or more instance-manipulations applied to
|
||||
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
|
||||
the HTTP/1.1 specification [10].
|
||||
|
||||
The request MUST have included an A-IM header field listing at least
|
||||
one instance-manipulation. The response MUST include an Etag header
|
||||
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].
|
||||
|
||||
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]
|
||||
|
||||
[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>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user