Subject: [http-state] nameless valueless cookies, and http vs javascript

From: Dan Winship <[email-masked]>
Date: Tue, 01 Dec 2009 16:59:07 -0500

The spec allows for a cookie in Set-Cookie to have both a 0-length name
and a 0-length value (which can be expressed as either "Set-Cookie: " or
"Set-Cookie: ="). Later it says that:

   the user agent SHOULD attach exactly one HTTP header named Cookie if
   the cookie-string (defined below) for that URI is non-empty.

But this is not quite right, because it would imply that if you had an
"empty" cookie and also some non-empty cookies, that you *would* emit
the empty cookie as well. Eg:

    test:
      Set-Cookie: a=b
      Set-Cookie: =
      Set-Cookie: c=d

    expected:
      Cookie: a=b; ; c=d

but Firefox outputs "Cookie: a=b; c=d". Assuming other browsers behave
the same, we need to add something like "either the cookie name or
cookie value or both is non-empty" to the cookie-list requirements in
5.3 part 1. (And then perhaps change the "cookie-string is non-empty"
rule to "cookie-list is non-empty".)

Another issue: we test that "Set-Cookie: =" and "Set-Cookie: " don't
cause cookies to be emitted, but we don't test how they interact with
previous Set-Cookies. The current rules suggest:

    test:
      Set-Cookie: foo
      Set-Cookie:

    expected:
      (empty)

and

    test:
      Set-Cookie: foo
      Set-Cookie: =

    expected:
      (empty)

Firefox gives the expected answer on the second one, but gives "Cookie:
foo" on the first, suggesting that it just completely ignores the blank
Set-Cookie header. However, if you do it in JavaScript, you get the
expected answer either way:

      >>> document.cookie="foo"
      >>> document.cookie
      "foo"
      >>> document.cookie=""
      >>> document.cookie
      ""

The fact that this works this way in javascript is intentional
(https://bugzilla.mozilla.org/show_bug.cgi?id=169091#c16). I'm not sure
if the different behavior via HTTP is intentional or not.

-- Dan

---

From: Adam Barth <[email-masked]>
Date: Sat, 5 Dec 2009 18:10:00 -0800

These are great cases.  Thanks.  (dwitte, there's a question for you
at the bottom.)

> rule to "cookie-list is non-empty".)

Here's how some browser behave:

Test Case 0020:

Set-Cookie: a=b
Set-Cookie: =
Set-Cookie: c=d

Internet Explorer, Firefox, Safari, Opera: a=b; c=d
Chrome: a=b; ; c=d

It seems clear we should do as you suggest and spec the
IE/Firefox/Safari/Opera behavior.  I've add two more tests (0021 and
0022) that show the cookie is elided only when it would be represented
by the empty string.

Given the considerations below, I've left the empty/empty cookie in
the model of the state store, but elided it during serialization.

> previous Set-Cookies. The current rules suggest:

Now test 0023

>      (empty)

Now test 0024

> Set-Cookie header.

Here's the compatibility matrix:

0023:
(empty): Internet Explorer, Safari,
foo: Firefox, Chrome

0024:
(empty): Internet Explorer, Firefox, Safari, Chrome

> However, if you do it in JavaScript, you get the
>      >>> document.cookie="foo"
>      >>> document.cookie
>      "foo"
>      >>> document.cookie=""
>      >>> document.cookie
>      ""
>

Interesting.  It's clear we have the right behavior for 0024 because
everyone agrees.  I don't have a strong opinion about what to do with
0023.

dwitte, what do you think?

Adam