How to disable HTTP/2 on IIS 10

Question

IIS 10 claims to fully support HTTP/2. I'm wondering if there is a way to turn off HTTP/2 on IIS 10.

Worshipful

Why do you want to turn it off? – Pitt

Because our server code does't work via HTTP/2. Although I'm not sure why it doesn't work. – Worshipful

See my question here (serverfault.com/questions/712808/…) for a reason why one would want to disable it. – Motherly

Then I think the appropriate question would be why your code doesn't support it. It should be largely transparent. – Ranunculaceous

When we use HTTP/2 in our development environment we have a certificate issued by our own root CA, what browsers like Chrome and Firefox don't seem to like. – Bituminize

@MikeBishop We've seen several hard-fail incompatibilities between IIS 10's HTTP/2 implementation and both Google Chrome and the OkHttp library. Our only solution has also been to disable HTTP/2 in IIS. – Carib

@Zero3, if you have a simple repro of those issues, I'd love to see them. The main thing that I'm aware of is that, if the application emits headers that aren't permitted in HTTP/2, the HTTP code doesn't block them. Some clients (rightly) choke on that. – Ranunculaceous

@MikeBishop Setup 1: Windows 10 + Latest IIS Express + Latest Chrome. Setup 2: Windows Server 2016 + IIS 10 + Recent OkHttp on Android. On both setups, all requests fail with obscure "protocol error" messages after the first couple of requests in quick succession. Disabling HTTP/2 on IIS fixes the issue on both setups. I have not tried to reproduce outside our business context, but I imagine it would be straightforward. – Carib

Here's another reason: NTLM due to it's serial request/response handshaking fails under the more-parallel http2. This results in a "Site cannot be reached" error from chrome between the very first request to the site and the time that it fails over to HTTP1.1 and then renders the first page. After that the site runs fine (because it's running http1.1), but the initial error is very upsetting to users. – Cockloft

See crbug.com/685741 for discussion; NTLM requires HTTP/1.1. – Indubitable

Another reason: forums.iis.net/post/2137486.aspx – Incursion

@Carib Did you ever find another way to solve this issue other than disabling HTTP2 on the server? – Kaciekacy

No. Not really. – Worshipful

@Kaciekacy Nop. It remains disabled on all our production systems. We plan to revisit this issue in the future at some point, but stability is more important for us right now. I will try to remember to post our solution here if/when we find one. – Carib

@Carib We had to disable it as well. okhttp3 was connecting fine for direct network calls, but once we started to override the URL inside the Webview we started seeing the SPDY errors. I'm investigating it now and will post a solution if/when I find it too. – Kaciekacy

Our use case is electron / chromium with IIS / Negotiate and SSL. We get an first load of the app that doesn't repeat itself if you reload the page. Electron only recently (grudgingly) added the ability to pass --disable-http2 to chromium. Before that we had to fix it on server side by disabling http/2. Strangely we just added a new IIS server that just refuses to obey the registry values to disable http2. – Curtice

Answer 1

To disable HTTP/2 on Windows 10 HTTP.SYS, set the following registry value on the Windows 10 desktop in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters

EnableHttp2Tls REG_DWORD 0

EnableHttp2Cleartext REG_DWORD 0

The second of these is only necessary if the failure is with HTTP. The first is for HTTPS.

Worshipful

I had to reboot the machine for this to take effect. – Bituminize

I don't know why but this doesn't seem to be working on windows server 2016 1607 Build 14393.2551. It seems to work just fine on 1607 build 14393.2485. – Curtice

Answer 2

This is old - but I thought id share my experience. I noticed this when we converted from server 2008 to 2016, and only on our classic asp pages. I noticed that I was setting response.buffer to be true, then working with the response headers and such and finally sending response.flush.

I saw that Chrome would have this problem only on the first call, if I send the call again it works - and thats because it was falling back to http 1.1. Disabling http2 worked but thats not a good solution.

I added response.end after the response.flush and the problem went away. So take this for what it is worth - for me it seemed to be connected to not ending the response and this worked fine in http 1.1 but somehow in http2 does not.

Perhaps this can help someone else along the way.

Procephalic

thank you !!, you have made my day! I have moved an SSRS to a new server with HTTPS, and when downloading the reports it gave me this problem: #45247398 With your solution now it is perfect! – Grackle