Code change:
Adds an example to the Examples section to clarify and illustrate that cookie names are case-sensitive. Additionally adds a clarification that cookie names could be empty to improve readability.
Agreed
What should a user agent do with the "set-cookie-string" ? The current RFC says that the name string can be empty and then in a subsequent step to ignore that cookie. URL
Hi, instructs >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. 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. which covers the case of a nameless cookie such as . I think clarifying, similar to the value string, that the name string could be possibly empty would improve readability, I'll make that change.
Thank you NAME This means there is a change in the recommended parsing algorithm: now empty named cookies are ok. Is that intended?
That's correct. Even though it's strongly not recommended we found that servers still produced unusual set-cookie strings, including empty cookie names, and many UAs accepted them. So the parsing change is meant to standardized behavior so that UAs can at least all do the same thing with them. I still strongly recommend that any sites only use cookies with a non-empty name that conforms to 's syntax. Same for the value field too, now that I'm mentioning it. It'll probably work otherwise, but why make your life harder?
I think the spec would benefit from getting this fact explicitly specified. and are two different cookies.
If you had asked me if this already existed I would have guessed yes. Seems like an obvious improvement
LGTM. It'd be very nice if we could remove the notion of empty cookie names, but since we can't we should document them clearly. :/

Related discussion:
text: semantics). Notice that the Cookie header field above contains two cookies, one <del> named SID and one named lang.  If the server wishes the user agent to persist the cookie over multiple "sessions" (e.g., user agent restarts), the server can specify an expiration date in the Expires attribute.  Note that the user agent might delete the cookie before the expiration date if the user agent's cookie store exceeds its quota or if the user manually deletes the server's cookie. </del> <ins> named SID and one named lang. Cookie names are case-sensitive, meaning that if a server sends the user agent two Set-Cookie header fields that differ only in their name's case the user agent will store and return both of those cookies in subsequent requests. If the server wishes the user agent to persist the cookie over multiple "sessions" (e.g., user agent restarts), the server can specify an expiration date in the Expires attribute.  Note that the user agent might delete the cookie before the expiration date if the user agent's cookie store exceeds its quota or if the user manually deletes the server's cookie. </ins> Finally, to remove a cookie, the server returns a Set-Cookie header field with an expiration date in the past.  The server will be