I'm aware that HTTP servers can send headers with duplicate keys (at least Set-Cookie
comes to mind), but is there a plausible reason for clients to do this?
问题:
回答1:
RFC 7230 does allow for duplicate headers under some circumstances. From section 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.
One somewhat "plausible" scenario comes to mind: When the HTTP request is passing through a proxy, the proxy might simply tack on another header (say, an X-Forwarded-For
, or an extra Accept-Encoding
), rather than determine if a header already exists, then parse and modify it accordingly.
Technically, any client is "allowed" to send multiple headers with the same name, so long as it meets the requirements in RFC 7230 above.
回答2:
a) It might be easier when multiple pieces of code are involved,
b) It can be unavoidable for certain fields such as Set-Cookie (see https://greenbytes.de/tech/webdav/rfc7230.html#rfc.section.3.2.2.p.4).