You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
[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.
Comment by @fpalombini
Section 3:
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).
The text was updated successfully, but these errors were encountered: