5

Am I missing something here or is this a bug in the CookieContainer?

I'm adding 3 cookies to the container and then I call the GetCookieHeader function for 2 urls:

CookieContainer cc = new CookieContainer();

cc.Add(new Cookie("Cookie1", "1", "/a", "test.com"));
cc.Add(new Cookie("Cookie2", "2", "/a/0/", "test.com"));
cc.Add(new Cookie("Cookie3", "3", "/a/1/", "test.com"));

var result1 = cc.GetCookieHeader(new Uri("http://test.com/a/1/list"));
Assert.AreEqual("Cookie3=3; Cookie1=1", result1);

var result2 = cc.GetCookieHeader(new Uri("http://test.com/a/0/list"));
Assert.AreEqual("Cookie2=2; Cookie1=1", result2);

The problem is the last assertion which throws an exception as the returned header is only "Cookie2=2". I don't see any reason why the Cookie1 cookie is omitted there - according to RFC6265 it should return two cookies similar to the first assertion above, shouldn't it?

A couple of remarks:

  • The cookies are all in the container so it's not the adding that's the problem but the GetHeader function.

  • This behaviour stays the same when adding 4, 5 etc. cookies: Only a path matching the last added cookie will include the cookie for the base path!

  • The behaviour changes when removing all "a" in the paths and using only "/", "/0/" and "/1/" as paths for the 3 cookies and "http://test.com/1/list" and "http://test.com/0/list" in the assertion urls). All the assertions then succeed - I would expect the same behaviour with the "a"!

PS: Let me add the relevant part from the spec:

A request-path path-matches a given cookie-path if at least one of the following conditions holds:

- The cookie-path and the request-path are identical.

- The cookie-path is a prefix of the request-path, and the last character of the cookie-path is %x2F ("/").

- The cookie-path is a prefix of the request-path, and the first character of the request-path that is not included in the cookie-path is a %x2F ("/") character.

So to me this is clearly a bug...?

srudin
  • 89
  • 4
  • 2
    I recommend that you simplify the test by deleting unnecessary stuff. It is hard to see what you mean. – usr Nov 18 '14 at 20:57
  • I tried to divide the code on some more lines in order to make it more readable. But there's nothing unnecessary in it so I cannot delete anything. – srudin Nov 18 '14 at 21:08
  • 2
    Shorten the URLs and names. Delete the JSESSIONID cookie. At the moment readers must find a 1-bit difference between URLs... – usr Nov 18 '14 at 21:11
  • Ok, I tried to narrow it down and simplified the example - but as you can see the paths are part of the problem and the first cookie missing is the very problem. – srudin Nov 18 '14 at 21:35
  • 1
    possible duplicate of [CookieContainer handling of paths (Who ate my cookie?)](http://stackoverflow.com/questions/3716144/cookiecontainer-handling-of-paths-who-ate-my-cookie) -- in short: yes, this is a bug. – Jeroen Mostert Nov 18 '14 at 22:46

1 Answers1

2

I believe I found the problem. In the System.Net.CookieContainer class in function InternalGetCookies(Uri) around lines 700-730 there's an iteration over the paths. After the first path is found, those cookies are added and the iteration is then breaked and only the values for "/" are additionally being added!

In other words: You only get the cookies from the first matching path and those from "/". To me this is a clear misbehaviour and therefore a bug - or I don't understand the RFC I mentioned above.

srudin
  • 89
  • 4
  • Thanks Jeroen - didn't found this post. Yes, it's very likely to be the same. I'll therefore close this one. – srudin Nov 18 '14 at 23:03