Need clarification for cookie domain format

[aldaris]

The add cookie command doesn't spell out the exact format of the cookie domain value, based on the current behavior of browsers I think the expectation is something like:

• if the cookie domain has a preceding dot character, the browser should ignore the dot character and create the cookie as a domain cookie
• if the cookie domain does not have a preceding dot character, then the browser should still create a domain cookie
• if the cookie domain field is absent in the request then the cookie should be created as a host only cookie

Similarly it is not clear how get named cookie should report the domain of the cookie. Firefox for example currently returns domain cookies with a preceding dot character, but host only cookies are represented by returning the value without a preceding dot character, to give an example Domain cookie where domain is google.com:

"domain": ".google.com"

Host only cookie for google.com:

"domain": "google.com"

[andreastt]

@shs96c What is the correct behaviour from Selenium’s side here?

[shs96c]

Right now, Selenium just takes the domain returned from the browser and shovels that into the response. Reading the code of the legacy Firefox driver, whatever is returned from Firefox's own cookie manager is returned, and that can contain a leading period. The IEDriver grabs the current URL and then uses the hostname from that, so is unlikely to have a leading period.

[aldaris]

Are there any plans to make this clearer?

Currently Firefox and Chrome differs in behaviour when adding new cookies:

• Firefox creates domain cookies when the domain is specified (with or without leading dot)
• Chrome creates domain cookies only when the domain is specified with a leading dot, but creates host only cookies when there is no leading dot.

The least ambiguous way to deal with this would be to have a new field in the cookie representation that differentiates host only cookies from domain cookies and the cookie domain would never have leading dot in cookie representations.

UPDATE The above description of the existing behaviour is most likely out of date now. The uncertainty around the cookie format remains nonetheless.