In a scenario like follows (trying to replace/hand off a cookie from one subdomain to another):
Set-Cookie: AUTH_TOKEN=;Version=1;Comment="authentication token";Domain=.example.org;Path=/;Max-Age=0;HttpOnly;Expires=Thu, 01 Jan 1970 00:00:00 GMT,AUTH_TOKEN=815cd6bbd08576736a1fe21bdfbd5bff4caa6ba86f956d826a22c7352127c85c;Version=1;Comment="authentication token";Domain=.sub.example.org;Path=/;HttpOnly
...we have one session cookie and one with a blank value and in-the-past expiration (an accepted method for 'deleting' a cookie).
It seems clear that the session cookie should always be preferred over an obviously expired one. This approach could create weird results for folks running off-time machines, since it requires the client machine to be able to determine if a cookie is expired in the Expires=x case.
An argument could be made for the simpler solution of a session cookie ALWAYS being preferred, since it essentially means "client's discretion".
(all versions)
In a scenario like follows (trying to replace/hand off a cookie from one subdomain to another):
Set-Cookie: AUTH_TOKEN=;Version=1;Comment="authentication token";Domain=.example.org;Path=/;Max-Age=0;HttpOnly;Expires=Thu, 01 Jan 1970 00:00:00 GMT,AUTH_TOKEN=815cd6bbd08576736a1fe21bdfbd5bff4caa6ba86f956d826a22c7352127c85c;Version=1;Comment="authentication token";Domain=.sub.example.org;Path=/;HttpOnly
...we have one session cookie and one with a blank value and in-the-past expiration (an accepted method for 'deleting' a cookie).
It seems clear that the session cookie should always be preferred over an obviously expired one. This approach could create weird results for folks running off-time machines, since it requires the client machine to be able to determine if a cookie is expired in the Expires=x case.
An argument could be made for the simpler solution of a session cookie ALWAYS being preferred, since it essentially means "client's discretion".