Original text:
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.  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.)  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.)

Reviewer comments:
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. Maybe this super elegant solution (but the above ABNF would have to be tweaked):
FWIW nameless and valueless cookies are no longer RFC compliant after URL Up until then only Set-Cookie strings with empty names and empty values weren't accepted, but there were ways around this to get empty-name-empty-value cookies into user agents' cookie jar using the CookieStore API.
There are nameless cookies and there are valueless cookies (and, as you said, there are no nameless-and-valueless cookies). FWIW, the syntax in section 4.1.1 where is defined is a SHOULD, not a MUST, on the server's part. I think one issue is that reusing it to define makes that also implicitly a SHOULD, if I'm reading this correctly: Edit: To clarify, I'm thinking there's no accuracy issue with the spec as written, since if the server does things as recommended (and sends a cookie with name=value), then the user agent will respond as given by . But that is still totally confusing, at least to me, so I think we should still define this better.
(love the ambiguities of english -- thanks for the explicit callout and pointer to NAME
In the nameless cookie case, it seems that an unhandled edge case arises because of the following, from the section: To illustrate the problem with some examples: if is empty and is , the algorithm above works - the resulting cookie line would be if is empty and is , though, the resulting cookie line would be , which would be interpreted as a cookie with name and value . One solution for this, which is currently specified by the , is to forbid cookies with an empty name and a value containing '=' from being set. Limiting from containing a '=' is not mentioned in the section or the section of RFC6265bis, though. It seems like using the following in the section would be a better approach: This would fix the issue in the example above (the resulting cookie lines would be and respectively, both of which would be interpreted correctly). If we want to allow to be produced in the first case, we could replace step 2 above with something like: I'll submit a PR for this change.
The empty-name-but-nonempty-value case is serialized as and not for historical/compat reasons. There's some earlier discussion in . The case where the value contains an '=' is interesting though, and not tested by WPTs I believe. The Set-Cookie header can't produce a nameless cookie with value so this is only a concern for non-HTTP APIs that don't parse a set-cookie-string. Could we instead just add to the Storage Model section the restriction that the cookie-name and cookie-value cannot contain '=' or ';' characters? (Side note, more generally, this is getting out of hand and we should try to factor out common logic in the Storage Model and set-cookie-string parsing sections.)
hmm, looks like there is a WPT for this case, but the expected output for it would be interpreted incorrectly :( URL;l=22-26 Wouldn't be allowed in a Set-Cookie header? Also, '=' is a valid base64 character, so not allowing it in might cause a lot of headaches
Oh, my mistake, you're right that creates a nameless cookie with value . Chrome/Edge/Firefox agree on how to serialize these, but Safari ignores nameless cookies altogether. I would be a bit concerned about breaking stuff if this serialization changed. :-/ Theoretically there's a use case for this behavior... since and are the same cookie (the nameless cookie) but with different values, and they overwrite each other, a site could be relying on getting the output or (but never both) as a way of (sort of) setting two mutually exclusive cookies named and .
Maybe we just fix this with a note cautioning against using nameless cookies, and point to this issue as a warning.

Revised text:
store arbitrary data in a cookie-value SHOULD encode that data, for example, using Base64 RFC4648.  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.)