IssueTracker

Summary of enhancement:

The Android implementation of CookieManager / HttpCookie implement the RFC 2965 rules for matching domains, and hence which cookies can be sent in the header of a request for a given URL. It should be changed to implement RFC 6265.

Suggested as part of a discussion on the OkHttp GitHub site: https://github.com/square/okhttp/issues/991

Details:

See
RFC 2965: Section 1 (definition of "domain-match").
and
RFC 6265: Section 5.1.3 and, importantly, also section "4.1.2.3. The Domain Attribute", which suggests that leading "." character should be ignored for the "domain" attribute.

As concluded in the OkHttp discussion, this means that a cookie send from the server with a domain of "foo.com" will match (i.e. be sent to request for) "x.foo.com" with RFC 6265 rules, but not with RFC 2965 rules.

The reasoning in the OkHttp thread is not completely clear and it took some head-scratching to work out how RFC 6265 is supposed to work at all (then I found section 4.1.2.3, which explains it).

As written RFC 6265 says the following (additions in []'s are mine):

   A string [A] domain-matches a given domain string [B] if at least one of the
   following conditions hold:

[R1]  o  The domain string [B] and the string [A] are identical.  (Note that both
         the domain string [B] and the string [A] will have been canonicalized to
         lower case at this point.)

[R2]  o  All of the following conditions hold:

[R2.1]   *  The domain string [B] is a suffix of the string [A].

[R2.2]   *  The last character of the string [A] that is not included in the
            domain string [B] is a %x2E (".") character.
            ["last" in the this case means the character of A with the highest index that is not also found in B]

[R2.3]   *  The string [A] is a host name (i.e., not an IP address).


If you ignore 4.1.2.3, this would mean that:
A = secure.x.com, B = x.com would "domain match" (since the "." in "secure." passes R2.2)
but
A = secure.x.com, B = .x.com would not "domain match" (since "e" in "secure" fails R2.2).

RFC 6265 section 4.1.2.3 suggests that the "." in ".x.com" be ignored. For the implementation, whether section 4.1.2.3 means the "." character should be discarded if present "at the point of receipt", or kept and ignored during matches is unclear to me. I suspect it should be the former. The answer would affect things like getDomain(), setDomain(), toString().

Existing behavior:

Right now, Android does not ignore the "." in ".foo.com" at all and implements rules that are (close to those) defined in RFC 2965. It adds an additional (not-to-spec) rule that permits a cookie with domain that has a leading "." to match against a host without it. e.g. so a ".google.com" cookie will match "google.com". Removing this special case and either ignoring or discarding the leading "." on the domain cookie (as per RFC 6265) would keep the ".google.com" cookie matching "google.com" but also address the OkHttp bug's case.

To be clear: Making this change would mean that Android would begin successfully domain-matching "x.foo.com" for "foo.com", where previously this would have not matched (and was explicitly ruled out by RFC 2965). This appears to be a known difference between RFC 2965 and RFC 6265.

The OkHttp bug affects OkHttp when bundled with an application and the version that is repackaged and bundled with Android since they both use the default CookieHandler / CookieManager.

Other elements of RFC 6265 should probably be considered at the same time, API restrictions permitting...

For example, the "http-only" attribute is partly implemented internally in HttpCookie and the information is retained but it is not currently considered in the internal method HttpCookie.secureMatches() and therefore not considered as part of CookieManager.get(URI, Map)). It probably should be.