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

[Dan Winship <[e-mail]>]

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