Is it fine to use duplicate response header with same value?

Question

I found a response where duplicate headers are used by the application with the same value. Could anyone tell me that, Is it a good programming practice or those are used for security perspective or anything else?

 HTTP/1.1 200 
 Accept-Ranges: bytes
 Cache-Control: no-cache, must-revalidate, private
 Content-Type: text/html
 Date: Mon, 20 Nov 2017 04:08:51 GMT
 Expires: 0
 Last-Modified: Thu, 16 Nov 2017 14:04:48 GMT
 Pragma: 
 Public-Key-Pins: pin-sha256="5w0XrTCAbsVO7vTngDViNHPutlvB43qYionPbpV2ky0=";  
 max-age=5184000; includeSubDomains;
 Server: Any
 Set-Cookie: ********************* httponly; secure; path=/
 Strict-Transport-Security: max-age=31536000 ; includeSubDomains
 Strict-Transport-Security: max-age=31536000; includeSubDomains
 X-Content-Type-Options: nosniff
 X-Content-Type-Options: nosniff
 X-Frame-Options: SAMEORIGIN
 X-Frame-Options: SAMEORIGIN
 X-XSS-Protection: 1; mode=block
 Content-Length: 559
 Connection: Close

This application is using duplicate X-Content-Type-Options header, Strict-Transport-Security, X-Frame-Options header with same values. I posted this question at stackoverflow, but I didn't find any response.

Answer 1

From RFC2616

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

So

Cache-Control: no-cache
Cache-Control: must-revalidate
Cache-Control: private

would be fine. I'm not convinced that applies here. If having duplicate header entries were valid it will depend on each header as to whether having duplicate values is allowed.

From a security perspective if any of those lines are not legal it is not defined what the client will do with them - so ignoring them may be a valid option. So I would argue as well as bad practice it is technically a risk.

From a practical perspective there are a few ways I could imagine clients handling this.

• The obvious option is they would just take the first or last entry they encounter. Seeing as these are duplicates that wouldn't be an issue.
• The safe option is to error out the request.
• A smarter option would be to pass both to the handler and let it decide. I.e for security based headers always use the stricter value.
• Another option would be to concatenate headers into csv and pass that to the handler - which would cover the legal duplicate header cases.
• The worst case would be the client ignores the header.

Answer 2

If duplicating a header is fine and how it gets interpreted depends on the exact semantic of the header.
Some headers like Content-Encoding are cumulative, i.e. all values will be put together (at least in theory, practice might differ). In this case having multiple headers of the same value is of course different to having a single header.
Other headers are singletons and should occur at most once. Usually it is accepted if the same header and value is sent multiple times for singletons. But I would not rely on it since it is still invalid. And if the same header is sent multiple times with a different value, the behavior of the clients varies (might also depend on the header): some pick a specific header (i.e. first or last) while others treat the response as corrupt since multiple interpretations are possible which can result in security problems.

Answer 3

The correct behavior (as per RFC) is to append if the header is a list (like Cache-Control) or generate an error.

In practice, the Internet is a wild goose, as Steffen Ulrich says, the result will vary depending on the client. I think most clients do not generate an error. One problem with the error concept is that a header you do not know could be a one value header (opposed to a list) and thus you can't know whether it is allowed to be repeated or not. So the RFC is nice but can't be properly followed for such headers.

In most cases, I would say it's bad practice to repeat headers especially with the same values and would look into whether it is possible to avoid the duplication. Since in your case both have the exact same value, it is likely fine for most clients available out there.