3

Is it valid in HTTP (and does it work reliably) to send multiple cookies with the same name in the same HTTP Set-Cookie response header?

The response would be similar to:

Set-Cookie: NAME=bad;  path=/notthere;     expires=getridofthiscookie
Set-Cookie: NAME=good; path=/
Set-Cookie: NAME=bad;  domain=a.subdomain; expires=getridofthisaswell

The purpose is to get rid of extraneous cookies ('bad' cookies) created with the wrong path (or on a subdomain) which is leading to less-than-desirable cookie values sent to the server depending on the request path/domain.

Related

Community
  • 1
  • 1
user2864740
  • 60,010
  • 15
  • 145
  • 220
  • Slightly confused about the question. Obviously, you can't delete cookies on other domains; this would be a massive security hole. So, the third line in your example does not work for more basic reasons than `Set-Cookie` header mechanics, and there is no way to delete a cookie on another domain. Or, perhaps I misunderstood the question? – RomanK Sep 25 '16 at 12:54
  • @RomanK It was indeed a bit unclear. Some of the cookies to remove are on subdomains of the primary; they should only be cookies on the primary domain and the goal is to them expire them from the subdomains while ensuring they exist on the primary domain. I've updated the question to put the lid back on that can. – user2864740 Sep 25 '16 at 19:39
  • @RomanK The entire problem could have been avoided by properly creating the cookies with an explicit path/domain to begin with and .. unfortunately that is not the current case. – user2864740 Sep 25 '16 at 19:43
  • Possibly related http://stackoverflow.com/questions/12281038/set-multiple-cookies-with-the-same-name-in-django , where being unable to do that is considered as a bug. – Joe Sep 26 '16 at 11:12
  • Perhaps you can set a single `bad` cookie for ".domain.com" (i.e. a wildcard cookie)? http://serverfault.com/questions/153409/can-subdomain-example-com-set-a-cookie-that-can-be-read-by-example-com – RomanK Sep 26 '16 at 13:53
  • @RomanK Per my understanding (which is often suspect and usually amenable!), cookies are unique per name/domain/path triplet. The goal is to only have a 'NAME=good' cookie in the browser's cookie jar at the end of the request, given the precondition that only those names/domains/paths previously existed. – user2864740 Sep 26 '16 at 16:32

1 Answers1

0

it works for me with the latest Edge (Version 92.0.902.67 (Official build) (x86_64))

I have two local cookies with the same name test, and bad one is associated with the subdomain (.www.domain.com) and the good one is associated with the domain (www.domain.com).

I use Charles to mimic web server response containing two set-cookie headers, something like this:

set-cookie:test=blabla; path=/; secure; SameSite=None
set-cookie:test=; path=/; domain=.www.domain.com; max-age=0; expires=Thu, 01 Jan 1970 00:00:00 -0000; secure; SameSite=None

And Edge is smart enough to delete the bad cookie and update the good cookie.

Gang Peng
  • 21
  • 3