JDK-7015981 : java.net.HttpCookie.domainMatches returns false if domain doesn't start with a dot
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 6u23
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-01-31
  • Updated: 2014-03-25
  • Resolved: 2011-06-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 8
6u27 b03Fixed 8Fixed
Description
We believe that the java.net.HttpCookie.domainMatches method does
not work perfectly according RFC 2965.

The following short testcase demonstrates the issue.

$ cat MyCookieDomain.java
public class MyCookieDomain {
    public static void main(String[] args) throws Exception {
        System.out.println(
            java.net.HttpCookie.domainMatches(args[0], args[1]));
    }
}

$ javac MyCookieDomain.java
$ java -showversion MyCookieDomain ajax.com www.ajax.com
java version "1.6.0_23"
Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
Java HotSpot(TM) Server VM (build 19.0-b09, mixed mode)

false


The method returns false for "ajax.com". However, the Javadoc for the 
static domainMatches method even contains an example from RFC 2965:

      *  A Set-Cookie2 with Domain=ajax.com will be accepted, and the
         value for Domain will be taken to be .ajax.com, because a dot
         gets prepended to the value.

See also 
http://download.oracle.com/javase/6/docs/api/java/net/HttpCookie.html#domainMatches%28java.lang.String,%20java.lang.String%29
http://www.ietf.org/rfc/rfc2965.txt

According to the example, we believe that the method should return true
and not false. We believe that for the check, the method should prepend a leading dot
to the domain value if an explicitly specified value does not start with a dot.

Please evaluate.
Comments
EVALUATION Whole implementation of user agent's role is a responsibility of s/w that uses HttpCookie class. (*) According to definition, "user agent is the client which initiates an HTTP request." HttpCookie class doesn't initiate any HTTP request. http://www.ietf.org/rfc/rfc2965.txt 1. TERMINOLOGY The terms user agent, client, server, proxy, origin server, and http_URL have the same meaning as in the HTTP/1.1 specification [RFC2616]. http://www.ietf.org/rfc/rfc2616.txt 1.3 Terminology ... request An HTTP request message, as defined in section 5. ... user agent The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools. ... (**) HttpCookie class has no information to be able to implement user agent's role, e.g. set defaults values to optional attributes that are missing. For instance, HttpCookie class doesn't know what origin server's FQDN name is, hence HttpCookie class can not set default value for missing Domain attribute.
14-05-2011
SUGGESTED FIX remove misleading example from javadoc. - * <li>A Set-Cookie2 with Domain=ajax.com will be accepted, and the - * value for Domain will be taken to be .ajax.com, because a dot - * gets prepended to the value.</li>
26-02-2011
EVALUATION Example from sec. 3.3.2 RFC 2965 (below) misleads and creates a lot of confusion. It has no relation to domainMatches method. * A Set-Cookie2 with Domain=ajax.com will be accepted, and the value for Domain will be taken to be .ajax.com, because a dot gets prepended to the value.
26-02-2011
EVALUATION Definition of domain-match relation (RFC 2965) Host A's name domain-matches host B's if * their host name strings string-compare equal; or * A is a HDN string and has the form NB, where N is a non-empty name string, B has the form .B', and B' is a HDN string. java.net.HttpCookie.domainMatches() method implements this relation correctly. "www.ajax.com" does not domain-match "ajax.com" according to domain-match definition. ****************************** > However, the Javadoc for the static domainMatches method even contains an example from RFC 2965: > > * A Set-Cookie2 with Domain=ajax.com will be accepted, and the > value for Domain will be taken to be .ajax.com, because a dot > gets prepended to the value. This example is from section "3.3.2 Rejecting Cookies". It makes no statement about any domain-match relation. Domain-match relation is a relation between two entities, and the example above concerns only one entity - value of Domain attribute. The purpose of the example is to demonstrate a valid value of Domain attribute for cases when this attribute explicitly presents in the Set-Cookie2 response header. In the same section there is another example that demonstrates values of Domain attribute that are not valid, so such requests should always be rejected, regardless of other conditions * A Set-Cookie2 with Domain=.com or Domain=.com., will always be rejected, because there is no embedded dot. "3.3.2 Rejecting Cookies" section describes the rules that allow user agent to reject ��ookies without further validation. These rules are based on the values of attributes that are explicitly present in the Set-Cookie2 response header. The phrase "A Set-Cookie2 with Domain=ajax.com will be accepted..." in the RFC example might be ambiguous, and it had better say "will not be [immediately] rejected", but outcome of this preliminary checks is to allow or deny further validation and "acceptance" at this stage is not final. ****************************** > According to the example, we believe that the method should return true > and not false. We believe that for the check, the method should prepend a leading dot > to the domain value if an explicitly specified value does not start with a dot. java.net.HttpCookie.domainMatches() method should implement domain-match relation check only, and should not modify any of its arguments. It can be called from different contexts and it should not make any assumption. Below is an example of a domain value that should not start with a dot. Section "3.3.1 Interpreting Set-Cookie2" describes default values for optional attributes, that are missing: Domain Defaults to the effective request-host. (Note that because there is no dot at the beginning of effective request-host, the default Domain can only domain-match itself.) According to "3.2.2 Set-Cookie2 Syntax" section, RFC 2965, it's user agent's responsibility to prepend a leading dot to a domain value if a value explicitly presents without a leading dot in the Set-Cookie2 response header Domain=value OPTIONAL. The value of the Domain attribute specifies the domain for which the cookie is valid. If an explicitly specified value does not start with a dot, the user agent supplies a leading dot. --
11-02-2011