Select Page

Leading Dots On HTTP Cookie Domains Ignored

Cyberdime
Published: October 29, 2022

I’ve been using Cookies in my ColdFusion web applications forever. But, I honestly don’t have the best mental model for how the low-level intricacies of cookies work. For most of my career, I only ever defined cookies using a “name”, “value”, and an “expires” attributes — I didn’t even know you could define a “domain” until we had to start locking down enterprise-cookies (by subdomain) at InVision. And even now, I’m still fuzzy on how the domain setting operates; which is why something caught my eye when I was reading through the Set-Cookie HTTP header docs on MDN:

Domain=<domain-value>

Defines the host to which the cookie will be sent. If omitted, this attribute defaults to the host of the current document URL, not including subdomains. Contrary to earlier specifications, leading dots in domain names (.example.com) are ignored. Multiple host/domain values are not allowed, but if a domain is specified, then subdomains are always included.

At work, we definitely have code that sets and expires cookies using a leading dot (.); but, it seems like this appendage may be superfluous. To test this, I wanted to look at whether or not domains with-and-without a leading dot are interoperable.

First, I tried setting a cookie with a leading dot:

<cfscript>
	// Using a leading-dot on the cookie domain to STORE the cookie.
	cookie[ "hello" ] = {
		domain: ".local.invisionapp.com",
		value: "world",
		preserveCase: true,
		expires: "never"
	};
</cfscript>

And, when we run this Luce CFML / ColdFusion code, we can see that the cookie is set:

EditThisCookie Chrome extension showing cookie domain set with leading dot.

As you can see, the domain in my EditThisCookie Chrome extension show the leading dot. But now, let’s try to delete (expire) this cookie using a domain with no leading dot:

<cfscript>
	// Using NO leading-dot on the cookie domain to DELETE the cookie.
	cookie[ "hello" ] = {
		domain: "local.invisionapp.com",
		value: "",
		preserveCase: true,
		expires: "now" // Expire the cookie.
	};
</cfscript>

Here, we’re using the same domain, only we’re omitting the leading dot. And, when we run this Lucee CFML / ColdFusion code, we can see that the cookie has been removed!

EditThisCookie Chrome extension showing cookie was removed even though we expired a cookie without a leading dot.

As you can see, the cookie was successfully evicted when we expired the cookie using a domain without a leading dot.

I also tried this in the other direction as well:

  1. Set the cookie without a leading dot.

  2. Expire the cookie with a leading dot.

And, the results are the same. The interoperability goes in both directions. Which makes sense if you take the MDN at their word: that the leading dot gets ignored.

It’s somewhat ironic that cookies are such a fundamental part of how web applications work; and yet, after so many years, I’m still building out my mental model for how cookies interact with my ColdFusion applications.

Check out the license.

Source: www.bennadel.com