@bortzmeyer Yes, we should.

@X_Cli Biggest problem is that you cannot enforce it: JavaScript does not know the HTTP version it uses, and, if there is a proxy, you cannot guarantee end-to-end HTTP/2.

@bortzmeyer JS is a false problem: just fire up your request, and you will receive an error if you cannot establish the TLS handshake.
Intercepting proxies that break protocols should be ignored. We use TLS precisely to avoid middleboxes meddling with the protocol. Trying to take them into account in the model will just make it more complex, and less efficient and less secure. We must stop believing that H2 is backward compatible with H1. That's just not true.

@X_Cli Mark Nottingham was not talking about intercepting proxies but abot explicit proxies, such as CDN servers, which may be regarded as a kind of proxies).

@bortzmeyer Reverse proxies/load balancers and WAF should really use H2 when they receive H2, because the downgrade/upgrade transcoding rules are not really working well. Information is lost in the process and some optimization for one protocol may degrade the performance for the other one. Also, with H1, you can only have 6 connections per destination server and there is HoL blocking. That does not scale at all.

@X_Cli Yes, but they don't (Cloudflare, for instance).

@X_Cli The JS problem is that, if JS can send its request, it cannot know if it was over HTTP/2 or not. JS does not have this information.

@bortzmeyer What does the JS script need that information for? I don't see a use case at all.

@X_Cli To enforce the rule "HTTP/2 only" (if we make this rule a MUST).

@bortzmeyer I dont' think that's JS job to do that. That's the server endpoint that should enforce that. If the server endpoint accepts H1, that's the one breaking the MUST requirement..

@X_Cli This is a general IETF rule: you don't make a MUST if it cannot be enforced. If one end cannot check that the MUST is OK, the standard is useless.

@bortzmeyer Well, that's a rather strict interpretation of the "running code" part of the motto. I don't approve ;) I am OK with this staying a draft or an experiment until implementations catch up.

@Shaft Interesting error, it turns secure HTTPS into NSA-friendly HTTP :-)