Set more than one HTTP header with the same name?

问题:

As far as I know it is allowed by the HTTP spec to set more than one HTTP header with the same name. Is there any use case to do so (from client to server and vice versa)?

HTTP 1.1 Section 4.2:

Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each 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, and thus a proxy MUST NOT change the order of these field values when a message is forwarded.

If I'm not wrong there is no case where multiple headers with the same name are needed.

回答1:

Since duplicate headers can cause issues with various web-servers and APIs (regardless of what the spec says), I doubt there is any general purpose use case where this is best practice. That's not to say someone somewhere isn't doing it, of course.

回答2:

It's commonly used for Set-Cookie:. Many servers set more than one cookie.

Of course, you can always set them all in a single header.

Actually, I think you cannot set multiple cookies in one header. So that's a necessary use-case.

The Cookie spec does claim that you can combine multiple cookies in one header the same way other headers can be combined (comma-separated), but it also points out that non-conforming syntaxes (like the Expires parameter, which has ,s in its value) are still common and must be dealt with by implementations.

So, if you use Expires params in your Set-Cookie headers and you don't want all your cookies to expire at the same time, you probably need to use multiple headers.

回答3:

It's only allowed for headers using a very specific format, see RFC 2616, Section 4.2.

回答4:

As you're looking for use-cases, maybe Accept would be a valid one.

• Accept: application/json
• Accept: application/xml

回答5:

Old thread, but I was looking into this same issue. Anyway, the Accept and Accept-Encoding headers are typical examples that uses multiple values, comma separated. Even if these are request specific header, the specs do not differentiate between request and response at this level. Check the one from this page. What the spec says is that if you have commas as character in the value of the header, you cannot use multiple headers of the same name, unless you disambiguate the use of the comma.

回答6:

In my humble opinion, only those headers, whose value can be expressed(defined) with comma separated, can be written in multiple headers with a single or multiple values.

Let's say we have a header whose value can be written in comma separated list.

Entries-In-Order: Jane,John,Charlie

That header value is valid by its definition and the server or the client knows it. And then we can separate it as

Entries-In-Order: Jane,John
Entries-In-Order: Charlie

But any headers don't understand the comma separated value cannot be written in multiple.

Who-Are-Responsible: John, Jane or maybe Charlie?

If, by definition, the server or the client might handle the whole string(John,Jane,maybe Charlie?) as a single value, writing it as a multiple headers won't work as expected.

My-Dummy-Header: John
My-Dummy-header: Jane or maybe Charlie?