httpstatuses/contents/codes/300.md

50 lines
2.5 KiB
Markdown
Raw Normal View History

2015-11-06 21:39:33 +01:00
---
set: 3
code: 300
title: Multiple Choices
references:
"Rails HTTP Status Symbol": ":multiple_choices"
2015-11-06 21:39:33 +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
representation(s) for its needs ([RFC7231 Section 3.4][2]).
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][3]).
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][4]], each with a relationship of "alternate", though deployment is a
chicken-and-egg problem.
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>