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:
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
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.
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.
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>
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.
The terms user agent, client, server, proxy, origin server, and
http_URL have the same meaning as in the HTTP/1.1 specification
An HTTP request message, as defined in section 5.
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.