net/http/cookiejar: Domain matching against IP address #12610
Comments
The situation is not really simple: RFC 6265 is not clear whether to allow or deny The current implementation in Chromium rejects domain cookies in IP addresses My gut feeling is that cookies with an IP address as the domain-attribute should be RFC 6265 is not really clear here. I read the following
RFC 6265 section 5.1.3, second bullet, third star [7] as a definition of host name in Therefore my understanding of the algorithm to produce a canonicalized host name
RFC 6265 section 5.1.2 step 1 [8] is that an IP address does not qualify as a
and the cookie should be dropped as it is done currently. [1] go/src/net/http/cookiejar/jar.go Lines 447 to 452 in 7f0be1f [2] https://code.google.com/p/chromium/issues/detail?id=3699 [3] https://codereview.chromium.org/18657/diff/1/net/base/cookie_monster_unittest.cc [4] https://bugzilla.mozilla.org/show_bug.cgi?id=125344 [5] http://src.chromium.org/viewvc/chrome/trunk/src/net/cookies/cookie_store_unittest.h [6] https://hg.mozilla.org/mozilla-central/file/3e8dde8f8c17/netwerk/cookie/nsCookieService.cpp#l3502 [7] http://tools.ietf.org/html/rfc6265#section-5.1.3 |
The Chromium test case you linked as [5] shows that Chromium allows a cookie to be set with a domain attribute if that attribute is an exact match (L470-L472 in the same file).
The third star is so that suffix matching is only applied on host names. 5.1.3 also states that if the two strings matches each other exactly, they domain-match. Regarding RFC6265 5.3:
If I visit the URL http://127.0.0.1/ in my browser, it is my understanding that "the canonicalized request-host" is "127.0.0.1". If the domain-attribute in the Set-Cookie header is set to 127.0.0.1, the canonicalized request-host domain-matches the domain-attribute under the rules of 5.1.3 (exact match). |
The comment in the Chromium test case is interesting: "This matches IE/Firefox, even though it seems a bit wrong." Maybe that behaviour is wrong. One more from the Chromium test case: Chromium treats As I said RFC 6265 is not clear here. I think silently converting the domain cookie to a host cookie is okay, but I do not think that domain cookies on IP addresses make sense at all. Would you have time to test the behaviour on Chrome, FF, IE, Safari and curl? I thinks showing that all these "browsers" handle domain attributes equal to the request IP address the same would add considerable weight to the proposed change. |
For the following web service:
curl 7.40.0 sets the cookie "foo" for 127.0.0.1 I will be able to test IE, Safari in the beginning of next week. |
Safari 9.0 (11601.1.56) sets the cookie "foo" for 127.0.0.1 for the previously mentioned test case. *: Added Expires attribute to make sure a persistent cookie file was created in "Temporary Internet Files". |
This certainly makes it challenging to use |
Having spent some time working out why a Go test behaved differently to a browser test, I ended up at this discussion. Even after following the referenced links, I find the argument for the current behavior to be unconvincing. RFC 6265 section 5.1.3 states that there is a match if "the domain string and the string are identical". The only way to make this exclude IP addresses is to infer a definition of the term "string" to mean "host name (i.e., not an IP address)". But if "string" is defined this way for the entire section, then why would the RFC need these exact words as a requirement of the alternative branch? It would be tautological. Combined with the other evidence that browsers do support exact matches on IP addresses (the Chromium tests, Firefox code, and the last comment by @sebcat), my opinion is that this should be fixed in the Go library. |
Hello,
The following test fails:
Further inspection shows that it fails with errNoHostname here:
go/src/net/http/cookiejar/jar.go
Lines 447 to 452 in 7f0be1f
I believe the comment refers to RFC6265 5.1.3. It states that the domain string must either be identical with the string it's matched against, OR that all of the three subsequently listed conditions are met, one of which are that the string being matched must be a host name.
In the case of the matched string being an IP address and the domain string being the same IP address, the first condition is met. I therefor believe that L447-L452 should be removed.
The text was updated successfully, but these errors were encountered: