HTTP 状态代码 300（多项选择）的确切响应结构是什么？
当用户点击我网站上的绘图链接时 http://mysite.com/some-drawing， 我希望我的服务器响应状态代码 300 和两个资源位置：http://mysite.com/some-drawing.png 和 http://mysite.com/some- Drawing.myapp，并让客户端浏览器根据其功能自动决定使用哪一个：
如果用户计算机上安装了 MyApp，则浏览器应下载
*.myapp< /code>版本并使用MyApp显示但是，如果 MyApp 未安装，并且浏览器无法显示此版本，那么我希望它选择
*.png版本。
但是，我很难弄清楚状态代码为 300 的 HTTP 响应的结构。
rfc2616 说：
所请求的资源对应于一组中的任意一个 每个代表都有自己的具体位置和代理人 提供驱动谈判信息（第 12 节），以便 用户（或用户代理）可以选择首选的表示形式并且 将其请求重定向到该位置。
除非它是一个 HEAD 请求，否则响应应该包含一个实体 包含资源特征和位置的列表 用户或用户代理可以选择最合适的一个。这 实体格式由内容中给出的媒体类型指定 类型标题字段。取决于格式和功能 用户代理，选择最合适的选择可能是 自动执行。然而，该规范没有定义 此类自动选择的任何标准。
如果服务器有首选的表示方式，它应该 在位置中包含该表示的特定 URI 场地;用户代理可以使用位置字段值进行自动 重定向。除非另有说明，否则此响应是可缓存的。
“包含资源特征和位置列表的实体”这一措辞似乎含糊不清。这是什么意思？有人知道这是怎么做到的吗？
When a user clicks a link to a drawing on my site http://mysite.com/some-drawing,
I would like my server to respond with status code 300 and two resource locations: http://mysite.com/some-drawing.png and http://mysite.com/some-drawing.myapp, and have the client browser decide automatically which one to use, based on its capabilities:
If MyApp is installed on the user's machine, then the browser should download the
*.myappversion and use MyApp to display it.However, if MyApp is not installed, and the browser is incapable to display this version, then I would like it to pick the
*.pngversion.
However, I am having a hard time figuring out the structure of a HTTP response with status code 300.
The rfc2616 says:
The requested resource corresponds to any one of a set of
representations, each with its own specific location, and agent-
driven negotiation information (section 12) is being provided so that
the user (or user agent) can select a preferred representation and
redirect its request to that location.Unless it was a HEAD request, the response SHOULD include an entity
containing a list of resource characteristics and location(s) from
which the user or user agent can choose the one most appropriate. The
entity format is specified by the media type given in the Content-
Type header field. Depending upon the format and the capabilities of
the user agent, selection of the most appropriate choice MAY be
performed automatically. However, this specification does not define
any standard for such automatic selection.If the server has a preferred choice of representation, it SHOULD
include the specific URI for that representation in the Location
field; user agents MAY use the Location field value for automatic
redirection. This response is cacheable unless indicated otherwise.
The wording "entity containing a list of resource characteristics and location(s)" seems ambiguous. What does it mean? Does anybody know how this is done?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
那是行不通的。
“多项选择”是通过发送超文本 (HTML) 内容中的链接并让用户选择来完成的。
That won't work.
The "multiple choices" are done by sending the links in hypertext (HTML) content and let the user pick.
理论上，如果客户端支持服务器驱动的协商，您可以发回各种“Accept-*”标头，但这些标头相当有限（例如，Languauge、Encoding、Charset），并且可用于“您想要 PDF”吗？或者 MS Word 文档？或“您想要西班牙语还是英语？”），但不是出于其他任意的区别。我不知道有任何浏览器支持它。相反，他们让浏览器发送 Accept 标头，然后服务器以它认为最好的方式进行响应。
请参阅：
更新：
另请参阅 Mozilla 开发者网络的“内容协商”，其中讨论了以下内容的一些优点和缺点服务器驱动与客户端驱动的协商，以及一些可能感兴趣的附加标头（例如，查看客户端是否发送“协商”以宣布其支持的内容）
In theory, if a client supported server-driven negotiation, you could send back various 'Accept-*' headers, but those are rather limited (eg, Languauge, Encoding, Charset), and could be used for 'do you want the PDF or MS Word document?' or 'Would you like that in Spanish or English?'), but not for other arbitrary distinctions. I'm not aware of any browsers that support it. Instead, they have the browser send the Accept headers, and the server respond with whatever it thinks is best.
See :
update :
Also see Mozilla Developer Network's "Content negotiation", which discusses some advantage and disadvantages of server-drive vs. client-driven negotiation, and some additional headers that may be of interest (eg, looking to see if the client sends 'Negotiate' to announce what it supports)