I must be missing some basic thing about cookies. On localhost, when I set a cookie on server side and specify the domain explicitly as localhost (or .localhost). t
There seems to be an issue when you use https://
and then http://
. The http://
site does not send cookies with requests after https://
site sets them. Force reload and clear cache doesn't help. Only manual clearing of cookies works. Also, if I clear them on the https://
page, then http://
page starts working again.
Looks to be related to "Strict secure cookies". Good explanation here. It was released in Chrome 58 on 2017-04-19.
It looks like Chrome does in fact record both secure cookies and non-secure cookies as it will show the correct cookies depending on the page's protocol when clicking the address bar icon.
But Developer tools > Application > Cookies
will not show a non-secure cookie when there is a secure cookie of the same name for the same domain, nor will it send the non-secure cookie with any requests. This seems like a Chrome bug, or if this behavior is expected, there should be some way to view the secure cookies when on a http
page and an indication that they are being overridden.
Workaround is to use different named cookies depending on if they are for an http site or https site, and to name them specific to your app. A __Secure-
prefix indicates that the cookie should be strictly secure, and is also a good practice because secure and non-secure won't collide. There are other benefits to prefixes too.
Using different /etc/hosts
domains for https vs. http access would work too, but one accidental https://localhost
visit will prevent any cookies of the same names to work on http://localhost
sites - so this is not a good workaround.
I have filed a Chrome bug report.