Multiple Vary HTTP headers or one combined?
Asked Answered
O

2

15

Question: What is the best way to send Vary HTTP header when server accept gzip/deflate connections AND serve a different content for mobile clients?

I see two possible variants but I cannot find any useful information whether they are correct and/or supported by most proxies and search engines:

  1. Combine variants to a single line: Vary: Accept-Encoding,User-Agent
  2. Send two separate headers:

Vary: Accept-Encoding

Vary: User-Agent

Any information or link to appropriate W3C standard are welcome :)

Operose answered 1/3, 2015 at 9:49 Comment(0)
C
17

Both are valid (and mean the same thing).

And no, the W3C isn't relevant here. You will need to look into the IETF RFCs 7230 and 7231.

Commissioner answered 1/3, 2015 at 21:13 Comment(3)
It bears mentioning those variants are - despite being gramatically different - semantically identicalTheurer
Thanks, Julian! I should mention that according to tools.ietf.org/html/rfc7230#section-3.2.2 (RFC 7230 Section 3.2.2) you've provided in your answer it is recommended to combine headers into one string but allowed to separate. Not sure if it's applicable to Vary header though.Operose
"unless either the entire field value for that header field is defined as a comma-separated list" - quoting selectively isn't helpful....Commissioner
A
1

Multiple header fields with the same name are allowed for two cases:

  1. Set-Cookie

  2. All header fields where value is always a list (values seperated by commas)

Examples: 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.)

Argive answered 4/2, 2020 at 15:13 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.