Allow cookies without key or value

[inikulin]

As a part of discussion in whatwg/html#804 I've made a research 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 foo; 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.

[mnot]

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.

[reschke]

Context: around https://mailarchive.ietf.org/arch/msg/http-state/7UX_L6HCNbMIyuI2Q9LQ3V7wDgk, ticket in https://trac.tools.ietf.org/wg/httpstate/trac/ticket/1

[johnwilander]

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: ""?

[annevk]

Per the table linked in OP Safari serializes input foo as foo= whereas others serialize as foo.

Firefox attempted to be more strict on cookie setting lacking = and found it broke a router: https://bugzilla.mozilla.org/show_bug.cgi?id=1551729. 😟

[mikewest]

https://wpt.fyi/results/cookies/http-state/general-tests.html?label=experimental&label=master&aligned is the relevant test, in particular the following subtests:

• 0004 sends Set-Cookie: foo. Chromium stores a cookie with an empty name and value of foo, serialized as Cookie: foo. Firefox does the same. Safari drops the cookie entirely. Given Firefox's experience with https://bugzilla.mozilla.org/show_bug.cgi?id=1551729 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 Cookie: foo, and update the spec accordingly.

• 0020 sends Set-Cookie: a=b, Set-Cookie: =, and Set-Cookie: c=d. Chromium stores three cookies: ("a", "b"), ("", ""), and ("c", "d"), serialized as Cookie: a=b; ; c=d. Firefox and Safari store two cookies: ("a", "b") and ("c", "d"), serialized as Cookie: a=b; c=d. The latter is clearly correct and matches the spec; filed https://bugs.chromium.org/p/chromium/issues/detail?id=1037996 to change Chromium's behavior.

• 0021 sends Set-Cookie: a=b, Set-Cookie: =x, and Set-Cookie: c=d. Chromium stores three cookies: ("a", "b"), ("", "x"), and ("c", "d"), serialized as Cookie: a=b; x; c=d. Firefox does the same. Safari stores two cookies: ("a", "b") and ("c", "d"), serialized as Cookie: a=b; c=d. If we change 0004 above, then we'd update this test as well to match Chromium and Firefox.

• 0022 sends Set-Cookie: a=b, Set-Cookie: x=, and Set-Cookie: c=d. Chromium stores three cookies: ("a", "b"), ("x", ""), and ("c", "d"), serialized as Cookie: a=b; x=; c=d. Firefox does the same. Safari also stores the same three cookies, but serializes them as Cookie: a=b; c=d; x=. I think this ordering problem is similarly represented in 0016 and 0017, and is something that can be dealt with separately from this issue.

• 0023 sends Set-Cookie: foo and Set-Cookie:. Chromium stores ("", "foo"), and then overwrites it with ("", ""). Firefox stores ("", "foo") and ignores the empty cookie. Safari ignores both (as per 0004 and 0021 above). I think Firefox's behavior is most correct here as a logical consequence of the spec change to fix 0004, and I believe Chromium will match it once the bug filed for 0020 above is addressed.

• 0027 sends Set-Cookie: foo and Set-Cookie: bar. Chromium stores ("", "foo"), and then overwrites it with ("", "bar"). Firefox does the same. Safari ignores both. If we change 0004 as above, then Firefox and Chromium's behavior will match the spec, and the test should be updated.

I'll put up a PR against the spec if folks are on board with the suggestions above.

[mikewest]

Putting together a fix for Chromium's 0020 behavior, I ran into more excitement:

0024 (Set-Cookie: foo, Set-Cookie: =), 0025 (Set-Cookie: foo, Set-Cookie: ; bar), and 0026 (Set-Cookie: foo, Set-Cookie: ) show that Firefox overwrites ("", "foo") with ("", ""), and serializes it as "". 0028 would show the same, but it's incorrect in the WPT repository; it should contain a tab character, and the expectations are simply wrong (also in the original repo).

I'd suggest that this behavior doesn't make much sense, and that it would be better for browsers to align on requiring cookies to have either a name or a value, and to ignore Set-Cookie headers that parse with empty names and empty values.

That would change the expectations for these four tests to expect a serialization of "Cookie: foo".

WDYT, @annevk, @johnwilander?

[mikewest]

For clarity: https://chromium-review.googlesource.com/1982551 shows the test expectations I'd suggest we end up with.

[chlily1]

Tl;dr: I think changing the spec to match current implementations for Set-Cookie: foo to produce Cookie: foo (i.e. 0004 case) makes sense. I think disallowing Set-Cookie: = (0020 case) and Set-Cookie: (0023 case) would make sense too, but that might break things.

In the 0004 case:

We've been parsing Set-Cookie: foo 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 (Set-Cookie: =) and 0023 (empty Set-Cookie) 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.

[mikewest]

Thanks, @chlily1! I agree with you for the 0004 case. @johnwilander, would Apple be willing to change CFNetwork's behavior to match the suggestions above?

For 0020 and 0023:

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...

Looking at the stable channel on for the 28 days ending on Dec 31st, 0.0025% of Cookie 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.

(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.)

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." :)

[annevk]

I'm okay with your proposed changes.

cc @youennf @ddragana @rwlbuis

[mikewest]

#1018 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. :) )

[johnwilander]

Thanks, @chlily1! I agree with you for the 0004 case. @johnwilander, would Apple be willing to change CFNetwork's behavior to match the suggestions above?

I’ve pinged the relevant folks to take a look at this thread. Like me, many won’t be back until Monday.

For 0020 and 0023:

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...

Looking at the stable channel on for the 28 days ending on Dec 31st, 0.0025% of Cookie 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.

(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.)

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." :)

[tunetheweb]

Looking at the stable channel on for the 28 days ending on Dec 31st, 0.0025% of Cookie 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.

Not sure if it's the same thing, but I've seen facebook send an empty set-cookie: header frequently.

For example visiting https://www.theguardian.com/international loads a 1 pixel gif with the following URL: https://www.facebook.com/tr?id=XXXXXXXXXXX&ev=PageView&noscript=1 (replacing XXXX with your unique tracking reference) with the following response headers (note the blank set:cookie: header, third from the bottom):

alt-svc: h3-24=":443"; ma=3600
cache-control: no-cache, must-revalidate, max-age=0
content-length: 44
content-type: image/gif
date: Fri, 03 Jan 2020 15:43:17 GMT
expires: Fri, 03 Jan 2020 15:43:17 GMT
last-modified: Fri, 21 Dec 2012 00:00:01 GMT
server: proxygen
set-cookie: 
status: 200
strict-transport-security: max-age=31536000; includeSubDomains

This then gets set in the Chrome Cookie jar with the following:

I can't seem to find this showing in Firefox's cookie jar (even when turning off the default Enhance Tracking Protection) nor in Safari.

Anyway, I'm sure a good few of us wouldn't care if this "cookie" died a death, or if Chrome changed to ignore this "cookie", and not even sure if it DOES anything (it doesn't seem to be sent in follow up HTTP requests, but that's not to say it's not looked at by some local JavaScript). However, given the prevalence of Facebook tracking I'm really surprised these sorts of cookies are only seen by 0.12% of users so thought I'd comment to note this in case those estimates are not accurate? Perhaps the stats are not picking up these cases?

I've seen this on many sites and only picked the Guardian as a well-known example and guessed first time it would be on there (news sites are good ones to pick when looking for tracking pixel examples!). https://www.wsj.com/ sets the same if you prefer something US based and https://www.theaustralian.com.au/ sets the same (but not on the main domain) for those of you in that side of the world.

[chlily1]

Looking at the stable channel on for the 28 days ending on Dec 31st, 0.0025% of Cookie 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.

The number of 0-byte Cookie headers is only a lower bound on how many no-name-no-value cookies are in use. If such a cookie were sent along with some other cookies, it would not be logged as a 0-byte header. I don't think we have any metrics on per-cookie length, just the total length of the Cookie header. So it might be worth collecting more data?

Also, that metric doesn't include cookies accessed via document.cookie.

[mikewest]

Regarding @bazzadp's comments on Facebook; I pinged someone there who will forward this to the appropriate team. It sounds like a bug to me, and not something that I think should stop us from making a decision here on the underlying question of whether an empty cookie is a thing we should support.

@chlily1: I read your comments above as generally approving of the change suggested in #1018, 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 #159 (comment) above).

The number of 0-byte Cookie headers is only a lower bound on how many no-name-no-value cookies are in use.

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 Cookie 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 a=b; ; c=d to a=b; c=d.

Also, that metric doesn't include cookies accessed via document.cookie.

I think this is the easier case, actually, as the serialization of an empty cookie is indistinguishable from a empty cookie jar.

[tunetheweb]

Regarding @bazzadp's comments on Facebook; I pinged someone there who will forward this to the appropriate team. It sounds like a bug to me, and not something that I think should stop us from making a decision here on the underlying question of whether an empty cookie is a thing we should support.

Thanks for sending on @mikewest . 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?

Maybe a lot less users than I think are getting this cookie but given I’ve spotted it on 3 major news paper sites in 3 distinct countries, without having to look too far for these examples, makes me suspect that is not the case. Other analysis says Facebook assets are being used on 2.38% of the most used 5.7 million sites and I’d guess they all come with some cookies for free. And that stat treats each of those 5.7 million sites equally when actual usage will be heavily skewed to the sites at the top end than the tail so usage will likely be more than that as top end sites are more likely to use Facebook advertising in my opinion. And again, I’m not concerned with this Facebook example - but more that it seems to suggest the 0.12% stat feels wrong.

Or maybe it’s not being included since this empty cookie doesn’t seem to be sent in follow up requests, and that’s what that stat is measuring? If that’s the reason, and we’re comfortable with that explanation and the risks that entails (I am for what it’s worth), then that’s fine, but thought it worth asking the question.

[mikewest]

As @chlily1 notes above, we don't have statistics on cookie size generally; just aggregate numbers on Cookie header length. The "0.12% of users" statistic is the set of users who have ever sent an empty Cookie header (e.g. the only cookie they have for a given request is empty). If nameless/valueless cookies are set for other sites, they'll be serialized as ...; ;..., which we don't track specifically. I noted above that I'm less concerned about this case than I am about the "We used to get a Cookie header, but now we don't get anything at all!" case, but I'm honestly not terribly concerned about either given the existing diversity in the way browsers handle Set-Cookie: =.

[tunetheweb]

OK makes sense. Thanks for answering.

[chlily1]

@chlily1: I read your comments above as generally approving of the change suggested in #1018, but cautious about how to ship it in Chrome?

Yes, that's right.

[johnwilander]

The CFNetwork team approves of the change and is tracking the work in rdar://problem/58358759.

[mikewest]

The CFNetwork team approves of the change and is tracking the work in rdar://problem/58358759.

Given that, I'd suggest that we land something like #1018 along with the tests from https://chromium-review.googlesource.com/c/chromium/src/+/1982551.

Thanks!