United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7015981 java.net.HttpCookie.domainMatches returns false if domain doesn't start with a dot
JDK-7015981 : java.net.HttpCookie.domainMatches returns false if domain doesn't start with a dot

Details
Type:
Bug
Submit Date:
2011-01-31
Status:
Closed
Updated Date:
2011-06-21
Project Name:
JDK
Resolved Date:
2011-06-08
Component:
core-libs
OS:
generic
Sub-Component:
java.net
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u23
Fixed Versions:
6u27 (b03)

Related Reports
Backport:

Sub Tasks

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

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.
--
                                     
2011-02-11
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.
                                     
2011-02-26
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>
                                     
2011-02-26
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.
                                     
2011-05-14



Hardware and Software, Engineered to Work Together