curl-library
Re: Incorrect handling of subdomain cookies.
Date: Wed, 28 Sep 2016 03:23:40 -0700
I've checked bunch of browsers:
1. Cookies are empty
2. Open http://httpbin.org/response-headers?Set-Cookie=%20foo=
bar;%20domain=.httpbin.org&Set-Cookie=%20foo=qux;
3. Check two cookies are set in browser with corresponding domains (.
httpbin.org and httpbin.org)
4. Open http://httpbin.org/get
5. Check in dev-tools what is sent to server
6. Retry http://httpbin.org/response-headers?Set-Cookie=%20foo=
qux;&Set-Cookie=%20foo=bar;%20domain=.httpbin.org
Note what http://httpbin.org/cookies returns just one value per cookie.
1. Chrome (53.0.2785.116 (64-bit)), Mac OS.
3) Confirmed 4) "Cookie": "foo=bar; foo=qux" is sent. 6) Cookies
are sent FIFO order: "Cookie": "foo=qux; foo=bar"
2. Opera 39.0.
3) Confirmed 4) Same as Chrome. Expected as same engine is used. 6)
Same as Chrome
3. Safari 10.0 (10602.1.50.0.10)
3) Confirmed 4) Same as Chrome. 6) Cookies are sorted. "Cookie":
"foo=bar; foo=qux"
4. Firefox 45.0.2.
3) Confirmed 4) Same as Chrome 6) Same as Chrome
5. Edge 38.14393.0.0, EdgeHTML 14.14393
3) Single cookie stored in browser: foo=qux, .httpbin.org 4) "Cookie":
"foo=qux" 6) Single cookie stored in browser: foo=bar; domain=.httpbin.org
Sent as "Cookie": "foo=bar";
Extra checks for Edge:
http://httpbin.org/response-headers?Set-Cookie=%20foo=bar;%20domain=.
httpbin.org&Set-Cookie=%20foo=qux;%20domain=httpbin.org => foo=qux; domain:
.httpbin.org
http://httpbin.org/response-headers?Set-Cookie=%20foo=qux;%20domain=
httpbin.org&Set-Cookie=%20foo=bar;%20domain=.httpbin.org => foo=bar;
domain: .httpbin.org
Sergei
On Tue, Sep 27, 2016 at 11:27 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Tue, 27 Sep 2016, Sergei Kuzmin wrote:
>
> Thanks for extensive explanation. What do you thing would be the best? Is
>> it asking IETF for comment? Eventually it would be nice to match browsers
>> behavior but not at expense of missing RFC guidelines. It's unclear whether
>> to fix curl or major browsers.
>>
>
> The httpwg in the IETF will probably soon work on a "6265bis" document,
> that is a revision and update of the RFC 6265 that we made a few years
> back[1]. This, to make it more accurately describe how cookies are de-facto
> used in the real world. Even if we didn't manage it 100% with RFC 6265, it
> was still the first cookie spec that was close to describing how cookies
> work on the web. (And those old enough may remember me struggling against
> specifying some of the browser behaviors as mandated[2].)
>
> Web browsers will not change behavior due to RFC contents if they
> think/know other browsers do it that way - web compatibility trumps
> basically anything. I'd say it is much more likely that an updated spec
> will use wording that makes the current browser behaviors compliant. Of
> course this is my guess based on my many years working in the httpwg and
> with the browser people.
>
> If there is more than one browser that works that way, it is best to just
> admit defeat and switch over to behave like that...
>
> [1] = https://daniel.haxx.se/blog/2011/04/28/the-cookie-rfc-6265/
> [2] = https://daniel.haxx.se/blog/2010/01/20/cookie-order/
>
> --
>
> / daniel.haxx.se
>
> -------------------------------------------------------------------
> List admin: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette: https://curl.haxx.se/mail/etiquette.html
>
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-09-28