可以接受重复的HTTP响应标头吗？

123

我尚未找到有关该标准是否允许重复的HTTP响应标头的任何规范，但是我需要知道这是否会引起兼容性问题。

说我有一个这样的响应头：

HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.4; JBoss-4.0.3SP1 (build: CVSTag=JBoss_4_0_3_SP1 date=200510231054)/Tomcat-5.5
Cache-Control: no-cache
Cache-Control: no-store
Location: http://localhost:9876/foo.bar
Content-Language: en-US
Content-Length: 0
Date: Mon, 06 Dec 2010 21:18:26 GMT

请注意，有两个Cache-Control标头具有不同的值。浏览器是否总是像对待“缓存控制：无缓存，无存储”那样对待它们？

http-headers

— 苏章
source

Answers:

156

是

此处提供的HTTP RFC2616 表示：

当且仅当该报头字段的整个字段值定义为以逗号分隔的列表[即，＃（值）]时，消息中才会存在多个具有相同字段名的消息报头字段。通过将每个随后的字段值附加到第一个字段（每个字段用逗号隔开），必须在不改变消息语义的情况下，将多个头字段组合成一对“字段名：字段值”。因此，具有相同字段名称的报头字段的接收顺序对于组合字段值的解释很重要，因此代理在转发消息时不得更改这些字段值的顺序

因此，如果将整个字段值定义为用逗号分隔的值列表，则可以使用多个具有相同名称的标头（www-authenticate是这种情况）。

缓存控制记录在这里：http : //www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9像这样：

Cache-Control   = "Cache-Control" ":" 1#cache-directive

该#1cache-directive语法定义了至少一个缓存指令元素的列表（有关#values的正式定义，请参见此处：符号约定和通用语法）

所以，是的，

Cache-Control: no-cache, no-store

等价于（顺序很重要）

Cache-Control: no-cache
Cache-Control: no-store

— 西蒙·穆里尔
source

谢谢您的快速回应，西蒙！但是RFC 2616中引用的段落也不适用于Cache-Control吗？我想念什么吗？

— Su Zhang 2010年

几乎100％正确。缓存控制允许多个值： Cache-Control = "Cache-Control" ":" 1#cache-directive。注意#之前cache-directive。这表示可以接受多个值（来自上面的定义）...

— ircmaxell，2012年

“并且仅当该标头字段的整个字段值定义为逗号分隔的列表时” –在我看来，多个值必须定义为逗号分隔的列表，即，它们不能为拆分为单独的标题。

— mpen 2014年

@mark-“定义为以逗号分隔的列表”在这里表示“在BNF语法中定义为以逗号分隔的列表”。缓存控制字段的确定义为（x＃blahblah）。

— Simon Mourier 2014年

较新的RFC 7230中有关处理多个标头的部分是tools.ietf.org/html/rfc7230#section-3.2.2

— Matthew Buckett

请注意，HSTS RFC6797通过为STS标头的多个实例定义行为来与RFC2616（违反了“仅当”语言）相矛盾，尽管它没有填充逗号分隔的值：

  "If a UA receives more than one STS header field in an HTTP
  response message over secure transport, then the UA MUST process
  only the first such header field."

— 海报男孩
source

不正确 RFC6797并未将STS标头定义为包含逗号分隔的列表。因此，RFC 2616中的“仅当且仅当”规则适用于相同（意味着不允许使用多个STS头，因为STS头未定义为采用逗号分隔的列表）。RFC6797只是无法确定违反该规则的后果，RFC2616似乎没有解决这个问题。

— 弗朗斯