Multiple HTTP Headers with the same field name

conflicting-headers.md

In 8.3.1. Considerations for New Header Fields, not really an appropriate place

Authors of specifications defining new header fields are advised to
consider documenting:

o  Whether the field is a single value, or whether it can be a list
   (delimited by commas; see Section 3.2 of [Part1]).

   If it does not use the list syntax, document how to treat messages
   where the field occurs multiple times (a sensible default would be
   to ignore the field, but this might not always be the right
   choice).

So HTTP here says to ignore the field, but it is not really a prescription.

About the 3.2.2. Field Order

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

Multiple header fields with the same field name can be combined 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.

So still not really a recommendation on how to parse when it is happening and it is NOT a comma separated type of header. So no luck.

The question was recently asked on the mailing list for Location:

If different applications interpret duplicate headers differently, we have a serious problem

Location: http://abc.com Location: http://xyz.com

Some chooses the 1st one, some chooses the 2nd one, and some may see the merged http://abc.com,http://xyz.com (a valid URI)

We probably should require that an application either reject the message, or merge the header first if it wants to parse the header.

It led to the opening of issue 429 but which was later on changed to WONTFIX following this message.

So I guess it is up to browser implementations to define which one of the following options and document it.

1. Take the first Location and ignore the others.
2. Take the last Location and ignore the others.
3. Ignore every Location when there are multiple ones in the headers.