mirror of
https://github.com/rmaake1/httpstatuses.git
synced 2024-11-02 00:32:36 +01:00
56 lines
2.7 KiB
Markdown
56 lines
2.7 KiB
Markdown
---
|
|
set: 3
|
|
code: 300
|
|
title: Multiple Choices
|
|
references:
|
|
"Rails HTTP Status Symbol": ":multiple_choices"
|
|
---
|
|
|
|
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<sup>[1](#ref-1)</sup>.
|
|
|
|
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<sup>[2](#ref-2)</sup>.
|
|
|
|
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<sup>[3](#ref-3)</sup>, each with a relationship of "alternate",
|
|
though deployment is a chicken-and-egg problem.
|
|
|
|
---
|
|
|
|
* <span id="ref-1"><sup>1</sup> Content Negotiation
|
|
[RFC7231 Section 3.4][2]</span>
|
|
* <span id="ref-2"><sup>2</sup> Calculating Heuristic Freshness
|
|
[RFC7234 Section 4.2.2][3]</span>
|
|
* <span id="ref-3"><sup>3</sup> Web Linking [RFC5988][4]</span>
|
|
* Source: [RFC7231 Section 6.4.1][1]
|
|
|
|
[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> |