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: NAME I read your comments above as generally approving of the change suggested in URL, but cautious about how to ship it in Chrome? That feels like an important part of an eventual "Intent to Ship", rather than a discussion of what we'd like the spec to say. If we decide to accept the suggestions above, then I'm pretty confident that we can work out how and when to ship it (especially given that there's no real agreement among browsers today, so the status quo is already trifurcated as per URL above). Indeed! You're exactly right, and I should have been more clear. The 0.0025% is the number of requests (not page views, FWIW) for which we'd shift from sending an empty header to sending no header at all. That seems to me to be a change more likely to invalidate an application's expectations than shifting from to . I think this is the easier case, actually, as the serialization of an empty cookie is indistinguishable from a empty cookie jar.
Thanks for sending on NAME . I more meant it as a concern that the 0.12% of users figure sounds way too low to me given Facebooks prevalence. Note you don’t need to be a Facebook user or visit a Facebook site to get this cookie - just a site that uses Facebook advertising pixels (of which there are many!). So I still have that concern that this figure sounds way too low to me. Which then begs the question as to whether there are more cases than we think there are? Now I agree that particular example sounds like a bug and I doubt this empty cookie is being used and so don’t think blocking it off will cause a breakage, but still, I’m uneasy that the stats seem wrong and that we are using this (potentially incorrect) stat to justify the low chance of breakage with this change. There might be other cookies on other sites that will cause breakage. To be clear, I don’t actually think it will cause a lot of breakage, but would rather than was based on a stat we are comfortable to stand behind than one that we have potential concerns with. Is there any way to double check that 0.12% stat given this example?