GNOME Bugzilla – Bug 577360
SoupCookieJar does not save two cookies with same name but different path
Last modified: 2009-04-03 14:18:37 UTC
Please describe the problem: here is a part of network debugging from midori: < Set-Cookie: JSESSIONID=5BCBB26D886B3F902B461B268ED610C7; Path=/ < Set-Cookie: JSESSIONID=5BCBB26D886B3F902B461B268ED610C7; Expires=Sat, 27-Jun-2048 19:06:48 GMT; Path=/wiki here is a part of rfc http://www.w3.org/Protocols/rfc2109/rfc2109 4.3.2 Rejecting Cookies To prevent possible security or privacy violations, a user agent rejects a cookie (shall not store its information) if any of the following is true: * The value for the Path attribute is not a prefix of the request- URI. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
what is see in cookies.txt: $ cat cookies.txt|grep JS www.linux.org.ru FALSE /wiki FALSE 1241039000 JSESSIONID 2B2C48D59C87880AC376ADE7F0821731 while i just acceessed http://linux.org.ru/ and i was never redirected to /wiki/. This behavior completely breaks site work with webkit-gtk browsers.
First off, RFC 2109 has absolutely nothing to do with anything. The original cookie spec can be found here: http://web.archive.org/web/20080205173011/http://wp.netscape.com/newsref/std/cookie_spec.html but that's not really accurate either. The only thing that defines the way that cookies work is looking at what the major browsers do, and then copying them. I tried checking what Firefox does in this situation, but when I click on that link, it doesn't send me any cookies with Path=/wiki, so Firefox doesn't even have the chance to accept them. However, looking at the firefox source code, we see: #if 0 } else { /** * The following test is part of the RFC2109 spec. Loosely speaking, it says that a site * cannot set a cookie for a path that it is not on. See bug 155083. However this patch * broke several sites -- nordea (bug 155768) and citibank (bug 156725). So this test has * been disabled, unless we can evangelize these sites. */ // get path from aHostURI nsCAutoString pathFromURI; if (NS_FAILED(aHostURI->GetPath(pathFromURI)) || !StringBeginsWith(pathFromURI, aCookieAttributes.path)) { return PR_FALSE; } #endif (bugzilla is going to linkify those bug references, but they're actually referring to bugzilla.mozilla.org bugs). So AFAICT, libsoup's behavior here matches Firefox's, and presumably that of the other major browsers as well. Is there some specific problem you are seeing that you believe to be caused by this behavior?
first of all issue im talking about happens on http://linux.org.ru site after login. Once im logged to this page im getting two set-cookie requests: Set-Cookie: JSESSIONID=5BCBB26D886B3F902B461B268ED610C7; Path=/ Set-Cookie: JSESSIONID=5BCBB26D886B3F902B461B268ED610C7; Expires=Sat, 27-Jun-2048 19:06:48 GMT; Path=/wiki in cookies.txt JSESSIONID is only defined for /wiki directory. However, script to post comments http://linux.org.ru/add_comment.jsp returns an error once JSESSIONID cookie is not set. Once im rewriting /wiki to / path for this cookie in cookies.txt -- script starts to work. Thing is that even qtwebkit doesnt has this issue. So seems that only libsoup is acting different in this case.
oh... gotcha. the bug is that libsoup is receiving two cookies (/ and /wiki) but only keeping one of them (/wiki)
kind of. But note, two cookies have the same body, same sessionid. can we consider this as two different cookies? Probably thats an update for existing one?
Created attachment 131962 [details] [review] fix can you try this patch?
it works. Comments started to work. $ grep JSESSIONID .config/midori/cookies.txt .linux.org.ru TRUE / FALSE 1241275661 JSESSIONID 8E48EEDE8B4D3A168D56BFF00083DCEA www.linux.org.ru FALSE /wiki FALSE 1241318470 JSESSIONID FEEB8F0DCE4DCADACE79EDF3E4CC3F49
fixed in trunk, will be in 2.26.1 (April 15th). Thanks for the detailed bug report, sorry it took me a few tries to figure out what you meant. :)