Prompt and scope
A client requests a resource using transparent content negotiation and receives HTTP 506 Variant Also Negotiates. The system has Apache-style negotiation, reverse proxies, and caches. Explain the semantics, loop trigger, diagnosis, cache behavior, and fallback.
What the interviewer evaluates
- Knowing that 506 comes from RFC 2295 transparent content negotiation.
- Distinguishing a negotiation loop from 406 Not Acceptable and proxy 502.
- Inspecting Alternates, Variant-Vary, TCN, and related metadata.
- Defining retry, caching, and downgrade boundaries.
- Adding cycle detection, observability, and release gates.
Clarifications to ask first
Confirm Accept and Accept-Language, whether the resource is a variant list, which layer emits 506, whether a proxy cache is involved, and whether a fixed representation is acceptable. Assume a variant points back to the negotiating resource.
Thirty-second answer framework
506 means transparent negotiation formed a loop and the server cannot select a final representation. Trace the response chain and negotiation metadata to prove a cycle instead of treating it as a generic upstream failure. The client should not blindly retry the same configuration; it can request a fixed representation or disable negotiation. Bound negotiation depth, repair variants, and monitor 506 against 406.
Step-by-step deep dive
1. Explain transparent negotiation
RFC 2295 lets an origin publish variants, while clients and intermediaries select a representation from request headers. The request must eventually converge on a concrete resource.
2. Identify the loop
If a variant points to another resource that also requires transparent negotiation, selection can return to the original object. Record resource URI, variant URI, negotiation proxy, request id, and a visited set; revisiting a node proves a cycle.
3. Separate nearby status codes
406 means no representation satisfies the client conditions. 502 means a gateway received an invalid upstream response. A 506 investigation must follow the negotiation graph, not just the final edge status.
4. Design client fallback
Retrying with the same headers and configuration cannot remove the cycle. Request a fixed variant, omit transparent negotiation, or surface a repair message. Retry only within a budget after a configuration change or explicit transient signal.
5. Handle cache keys and Vary
Cache keys must include the Vary dimensions used in negotiation; a 506 must not become a long-lived answer for every representation. Follow Cache-Control for error caching and account for old proxy entries after repair.
6. Repair and secure the server
Build a variant graph before release and run cycle detection with depth and time limits. Return a correlation id rather than internal URI topology. Proxies preserve original status, Via, and trace data so rewrites do not hide the cause.
7. Validate and observe
Test self-cycles, two-node cycles, deep acyclic lists, different Accept and language headers, proxy caches, rollout, and rollback. Monitor 506/406, negotiation time, fallback, cache hits, and repair duration.
High-quality sample answer
506 is RFC 2295’s transparent-negotiation loop error. When a variant points back to a negotiating resource, the server cannot produce a final representation. I would record URI, variant, proxy, and request id, use a visited set to prove the cycle, and preserve original status and trace at every hop.
The same conditions should fail fast rather than retry. The client may request a fixed variant. Before release, the server builds the variant graph, checks cycles, bounds depth and time, and validates Vary and cache keys. Acceptance covers header and language changes, proxy caches, rollout, rollback, and the distinction from 406.
Common mistakes
- Treating 506 as 406 or 502.
- Inspecting only the proxy’s final status instead of the variant graph.
- Retrying the same negotiation configuration forever.
- Omitting Vary dimensions from cache keys.
- Shipping without cycle detection and depth limits.
- Returning internal variant URIs in errors.
Follow-up questions and responses
Follow-up 1: What is the key difference between 506 and 406?
406 has no acceptable representation. 506 means the negotiation process itself cycles and cannot converge.
Follow-up 2: May a client retry 506?
Not with unchanged configuration. Retry only after repair or an explicit transient signal, within a budget.
Follow-up 3: How do you prove a proxy changed the status?
Compare per-hop trace, Via, original status, and negotiation headers; reproduce directly against the origin when needed.
Follow-up 4: Should the error be cached?
Follow Cache-Control and avoid amplifying the loop; purge affected stale entries after repair.