Mirrors/httpstatuses
1
0
Fork 0
mirror of https://github.com/rmaake1/httpstatuses.git synced 2024-07-05 11:36:37 +02:00
Code Issues Packages Projects Releases Wiki Activity

Improves 2xx class of status codes with references

Browse Source
This commit is contained in:
Samuel Ryan 2015-11-09 00:28:54 +00:00
parent 035ca67ac3
commit 196d9c67ce
10 changed files with 116 additions and 90 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
contents/codes/200.md
View File

@ -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
* `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.
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
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][2]).
A 200 response is cacheable by default; i.e., unless otherwise indicated by the
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>

14
contents/codes/201.md
View File

@ -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

15
contents/codes/202.md
View File

@ -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>

24
contents/codes/203.md
View File

@ -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>

18
contents/codes/204.md
View File

@ -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>

11
contents/codes/205.md
View File

@ -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>

38
contents/codes/206.md
View File

@ -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>

9
contents/codes/207.md
View File

@ -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>

19
contents/codes/208.md
View File

@ -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>

12
contents/codes/226.md
View File

@ -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>