300 Multiple Choices
The request has more than one possible representation and the server is asking the client to pick one.
Status
HTTP/1.1 300 Multiple Choices
Details
- Category: 3xx
- Status: Standard. Registered with IANA and defined by a current standards-track RFC.
- Specification: RFC 9110 §15.4.1
- Cacheable: Cacheable by default
- Response body: Allowed
- Retry: Retry only after changing the request
300 exists for agent-driven content negotiation. Instead of choosing a variant itself, the server lists the alternatives (different languages, formats, or encodings) and lets the client or the user decide. The list normally arrives as links in the body, and the server may still hint at a preferred option with a Location header.
It is almost never used. Server-driven negotiation with Accept headers and the Vary response header handles the same job without an extra round trip, so most sites simply serve their best guess with 200.
Headers
- Location: Optional. Names the server's preferred variant when one exists.
- Vary: Tells caches which request headers select among variants.
Common causes
- A resource is published in several formats or languages and the server declined to choose.
- A transparent content negotiation implementation following RFC 2295.
Usage notes
For clients
- Parse the list of alternatives and request the one you want.
- Send precise Accept, Accept-Language, and Accept-Encoding headers so the server can pick for you next time.
For servers
- Prefer server-driven negotiation with a correct Vary header. It is faster and every client understands it.
- If you do send 300, make the alternatives machine readable rather than a page of prose.
Examples
A document published in several languages
HTTP request
GET /manual HTTP/1.1 Host: docs.example.com
HTTP response
HTTP/1.1 300 Multiple Choices Content-Type: text/html; charset=utf-8 Location: /manual.en.html <ul> <li><a href="/manual.en.html">English</a></li> <li><a href="/manual.de.html">Deutsch</a></li> </ul>