NTLM is working, this is more an authentication restart issue in our code... This is an indirect regression from bug 1434137 (uncover of a bug somewhere else). ``` 2019-03-27 14:46:28.273000 UTC - [Parent 1440: Socket Thread]: I/nsHttp Http2Session::ProcessWaitingWebsockets 0000000020D82000 Re-queuing websocket as h1 due to mPeerAllowsWebsockets=false ``` What I exactly see in the log: - there is a web socket initiated request for `https://web.whatsapp.com/ws` - we successfully authenticate to the proxy with NTLM (get 200 CONNECTED) - the end point server is h2 - we restart the ws request and enforce h1 - we create a new connection to the proxy - the (somewhat fragile) logic in the http channel believes we failed to authenticate the proxy with the default credentials and kills the cached entry ``` 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: D/nsHttp nsHttpChannelAuthProvider::GetCredentialsForChallenge [this=000000001DD3B6A0 channel=0000000020E1B718 proxyAuth=1 challenges=NTLM] 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: D/nsHttp nsHttpAuthCache::GetAuthEntryForDomain [key=http://lelapomi.telecomitalia.local:8080 realm=] 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: V/nsHttp nsHttpNTLMAuth::ChallengeReceived [ss=0000000000000000 cs=000000001E2F4E80] 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: V/nsHttp Force use of generic ntlm auth module: 0 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: D/nsHttp identity invalid = 1 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: D/nsHttp nsHttpChannel::CloseStickyConnection this=0000000020E1B000 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: V/nsHttp nsHttpConnection::DontReuse 0000000020E85800 spdysession=0000000000000000 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: D/nsHttp nsHttpChannel::ConnectionRestartable this=0000000020E1B000, restartable=0 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: D/nsHttp clearing bad auth cache entry 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: D/nsHttp Destroying nsHttpAuthNode @000000001FAEE8C0 ``` the auth node is created by the very first channel, suing default credentials. - we ask for credentials with a prompt - you canceled the prompt, which canceled the request The channel must be notified the proxy connection is re-attempted and not because of authentication failure. This is going to be a bit tricky.
Bug 1536787 Comment 13 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
NTLM is working, this is more an authentication restart issue in our code... This is an indirect regression from bug 1434137 (uncover of a bug somewhere else). ``` 2019-03-27 14:46:28.273000 UTC - [Parent 1440: Socket Thread]: I/nsHttp Http2Session::ProcessWaitingWebsockets 0000000020D82000 Re-queuing websocket as h1 due to mPeerAllowsWebsockets=false ``` What I exactly see in the log: - there is a web socket initiated request for `https://web.whatsapp.com/ws` - we successfully authenticate to the proxy with NTLM (get 200 CONNECTED) - the end point server is h2 - we restart the ws request and enforce h1 - we create a new connection to the proxy - the (somewhat fragile) logic in the http channel believes we failed to authenticate the proxy with the default credentials and kills the cached entry ``` 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: D/nsHttp nsHttpChannelAuthProvider::GetCredentialsForChallenge [this=000000001DD3B6A0 channel=0000000020E1B718 proxyAuth=1 challenges=NTLM] 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: D/nsHttp nsHttpAuthCache::GetAuthEntryForDomain [key=http://lelapomi.telecomitalia.local:8080 realm=] 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: V/nsHttp nsHttpNTLMAuth::ChallengeReceived [ss=0000000000000000 cs=000000001E2F4E80] 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: V/nsHttp Force use of generic ntlm auth module: 0 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: D/nsHttp identity invalid = 1 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: D/nsHttp nsHttpChannel::CloseStickyConnection this=0000000020E1B000 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: V/nsHttp nsHttpConnection::DontReuse 0000000020E85800 spdysession=0000000000000000 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: D/nsHttp nsHttpChannel::ConnectionRestartable this=0000000020E1B000, restartable=0 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: D/nsHttp clearing bad auth cache entry 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: D/nsHttp Destroying nsHttpAuthNode @000000001FAEE8C0 ``` the auth node is created by the very first channel, using default credentials. - we ask for credentials with a prompt - you canceled the prompt, which canceled the request The channel must be notified the proxy connection is re-attempted and not because of authentication failure. This is going to be a bit tricky.
NTLM is working, this is more an authentication restart issue in our code... This is an indirect regression from bug 1434137 (uncover of a bug somewhere else). ``` 2019-03-27 14:46:28.273000 UTC - [Parent 1440: Socket Thread]: I/nsHttp Http2Session::ProcessWaitingWebsockets 0000000020D82000 Re-queuing websocket as h1 due to mPeerAllowsWebsockets=false ``` What I exactly see in the log: - there is a web socket initiated request for `https://web.whatsapp.com/ws` - we successfully authenticate to the proxy with NTLM (get 200 CONNECTED) - the end point server is h2 - we restart the ws request and enforce h1 - we create a new connection to the proxy - the (somewhat fragile) logic in the http channel believes we failed to authenticate the proxy with the default credentials and kills the cached entry ``` 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: D/nsHttp nsHttpChannelAuthProvider::GetCredentialsForChallenge [this=000000001DD3B6A0 channel=0000000020E1B718 proxyAuth=1 challenges=NTLM] 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: D/nsHttp nsHttpAuthCache::GetAuthEntryForDomain [key=http://lelapomi.telecomitalia.local:8080 realm=] 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: V/nsHttp nsHttpNTLMAuth::ChallengeReceived [ss=0000000000000000 cs=000000001E2F4E80] 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: V/nsHttp Force use of generic ntlm auth module: 0 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: D/nsHttp identity invalid = 1 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: D/nsHttp nsHttpChannel::CloseStickyConnection this=0000000020E1B000 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: V/nsHttp nsHttpConnection::DontReuse 0000000020E85800 spdysession=0000000000000000 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: D/nsHttp nsHttpChannel::ConnectionRestartable this=0000000020E1B000, restartable=0 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: D/nsHttp clearing bad auth cache entry 2019-03-27 14:46:28.317000 UTC - [Parent 1440: Main Thread]: D/nsHttp Destroying nsHttpAuthNode @000000001FAEE8C0 ``` (the auth node is created by the very first channel, using default credentials.) - we ask for credentials with a prompt - you canceled the prompt, which canceled the request The channel must be notified the proxy connection is re-attempted and not because of authentication failure. This is going to be a bit tricky.