Unable to reproduce the issue on Win-10 using chrome reported version #56.0.2924.87 and latest canary #59.0.3032.0.

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Connected to URL: (http://www.botlibre.com) and logged into it.
2. Connected URL: https (https://www.botlibre.com) and logged into it and logged out of it.
3. Again connected as http (http://www.botlibre.com).
4. Observed that JSESSIONID cookie worked between http and https without any issues.

Reporter@ - Could you please check this issue on latest canary #59.0.3032.0 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.

Thanks...!!

Deleted: 698741.mp4 6.3 MB

	698741.mp4 6.3 MB View Download

paphus:  Is there ever a JSESSIONID cookie being set with the secure cookie attribute?  We no longer allow HTTP requests to overwrite secure cookies with insecure ones.

So you intentionally broke millions of websites? and no longer support websites with http and https?

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@ mmenke: Request you to please address as per comment#6.

Thanks.!

ranjitkan@: Neither Matt's question in c#5 nor krasjshree@'s question in c#2 has been answered yet by the OP; as far as I'm concerned, this bug is still waiting on feedback from that poster.  Please update this bug if you disagree and why you disagree.  (Note that the network bug triage rotation means that it's unlikely that Matt would be the one to respond to this request in any case; we tradeoff responsibility every two days.)

In response to c#6: I think Chrome has worked this way for years; I do not believe that the change Matt refers to in c#5 could be responsible for any recent breakage.  It's possible that something subtle has happened recently that means I'm wrong.  If you keep working with us, we may be able to figure out what root cause for this bug is; without your help, that's unlikely.

HTTP requests not being able to overwrite secure cookies is actually a fairly recent change (on the order of months old, not years).  See  https://tools.ietf.org/html/draft-ietf-httpbis-cookie-alone.  The associated bug is issue 568188.  Intent to implement and ship can be found at https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/g_igIzSue40.

It's still not clear to me that this is the issue the OP is running into, due to lack of response to comment #2.

Lack of response to comment #5, rather.

Yes, this is the issue.


See,
http://stackoverflow.com/questions/42138715/chrome-cookies-not-working-after-tomcat-web-server-reboot

Thank you for providing more feedback. Adding requester "ranjitkan@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

It's also my understanding that FireFox has now shipped this as of FireFox 52, which was released last month, so going to go ahead and close this.