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

[Adam Barth <[e-mail]>]

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

On Tue, Dec 1, 2009 at 1:59 PM, Dan Winship <[e-mail]> wrote:
> 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".)

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.

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

Now test 0023

> and
>
>    test:
>      Set-Cookie: foo
>      Set-Cookie: =
>
>    expected:
>      (empty)

Now test 0024

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

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

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