Does the order of headers in an HTTP response ever matter?

Question

Is it ever meaningful whether the order of headers is

A: 1
B: 2

vs

B:2
A:1

I'm trying to figure out if I can use a dictionary to store a list of headers or if it needs to be some kind of list or ordered dictionary.

Cambyses

The order of the "request" headers can be used for browsers/bots fingerprinting. – Caruso

Answer 1

No, it does not matter for headers with different names. See RFC 2616, section 4.2:

The order in which header fields with differing field names are received is not significant. However, it is "good practice" to send general-header fields first, followed by request-header or response- header fields, and ending with the entity-header fields.

It DOES matter, however, for multiple headers with the same name:

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.

Zipah

ASP.net uses a plain NameValueCollection to store the response headers. – Melodeemelodeon

For multiple headers with the same name it matters EVEN MORE if its not legal for that header to appear multiple times, e.g. Content-Length - different servers will handle it in a different way. E.g. one will take the first, one will take the last, and another will be randomly undefined. So while it makes a difference, there might not be much you can do about it. – Kindling

(Oh dang, just noticed the date you posted this...! :-O Sorry, I just happened across it now...) – Kindling

@AviD: Yes, that's where the "if and only if the entire field-value for that header field is defined as a comma-separated list" condition kicks in. Headers like Content-Length are NOT a comma-separate list, so multiple Content-Length headers are not allowed. But the Accept header is a comma-separated list, so having multiple headers like "Accept: text/plain" and "Accept: text/html" is equivalent to "Accept: text/plain, text/html", but NOT equivalent to "Accept: text/html, text/plain" (the order matters). – Zipah

RFC 2616 has been obsoleted by RFC 7230, but the rules stay the same, as mentioned in section 3.2.2. Field Order. – Unguentum

Answer 2

The order of the headers should not matter. There might be "weaker" implementations of HTTP standard where the ordering does matter, but it shouldn't in general.

Here's a link that describes HTTP headers:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2

Caucasia

Answer 3

HTTP Headers are independent of each other and you can use a dictionary to store them without worrying about their order.

Primaveras

Not true for multiple occurances of the same header. – Repent

Answer 4

It could also matter when specifying set-cookie several times for the same cookie:

"Set-Cookie: COOKIE1=VALUE1; ...
"Set-Cookie: COOKIE1=VALUE2; ...

In this case, COOKIE1 will be set to VALUE2, and if the order is changed:

"Set-Cookie: COOKIE1=VALUE2; ...
"Set-Cookie: COOKIE1=VALUE1; ...

COOKIE1 will be set to VALUE1

Diseased

Answer 5

RFC 7230, section 3.2.2: Field Order addresses this question specifically. Quotes here are from that section of the specification, with emphasis added by me:

The order in which header fields with differing field names are received is not significant.

It goes on to qualify that with a note about good practice for the sake of performance:

However, it is good practice to send header fields that contain control data first, such as Host on requests and Date on responses, so that implementations can decide when not to handle a message as early as possible.

In certain cases it is permissible for a message to contain multiple header fields with the same name. In this case, order does matter.

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. The order in which header fields with the same field name are received is therefore significant to the interpretation of the combined field value.

Upswing

My answer here is not significantly different from existing ones, but I wanted to add a new updated answer that quotes the current HTTP/1.1 spec instead of the outdated RFC 2616. – Upswing