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

【问题标题】：What is the exact response structure for HTTP status code 300 (Multiple Choices)?HTTP 状态码 300（多选）的确切响应结构是什么？
【发布时间】：2012-01-18 05:18:11
【问题描述】：

当用户在我的网站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 请求，否则响应应该包含一个实体包含资源特征和位置列表用户或用户代理可以选择最合适的一个。这实体格式由 Content- 中给出的媒体类型指定类型标题字段。取决于格式和能力用户代理，选择最合适的选择可能是自动执行。但是，本规范没有定义这种自动选择的任何标准。

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

“包含资源特征和位置列表的实体”措辞似乎含糊不清。这是什么意思？有人知道这是怎么做到的吗？

【问题讨论】：

标签： http http-headers http-status-codes

【解决方案1】：

那行不通。

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

【讨论】：

rfc 说：“根据用户代理的格式和功能，可以自动选择最合适的选择”。您是说所有主流浏览器都通过提示用户手动选择来将所有状态 300 响应视为相同？
是的。您知道允许用户代理为您选择的格式吗？
例如：“multipart/alternative”metia 类型实体。这至少是电子邮件客户端用来确定呈现给用户的最佳选择的原因。
“multipart/alternative”媒体类型未指定替代的类型。每个备选方案都有自己的 mime 类型。例如，此 mime 类型可以是“application/http”，并包括诸如“HTTP/1.1 307 Moved\n\rLocation: //mysite.com/some-drawing.myapp”之类的 http 实体。但是，对于这样的事情，这似乎过于繁琐，而且我不确定在这种情况下浏览器会如何选择。但这只是一种选择；可能还有其他人。
好的，在找不到主流浏览器如何处理状态码300的信息后，我已经下载了webkit源代码并自己搜索了答案。似乎 webkit 像其他重定向状态代码一样处理状态 300：根据 Location 标头进行重定向，或者如果此标头丢失，则向用户显示错误。所以，@Julian-Reschke 似乎是对的：我的解决方案不起作用。 :-(

【解决方案2】：

理论上，如果客户端支持服务器驱动的协商，您可以发回各种“Accept-*”标头，但这些标头相当有限（例如，Languauge、Encoding、Charset），并且可以用于“do you想要 PDF 或 MS Word 文档？或“你想要西班牙语还是英语？”），但不是为了其他任意区别。我不知道有任何浏览器支持它。相反，他们让浏览器发送 Accept 标头，然后服务器以它认为最好的任何内容进行响应。

见：

RFC 2295, "Transparent Content Negotiation in HTTP"
RFC 2616, "HTTP/1.1" section 12 "Content Negotiation"（针对与服务器驱动的内容协商相关的问题）

更新：

另请参阅Mozilla Developer Network's "Content negotiation"，其中讨论了服务器驱动与客户端驱动协商的一些优点和缺点，以及一些可能感兴趣的附加标头（例如，查看客户端是否发送“协商”来宣布它支持什么）

【讨论】：