A web framework's cookie helper triple-sets a cookie with different Domain= like so, and no one remembers why.
Set-Cookie: x=y; Path=/
Set-Cookie: x=y; Path=/; Domain=example.org
Set-Cookie: x=y; Path=/; Domain=.example.org
Why set the same cookie three times with different Domain=? Is this a workaround for a now-irrelevant browser bug and can be simplified, or is it still needed today?
i'm guessing it's done as a convenience to handle "www" and non-www host names within the same session...
the first cookies domain will default to the "current host name" which might be "www.example.org". since it's pretty common for sites to be accessible with or without the www subdomain, the third cookie makes this work seamlessly when a session happens to cross both host names (some load balancing / caching schemes might use a cache.example.org or www2 or something). perhaps a reasonable default, but could cause some security issues theoretically...
i'm guessing the third cookie is used because the second would be rejected by UAs that conform to the letter of the netscape spec - cookie domains in the org tld must have at least 2 dots in them...
Any domain that fails within one of the seven special top level domains listed below only require two periods. Any other domain requires at least three. The seven special top level domains are: "COM", "EDU", "NET", "ORG", "GOV", "MIL", and "INT".
http://web.archive.org/web/20070805052634/http://wp.netscape.com/newsref/std/cookie_spec.html