506 - Variant Also Negotiates
HTTP 506 Variant Also Negotiates means transparent content negotiation is misconfigured and selected variants are themselves negotiable.
Last reviewed: February 12, 2026|Editorial standard: source-backed technical guidance
What Does Variant Also Negotiates Mean?
Content negotiation configuration is internally inconsistent, causing variant selection to recurse into another negotiable variant instead of a final representation.
Common Causes
- -Negotiated variant points to another negotiable variant.
- -Variant metadata contains circular references.
- -Negotiation rules were deployed with invalid mappings.
How to Fix Variant Also Negotiates
- 1Inspect variant mapping and ensure each negotiable resource resolves to a concrete non-negotiable representation.
- 2Remove circular or self-referential variant definitions from negotiation metadata.
- 3Retest negotiation with explicit `Accept` variants to verify deterministic representation selection.
Step-by-Step Diagnosis for Variant Also Negotiates
- 1Capture negotiation trace showing how selected variant points back to negotiable resource.
- 2Inspect `Alternates`/variant metadata for recursive or cyclic resolution paths.
- 3Verify deployment changes to variant maps and transparent negotiation modules.
- 4Retest with targeted variant requests and confirm chosen representation is terminal.
Variant Graph Integrity Analysis
- -Build variant dependency graph and detect cycles (example: `index.en` maps to `index` which negotiates back to `index.en`).
- -Verify each variant target is a concrete representation (example: variant entry points to negotiable script endpoint instead of static resource).
Negotiation Rule and Deployment Drift Checks
- -Compare current rule set against last known-good release (example: recent config change introduced recursive fallback chain).
- -Audit edge/origin negotiation engine parity (example: CDN variant map differs from origin map, causing only edge 506 responses).
Implementation Examples
curl -i -X GET https://api.example.com/v1/resource
# Response:
# HTTP/1.1 506 Variant Also Negotiates
# {"error":"Variant Also Negotiates","code":"506"}const response = await fetch('https://api.example.com/v1/resource', {
method: 'GET',
headers: { 'Accept': 'application/json' }
});
if (response.status === 506) {
console.error('Handle 506 Variant Also Negotiates');
}import requests
response = requests.get(
'https://api.example.com/v1/resource',
headers={'Accept': 'application/json'}
)
if response.status_code == 506:
print('Handle 506 Variant Also Negotiates')How to Verify the Fix
- -Repeat requests across supported `Accept` variants and confirm 506 no longer appears.
- -Validate each negotiable resource resolves to a single concrete representation path.
- -Monitor negotiation error metrics for recurrence after configuration rollout.
How to Prevent Recurrence
- -Add static validation that rejects recursive variant references in build/deploy pipelines.
- -Version and test negotiation maps with representative language/media combinations.
- -Roll out negotiation config changes with canary validation before full deployment.
Pro Tip
- -treat variant mappings as a directed acyclic graph and run cycle detection in CI to prevent 506 regressions entirely.
Decision Support
Compare Guide
429 Too Many Requests vs 503 Service Unavailable
Use 429 for caller-specific throttling and 503 for service-wide outages, so retry behavior, escalation paths, and incident ownership stay correct.
Compare Guide
500 Internal Server Error vs 502 Bad Gateway: Root Cause
Debug 500 vs 502 faster: use 500 for origin failures and 502 for invalid upstream responses at gateways, then route incidents to the right team.
Playbook
API Timeout Playbook (502 / 504 / DEADLINE_EXCEEDED)
Use this playbook to separate invalid upstream responses from upstream wait expiration and deadline exhaustion, and apply timeout budgets, safe retries, and circuit-breaker controls safely.
Playbook
Availability and Dependency Playbook (500 / 503 / ServiceUnavailable)
Use this playbook to separate origin-side 500 failures from temporary 503 dependency or capacity outages, then apply safe retry and escalation paths.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.