,{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"Is 506 a client error or a server error?","acceptedAnswer":{"@type":"Answer","text":"It is a server error. The 5xx range indicates a problem with the server configuration or behavior. The client request was valid; the server content negotiation setup is misconfigured."}},{"@type":"Question","name":"Is RFC 2295 still valid?","acceptedAnswer":{"@type":"Answer","text":"RFC 2295 remains published as an Experimental RFC and has not been formally obsoleted. However, TCN was never advanced to standards track and is not part of the modern HTTP specification RFC 9110."}}]}

HTTP 506 Variant Also Negotiates

Quick reference

Code506
NameVariant Also Negotiates
Category5xx Server Error
SpecRFC 2295 §8.1
Cacheable?No
In practiceExtremely rare — TCN is not deployed

What 506 means

HTTP 506 Variant Also Negotiates is defined by RFC 2295, which specifies Transparent Content Negotiation (TCN). TCN is a protocol extension that allows servers to describe available variants of a resource (different languages, formats, encodings) and lets clients or intermediary agents algorithmically select the best variant before fetching it.

In the TCN model, a resource at /document can be a "negotiable resource" — it returns a list of variants. Each variant URL (e.g. /document.en.html, /document.fr.pdf) is supposed to be a terminal resource that delivers actual content, not another negotiable resource.

506 is returned when the server detects a configuration error: a URL that was supposed to be a terminal variant is itself configured as a negotiable resource, creating a circular or infinite negotiation loop. The server refuses to proceed rather than loop indefinitely.

TCN background

RFC 2295 was published in March 1998 as an Experimental RFC by Koen Holtman and Andrew Mutz. It proposed that HTTP servers include a TCN: choice or TCN: list header in responses, a Vary header identifying negotiation dimensions, and an Alternates header listing available variants with quality scores.

A client supporting TCN would send an Accept: header and receive either a direct variant (choice response) or a list of alternates to choose from (list response). Agents could cache the variant lists and make future requests directly to the best variant URL without negotiation overhead.

A correctly configured TCN server would look like this:

GET /document HTTP/1.1
Host: example.com
Accept-Language: fr
Accept: text/html

HTTP/1.1 200 OK
TCN: choice
Vary: negotiate, accept, accept-language
Alternates: {"document.en.html" 0.9 {type text/html} {language en}},
            {"document.fr.html" 1.0 {type text/html} {language fr}}
Content-Location: document.fr.html
Content-Type: text/html

The variant URL document.fr.html is supposed to respond with actual French HTML content. If instead document.fr.html is also configured with TCN negotiation headers (returning its own Alternates: list), the server has made a misconfiguration: a variant is also a negotiating resource. That is the exact condition RFC 2295 §8.1 says should return 506.

Why you will almost never see 506

TCN was never standardized beyond Experimental status and was never adopted by mainstream HTTP servers. nginx, Apache, IIS, and Caddy do not implement TCN. No major web framework generates TCN: or Alternates: headers by default. Browser content negotiation today uses Accept, Accept-Language, Accept-Encoding, and Accept-CH headers with standard 200 responses — not the TCN variant-list protocol.

The only practical ways to encounter 506 in the wild are custom middleware that intentionally implements TCN, legacy Apache modules compiled with experimental TCN support (the mod_negotiation module has some TCN-adjacent behavior), or a misconfigured content-delivery system that erroneously applies variant headers to variant URLs.

If you are seeing 506 responses in production, the cause is almost certainly a misconfigured custom proxy, CDN rule, or middleware layer that is adding negotiation headers to variant URLs. It is not a client-side error.

How to fix 506

The fix is always on the server side. There are three scenarios:

Apache mod_negotiation misconfiguration: Apache's MultiViews option enables server-driven negotiation. If a .var type map file lists a variant file that itself has a type-map handler, Apache may produce circular negotiation. Audit .htaccess and httpd.conf for AddHandler type-map directives applied to variant files:

# Bad — variant file is also mapped as a type-map
AddHandler type-map .var
# document.html.var should NOT appear in another .var file

Ensure variant files in type maps are plain content files (HTML, PDF, text) with no handler that would cause re-negotiation.

Custom TCN middleware: If you have implemented TCN in application code, ensure the middleware that adds TCN: and Alternates: headers is only applied to negotiable root resources, not to variant URLs. Add a guard that checks whether the request path is a known variant URL and skips header injection:

function tcnMiddleware(req, res, next) {
  if (isVariantUrl(req.path)) {
    return next(); // skip TCN headers for variant endpoints
  }
  res.setHeader('TCN', 'choice');
  // ... add Alternates header ...
  next();
}

CDN/proxy misconfiguration: If a CDN cache rule or Cloudflare Worker is adding negotiation headers to all responses indiscriminately, update the rule to only apply to the root negotiable resource URL, not to its variant children.

506 vs related codes

CodeMeaningConnection to 506
506Variant is itself negotiable (TCN loop)—
300 Multiple ChoicesServer offers multiple representationsStandard alternative to TCN
406 Not AcceptableNo acceptable variant existsNormal negotiation failure
500 Internal Server ErrorGeneric server errorWhat most servers return for misconfiguration

Frequently asked questions

Is 506 a client error or a server error?

It is a server error. The 5xx range indicates a problem with the server configuration or behavior. The client request was valid; the server's content negotiation setup is misconfigured.

Does any modern browser trigger 506?

No. Modern browsers do not send TCN negotiation requests (Negotiate: header). They use standard Accept headers, and servers respond with a direct resource selection via 200. A browser receiving a 506 would display it as a generic server error page.

Can I ignore 506 if I see it in logs?

You should not ignore it. Even if TCN is not intentionally deployed, a 506 indicates some layer (middleware, proxy, CDN rule) is emitting negotiation headers incorrectly. Find and correct that layer to prevent user-visible errors.

Is RFC 2295 still valid?

RFC 2295 remains published as an Experimental RFC and has not been formally obsoleted. However, TCN was never advanced to standards track and is not part of the modern HTTP specification (RFC 9110). The 506 status code is registered in the IANA HTTP Status Code Registry.

Related guides

HTTP 406 · HTTP 500 · HTTP 508 · HTTP 510 · HTTP 300

Server Errors Hub · All Guides · Home