A leading dot is added to the domain of the cookies without a subdomain

[ziadloo]

Describe the bug
A leading dot . is added to the beginning of the domain for cookies set without any subdomain.

To Reproduce
Steps to reproduce the behavior:

1. Send a request (in my case I sent a POST) to a URL that returns Set-Cookie: name=value; path=/; domain=example.com; expires=Sat, 11 Jan 2020 00:00:00 GMT; in its response headers (example.com is the same domain as your URL).
2. Take a look at the cookies set in the MANAGE COOKIES page. The cookie will read: name=value; path=/; domain=.example.com; expires=Sat, 11 Jan 2020 00:00:00 GMT;. To make sure it was not missed, the problem is the leading . added to the beginning of the domain. This will prevent the cookie from being sent alongside the request if the URL points to a subdomain like www.example.com.

Expected behavior
I was expecting the cookie to be set with the same exact domain and as a result, it should be sent to example.com and all its subdomains.

App information (please complete the following information):

• App Type: Native App
• Postman Version: v7.15.0
• OS: Kubuntu 18.04
• Postman Interceptor: v0.2.28

Additional context
Of course, you'll need the Interceptor properly set up to work with cookies.

[codenirvana]

@ziadloo The leading dot signifies that the cookie will be used for subdomains as well.

As in your example, having domain=example.com means that the cookie name will be used for every subdomain of example.com.

Whereas, with Set-Cookie: name=value; path=/; makes the cookie HostOnly and will only be used for the requesting hostname.

Your expected behavior persists.

[ziadloo]

Thanks @codenirvana but I'm not sure what was misunderstood here so I'll try to explain it once more.

When I send back a set-cookie response header to Postman without a . before the domain name (e.g. example.com), Postman will create a cookie with the . (e.g. .example.com). In other words, Postman does not support cookies that should be sent to all the subdomains (because Postman automatically adds a . to the beginning of the domain).

I believe that should be considered a bug. Please let me know if I can help in any way.

[codenirvana]

Postman does not support cookies that should be sent to all the subdomains (because Postman automatically adds a . to the beginning of the domain).

So I set up example.dev which responds with Set-Cookie: Cookie_1=value1; path=/; domain=example.dev;.

I see a leading dot added in the manage cookie modal.

Next, I request to a subdomaintest.example.dev and the cookie set in example.dev is sent correctly.

[ziadloo]

To be honest, it's been a while since I posted this message and I don't recall if I tested to see if the cookie was actually sent after I saw the leading . or not. I will definitely test it as soon as I get the chance. But even if it is sent (pending verification), then the problem is that:

Postman does not support cookies that should not be sent to all the subdomain. These are the cookies that the domain part starts with a ..

In any case, something's wrong here. The leading . should not be added and if it exists (for whatever reason), the cookie should not be sent.

[shamasis]

Host only cookies, @ziadloo, has a separate flag called - hostOnly (very creative!!) https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/cookies/Cookie

Edit: My bad ... I read the doc and jumped the gun! 🤦🏼‍♂️ The hostOnly is inferred from the domain. Let’s test out if hostOnly is possible and then take this up accordingly.

Cookie string is a messy thing to manage and the defaults we use are generally useful for majority of users. At this point of time, we would not like to change the behaviour. We would give this a shot when we work on a more managed cookie manager!

[codenirvana]

To be honest, it's been a while since I posted this message and I don't recall if I tested to see if the cookie was actually sent after I saw the leading . or not. I will definitely test it as soon as I get the chance.

Sure, no issues 👍

Postman does not support cookies that should not be sent to all the subdomain. These are the cookies that the domain part starts with a ..

As mentioned in #7901 (comment), remove the domain part from the set-cookie string and the cookie becomes hostOnly (not sent for subdomains) and the leading dot is also gets removed.

Finally, I would like to clarify a few doubts regarding the leading dot in the saved cookie domain.

1. If a domain is specified in Set-Cookie, subdomains are always included
2. There's a difference in Set-Cookie string format and it's corresponding stored cookie string
3. A cookie is a host-only cookie when the request's host exactly matches the domain of the cookie (i.e, not sent for subdomain)
4. There's no flag called hostOnly in the cookie string
5. So, the domain part is used to infer that. where leading dot signifies not hostOnly
6. Every client (and browsers) uses this leading dot semantics to infer hostOnly or not

Closing this issue since the cookies are working as expected. Feel free to reopen if the issue persists.