Errata fix

[sbingler]

Fixes erratum 6093

[martinthomson]

I know that the change is editorial, but it seems to me if you are concerned about combining by intermediaries, this is the opposite of the advice that you should be giving.

[mikewest]

1. We're changing this to a MUST in [RFC6265bis] Harden requirements for the Set-Cookie profile. #2988. Perhaps changing the wording in that PR would be simpler than rebasing this on top of that?

2. I'm not sure I follow your suggestion, @martinthomson. What advice should we be giving here?

[sbingler]

Perhaps changing the wording in that PR would be simpler than rebasing this on top of that?

Now that it's just a single change in this PR I think combining them is just as easy as not (maybe easier to avoid merge issues)

I'm not sure I follow your suggestion, @martinthomson. What advice should we be giving here?

I'm also not clear on why this isn't the correct advice.

[martinthomson]

The statement says that you should not produce set-cookie: a=b;c=d from set-cookie: a=b and set-cookie: c=d. It justifies that by saying that the usual combining rules for fields don't work. However, the advice you want is: if you combine set-cookie, use a semicolon rather than a comma.

The thing that got me to react here was the implication that leaving the cookie fields alone carries a risk that an intermediary might combine fields without knowing that set-cookie is special. In THAT case, combining (using ";") at the origin server would be an excellent idea because it would avoid that happening.

(There are other concerns, like the effect of combining on HTTP/2 and HTTP/3 header compression efficiency. But maybe we don't need to get into that level of detail.)

It's possible that this is just poor wording. Maybe if you say that implementations (origin servers, any servers, intermediaries, clients, anyone) shouldMUST not combine set-cookie using ",". That this specifically names origin servers invokes all of the above questions. (If you agree, we should open an issue to clarify, rather than continuing here, where it will definitely be lost.)

[sbingler]

However, the advice you want is: if you combine set-cookie, use a semicolon rather than a comma.

We don't want to give that advice either.
Within a set-cookie string any values separated by a semicolon will be treated as attributes for the first name=value pair.

From Section 5.6

2. If the set-cookie-string contains a %x3B (";") character:
     1. The name-value-pair string consists of the characters up to, but not including, the first %x3B (";"), and the unparsed-attributes consist of the remainder of the set-cookie-string (including the %x3B (";") in question).

So set-cookie: a=b;c=d would set a cookie a=b with some attribute c that has a value of d. Since c is an unrecognized attribute it'll be ignored and a default a=b cookie will be set.

The thing that got me to react here was the implication that leaving the cookie fields alone carries a risk that an intermediary might combine fields without knowing that set-cookie is special.

Presumably an intermediary would have implemented the HTTP spec which specifically calls out Set-Cookie as special. Granted that's specified with an "ought".

That this specifically names origin servers invokes all of the above questions

Fair.

I think we can resolve this ambiguity by calling out origin servers and intermediaries. Something like

Origin servers and intermediaries MUST NOT each combine multiple Set-Cookie header fields into a...
Not sure how clear the "MUST NOT each" phrasing is, open to suggestions. This should take care of that ambiguity.

I'll upload a patch

[sbingler]

@mikewest Thoughts on the recent change?

[mikewest]

This LGTM, but I think we could add a little more clarification of the problem since I'm not sure we're on the same page about that.