Not all browsers behave the same when it comes to setting cookies. You should be aware of some key differences in behaviour:
According to RFC 6265, if a
Domain is not specified, a cookie should be treated as host-only, which means that a cookie set with no
Domain attribute on setcookie.net is not valid for www.setcookie.net.
However, IE and older versions of Edge chose not to support this specification until recently, and cookies without a
Domain attribute would still be sent to subdomains. This was fixed in the following versions:
- Edge on Windows 10 RS3
- IE11 on Windows 10 RS4 (April 2018)
As above, RFC 6265 describes how a
Path should be interpreted. When no attribute is provided, it defaults to the “directory” of the request URI’s path, so if the request path is /foo/bar, the
Path attribute defaults to
/foo, so the cookie would be sent to /foo/baz.
However, IE again does not conform to this spec, and defaults the cookie path to the request path, meaning a cookie set on /foo/bar would not be sent to /foo/baz. Setting the
Path explicitly solves this issue.
SameSite defaulting to
Cookies that do not pass a
SameSite attribute should default to
Lax according to the draft specification.
However, Firefox and Safari do not follow this behaviour. It is advised to explicitly set this attribute for the most compatible experience.
Path attribute for
The Cookie Prefixes draft specification states that cookies that begin with
MUST contain a
Path attribute with a value of
Notably, Chrome only checks if the path is implicitly
/; so setting a
__Host- cookie without a
Path attribute works, as long as the request URL is at the top level, such as setcookie.net or setcookie.net/foo.