多个 Vary HTTP headers 还是一个组合？
Multiple Vary HTTP headers or one combined?
问题：当服务器接受 gzip/deflate 连接并提供不同内容时，发送 Vary HTTP header 的最佳方式是什么移动客户端？
我看到了两种可能的变体，但我找不到任何有用的信息，它们是否正确and/or 大多数代理和搜索引擎都支持：
- 将变体合并为一行：
Vary: Accept-Encoding,User-Agent
- 发送两个单独的 headers:
Vary: Accept-Encoding
Vary: User-Agent
欢迎提供任何信息或 link 适当的 W3C 标准:)
两者都有效（并且意思相同）。
不，这里与 W3C 无关。您需要查看 IETF RFC 7230 和 7231。
在两种情况下允许多个 header 同名字段：
Set-Cookie
值始终为列表的所有 header 个字段（值以逗号分隔）
示例：Accept-Encoding、Vary、...
RFC 7230 - 3.2.2
A sender MUST NOT generate multiple header fields with the same
field name in a message unless either the entire field value for
that header field is defined as a comma-separated list [i.e., #(values)]
or the header field is a well-known exception (as noted below).
A recipient MAY combine multiple header fields with the same field
name into one "field-name: field-value" pair, without changing the
semantics of the message, by appending each subsequent field value to
the combined field value in order, separated by a comma. The order
in which header fields with the same field name are received is
therefore significant to the interpretation of the combined field
value; a proxy MUST NOT change the order of these field values when
forwarding a message.
Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
appears multiple times in a response message and does not use the
list syntax, violating the above requirements on multiple header
fields with the same name. Since it cannot be combined into a
single field-value, recipients ought to handle "Set-Cookie" as a
special case while processing header fields. (See Appendix A.2.3
of [Kri2001] for details.)
问题：当服务器接受 gzip/deflate 连接并提供不同内容时，发送 Vary HTTP header 的最佳方式是什么移动客户端？
我看到了两种可能的变体，但我找不到任何有用的信息，它们是否正确and/or 大多数代理和搜索引擎都支持：
- 将变体合并为一行：
Vary: Accept-Encoding,User-Agent - 发送两个单独的 headers:
Vary: Accept-Encoding
Vary: User-Agent
欢迎提供任何信息或 link 适当的 W3C 标准:)
两者都有效（并且意思相同）。
不，这里与 W3C 无关。您需要查看 IETF RFC 7230 和 7231。
在两种情况下允许多个 header 同名字段：
Set-Cookie值始终为列表的所有 header 个字段（值以逗号分隔）
示例：Accept-Encoding、Vary、...
RFC 7230 - 3.2.2
A sender MUST NOT generate multiple header fields with the same field name in a message unless either the entire field value for that header field is defined as a comma-separated list [i.e., #(values)] or the header field is a well-known exception (as noted below).
A recipient MAY combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the
semantics of the message, by appending each subsequent field value to the combined field value in order, separated by a comma. The order
in which header fields with the same field name are received is
therefore significant to the interpretation of the combined field
value; a proxy MUST NOT change the order of these field values when
forwarding a message.Note: In practice, the "Set-Cookie" header field ([RFC6265]) often appears multiple times in a response message and does not use the list syntax, violating the above requirements on multiple header fields with the same name. Since it cannot be combined into a single field-value, recipients ought to handle "Set-Cookie" as a special case while processing header fields. (See Appendix A.2.3 of [Kri2001] for details.)