【发布时间】：2010-10-19 12:24:51
【问题描述】：
标题的顺序是否有意义
A: 1
B: 2
对
B:2
A:1
我正在尝试确定是否可以使用字典来存储标题列表，或者它是否需要某种列表或有序字典。
【问题讨论】：
-
“请求”标头的顺序可用于浏览器/机器人的指纹识别。
标签： http-headers
【发布时间】：2010-10-19 12:24:51
【问题描述】：
HTTP 标头相互独立，您可以使用字典来存储它们而不必担心它们的顺序。
【讨论】：
-
同一标题多次出现时不正确。
不，不同名称的标题无关紧要。请参阅RFC 2616，第 4.2 节：
不同字段名的头部字段的顺序 收到的影响不大。但是，发送是“好习惯” 首先是general-header字段，然后是request-header或response- 头字段，并以实体头字段结尾。
但是，对于具有相同名称的多个标头来说，这很重要：
具有相同字段名的多个消息头字段可以是 当且仅当该消息的整个字段值出现在消息中 标头字段被定义为一个逗号分隔的列表 [即，#(values)]。 必须可以将多个标头字段合并为一个 “field-name: field-value”对，不改变语义 消息，通过将每个后续字段值附加到第一个，每个 用逗号分隔。头域相同的顺序 因此，收到的字段名称对 组合字段值的解释，因此代理不得 转发消息时更改这些字段值的顺序。
【讨论】：
-
ASP.net 使用普通的 NameValueCollection 来存储响应标头。
-
对于具有相同名称的多个标题，如果该标题多次出现是不合法的，则更重要，例如
Content-Length- 不同的服务器会以不同的方式处理它。例如。一个取第一个，一个取最后一个，另一个随机未定义。因此，尽管它有所作为，但您可能无能为力。 -
（哦，天哪，刚刚注意到您发布此内容的日期...！：-O 抱歉，我现在刚好碰到它...）
-
@AviD：是的，这就是“当且仅当该标头字段的整个字段值被定义为逗号分隔列表”条件的地方。像 Content-Length 这样的标头不是逗号分隔的列表，因此不允许使用多个 Content-Length 标头。但是 Accept 标头是一个逗号分隔的列表，因此具有多个标头，例如“Accept: text/plain”和“Accept: text/html”等价于“Accept: text/plain, text/html”，但不等价于“接受：text/html, text/plain”（顺序很重要）。
-
RFC 2616 已被 RFC 7230 淘汰，但规则保持不变，如 section 3.2.2. Field Order 中所述。
标题的顺序无关紧要。可能有“较弱”的 HTTP 标准实现，其中排序确实很重要，但一般来说不应该。
这是一个描述 HTTP 标头的链接：
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2
【讨论】：
为同一个 cookie 多次指定 set-cookie 也很重要：
"Set-Cookie: COOKIE1=VALUE1; ...
"Set-Cookie: COOKIE1=VALUE2; ...
在这种情况下，COOKIE1 将被设置为VALUE2，如果顺序改变：
"Set-Cookie: COOKIE1=VALUE2; ...
"Set-Cookie: COOKIE1=VALUE1; ...
COOKIE1 将设置为 VALUE1
【讨论】：
RFC 7230, section 3.2.2: Field Order 专门解决了这个问题。这里的引用来自规范的那个部分，重点是我添加的：
具有不同字段名称的标头字段的接收顺序不重要。
为了提高性能，它继续用一个关于良好实践的注释来限定它：
但是，最好先发送包含控制数据的标头字段，例如请求的主机和响应的日期，以便实现可以尽早决定何时不处理消息。
在某些情况下，允许消息包含多个具有相同名称的标头字段。在这种情况下，顺序确实很重要。
接收者可以将多个具有相同字段名称的标头字段组合成一个“字段名称：字段值”对，而不改变消息的语义，方法是将每个后续字段值按顺序附加到组合的字段值中，用逗号分隔。因此，接收具有相同字段名称的标头字段的顺序对于组合字段值的解释具有重要。
【讨论】：
-
我的答案与现有答案没有太大区别，但我想添加一个新的更新答案，引用当前的 HTTP/1.1 规范而不是过时的 RFC 2616。