kyle-long
commented
8 years ago Five more minutes of research shows that this is not true and the RFC explicitly addresses this.
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.
Originally we decided on multiple Link headers because it is much easier to read instead of having them all on a single line. One thing we had not considered is that header order doesn't need to be preserved. So, for instance, if it goes through a proxy, there is nothing stopping them from jumbling the order which would screw up a sort.
The only solution I can think of is to make links come back all in a single header. This would make it extremely hard to read but at least it would be reliable. It may not be as big a deal after we have proper tools for dealing with the API (instead of curl).