Return to Answer

Before worrying about why it happens, you may want to consider whether it's actually a problem for you. It seems to be that having a leading dot shouldn't be affecting cookie behaviour in the browser.

The leading dot means that the cookie is valid for subdomains as well. RFC 6265 Section 4.1.2.3 defines this as so modern browsers should ignore leading dots if you're on the base domain.

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, www.example.com, and 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.)

EDIT:

I've done a little bit of testing and it looks as though Magento wasn't actually sending the cookie domain with a leading dot as the Set-Cookie header by default, so this points the issue towards being browser behavious and how it handles the Set-Cookie headers.

Chrome dev tools network inspector:

Chrome dev tools cookie list:

I suspect that the cookies you seen without the leading dot are from cookies assigned by JS functions, rather than a Set-Cookie header.

EDIT 2:

As you mentioned in the comments below, the JS function PHP function for the cookie JS here does look like it adds the leading dot to the domain when the form_key is instantiated here, though any further communications with that form_key have the leading dot stripped in the headers too.

This could be a core bug, or it could be a configuration issue (I'm more inclined to think the former of the two)

Before worrying about why it happens, you may want to consider whether it's actually a problem for you. It seems to be that having a leading dot shouldn't be affecting cookie behaviour in the browser.

The leading dot means that the cookie is valid for subdomains as well. RFC 6265 Section 4.1.2.3 defines this as so modern browsers should ignore leading dots if you're on the base domain.

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, www.example.com, and 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.)

EDIT:

I've done a little bit of testing and it looks as though Magento wasn't actually sending the cookie domain with a leading dot as the Set-Cookie header by default, so this points the issue towards being browser behavious and how it handles the Set-Cookie headers.

Chrome dev tools network inspector:

Chrome dev tools cookie list:

I suspect that the cookies you seen without the leading dot are from cookies assigned by JS functions, rather than a Set-Cookie header.

EDIT 2:

As you mentioned in the comments below, the JS function PHP function for the cookie JS here does look like it adds the leading dot to the domain when the form_key is instantiated here, though any further communications with that form_key have the leading dot stripped in the headers too.

This could be a core bug, or it could be a configuration issue (I'm more inclined to think the former of the two)

Before worrying about why it happens, you may want to consider whether it's actually a problem for you. It seems to be that having a leading dot shouldn't be affecting cookie behaviour in the browser.

The leading dot means that the cookie is valid for subdomains as well. RFC 6265 Section 4.1.2.3 defines this as so modern browsers should ignore leading dots if you're on the base domain.

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, www.example.com, and 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.)

EDIT:

I've done a little bit of testing and it looks as though Magento wasn't actually sending the cookie domain with a leading dot as the Set-Cookie header by default, so this points the issue towards being browser behavious and how it handles the Set-Cookie headers.

Chrome dev tools network inspector:

Chrome dev tools cookie list:

I suspect that the cookies you seen without the leading dot are from cookies assigned by JS functions, rather than a Set-Cookie header.

EDIT 2:

As you mentioned in the comments below, the JS function here does look like it adds the leading dot to the domain when the form_key is instantiated here, though any further communications with that form_key have the leading dot stripped in the headers too.

This could be a core bug, or it could be a configuration issue (I'm more inclined to think the former of the two)

Before worrying about why it happens, you may want to consider whether it's actually a problem for you. It seems to be that having a leading dot shouldn't be affecting cookie behaviour in the browser.

The leading dot means that the cookie is valid for subdomains as well. RFC 6265 Section 4.1.2.3 defines this as so modern browsers should ignore leading dots if you're on the base domain.

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, www.example.com, and 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.)

EDIT:

I've done a little bit of testing and it looks as though Magento wasn't actually sending the cookie domain with a leading dot as the Set-Cookie header by default, so this points the issue towards being browser behavious and how it handles the Set-Cookie headers.

Chrome dev tools network inspector:

Chrome dev tools cookie list:

I suspect that the cookies you seen without the leading dot are from cookies assigned by JS functions, rather than a Set-Cookie header.

EDIT 2:

As you mentioned in the comments below, the JS function PHP function for the cookie JS here does look like it adds the leading dot to the domain when the form_key is instantiated here, though any further communications with that form_key have the leading dot stripped in the headers too.

This could be a core bug, or it could be a configuration issue (I'm more inclined to think the former of the two)

Before worrying about why it happens, you may want to consider whether it's actually a problem for you. It seems to be that having a leading dot shouldn't be affecting cookie behaviour in the browser.

The leading dot means that the cookie is valid for subdomains as well. RFC 6265 Section 4.1.2.3 defines this as so modern browsers should ignore leading dots if you're on the base domain.

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, www.example.com, and 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.)

EDIT: I've done a little bit of testing and it looks as though Magento wasn't actually sending the cookie domain with a leading dot as the Set-Cookie header by default, so this points the issue towards being browser behavious and how it handles the Set-Cookie headers.

Chrome dev tools network inspector:

Chrome dev tools cookie list:

I suspect that the cookies you seen without the leading dot are from cookies assigned by JS functions, rather than a Set-Cookie header.

Before worrying about why it happens, you may want to consider whether it's actually a problem for you. It seems to be that having a leading dot shouldn't be affecting cookie behaviour in the browser.

The leading dot means that the cookie is valid for subdomains as well. RFC 6265 Section 4.1.2.3 defines this as so modern browsers should ignore leading dots if you're on the base domain.

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, www.example.com, and 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.)

EDIT:

I've done a little bit of testing and it looks as though Magento wasn't actually sending the cookie domain with a leading dot as the Set-Cookie header by default, so this points the issue towards being browser behavious and how it handles the Set-Cookie headers.

Chrome dev tools network inspector:

Chrome dev tools cookie list:

I suspect that the cookies you seen without the leading dot are from cookies assigned by JS functions, rather than a Set-Cookie header.

EDIT 2:

As you mentioned in the comments below, the JS function here does look like it adds the leading dot to the domain when the form_key is instantiated here, though any further communications with that form_key have the leading dot stripped in the headers too.

This could be a core bug, or it could be a configuration issue (I'm more inclined to think the former of the two)