How does a browser handle cookie with no path and no domain

Question

I have googled this a lot now and have found conflicting answers. So my question is: how does a browser handle an HTTP cookie that has no domain and no path attributes?

For example this response from server:

200 OK https://example.com/a/b (6047ms) 
Set-Cookie: x-my-cookie=1.0; Max-Age=86400000; Expires=Sun, 05-Jan-2020    08:30:25 GMT

Should the cookie be included when making requests to https://m.example.com/a/b?

What about https://example.com/zzzz?

And https://example.com/a?

And https://example.com/a/b/c?

And https://example.com?

Answer 1

For Set-Cookie without domain attribute, the cookie's domain value is "the origin server". According to RFC6265:

Unless the cookie's attributes indicate otherwise, the cookie is returned only to the origin server (and not, for example, to any subdomains)...If the server omits the Domain attribute, the user agent will return the cookie only to the origin server.

With the following exception:

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 www.example.com as well.

Maybe that's why you found conflicting answers.

---

For Set-Cookie without path attribute, RFC6265 states that:

If the server omits the Path attribute, the user agent will use the "directory" of the request-uri's path component as the default value.

---

For your example, the answer would be:

Should the cookie be included when making requests to https://m.example.com/a/b?

No. Because m.example.com is not the origin server (example.com).

What about https://example.com/zzzz?

No. Because /zzz is not under "directory" /a/b.

And https://example.com/a?

No. Because /a is not under "directory" /a/b.

And https://example.com/a/b/c?

Yes. Because /a/b/c IS under "directory" /a/b.

And https://example.com?

No. Because / is not under "directory" /a/b.

Answer 2

The accepted answer is incorrect in regards to one scenario:

And https://example.com/a?

No. Because /a is not under "directory" /a/b.

If you only care about Internet Explorer, that's true. If you care about the standard and browsers that comply with it, it isn't.

RFC 6265 provides the following algorithm for computing the default cookie path to use when a Path attribute is not present:

The user agent MUST use an algorithm equivalent to the following algorithm to compute the default-path of a cookie:

1. Let uri-path be the path portion of the request-uri if such a portion exists (and empty otherwise). For example, if the request-uri contains just a path (and optional query string), then the uri-path is that path (without the %x3F ("?") character or query string), and if the request-uri contains a full absoluteURI, the uri-path is the path component of that URI.

2. If the uri-path is empty or if the first character of the uri- path is not a %x2F ("/") character, output %x2F ("/") and skip the remaining steps.

3. If the uri-path contains no more than one %x2F ("/") character, output %x2F ("/") and skip the remaining step.

4. Output the characters of the uri-path from the first character up to, but not including, the right-most %x2F ("/").

I've highlighted #4 becuase that's the part that matters. For a cookie set at uri-path /a/b, the "right-most" / is the one before the b. The algorithm says to stop there, hence the default cookie path is /a and therefore the cookie should get sent to https://example.com/a.

But as most web developers know, "should" is one thing and "does" is something else. So I wrote a small web app to test this exact scenario: Will a cookie without an explicit Path attribute that is set at /a/b be sent in requests to /a? Here's my findings (latest browser versions, Windows 10):

Chrome - yes

Firefox - yes

Edge - yes

Internet Explorer - no