What is 300 Status Code Multiple Choices?
Table of Contents
We all know about the 301 “permanent redirect” and 302 “temporary redirect” HTTP response status codes, but have you heard of the 300 status code? Don’t worry if you haven’t – you are not alone. It’s not as common as other 3XX HTTP response status codes.
The 300 status code has unique characteristics that make it useful in some specific cases.
In this guide, we’ll explore the 300 status code, its applications, and the most common problems associated with it.
How does Status Code 300 Work?
Here is what a typical client-server interaction involving a 300 response code looks like:
- A client requests a resource – a client (browser, application) sends an HTTP request (GET, POST, etc.) to a web server for a specific resource.
- The web server processes the request – the web server receives the request and determines that the resource has multiple versions. These could be pages in different languages, formats (XML, JSON, etc.), or locations.
- The web server responds with the HTTP Response Code 300 “Multiple Choices” – the web server sends back the 300 response code to the client. This response contains a list of available options for the client to choose from.
The list may be presented in the request body or in the “Location” header.
- The client makes a choice and sends back a new request – the client must choose one of the presented options and send back another HTTP request informing the server of the choice.
Alternatively, the client application could be configured to make an automatic selection based on predefined criteria. - The web server processes the subsequent request – the web server processes the new request. It responds with the resource corresponding to the choice made by the client. If successful, the new response is 200 “OK.”
Depending on the website to which the HTTP request is sent, these choices are presented as URI, Alternates, or Link HTTP headers (the most used method).
If one of the choices is preferred, the web server should generate a Location HTTP header specifying the URI of the preferred resource version.
Unless the HTTP request method is HEAD, such as a POST or GET request, the 300 response code has a message body containing a list of the available choices.
Below is an example of such a response.
HTTP/1.1 300 Multiple Choices
Content-Type: text/html
<!DOCTYPE html>
<html>
<head>
<title>300 Multiple Choices</title>
</head>
<body>
<h1>Multiple Choices</h1>
<p>The requested resource has multiple representations. Please select one of the following options:</p>
<ul>
<li><a href="http://example.com/resource/en">English</a></li>
<li><a href="http://example.com/resource/fr">French</a></li>
<li><a href="http://example.com/resource/es">Spanish</a></li>
</ul>
</body>
</html>The 300 response code is cacheable. This means clients (browsers or user-agents) can save the response and load it from their storage for any future requests, increasing performance. The web server checks the Last-Modified date from the request header fields sent from a client that already cached the resource, and if it matches the latest resource version, returns a 304 “Not Modified” response code.
In general, the 300 status code is not widely used since there is no standardized way of presenting the choices.
Key Characteristics of 300 Multiple Choices
The 300 response code has several prominent characteristics that distinguish it from other HTTP status codes.
Multiple Options
The server presents several options for the client to choose from. How these options are presented depends on the server or website.
It could be a bulleted or numbered list in the body of the 300 response or a list in the “Location” header.
No Automatic Redirection
Unlike other 3xx codes, 300 does not automatically redirect the user to a specific location. Instead, the visitor must choose the desired resource location.
The web server will not deliver content until the client explicitly makes a choice. Whether it is a manual selection or an automatic one made by an application is entirely up to the client.
User Interaction Required
With the 300 HTTP response code, the origin server requires the user (user agent) to select one of the available choices.
The server cannot proceed until one of the options is selected.
When Is 300 Multiple Choices Used?
Although rarely used, the 300 status code possesses distinct features that make it useful in specific cases. Here are the most common ones.
Negotiating Multiple Formats
When a resource is available in multiple formats (e.g., different languages and media types), the origin server lets users choose their preferences by employing a 300 response code.
For example, you can list several optional formats (MPEG, MP4, etc) for the same video that clients can choose from.
Selecting Resource Versions
If a resource has multiple versions, such as API versions, the 300 status code indicates the available options to users.
For example, a server might offer a document in different languages or formats, such as HTML, PDF, or plain text. The client can then select the desired version based on user preferences or capabilities. This mechanism enables more flexible content delivery, ensuring the client receives the most appropriate resource without making multiple subsequent requests.
Alternative Resources
When a resource has multiple alternative locations or representations, the server can provide these choices to the client.
Let’s say you may want to display different content for different regions. Before they proceed on your website, you can prompt visitors to select their region from a menu with a 300 response code.
Tips for Managing a 300 Status Code
The 300 response code is not as popular as other redirect types, so users are not that familiar with it. Therefore, you should be extra careful and diligent when employing it to ensure that the 300 HTTP status code doesn’t confuse them.
Below, you’ll find some useful tips for handling a 300 response code “Multiple Choices.”
- Maintain Clear Documentation – Document the different choices available and the criteria for each. This will help both developers and users understand the options better when they encounter the 300 HTTP code.
- Keep Naming Consistency – Use a consistent naming convention for the different resource versions. This will help users be clear about what they are choosing.
- Client-Side Handling – Ensure client applications, such as browsers or mobile apps, can properly handle 300 responses.
- Regular Updates – Keep the list of available choices up to date. If a resource representation or version becomes obsolete, remove it from the options to avoid broken links.
- Provide Clear Instructions – Facilitate an intuitive and user-friendly interface for your website or web application. Include descriptive text and clear instructions for each choice.
This way, you’ll avoid frustrating your visitors, who will have a clear understanding of the choices presented. Furthermore, clear instructions will help search engines properly crawl your site. - Conduct Cross-Device/Browser Testing – Multi-device/platform compatibility is essential nowadays. Regularly test your website or application on different devices or browsers to ensure they can handle correctly the choices given in the 300 response code.
- Monitor Usage – Keep track of how often each option is selected. You can use this information to set a default resource location that meets your users’ preferences.
You can use various tools to monitor which pages generate more traffic. Many web hosting providers offer in-house traffic analysis tools that break down the traffic by page hits. SiteGround users can monitor their traffic from Site Tools > Statistics > Traffic.
If your web hosting doesn’t provide such instruments, you can opt for third-party monitoring services (like Google Analytics or Ahrefs) or plugins (for WordPress, Joomla, etc.).
Common Problems
Just like any other type of redirect, the 300 status code can misfire if not used correctly. It can cause a website to produce an invalid response displaying an error code or a blank page. Here are some of the causes for a problematic 300 response code.
Misconfigured Options
Incorrectly setting up the available choices presented by a 300 HTTP code can confuse users and lead to errors. Such misconfigurations could be:
- Broken links – Incomplete URLs won’t open the designated page and will confuse visitors, leading to a worsened user experience.
- Incorrect Content-Type – Content-Type is a representation header designed to inform clients of the media type of the requested resource. If the Content-Type header doesn’t match the actual type of a resource, the subsequent client request may not execute the target resource correctly.
- No fallback mechanism – The 300 response code does not include a default option or a fallback mechanism in case the user cannot make a choice or if the client does not support 300 response codes.
Inconsistent Naming of The Choices
Links that do not follow a consistent naming convention make the choices unclear. For example, a link may be named “resource/en” in one place and “resource/english” in another.
As a result, visitors are more likely to leave your website instead of following through with the choices.
Unclear User Guidance
Unclear descriptions or instructions can confuse clients about the given choices. Also, they can prevent search engines from properly crawling your website. Thus, user experience and the SEO score may suffer.
Browser Incompatibility
Some browsers may not handle 300 responses correctly, leading to broken functionality of the website or application they are communicating with. For example, such incompatibilities may arise when the request entity contains an Expect request header field, which specifies the response expected by the client.
If the status code 300 is not a requested response, the client may not be able to process it properly.
How to Fix Misconfigured 300 HTTP Code Issues?
Review The Server Configuration
Make sure that your web server correctly specifies the multiple choices presented in the 300 response code. Each option should be a valid URL pointing to a different version of the targeted resource.
Validate the 300 Response Code Headers
Review the HTTP response header fields, such as the Location header. It must contain the correct URLs for the available choices. Incorrect headers can lead to broken links and user frustration.
Inspect the Error Logs
Enable error logging in your website to inspect problems recorded while visitors access your website. These logs can help you pinpoint the origin of many client-side errors (like invalid request message framing, too many requests, etc.) or server-side errors (like insufficient server resources, access restrictions, etc.).
These logs can also help you identify issues related to the 300 response code. SiteGround users have easy-to-find & detailed error logs at their disposal in their website’s Site Tools > Statistics > Error Log.
Implement Fallback Mechanism
If clients cannot handle the 300 status code, implement a fallback mechanism that redirects to a default choice. This ensures that users can still access the resource even if they don’t make a selection.
Wrap Up
The status code 300 is a server response prompting clients to select from multiple options to proceed. This can be quite useful, especially when you have several versions of a resource (page, file formats) from which clients can choose.
However, it also has some limitations, making it unsuitable in some scenarios. If you decide to incorporate it into your website or application, you should consider its pros and cons. We hope that you’ll make an informed decision after reading this article.