mirror of
https://github.com/rmaake1/httpstatuses.git
synced 2024-10-04 15:17:23 +02:00
Adds 3xx Redirection class status code descriptions from the latest standards
This commit is contained in:
Samuel Ryan
parent
5c9aa2e2e8
commit
ed94ac1966
@ -2,6 +2,49 @@
|
||||
set: 3
|
||||
code: 300
|
||||
title: Multiple Choices
|
||||
references:
|
||||
"Rails HTTP Status Symbol": ":multiple_choices"
|
||||
---
|
||||
|
||||
This is the contents of the 300 status code
|
||||
|
||||
The 300 (Multiple Choices) status code indicates that the target resource has
|
||||
more than one representation, each with its own more specific identifier, and
|
||||
information about the alternatives is being provided so that the user (or user
|
||||
agent) can select a preferred representation by redirecting its request to one
|
||||
or more of those identifiers. In other words, the server desires that the user
|
||||
agent engage in reactive negotiation to select the most appropriate
|
||||
representation(s) for its needs ([RFC7231 Section 3.4][1]).
|
||||
|
||||
If the server has a preferred choice, the server SHOULD generate a Location
|
||||
header field containing a preferred choice's URI reference. The user agent MAY
|
||||
use the Location field value for automatic redirection.
|
||||
|
||||
For request methods other than HEAD, the server SHOULD generate a payload in the
|
||||
300 response containing a list of representation metadata and URI reference(s)
|
||||
from which the user or user agent can choose the one most preferred. The user
|
||||
agent MAY make a selection from that list automatically if it understands the
|
||||
provided media type. A specific format for automatic selection is not defined by
|
||||
this specification because HTTP tries to remain orthogonal to the definition of
|
||||
its payloads. In practice, the representation is provided in some easily parsed
|
||||
format believed to be acceptable to the user agent, as determined by shared
|
||||
design or content negotiation, or in some commonly accepted hypertext format.
|
||||
|
||||
A 300 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]).
|
||||
|
||||
Note: The original proposal for the 300 status code defined the URI header field
|
||||
as providing a list of alternative representations, such that it would be usable
|
||||
for 200, 300, and 406 responses and be transferred in responses to the HEAD
|
||||
method. However, lack of deployment and disagreement over syntax led to both URI
|
||||
and Alternates (a subsequent proposal) being dropped from this specification. It
|
||||
is possible to communicate the list using a set of Link header fields
|
||||
[[RFC5988][3]], each with a relationship of "alternate", though deployment is a
|
||||
chicken-and-egg problem.
|
||||
|
||||
Source: [RFC7231 Section 6.4.1][4]
|
||||
|
||||
[1]: <http://tools.ietf.org/html/rfc7231#section-3.4>
|
||||
[2]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
|
||||
[3]: <http://tools.ietf.org/html/rfc5988>
|
||||
[4]: <http://tools.ietf.org/html/rfc7231#section-6.4.1>
|
||||
@ -2,7 +2,30 @@
|
||||
set: 3
|
||||
code: 301
|
||||
title: Moved Permanently
|
||||
summary: this and all future requests directed to the given URI
|
||||
references:
|
||||
"Rails HTTP Status Symbol": ":moved_permanently"
|
||||
---
|
||||
|
||||
This is the contents of the 301 status code
|
||||
The 301 (Moved Permanently) status code indicates that the target resource has
|
||||
been assigned a new permanent URI and any future references to this resource
|
||||
ought to use one of the enclosed URIs. Clients with link-editing capabilities
|
||||
ought to automatically re-link references to the effective request URI to one or
|
||||
more of the new references sent by the server, where possible.
|
||||
|
||||
The server SHOULD generate a Location header field in the response containing a
|
||||
preferred URI reference for the new permanent URI. The user agent MAY use the
|
||||
Location field value for automatic redirection. The server's response payload
|
||||
usually contains a short hypertext note with a hyperlink to the new URI(s).
|
||||
|
||||
Note: For historical reasons, a user agent MAY change the request method from
|
||||
POST to GET for the subsequent request. If this behavior is undesired, the
|
||||
[307 (Temporary Redirect)](/307) status code can be used instead.
|
||||
|
||||
A 301 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.4.2][2]
|
||||
|
||||
[1]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
|
||||
[2]: <http://tools.ietf.org/html/rfc7231#section-6.4.2>
|
||||
@ -2,6 +2,24 @@
|
||||
set: 3
|
||||
code: 302
|
||||
title: Found
|
||||
references:
|
||||
"Rails HTTP Status Symbol": ":found"
|
||||
---
|
||||
|
||||
This is the contents of the 300 status code
|
||||
The 302 (Found) status code indicates that the target resource resides
|
||||
temporarily under a different URI. Since the redirection might be altered on
|
||||
occasion, the client ought to continue to use the effective request URI for
|
||||
future requests.
|
||||
|
||||
The server SHOULD generate a Location header field in the response containing a
|
||||
URI reference for the different URI. The user agent MAY use the Location field
|
||||
value for automatic redirection. The server's response payload usually contains
|
||||
a short hypertext note with a hyperlink to the different URI(s).
|
||||
|
||||
Note: For historical reasons, a user agent MAY change the request method from
|
||||
POST to GET for the subsequent request. If this behavior is undesired, the
|
||||
[307 (Temporary Redirect)](/307) status code can be used instead.
|
||||
|
||||
Source: [RFC7231 Section 6.4.3][1]
|
||||
|
||||
[1]: <http://tools.ietf.org/html/rfc7231#section-6.4.3>
|
||||
@ -2,6 +2,38 @@
|
||||
set: 3
|
||||
code: 303
|
||||
title: See Other
|
||||
references:
|
||||
"Rails HTTP Status Symbol": ":see_other"
|
||||
---
|
||||
|
||||
This is the contents of the 201 status code
|
||||
The 303 (See Other) status code indicates that the server is redirecting the
|
||||
user agent to a different resource, as indicated by a URI in the Location header
|
||||
field, which is intended to provide an indirect response to the original
|
||||
request. A user agent can perform a retrieval request targeting that URI (a GET
|
||||
or HEAD request if using HTTP), which might also be redirected, and present the
|
||||
eventual result as an answer to the original request. Note that the new URI in
|
||||
the Location header field is not considered equivalent to the effective request
|
||||
URI.
|
||||
|
||||
This status code is applicable to any HTTP method. It is primarily used to allow
|
||||
the output of a POST action to redirect the user agent to a selected resource,
|
||||
since doing so provides the information corresponding to the POST response in a
|
||||
form that can be separately identified, bookmarked, and cached, independent of
|
||||
the original request.
|
||||
|
||||
A 303 response to a GET request indicates that the origin server does not have a
|
||||
representation of the target resource that can be transferred by the server over
|
||||
HTTP. However, the Location field value refers to a resource that is descriptive
|
||||
of the target resource, such that making a retrieval request on that other
|
||||
resource might result in a representation that is useful to recipients without
|
||||
implying that it represents the original target resource. Note that answers to
|
||||
the questions of what can be represented, what representations are adequate, and
|
||||
what might be a useful description are outside the scope of HTTP.
|
||||
|
||||
Except for responses to a HEAD request, the representation of a 303 response
|
||||
ought to contain a short hypertext note with a hyperlink to the same URI
|
||||
reference provided in the Location header field.
|
||||
|
||||
Source: [RFC7321 Section 6.4.4][1]
|
||||
|
||||
[1]: <http://tools.ietf.org/html/rfc7231#section-6.4.4>
|
||||
@ -2,6 +2,39 @@
|
||||
set: 3
|
||||
code: 304
|
||||
title: Not Modified
|
||||
references:
|
||||
"Rails HTTP Status Symbol": ":not_modified"
|
||||
---
|
||||
|
||||
This is the contents of the 304 status code
|
||||
The 304 (Not Modified) status code indicates that a conditional GET or HEAD
|
||||
request has been received and would have resulted in a [200 (OK)](/200) response
|
||||
if it were not for the fact that the condition evaluated to false. In other
|
||||
words, there is no need for the server to transfer a representation of the
|
||||
target resource because the request indicates that the client, which made the
|
||||
request conditional, already has a valid representation; the server is therefore
|
||||
redirecting the client to make use of that stored representation as if it were
|
||||
the payload of a [200 (OK)](/200) response.
|
||||
|
||||
The server generating a 304 response MUST generate any of the following header
|
||||
fields that would have been sent in a [200 (OK)](/200) response to the same
|
||||
request: Cache-Control, Content-Location, Date, ETag, Expires, and Vary.
|
||||
|
||||
Since the goal of a 304 response is to minimize information transfer when the
|
||||
recipient already has one or more cached representations, a sender SHOULD NOT
|
||||
generate representation metadata other than the above listed fields unless said
|
||||
metadata exists for the purpose of guiding cache updates (e.g., Last-Modified
|
||||
might be useful if the response does not have an ETag field).
|
||||
|
||||
Requirements on a cache that receives a 304 response are defined in
|
||||
[Section 4.3.4 of RFC7234][2]. If the conditional request originated with an
|
||||
outbound client, such as a user agent with its own cache sending a conditional
|
||||
GET to a shared proxy, then the proxy SHOULD forward the 304 response to that
|
||||
client.
|
||||
|
||||
A 304 response cannot contain a message-body; it is always terminated by the
|
||||
first empty line after the header fields.
|
||||
|
||||
Source: [RFC7232 Section 4.1][1]
|
||||
|
||||
[1]: <http://tools.ietf.org/html/rfc7232#section-4.1>
|
||||
[2]: <http://tools.ietf.org/html/rfc7234#section-4.3.4>
|
||||
@ -2,6 +2,15 @@
|
||||
set: 3
|
||||
code: 305
|
||||
title: Use Proxy
|
||||
#references:
|
||||
# "Rails HTTP Status Symbol": "use_proxy"
|
||||
# - Due to deprecation we won't show this... but should we?
|
||||
---
|
||||
|
||||
This is the contents of the 305 status code
|
||||
The 305 (Use Proxy) status code was defined in a previous version of this
|
||||
specification and is now deprecated, due to security concerns regarding in-band
|
||||
configuration of a proxy.
|
||||
|
||||
Source: [RFC7231 Section 6.4.5][1]
|
||||
|
||||
[1]: <http://tools.ietf.org/html/rfc7231#section-6.4.5>
|
||||
@ -2,6 +2,27 @@
|
||||
set: 3
|
||||
code: 307
|
||||
title: Temporary Redirect
|
||||
references:
|
||||
"Rails HTTP Status Symbol": ":temporary_redirect"
|
||||
---
|
||||
|
||||
This is the contents of the 307 status code
|
||||
The 307 (Temporary Redirect) status code indicates that the target resource
|
||||
resides temporarily under a different URI and the user agent MUST NOT change the
|
||||
request method if it performs an automatic redirection to that URI. Since the
|
||||
redirection can change over time, the client ought to continue using the
|
||||
original effective request URI for future requests.
|
||||
|
||||
The server SHOULD generate a Location header field in the response containing a
|
||||
URI reference for the different URI. The user agent MAY use the Location field
|
||||
value for automatic redirection. The server's response payload usually contains
|
||||
a short hypertext note with a hyperlink to the different URI(s).
|
||||
|
||||
Note: This status code is similar to 302 (Found), except that it does not allow
|
||||
changing the request method from POST to GET. This specification defines no
|
||||
equivalent counterpart for [301 (Moved Permanently)](/301) ([RFC7238][2], however,
|
||||
defines the status code [308 (Permanent Redirect)](/308) for this purpose).
|
||||
|
||||
Source: [RFC7231 Section 6.4.7][1]
|
||||
|
||||
[1]: <http://tools.ietf.org/html/rfc7231#section-6.4.7>
|
||||
[2]: <http://tools.ietf.org/html/rfc7238>
|
||||
@ -4,4 +4,30 @@ code: 308
|
||||
title: Permanent Redirect
|
||||
---
|
||||
|
||||
This is the contents of the 308 status code
|
||||
The 308 (Permanent Redirect) status code indicates that the target resource has
|
||||
been assigned a new permanent URI and any future references to this resource
|
||||
ought to use one of the enclosed URIs. Clients with link editing capabilities
|
||||
ought to automatically re-link references to the effective request URI
|
||||
([Section 5.5 of RFC7230][2]) to one or more of the new references sent by the
|
||||
server, where possible.
|
||||
|
||||
The server SHOULD generate a Location header field
|
||||
([[RFC7231], Section 7.1.2][3]) in the response containing a preferred URI
|
||||
reference for the new permanent URI. The user agent MAY use the Location field
|
||||
value for automatic redirection. The server's response payload usually contains
|
||||
a short hypertext note with a hyperlink to the new URI(s).
|
||||
|
||||
A 308 response is cacheable by default; i.e., unless otherwise indicated by the
|
||||
method definition or explicit cache controls ([see RFC7234, Section 4.2.2][4]).
|
||||
|
||||
Note: This status code is similar to 301 (Moved Permanently)
|
||||
([RFC7231, Section 6.4.2][5]), except that it does not allow changing the
|
||||
request method from POST to GET.
|
||||
|
||||
Source: [RFC738 Section 3][1]
|
||||
|
||||
[1]: <http://tools.ietf.org/html/rfc7538#section-3>
|
||||
[2]: <http://tools.ietf.org/html/rfc7230#section-5.5>
|
||||
[3]: <http://tools.ietf.org/html/rfc7231#section-7.1.2>
|
||||
[4]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
|
||||
[5]: <http://tools.ietf.org/html/rfc7231#section-6.4.2>
|
||||
Loading…
Reference in New Issue
Block a user