Code change:
contained in the set-cookie-string, and the unparsed-attributes is the empty string. <del> If the name-value-pair string lacks a %x3D ("=") character, ignore the set-cookie-string entirely. </del> <ins> If the name-value-pair string lacks a %x3D ("=") character, then the name string is empty, and the value string is the value of name-value-pair. </ins> <del> The (possibly empty) name string consists of the characters up to, but not including, the first %x3D ("=") character, and the (possibly empty) value string consists of the characters after the first %x3D ("=") character. </del> <ins> Otherwise, the name string consists of the characters up to, but not including, the first %x3D ("=") character, and the (possibly empty) value string consists of the characters after the first %x3D ("=") character. </ins> Remove any leading or trailing WSP characters from the name string and the value string. <del> If the name string is empty, ignore the set-cookie-string entirely. </del> <ins> If both the name string and the value string are empty, ignore the set-cookie-string entirely. </ins> The cookie-name is the name string, and the cookie-value is the value string.

Related discussion:
text: This patch alters the cookie parsing algorithm to treat as creating a cookie with an empty name and a value of "token". It also rejects cookies with neither names nor values (e.g. and . Tests in web-platform-tests/wpt. Closes httpwg/http-extensions.
NAME Ping?
Landing this based on the discussion in . NAME If the wording needs more cleanup, I'd appreciate feedback!
The cookie-pair ABNF rule still requires presence of . Is it intentional?
As a part of discussion in whatwg/html I've made a of the modern browsers compatibility with the RFC 6265. It appears that all browsers nowadays allows cookies without key or (in case of Safari) without value, thus making it de facto standard. However, it's debatable how cookies like should be treated: as the cookie without value or without key. Thinking of cookie jar as some kind of key/value store makes it more logical to treat such cookie as cookies without value, but on the other hand, currently most implementers treats them as the cookies with the special empty key.
Discussed at Berlin IETF; Julian points out that we should check previous discussion in cookie WG. Martin points out that we should talk to the implementation that has divergent behaviour.
Context: around URL, ticket in URL
For clarity, are we saying Chrome, Firefox, and Edge treat such a cookie as key: "" and value "foo", and Safari treats it like key: "foo" and value: ""?
Per the table linked in OP Safari serializes input as whereas others serialize as . Firefox attempted to be more strict on cookie setting lacking and found it broke a router: URL
URL is the relevant test, in particular the following subtests: sends . Chromium stores a cookie with an empty name and value of , serialized as . Firefox does the same. Safari drops the cookie entirely. Given Firefox's experience with and related bugs above, this seems like it might be baked into some user-visible sites that are unlikely to update. I'd suggest that we change this test expectation to , and update the spec accordingly. sends , , and . Chromium stores three cookies: , , and , serialized as . Firefox and Safari store two cookies: and , serialized as . The latter is clearly correct and matches the spec; filed URL to change Chromium's behavior. sends , , and .