Cookieless setting for non-www domain

If you do that, then login at yourdomain.com/wp-admin

The cookie (apparently) will be writ JUST for yourdomain.com … which is surprising news to me!

Ron: I would want to test that in multiple browsers, because the latest spec (RFC 6265) actually says otherwise.

5.1.3. Domain Matching

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

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

o All of the following conditions hold:

* The domain string is a suffix of the string.

* The last character of the string that is not included in the
domain string is a %x2E (“.”) character.

* The string is a host name (i.e., not an IP address).

In other words, if I define a cookie at example.com, then go to https://www.example.com, then the following holds:

– The domain string (example.com) is a suffix of https://www.example.com. Check.
– The last character of the string not in the domain string (example.com) is a period. Check.
– The string is a hostname. Check.

So https://www.example.com *should* receive the cookie. Some browsers may or may not do this.

The latest spec may or may not be valid in browsers, I admit. Previous specs that specified a dot at the beginning of the domain string for subdomains are not the case anymore. In fact, having a dot at the front of the domain is actually invalid, but ignored.

4.1.2.3. The Domain Attribute

The Domain attribute specifies those hosts to which the cookie will
be sent. For example, if the value of the Domain attribute is
“example.com”, the user agent will include the cookie in the Cookie
header when making HTTP requests to example.com, https://www.example.com, and
https://www.corp.example.com. (Note that a leading %x2E (“.”), if present,
is ignored even though that character is not permitted, but a
trailing %x2E (“.”), if present, will cause the user agent to ignore
the attribute.) If the server omits the Domain attribute, the user
agent will return the cookie only to the origin server.

WARNING: Some existing user agents treat an absent Domain
attribute as if the Domain attribute were present and contained
the current host name. For example, if example.com returns a Set-
Cookie header without a Domain attribute, these user agents will
erroneously send the cookie to https://www.example.com as well.

This has become very interesting and very useful discussion indeed, and I want to share with you guys the interesting part of my research.

1) I moved just the DNS hosting elsewhere, (CloudFlare for free), separate from the host.
2) By doing so, sometimes (not always) the images are served from one IP and the contents from another IP, something similar to CDN, which is at the mercy of DNS hosting provider.
3) I have my images at images.mysite.com and my main site is a non-www.
4) I removed the code define('COOKIE_DOMAIN', 'www.yoursite.com'); from my wp-config.php, and I have nothing defining about the cookies there now.
5) At the backend, I am able to log in to my admin panel.
6) At the front end, just for the first view cookies are getting created for the images and from the second view onwards cookies are not getting created for the images.
7) I tested this using Firefox/Firebug.

Seems to be an amicable solution. Just to make it sure again with you coders a quick question: Am I becoming cookieless at the mercy of my DNS host or is it because of something that I messed up? What are your comments?