Huh, I wonder if this is the root cause of #838395

Hrm...URLRequestTest.BasicAuthWithCookies is still passing.

cc'ing owner from  issue 6450  and  issue 1629  for further inputs on this issue.

@eroman: Please check the issue help in triaging this.

Thanks!

I really don't think CCing someone from issues  9  years old is likely to accomplish much here.

Thanks for the report and the packet capture.

Can you upload a NetLog dump showing the issue?
https://www.chromium.org/for-testers/providing-network-details

Another very helpful thing would be to run a "bisect" to identify where the regression happened. Open Terminal.app and the execute the following two commands to do a bisect for Chrome 65 -> 66:

python -c "import urllib2; import base64; print base64.b64decode(urllib2.urlopen(\"https://chromium.googlesource.com/chromium/src/+/master/tools/bisect-builds.py?format=TEXT\").read())" > bisect-builds.py

python bisect-builds.py -a mac -g 530369 -b 540276 --use-local-cache -- --no-first-run


You can read more about this at: https://www.chromium.org/developers/bisect-builds-py, but essentially it will download builds of Chrome, you test if it reproduces, then close Chrome and answer in the terminal window whether that build had the issue or not.

Thanks for looking into this issue. Attaching NetLog dump and new wireshark. About bisect builds, I just got chance to test only once. Then updated chrome. I am not sure, if it this issue is always seen or not.

Deleted: wireshark.pcapng 10.2 KB

wireshark.pcapng 10.2 KB Download

Deleted: chrome-net-export-log.json 3.0 MB

chrome-net-export-log.json 3.0 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

So at least in the case in the log, we already have cached auth credentials, send them, get the 401, and don't seem to set the cookie - the fact that we have auth credentials may or may not be relevant, but it is at least different from what the unit test does (URLRequestTest.BasicAuthWithCookies)

Thanks for providing the additional!

Have you disabled cookies in Chrome?

Please verify your settings at:
chrome://settings/content/cookies

I don't see any regression in behavior regarding Chrome respecting cookies in a 401 response. I have attached a simple server which simulates your server response, and it works fine for me in Chrome 66 by navigating to http://127.0.0.1:8081 after starting the server with "python test-server-839720.py 8081". Moreover we have unit-tests that cover this behavior and it continues to pass.

My best guess is that you have simply blocked cookies (either globally or for that site). If that is not the case, then something is not working with your cookie store.

A couple other related comments:

  * The server you are connecting to is requesting strict transport security, however is being accessed via http://, and also via an IP literal (which causes that header to be disregarded, so there is no redirect to https://).

  * IMPORTANT: The server is using Basic HTTP auth, over an insecure channel (http://), which offers absolutely no security, since it means that user/name passwords are sent in the clear, leading to the final remark:

  * Your pcap file, as well as the Chrome NetLog (which was captured with full byte logging), include the username/password that was used in the auth attempt. I am assuming that was just throw-away credential. But if it wasn't, we can mark this bug as private, and you should change the password.

Cheers.

Deleted: test-server-839720.py 1.4 KB

test-server-839720.py 1.4 KB View Download

Thanks you for looking into this issue and test-server. Cookies are all enabled(attached snapshot) in my browser. I could see that the browser updates cookie to the new value as received in 401. Just that it does not apply to restarted transaction. 

Yes. The credentials are throw away one.  

Deleted: Cookie_Settings.png 130 KB

	Cookie_Settings.png 130 KB View Download

Also seems like if cookies were disabled, we wouldn't be sending cookies in the first place.  I assume if the request succeeds in the same context (not failing with a 401, and also same [main]-frame/XHR/cross-site properties) can successfully overwrite the cookie using the same set-cookie line?

Thanks for following up.

Could you try reproducing using the attached test server?

Download the python file in comment #12, and then run:

  python test-server-839720.py 8081

Then load http://127.0.0.1:8081 in your browser.
The success case should be that you get prompted for auth once (enter any values), and then it displays a success page.

If it is "failing" it will continually prompt for auth.

Also, does this problem happen for you when using an incognito window as well?

Thanks for suggestions.
Following is the observation

1. I could not reproduce the issue with the test server.
2. issue happens happens only with http. https to same server works good.
3. If I cancel the repeated auth and refresh the window, cookie is properly reinserted in the GET request, and there is no problem.
4. with incognito window, the issue does not occur for the first time access after chrome restart. Subsequent logout and login cause the problem

Thank you!

I could reproduce the problem with test server itself after multiple attempts. 
Attached netlog and wireshark with testserver.

Thanks.

Deleted: wireshark_testServer.pcapng 1.1 MB

wireshark_testServer.pcapng 1.1 MB Download

Deleted: test-server-netlog.json 83.0 KB

test-server-netlog.json 83.0 KB View Download

Deleted: test-server-839720.py 1.6 KB

test-server-839720.py 1.6 KB View Download

one more observation is that, whenever 401 loop occur the requested page is already in cache. GET request goes with "If-Modified-Since" Header. If I clear "Cached images and files" then there is no 401 loop. I don't know if it is relevant. 

any update on this issue?

No updates - I haven't had a chance to look at your most recent data.

any update on this issue?

I am gone the next few weeks, leaving this open for others to investigate.

Punting back into the triage queue.

I looked over the netlog in #18. The set-cookie in 401 response is not being respected. I can't tell why that is the case from the logs.