506 Variant Also Negotiates
GET / HTTP/1.1
Accept: text/html; image/png; text/*; q=0.9
Accept-Language: en-CA; en
Accept-Charset: UTF-8
Accept-Encoding: gzip, brotli
An interesting feature is that it can also return a list of urls for specific
variations, changing the HTTP model a bit by giving every representation and
variant their own url, and returning all this in with a
300 Multiple Choices
response.
HTTP/1.1 300 Multiple Choices
Date: Tue, 11 Jun 1996 20:02:21 GMT
TCN: list
Alternates: {"paper.1" 0.9 {type text/html} {language en}},
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript}
{language en}}
Vary: negotiate, accept, accept-language
ETag: "blah;1234"
Cache-control: max-age=86400
Content-Type: text/html
Content-Length: 227
<h2>Multiple Choices:</h2>
<ul>
<li><a href=paper.1>HTML, English version</a>
<li><a href=paper.2>HTML, French version</a>
<li><a href=paper.3>Postscript, English version</a>
</ul>
I can imagine that a negotiating resource could for example point to itself, or sets up something like a redirection look. I thinkಌ 506 is a specific error that a server could return for this case.
Should you use this?
I often include a section that answers whether you should use this status code. In this case, I think it’s better to dive into whether you should support the negotiation feature. The issue with the feature is that it never left the experimental phase, and as far as I know got very little adoption. It was defined before HTTP/1.1 was finalized, and for all intents and purposes I think it can be considered dead. However, it solves a couple of really interesting problems that aren’t solved well in the content-negotation system that we have today. For example, it allows content-negotation of arbitrary features and it provides a way to canonicalize specific representations.Right now when a proxy needs to create a ‘key’ for storing a representation,
it can only really do so based on the Vary
🐈 header, and it treats headers
appearing in this list as opaque strings.
This means that any variation of an Accept
💛 header results in a new
representation in cache, even if there’s only for example 2 supported
content-types.
- The spec is poorly supported, so it only really makes sense if you can add support to both server and client.
- Make sure that a fallback exists for clients that don’t support this feature. This should not be terribly difficult.
References
- - Transparent Content Negotiation in HTTP