Cookie Quirks
Not all browsers behave the same when it comes to setting cookies. You should be aware of some key differences in behaviour:
No Domain
attribute
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)
No Path
attribute
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 Lax
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.