This worked before but not working since last week

I am able to reproduce this in latest canary - 	58.0.3004.0. We need a bisect for further debugging.

 Issue 688821  has been merged into this issue.

Thanks for merge. Yes the same has been happening,

Example URL:
https://www.sdtps.gov.ae/portal/pls/portal/!PORTAL.wwpob_smd.login?_smd_login_url=https%3A%2F%2Fwww.sdtps.gov.ae%2Fportal%2Fpage%2Fportal%2FDTPS%2FCRUD

Steps to reproduce the problem:
1. hit the url https://www.sdtps.gov.ae
2. Change the language to English as shown in attached Image
3. Press Login as shown in the image
4. Enter login credentails user: naji_test4 password:abc1234
5. Then click on My Service Option as shown in attached Image

What is the expected behavior?
It should after login and then redirects to relevent pages

It was working properly before latest chrome updates.

What went wrong?
Its giving error as below,

ERR_TOO_MANY_REDIRECTS

Deleted: I1.jpg 651 KB

	I1.jpg 651 KB View Download

Deleted: I2.jpg 641 KB

	I2.jpg 641 KB View Download

Deleted: I3.jpg 501 KB

	I3.jpg 501 KB View Download

Deleted: I4.jpg 638 KB

	I4.jpg 638 KB View Download

Deleted: I5.jpg 111 KB

	I5.jpg 111 KB View Download

Issue is not reproducible using a clean user profile.But once we make a browser exit and relaunch chrome I am getting - ERR_TOO_MANY_REDIRECTS. Tried clearing all the cookies but did not work. Also the results are inconsistent 
so hard to get a bisect.

Looping to - //src/net/OWNERS for further updates.

Deleted: Capture.PNG 54.3 KB

	Capture.PNG 54.3 KB View Download

Please don't assign bugs to people from //net directly. We have a triage queue, so the next triager will look at this.

Hrm this could be another case of StrictSecureCookies, as we are swapping between http/https sites, but I don't have hard evidence.

In #4, it does look like an http origin is trying to set a secure cookie ("portal"), which doesn't get sent up in a subsequent https redirect?

1. jww@ left the company, so he's probably not going to triage.

2. I suspect that this is indeed fallout from the strict secure change: when signing in, the user is redirected through `http://www.sdtps.gov.ae/portal/pls/portal/portal.wwsec_app_priv.process_signon?urlc=v1.2~520F0...`, which attempts to set `Set-Cookie:JSESSIONID=ntv5YcNKhScYpb32cy9J...0; path=/portal; secure` and two other similar cookies. These fail. It's not clear to me how this would have worked before, though, since those secure cookies wouldn't have been sent on to the `http` origins that ends up in the redirect loop. Perhaps I'm missing a point at which the `secure` flag is removed by a non-secure origin?

I think this is working as intended, but the redirect chain is a bit confusing, so I won't rule out a bug in our implementation.

Hi All, I can see you are working on the merged issue, could you guys please give us updates on the originally reported issue. This issue is been faced by a huge number of customers for us. All help/debugging is highly appriciated

@mkwst@chromium.org - Do you have nay update on this issue? Is there any chance that you have investigated the original issue reported by us instead of merged issue? This is largely impacting our customer as well as internal users. We are suggesting them to use different browser other than chrome as chrome stopped working for us. 

Hi All, here is some more information on the original ticket. Google Chrome is NOT sending the set-cookie header information whenever it switches from https to http. Basically in Chrome what is happening is as explained before in the first 4 steps after sign in.

1st step HTTPS has set cookie
2nd step HTTP doesn't have set cookie
3rd step HTTPS has the same set cookie as in step 1
4th step HTTP does not have the set cookie
5th step, your Origin is expecting a set cookie and since it does not have it present, it assigns a new set cookie, different from the one in step 1 and that creates the endless loop in Chrome.

Firefox/IE behavior after sign in
Firefox preserves the same set cookie on steps 1 to 4.
Then, on step 5, your Origin server expects a set cookie, and it is there since Firefox and IE kept it present, thus, no new set cookie is assigned and it proceeds to showing the calendar page you expect.

Is there going to be any update on this issue?  Customers are highly impacted and we are suggesting them to use different browsers.

Also suddenly having this issue as of about 10 days ago.  Clearing cookies does not fix the issue.  No changes made to our site or code base and had been working fine in Chrome for a long time.  Posting to see if there is an update?

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

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

This bug has an owner, thus, it's been triaged. Changing status to "assigned".