Original text:
A recipient MAY combine multiple field lines with the same field name into one field line, without changing the semantics of the message, by appending each subsequent field line value to the initial field <del> line value in order, separated by a comma.  The order in which field lines with the same name are received is therefore significant to the interpretation of the field value; a proxy MUST NOT change the order of these field line values when forwarding a message. </del>  This means that, aside from the well-known exception noted below, a sender MUST NOT generate multiple field lines with the same name in a

Reviewer comments:
Fetch and XMLHttpRequest have for the longest time used comma-followed-by-space (0x2C 0x20) as separator when multiple header fields are combined into a single header field. This is also what at least Firefox and Chrome do from code inspection: URL URL I think this is because of URL encouraging values to start with a single space and folks conceptually still seeing it as multiple values. Now URL has a much more explicit definition, which no longer allows for a space as far as I can tell, "breaking" with what implementations are doing. Most of the time this difference is insignificant, but anything with quoted-string or equivalent will be able to tell what was used if those configuring the headers like to play games. I'd like HTTP to either allow 0x2C 0x20 as an alternative separator (and have Fetch mandate it for browsers) or simply adopt 0x2C 0x20 as separator for everyone. I have some tests around this as well, but they only affect APIs, which theoretically could have a different non-HTTP-conformant view, but that'd seem really bad: URL See URL and URL for further context. cc NAME NAME NAME
Whitespace is allowed (and insignificant). Can you point at the actual difference between 2616 and 7230 which makes you think that something changed?
You mean when a quoted-string is broken into several header field instances?
In 2616 the same section states that values can be preceded by whitespace. Whereas in 7230 it only describes how to combine, without any mention of whitespace. Both sections are linked in OP. Yeah, also relevant for structured headers, which is how I started stumbling into this. If one client combines with a space, another without, and another with three spaces, you get subtly different strings and possibly room for security bugs.
This one? That's not specific to recombination.
I know...
Anne, I think what you're suggesting is to change: to: This is meaningful in some admittedly pathological cases, such as a header like this: Because the current text has a combined value of -- whereas most implementations will do .
So I think things are even more broken than I thought. A recipient that knows about URL and knows the header, might drop empty or whitespace values. So becomes (or maybe they'd reject it, depending on how the header was defined), but a basic intermediary would turn it into . The final recipient in that case cannot figure out what the sender meant. It seems to me that URL should only ever apply after combining header values, including empty ones, not before.
FWIW, the message was invalid wrt that header field already, so "figure out what the sender meant" doesn't make a lot of sense to me.
The problem is that "invalid" depends on whether the recipient knows the syntax, which is just broken if the recipient is allowed to combine before forwarding (which makes it "valid").
The only sensible thing to do is to always combine before determining validity.
See PR. NAME I haven't done anything to address your later comments; how do folks feel about adding a statement spelling out that consequence, either here, or in Considerations for New Fields?
I think explaining the issue would indeed be good.
NAME NAME - Are we sure what we really want to say "optional whitespace" here? Are CR LF or VTAB allowed?

Revised text:
A recipient MAY combine multiple field lines with the same field name into one field line, without changing the semantics of the message, by appending each subsequent field line value to the initial field  <ins> line value in order, separated by a comma and optional whitespace. For consistency, use comma SP. The order in which field lines with the same name are received is therefore significant to the interpretation of the field value; a proxy MUST NOT change the order of these field line values when forwarding a message. </ins> This means that, aside from the well-known exception noted below, a sender MUST NOT generate multiple field lines with the same name in a