当用户点击我网站http://mysite.com/some-drawing上的绘图链接时，
我希望我的服务器响应状态代码300和两个资源位置：http://mysite.com/some-drawing.png和http://mysite.com/some-drawing.myapp，并让客户端浏览器根据其功能自动决定使用哪一个：
如果MyApp安装在用户的计算机上，则浏览器应下载*.myapp版本并使用MyApp进行显示。
但是，如果未安装MyApp，并且浏览器无法显示此版本，那么我希望它选择*.png版本。
但是，我很难弄清楚状态码为300的HTTP响应的结构。
rfc2616说：
请求的资源对应于一组中的任何一个 表示，每个都有自己的特定位置，代理人 - 正在提供驱动的谈判信息（第12节） 用户（或用户代理）可以选择首选表示和 将其请求重定向到该位置。
除非是HEAD请求，否则响应应该包含一个实体 包含资源特征和位置的列表 用户或用户代理可以选择最合适的一个。该 实体格式由内容中给出的媒体类型指定 - 输入标题字段。取决于格式和功能 用户代理，选择最合适的选择可能 自动执行。但是，此规范没有定义 这种自动选择的任何标准。
如果服务器有首选的表示形式，它应该是 在Location中包含该表示的特定URI 领域;用户代理可以使用Location字段值进行自动 重定向。除非另有说明，否则此响应是可缓存的。
措辞“包含资源特征和位置列表的实体”似乎含糊不清。这是什么意思？有人知道这是怎么做的吗？
答案 0 :(得分：4)
那不行。
“多项选择”是通过发送超文本（HTML）内容中的链接并让用户选择来完成的。
答案 1 :(得分：3)
理论上，如果客户端支持服务器驱动的协商，您可以发回各种“Accept- *”标题，但这些标题相当有限（例如，Languauge，Encoding，Charset），并且可以用于'你做想要PDF或MS Word文档？'或者“你想用西班牙语或英语吗？”，但不能用于其他任意区别。我不知道任何支持它的浏览器。相反，他们让浏览器发送Accept标头，服务器以其认为最好的方式响应。
见：
更新：
另请参阅Mozilla Developer Network's "Content negotiation"，其中讨论了服务器驱动与客户端驱动协商的一些优缺点，以及一些可能感兴趣的其他标头（例如，查看客户端是否发送'协商'宣布它支持的内容）