Issue metadata
Sign in to add a comment
|
After successful authentication (WWW-Authenticate, IIS downgrade from HTTP/2->1.1), "This site can’t be reached" flickers by before showing the actual page
Reported by
mattiash...@gmail.com,
Apr 9 2017
|
||||||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
Example URL:
Steps to reproduce the problem:
* OS: Windows 10 or Server 2016 (not reproducable on older Windows OS) as server. I used W10 enterprise, IIS and Chrome both running locally.
* WebServer: Create an IIS application ('Add application' in IIS manager), with just a simple html page (content doesn't matter)
* TLS required: Make sure to use https. I configured a self signed cert on port 443.
* WWW-Authenticate: Protect the IIS application with "Windows Authentication". Default configuration will do.
* Configure 'Latency' to GPRS from F12 dev tools (makes the problem easier to spot, but it happens even without latency configured)
* Browse to the url from Chrome, e.g. https://myserver.domain.com/test/ and enter username/password. After that, you will see the error below for a short time before you get the "real" page.
What is the expected behavior?
After successful authentication (username/password dialog) in Chrome, I expect to see the page I browsed to.
What went wrong?
After successful authentication (username/password dialog) in Chrome, a "This site can’t be reached" message is displayed for a second or so. Then, the error message goes away and actual page is displayed (and everything works as expected).
Did this work before? No
Chrome version: 57.0.2987.133 (Official Build) (64-bit) Channel: stable
OS Version: 10.0
Flash Version:
WHAT I *THINK* HAPPENS:
IIS doesn't support WWW-Authenticate with http/2. Therefore, IIS falls back to http/1.1. Whether IIS does this correctly or not I don't know. But it seems like everyhing works after, so maybe the "This site can’t be reached" dialog in Chrome could be avoided?
* If I start chrome.exe with "--disable-http2", I cannot reproduce this.
* If I disable http2 in IIS, I cannot reproduce this.
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36
ERROR MESSAGE IN CHROME:
This site can’t be reached
The webpage at https://myserver.domain.com/test/ might be temporarily down or it may have moved permanently to a new web address.
ERR_UNEXPECTED
,
Apr 10 2017
Thank you for providing more feedback. Adding requester "bnc@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
,
Apr 10 2017
Thank you. What happens is that the server sends a RST_STREAM frame on stream 3 with error code HTTP_1_1_REQUIRED. This might be because it needs a client certificate to serve the request, but client certificates cannot be renegotiated on a HTTP/2 connection. Chrome handles this by closing the request, closing the connection, and retrying the request on a new connection without using HTTP/2. This should not be visible to the user, a "This site can't be reached." message should not be displayed.
,
Aug 30 2017
Looking at the network log attached to comment #2:
194 URL_REQUEST
197 HTTP_STREAM_JOB
202 SOCKET
fails with ERR_CERT_AUTHORITY_INVALID
204 HTTP_STREAM_JOB retrying seamlessly
207 SOCKET successful
208 HTTP2_SESSION
stream 1 gets 401 response
209 HTTP_STREAM_JOB retrying with client credentials
pools to existing 208 HTTP2_SESSION
stream 2 gets reset with HTTP_1_1_REQUEST
212 HTTP_STREAM_JOB retrying seamlessly
215 SOCKET successful with HTTP/1.1 as expected
ERR_UNEXPECTED, but I do not see what happens
216 URL_REQUEST retry logic, with briefly visible error message
219 HTTP_STREAM_JOB
223 SOCKET
fails with ERR_CERT_AUTHORITY_INVALID
224 HTTP_STREAM_JOB
228 SOCKET successful with HTTP/1.1 as expected
gets 401 response
retry on same socket with authorization header
successful
I do not see any events that would explain why ERR_UNEXPECTED happens. The symptom is similar to issue 685741 , but the underlying cause is different.
Note that there are ERR_CERT_AUTHORITY_INVALID errors, which are presumably clicked through (they could also be ignored via command line flag, but I do not see that in the log), which might indirectly cause this issue.
,
Aug 31 2017
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by b...@chromium.org
, Apr 10 2017