HTTP状态代码300（多选）的确切响应结构是什么？

当用户单击指向我的网站上的图形的链接时

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响应的结构

报告说：

请求的资源对应于一组资源中的任意一个 表示，每个表示都有自己的特定位置和代理- 提供受驱动的谈判信息（第12节），以便 用户（或用户代理）可以选择首选表示形式，并 将其请求重定向到该位置

除非是HEAD请求，否则响应应包括实体 包含来自的资源特征和位置的列表 哪个用户或用户代理可以选择最合适的。这个 实体格式由内容中给定的媒体类型指定- 键入标题字段。取决于 对于用户代理，可以选择最合适的选项 自动执行。但是，本规范没有定义 任何此类自动选择的标准

如果服务器有首选的表示方式，则应该 在位置中包含该表示的特定URI 领域用户代理可以使用位置字段值进行自动 重定向。除非另有说明，否则此响应是可缓存的

“包含资源特征和位置列表的实体”一词似乎模棱两可。这是什么意思？有人知道这是怎么做的吗？

那不行

---

“多选”是通过发送超文本（HTML）内容中的链接并让用户选择来完成的。

理论上，如果客户机支持服务器驱动的协商，您可以发回各种“Accept-*”标题，但这些标题相当有限（例如，语言、编码、字符集），并且可以用于“您想要PDF或MS Word文档吗？”或“您想要西班牙语或英语版本的文档吗？”），但不能用于其他任意区分。我不知道有任何浏览器支持它。取而代之的是，他们让浏览器发送Accept头，服务器以它认为最好的方式响应

见：

• （针对与服务器驱动的内容协商相关的问题）

更新：

---

另请参阅，其中讨论了服务器驱动与客户机驱动协商的一些优缺点，以及一些可能感兴趣的附加标题（例如，查看客户机是否发送“协商”来宣布其支持的内容）

rfc说：“根据用户代理的格式和功能，可以自动选择最合适的选项“。你是说所有主要浏览器都会通过提示用户手动选择来处理所有status 300响应吗？是的。您知道允许用户代理为您选择的格式吗？例如：“多部分/备选”metia类型实体。这至少是电子邮件客户端用来确定呈现给用户的最佳选择的内容。“多部分/备选”媒体类型没有指定备选媒体的类型。每个备选方案都有自己的mime类型。此mime类型可以是例如“application/http”，并包括http实体，例如“http/1.1 307 Moved\n\rLocation://mysite.com/some drawing.myapp”。然而，对于这样的东西来说，这似乎太麻烦了，而且我不确定在这种情况下浏览器会如何选择。但这只是一种选择；可能还有其他的。好吧，在找不到关于主要浏览器如何处理状态代码300的信息后，我下载了webkit源代码，自己搜索答案。webkit似乎像处理其他重定向状态代码一样处理状态300：根据位置标头重定向，或者如果缺少此标头，则向用户显示错误。所以，看来@Julian Reschke毕竟是对的：我的解决方案行不通-(