2015-11-06 21:39:33 +01:00
|
|
|
---
|
|
|
|
set: 3
|
|
|
|
code: 300
|
|
|
|
title: Multiple Choices
|
2015-11-07 03:57:14 +01:00
|
|
|
references:
|
|
|
|
"Rails HTTP Status Symbol": ":multiple_choices"
|
2015-11-06 21:39:33 +01:00
|
|
|
---
|
|
|
|
|
2015-11-07 03:57:14 +01:00
|
|
|
|
|
|
|
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
|
2015-11-07 04:04:37 +01:00
|
|
|
representation(s) for its needs ([RFC7231 Section 3.4][2]).
|
2015-11-07 03:57:14 +01:00
|
|
|
|
|
|
|
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
|
2015-11-07 04:04:37 +01:00
|
|
|
[Section 4.2.2 of RFC7234][3]).
|
2015-11-07 03:57:14 +01:00
|
|
|
|
|
|
|
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
|
2015-11-07 04:04:37 +01:00
|
|
|
[[RFC5988][4]], each with a relationship of "alternate", though deployment is a
|
2015-11-07 03:57:14 +01:00
|
|
|
chicken-and-egg problem.
|
|
|
|
|
2015-11-07 04:04:37 +01:00
|
|
|
Source: [RFC7231 Section 6.4.1][1]
|
2015-11-07 03:57:14 +01:00
|
|
|
|
2015-11-07 04:04:37 +01:00
|
|
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.4.1>
|
|
|
|
[2]: <http://tools.ietf.org/html/rfc7231#section-3.4>
|
|
|
|
[3]: <http://tools.ietf.org/html/rfc7234#section-4.2.2>
|
|
|
|
[4]: <http://tools.ietf.org/html/rfc5988>
|