Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

[翻译] rfc-7231#6.4.1

翻译:次碳酸钴
鼠标 hover 可见原文,如果发现错误请@我以便修正,谢谢捧场~

300 多重选择 rfc7231#section-6.4.1

300(多重选择)状态码表示目标资源有一种以上的表现形式,每种表现形式都具有特定的标识符。提供备选方案相关的信息以便用户(或用户代理)可以选择一个最优的表现形式,并重定向这个请求到一个或多个标识符。 换言之,服务器希望用户代理也加入它所需的最优表现形式选择协商当中(3.4 部分)。

如果服务器有一个最优选择,那它应该生成一个包含最优选择 URI 引用的 Location 头字段。 用户代理可以使用 Location 字段的值来自动重定向。

对于除 HEAD 之外的请求方法,服务器应该在 300 响应实体中生成一个包含各种表现形式元数据和 URI 引用, 以便于用户或用户代理能选出一个最优方案。 如果用户代理无法识别服务器提供的媒体类型,可以自动地从列表中做出一个选择。 自动选择的具体格式并没有这个这份规范中定义,因为 HTTP 试图与它的实体定义规范保持垂直。 在实践中,提供一种易于解析,相信用户代理可以接受的格式。例如通过共享设计或内容协商来定义,又或者使用一些可以普遍接受的超文本格式。 300 响应默认是可缓存的。也就是说,除非在方法定义或在缓存控制(见「RFC7234」的 4.2.2 部分)中指明,否则都是缓存的。

注意: 300 状态码的原始提案定义了 URI 头字段来提供被选表现形式的列表。它被定义为用于 HEAD 方法的 200、300 和 406 响应。 尽管如此,缺乏实现和有争议的以上语法导致 URI 和 Alternates(后来的提案)都被从这份规范中删除。 使用一个与 "alternate" 类似的 Link 头字段「RFC5988」集合可以表达这个列表,尽管部署上还是一个「鸡和蛋」的问题。

网名:
3.80.55.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^