Hello,

we are encountering the same issue. 

Backend is HTTP/2 enabled IIS (but it is probably irrelevant and a problem of HTTP/2 in Chrome in general).

Client app looks like this:
 /app
     /auth - only here server requires authentication and sends WWW-Authenticate header
     /site - regular website which should run with HTTP/2

The problem is: once Chrome goes to /app/auth and correctly downgrades because of the authentication, it never uses the h2 again even on other parts of the website.
It is quite limiting when trying to use full benefits of h2.

Chrome v65.

Thanks for looking into this.

I assume this is expected behavior.  I'll defer to those more knowledgeable on the situation on whether we should change what we do here.

Hello,
I have one more example.

Several applications are running on one domain.
I have several tabs with these apps open in Chrome. However, when in one of them I click on a link that requires NTLM, entire communication in all tabs for this domain switches to HTTP/1.1.

I've tried it also in a macOS browser on a computer that is not in the domain. When you open a URL that returns the status code 401 and the WWW-Authenticate: Negotiate and WWW-Authenticate: NTLM header, a logon entry dialog box appears. After entering any data, even nonsense, all communication with the domain in question will switch (in all tabs) to HTTP/1.1

As per above comments this issue seems to be out of scope of TE as this is related to switch between HTTP/1.1 and HTTP/2. Hence adding TE-NeedsTriageHelp label. Please remove if not the case.

Thanks!

This is a duplicate of  issue 516237  which is marked as WontFix.  See also previous discussion on  issue 685741 .

I think it might be worth revisiting this issue.  One approach could be to add a Boolean flag to HttpStreamFactoryImpl::Job to indicate NTLM.  HttpAuthController::NeedsHTTP11() was introduced at https://crrev.com/c/673091 and it can be called in HttpNetworkTransaction to set this flag before Job is instantiated.  Then Job would know not to use HTTP/2 connection.  It would be interesting to explore if this could be implemented without needing to bifurcate the socket pools, which sounds messy, and probably too complicated to be worth doing for this use case.  For example, note how WebSocket requests are also forced over non-HTTP/2 connections (except for the experimental WebSocket over HTTP/2 case), without needing that kind of socket pool black magic.

If this approach works, then it could be measured if the entire RequiresHTTP11/SetHTTP11Required logic could be removed from HttpServerProperties, if the only case when ERR_HTTP_1_1_REQUIRED is sent by servers can be eliminated with this logic.

On the other hand, it seems like for at least some servers, we would end up sending every request twice, which seems problematic - particularly for uploads.

I don't know, but it seems logical, and perhaps not so complicated to execute, that if any path requires HTTP/1.1, the further communication in it and it's subfolders is in HTTP/1.1. For other paths, however, the browser should stay with HTTP/2. Especially if it previously communicated with them without any problems, via HTTP/2.

It would be nice if it was possible to influence it in the client application. Then the browser wouldn't have to speculate about it, but that is not possible if I am not mistaken :-(

Now I can have a perfectly optimized application on HTTP/2 and if there is one NTLM-requiring file on the domain that the user needs to access, then the optimization is gone.


Just a little note on Comment 4.
The last section may be a bit confusing, it was Chrome  in macOS.

The root of the problem here is that the network stack currently does not support concurrent HTTP/1.1 and HTTP/2 connections to the same server.  See  issue 685741  comments 10 and 11 about opinions on this possibility.