proposal: http header fields order

[ddo]

Since Go http headers is store in a map and in Go 1 the runtime randomizes map iteration, so:

• we need a way to let people define the order.
• or at least Go set the default order by "good practice" as defined in 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.

[mvdan]

Is there anything in particular this would fix or help with, other than satisfying the RFC good practice?

cc @bradfitz

[bradfitz]

Yeah, what @mvdan said. But even that RFC text can be implemented without knowing the "original" order. I'd like to see evidence that anybody cares about the order before we even did that, though. I'd need a lot of evidence that order matters to somebody before adding new API around this.

[ddo]

There are many cases i guess.

Set-Cookie: cookie1=1
Set-Cookie: cookie1=2

cookie1 will be set to 2 if in order

Accept: text/plain
Accept: text/html

equivalent to Accept: text/plain, text/html, but not equivalent to Accept: text/html, text/plain.

[bradfitz]

There are many cases i guess.

Okay, it sounds like there's no concrete problem if we're guessing at hypotheticals here.

Neither of those Set-Cookie or Accept cases are problematic. We already preserve the order of multiple values for header fields.

I'm going to close this until a concrete problem is identified.