SHOULD NOT

[sbingler]

Comment by @fpalombini

Section 3:

Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field.

I wonder why this is a SHOULD NOT and not a MUST NOT. I do see this was a SHOULD NOT in the original RFC 6265. If it's the case that it has been kept as a SHOULD NOT because existing implementations do it despite this recommendation, I suggest explicitly motivate it here (for example by adding a note, as it has been done in other sections of the document).

[sbingler]

@mikewest

Do you have any more context as to why this is a "SHOULD NOT" instead of a "MUST NOT"?

Looking at the mail list for RFC6265 I found https://mailarchive.ietf.org/arch/msg/http-state/FwQWLsmRynEwtCKxOgUOWjFa7gE/

[S3 P4] It seems like there should be an all-caps requirement here, e.g., that "Origin servers MUST NOT fold multiple Set-Cookie header fields into a single header field".

Origin servers certainly can fold multiple Set-Cookie header fields
into a single header field if they desire. However, doing so changes
the semantics. Given the bytes on the wire, there's no experiment we
can run to see if the origin server did or did not perform this
folding. Therefore, a MUST-level requirement is inappropriate.

As I understand it, folding would cause multiple Set-Cooking header values to be considered instead as setting one cookie with many attributes. Is there a situation where this is "acceptable or even useful", to quote RFC 2119? It seems to me like folding is virtually guaranteed to be a bug.

Ok. I've changed this to a SHOULD. I suspect, actually, that this
requirement already exists in the document (in an obtuse way) because
the recommend grammar for servers won't produce a "," in the right
syntactic surrounds to be a folded Set-Cookie header.

Sounds like it's this way because it's a bad idea but we can't check/enforce that it hasn't occurred.

[mnot]

For what it's worth -- SHOULD vs MUST does not depend on whether it can be tested/enforced; it's whether there are exceptions to the rule.

[mikewest]

I agree with the position in that thread that there's no reasonable way to ensure that clients parse header-folded cookies in the way servers meant them to, and that this change in semantics runs against the grammar of the set-cookie header defined in 4.1.1.

I'd note, though, that that grammatical definition's section also suggests a number of SHOULDs that would ideally be MUSTs: "Servers SHOULD NOT send Set-Cookie header fields that fail to conform to the following grammar", "Per the grammar above, servers SHOULD NOT produce nameless cookies", "Servers SHOULD NOT include more than one Set-Cookie header field in the same response with the same cookie-name.", and so on.

I think I'd be comfortable being more prescriptive in the "well-behaved profile" that section 4 defines, and changing many these to hard requirements. I don't think that would require any changes to the client-side behavior that's more accepting of deviations from this profile (and would therefore have no practical effect on the world...), but could usefully increase the predictability of the profile.

I'll put up a PR to discuss.