Subject: RFC6265bis status

From: Mark Nottingham <[email-masked]>
Date: Wed, 5 Oct 2016 13:21:20 +1100

So far, we've adopted the following draft proposals for changing the Cookie specification:

- Leave Secure Cookies Alone
- Cookie Prefixes
- Same-Site Cookies

In Berlin, we discussed "Cookie Priorities" and "EAT Cookies"; in that room, there was only support for adopting the latter.

Therefore, absent any pushback on the list (now is your opportunity!), we'll consider <https://tools.ietf.org/html/draft-thomson-http-omnomnom> as adopted for the RFC6265bis effort. 

As discussed in Berlin, that doesn't mean that the draft will appear in the final work product verbatim (as with all of the draft proposals); only that it's in-scope for discussion.

It seems like we're at a point where we can start incorporating the draft proposals into a complete document, so that we can see how it works as a whole, identify any remaining issues, and discuss them (along with the outstanding ones; see <https://github.com/httpwg/http-extensions/issues?q=is%3Aopen+is%3Aissue+label%3A6265bis>).

Mike West has graciously agreed to edit the document, and should soon be publishing a -00 draft with minimal changes from 6265 as a starting point for further work.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 5 Oct 2016 07:59:03 +0200 (CEST)

On Wed, 5 Oct 2016, Mark Nottingham wrote:

> It seems like we're at a point where we can start incorporating the draft 
> proposals into a complete document, so that we can see how it works as a 
> whole, identify any remaining issues, and discuss them

We ran into an interesting cookie issue the other day in curl. Namely how to 
deal with two otherwise identically named cookies where the domain property 
differs only in a leading dot or not:

   https://curl.haxx.se/mail/lib-2016-09/0103.html

The two points being:
  1 - Are they two cookies or one?
  2 - In which order should they be sent by the client if two.

A revised spec should probably detail this too so that browsers (and others) 
will align.

-- 

  / daniel.haxx.se

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 5 Oct 2016 08:22:18 +0200 (CEST)

On Tue, 4 Oct 2016, Jim Manico wrote:

> If I may, why not allow multiple cookies per domain with the •same name• but 
> different values? This is already the case with request parameters in order 
> to support multi-select lists, why not cookies for similar use cases?

Note that these cookies I showed were set by the exact same domain and path, 
only with different domain properties (and only the leading dot changed) - so 
clearly Chrome and Firefox agree on how to deal with them while Edge and 
Safari have their own ideas. I don't see how them having different values 
would make anything different.

Multiple cookies could always be set for different paths on the same domain 
without problems.

-- 

  / daniel.haxx.se

---

From: Daniel Veditz <[email-masked]>
Date: Wed, 5 Oct 2016 10:05:36 -0700

​On Tue, Oct 4, 2016 at 10:59 PM, Daniel Stenberg <[email-masked]> wrote:

>  1 - Are they two cookies or one?

​Those are clearly two different cookies. The one set without a domain is a
"host" cookie and will only be returned to httpbin.org. The one with the .
httpbin.org domain would also be returned to www.httpbin.org,
foo.httpbin.org, etc.

-
​Dan Veditz​

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 6 Oct 2016 06:43:29 +1000

On 6 October 2016 at 03:05, Daniel Veditz <[email-masked]> wrote:

> ​Those are clearly two different cookies. The one set without a domain is
> a "host" cookie and will only be returned to httpbin.org. The one with
> the .httpbin.org domain would also be returned to www.httpbin.org,
> foo.httpbin.org, etc.
>
>
​But you can make them both domain cookies:
http://httpbin.org/response-headers?Set-Cookie=foo=bar;domain=.httpbin.org&Set-Cookie=foo=qux;domain=httpbin.org

... which then, presumably, makes them identical, so it's the usual
last-one-wins? That seems to be how the httpbin.org server treats it,
anyway.

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 6 Oct 2016 08:25:33 +1000

On 6 October 2016 at 08:12, Jim Manico <[email-masked]> wrote:

> I think this is bad behavior. If multiple cookies from the same domain
> have the same name yet different values, I think all values should all be
> returned. This suggested behavior is also how get parameters work in order
> to support multi-select lists.
>
>
​But that's how you update cookies. Doesn't matter if it's in a single
request, or subsequently; sending set-cookie with the same name (and other
attributes) and a new value overwrites the old cookie.

In this case it's just confirming that "domain=.example.org" is treated the
same as "domain=example.org"

(Before I should have said: that seems to be how Chrome treats it, since
httpbin.org isn't storing any state)

Cheers

---

From: Daniel Veditz <[email-masked]>
Date: Wed, 5 Oct 2016 15:36:15 -0700

> to support multi-select lists.

​A browser considers name-domain-path a unique cookie. if a server sends
two cookies with the same name-domain-path then it's really setting and
then updating the same cookie from the browser's POV. The browser cannot
return both values because it has forgotten the first.