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: I think disallowing (0020 case) and (0023 case) would make sense too, but that might break things. In the 0004 case: We've been parsing as an empty name with a non-empty value for a long time, afaict. Since Firefox seems to do the same thing, I think we should definitely update the spec to match the implementations (i.e. for a Set-Cookie line without a but with a valid token, treat the token as the value and, for cookies without a name, don't put a when serializing). In the 0020 () and 0023 (empty ) cases: Judging by Chrome metrics for Cookie.HeaderLength, there is definitely non-zero usage of empty cookies, so I'm concerned that rejecting empty cookies would break things... (In the 0020 case, one could also argue that explicitly sending a Set-Cookie header of indicates intent to create a cookie, even if it is empty.) I agree it's a bit silly to allow cookies with both empty name and empty value, though. I think that's a reasonable change to make to the spec, and maybe we don't care about potentially breaking things.
Thanks, NAME I agree with you for the 0004 case. NAME would Apple be willing to change CFNetwork's behavior to match the suggestions above? For 0020 and 0023: Looking at the stable channel on for the 28 days ending on Dec 31st, 0.0025% of headers were empty, spread over 0.12% of users. This is a pretty small number in total, and a pretty small number per user; certainly within the range of changes we've been successful with in the past. I wouldn't be surprised if it broke something (because everything we do with cookies breaks something!), but I would be surprised if it broke anything critical enough to retain the behavior. It would signify an intent to create a cookie without a name and without a value. What would that intent mean? I'd like it to mean "Don't create a cookie." :)
I'm okay with your proposed changes. cc NAME NAME NAME
URL should cover the proposed changes above. (I kinda want to rewrite the whole parsing algorithm in terms of Infra to be a bit more precise, but that's a task for another patch.