ndt-server: disable http2 for ndt7 and ndt5

[bassosimone]

By default Go enables http2, however gorilla/websocket does not support http2. So, we need to disable http2 otherwise a client may attempt to perform WebSocket using http2, as instructed by ALPN, but that process fails. This Stack Overflow thread may be useful to show us how to disable http2.

[stephen-soltesz]

Does the current code impact browser clients?

[bassosimone]

When I fetch https://ndt-iupui-mlab2-mil03.measurement-lab.org/ with chrome, it's using h2. Same when I navigate to https://ndt-iupui-mlab2-mil03.measurement-lab.org/static/ndt7.html. Yet Chrome performs the test using secure WebSocket. I believe the browser does not use h2 for WebSocket for now and I have seen there is an experimental flag for enabling it. Then, I found an authoritative source:

WebSockets over HTTP/2 [...] would only be used for secure WebSockets requests, and only if there is already an HTTP/2 connection where the server has already advertised support for WebSockets over HTTP/2 via the HTTP/2 SETTINGS parameter defined in the specification.

So, the answer to your question, @stephen-soltesz is "no".

[stephen-soltesz]

I believe this issue is obsolete. Please reopen if you disagree.

[bassosimone]

@stephen-soltesz has it been fixed by disabling h2? While it's not breaking clients now, it may break clients in the future when h2 increasingly becomes the norm, for this reason I think it is better to keep it open. The quote above, pulled from a discussion of a Chrome feature, explains the policy that Chrome is currently using vis a vis h2. Yet, our server is still replying with h2 http/1.1 in the ALPN. Also, while that is Chrome's policy, and while Firefox appears to be using a Chrome-like policy, it may be that in the future Firefox or other browsers may change policy. So, I'd keep this issue open.

(But I don't have the power to re-open the issue, so I think I cannot do myself the "reopen if you disagree" part.)

[bassosimone]

Thanks!