New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 787597 link

Starred by 69 users

Issue metadata

Status: Duplicate
Merged: issue 711186
Owner: ----
Closed: Mar 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Strange delay in AUTH_SERVER for https/SOAP request to exchange server

Reported by rursche...@gmail.com, Nov 21 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. HTTPS SOAP request to exchange server
2. Chromium process of electron app freezes for the duration of the delay
3. AUTH_SERVER in net-log shows delays of up to 10s

Delay is not consistent. Some AUTH_SERVER times are >300ms wheeas others are up to 10s  

What is the expected behavior?
No such huge delay in the AUTH_SERVER step of the HTTP request.

What went wrong?
Not sure this is a bug, but if it isn't maybe someone can explain what the delay in the AUTH_SERVER could be caused by.

t=51442931 [st=  143]     +AUTH_SERVER  [dt=8283]
t=51442931 [st=  143]       +HOST_RESOLVER_IMPL_REQUEST  [dt=11]
                             --> address_family = 0
                             --> allow_cached_response = true
                             --> host = "webmail-na.company.net:0"
                             --> is_speculative = false
t=51442931 [st=  143]          HOST_RESOLVER_IMPL_IPV6_REACHABILITY_CHECK
                               --> cached = true
                               --> ipv6_available = false
t=51442931 [st=  143]          HOST_RESOLVER_IMPL_CREATE_JOB
t=51442931 [st=  143]          HOST_RESOLVER_IMPL_JOB_ATTACH
                               --> source_dependency = 964 (HOST_RESOLVER_IMPL_JOB)
t=51442942 [st=  154]       -HOST_RESOLVER_IMPL_REQUEST
t=51451214 [st= 8426]     -AUTH_SERVER

Did this work before? N/A 

Chrome version: 62.0.3202.82  Channel: stable
OS Version: Windows 10 x64
Flash Version: 

As mentioned above this is from Chromium as part of electron, but the same delay has been observed in Chrome as well, though much less frequent.

The electron renderer process which is sending out this http/soap request freezes for the duration of the delay.
 
auth_server delay.txt
10.5 KB View Download
Correction, Chromium Version is 58.0.3029.110

Labels: Needs-Feedback Needs-Triage-M62
rurscheler@, Current Chrome Stable is #62.0.3202.94. Can you please update it to latest version (chrome://chrome) and see the issue still exists?

Thank you!
Since this is only reproducible using electron I am not able to test with Chrome 62.
I will try to reproduce it with Chrome 62.

But looking at the net-log closer I am wondering what Chromium is doing in those 8sec. Is it possible that its trying to get the info for the Kerberos or NTLM Authorization header?
Project Member

Comment 4 by sheriffbot@chromium.org, Nov 22 2017

Cc: manoranj...@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "manoranjanr@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
Here is some more information from the Chromium log.

The log shows the delay (9sec here, but it may be as high as 30s) in the first call to InitializeSecurityContext. The responses look fine (SEC_E_OK and SEC_I_CONTINUE_NEEDED). Does this mean the first call to the Windows system library's InitializeSecurityContext API blocks for that amount of time.

Any idea why what could be?

[11000:1122/121402.409:VERBOSE1:http_auth_sspi_win.cc(24)] AcquireCredentialsHandle returned 0x0
[11000:1122/121411.210:VERBOSE1:http_auth_sspi_win.cc(108)] InitializeSecurityContext returned 0x90312
[11000:1122/121411.265:VERBOSE1:http_auth_sspi_win.cc(108)] InitializeSecurityContext returned 0x0
[11000:1122/121417.557:VERBOSE1:mime_sniffing_resource_handler.cc(399)] To buffer: https://webmail-na.company.net/EWS/Exchange.asmx


Note that this issue is not only causing the app to freeze but also the active WebRTC call gets dropped. 

Comment 6 by b...@chromium.org, Nov 22 2017

Components: -Internals>Network Internals>Network>Auth
Labels: Triaged-ET TE-NeedsTriageHelp
The issue seems to be out of TE-scope as it is related to AUTH_SERVER for https/SOAP request. Hence, adding label TE-NeedsTriageHelp for further investigation from dev team.

Thanks...!!
Some more information. As shown in the logs the delay/freeze is caused after a kerberos failure and before the successful NTLM fallback. The kerberos issue has been solved. It was a missing SPN configuration for the load balancer sitting in front of the exchange servers.

But since this ticket is about the random delay/freeze of 1-30sec, we are going to try create a reproducible scenario and post that here. 

Comment 9 by mmenke@chromium.org, Mar 14 2018

Labels: Network-Triaged
Mergedinto: 711186
Status: Duplicate (was: Unconfirmed)
I'm going to merge this issue 711186 which deals with the issue of the IO thread freezing when token generation takes too long.

Sign in to add a comment