300 - Multiple Choices
HTTP 300 Multiple Choices means the target has more than one representation and the client should choose one.
Last reviewed: February 26, 2026|Editorial standard: source-backed technical guidance
What Does Multiple Choices Mean?
Negotiation is ambiguous for this URI, so the client must choose among multiple valid representations before processing can continue.
Common Causes
- -Origin has multiple active language representations and no deterministic default for broad Accept-Language header.
- -Caching layer stores html and json variants under same key, so selector returns multiple valid targets.
- -Short link maps to several enabled destinations after campaign split and no primary destination is configured.
How to Fix Multiple Choices
- 1Inspect negotiated variants and identify the canonical representation expected by each client type.
- 2Send explicit Accept, language, and encoding preferences that match server-supported variants.
- 3Configure a deterministic default representation when negotiation inputs are missing or ambiguous.
Step-by-Step Diagnosis for Multiple Choices
- 1Capture negotiation inputs and all representation options returned with 300 response.
- 2Verify whether a default canonical representation policy exists for clients lacking explicit preferences.
- 3Inspect edge/origin negotiation rules for inconsistent variant selection logic.
- 4Retest with explicit client preferences to confirm deterministic selection behavior.
Representation Set and Canonical Policy Audit
- -List available variants and identify missing canonical default (example: JSON and HTML both valid, but no default for API clients).
- -Check canonical URL strategy (example: migrated content keeps multiple equally weighted endpoints).
Negotiation Input Consistency Across Hops
- -Compare Accept-language/encoding handling at CDN and origin (example: CDN strips
Accept-Languagecausing ambiguous fallback). - -Validate client defaults by runtime (example: browser and CLI send different Accept headers and trigger different 300 behavior).
Implementation Examples
curl -i -X GET https://api.example.com/v1/resource
# Response:
# HTTP/1.1 300 Multiple Choices
# {"error":"Multiple Choices","code":"300"}const response = await fetch('https://api.example.com/v1/resource', {
method: 'GET',
headers: { 'Accept': 'application/json' }
});
if (response.status === 300) {
console.error('Handle 300 Multiple Choices');
}import requests
response = requests.get(
'https://api.example.com/v1/resource',
headers={'Accept': 'application/json'}
)
if response.status_code == 300:
print('Handle 300 Multiple Choices')How to Verify the Fix
- -Request the same URI and confirm clients receive one intended representation without repeated 300 responses.
- -Validate canonical links, content negotiation behavior, and crawler access across representation variants.
- -Check logs for reduced negotiation ambiguity and stable variant resolution after configuration rollout.
How to Prevent Recurrence
- -Document supported representations and default negotiation behavior in your API or content contract.
- -Add integration tests for media, language, and encoding negotiation matrices before deployment.
- -Keep CDN and origin negotiation rules version-controlled with automated diff and rollback checks.
Pro Tip
- -document explicit canonical representation priorities so crawlers and SDKs converge on one stable variant automatically.
Decision Support
Compare Guide
403 Forbidden vs 404 Not Found: When to Hide Resources
Use 403 for explicit access denial, or 404 to conceal resource existence when security policy requires reducing endpoint and object enumeration risk.
Compare Guide
404 Not Found vs 410 Gone: Missing vs Permanent Removal
Learn when to return 404 (missing or temporary absence) versus 410 (intentional permanent removal), including redirect and cache implications.
Playbook
Resource State Playbook (404 / 410 / ResourceNotFound)
Use this playbook to separate temporary missing-resource lookups from permanent removals, then fix scope, lifecycle, and identifier drift safely.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.