Code change:
store arbitrary data in a cookie-value SHOULD encode that data, for example, using Base64 RFC4648. <del> The domain-value is a subdomain as defined by RFC1034, Section 3.5, and as enhanced by RFC1123, Section 2.1.  Thus, domain-value is a string of USASCII characters, such as one obtained by applying the "ToASCII" operation defined in Section 4 of RFC3490. </del> Per the grammar above, the cookie-value MAY be wrapped in DQUOTE characters.  Note that in this case, the initial and trailing DQUOTE characters are not stripped.  They are part of the cookie-value, and will be included in Cookie header fields sent to the server. <ins> The domain-value is a subdomain as defined by RFC1034, Section 3.5, and as enhanced by RFC1123, Section 2.1.  Thus, domain-value is a string of USASCII characters, such as one obtained by applying the "ToASCII" operation defined in Section 4 of RFC3490. </ins> The portions of the set-cookie-string produced by the cookie-av term are known as attributes.  To maximize compatibility with user agents, servers SHOULD NOT produce two attributes with the same name in the same set-cookie-string.  (See storage-model for how user agents handle this case.) <ins> NOTE: The name of an attribute-value pair is not case sensitive.  So while they are presented here in CamelCase, such as "HttpOnly" or "SameSite", any case is accepted.  E.x.: "httponly", "Httponly", "hTTPoNLY", etc. </ins> Servers SHOULD NOT include more than one Set-Cookie header field in the same response with the same cookie-name.  (See set-cookie for how user agents handle this case.)

Related discussion:
text: While already discouraged by the grammar, this warning further discourages servers from sending nameless cookies which have a history of causing compatibility problems. It also reorders the notes in the syntax section to group similar notes together.
Ideally we'd define server-side parsing of cookie-string (or at least recommend behaviour here for things that don't match cookie-string!), given this does cause problems for some servers (e.g. URL). Until then we should at least make it clear that the "the algorithm to compute the cookie-string from a cookie store and a request-uri" can create things that don't match cookie-string (e.g., nameless cookies after ). There's a number of WPT expected results that don't match cookie-string.
Can you clarify what a fix would look like? Bonus points for a PR. (I mean, I can also attempt a PR, just not clear on what the recommended fix would be)
You attempting would probably be as good as me attempting!
I'm skeptical, however willing to try! And now I think I actually understand the bug report (and didn't when I commented). NAME is saying that the ABNF in URL has a bug, since is defined as: But nameless and valueless cookies exist. cf. URL URL
I think maybe this can be solved by making the following changes: This is pretty simple to grok: This is supposed to convey "a nameless cookie, OR a valueless cookie (but not both)" That should work for the following valid cookie-pairs: (nameless) (nameless2) (named cookie with empty , i.e., valueless) (name + value) If that's the route we go, then in URL cookie-string = cookie-pair *( ";" SP cookie-pair ) That should work. However... unless we tweak , I think you can end up with the following invalid cookie: . Will need to formalize "if no name, there must be a value". Maybe we can just add an and then do something like:
Actually that won't fix the bug I described.