Remove upgrade mechanism

[martinthomson]

This has not been implemented, so can likely go.

[wtarreau]

And with this, both "3.4. Starting HTTP/2 with Prior Knowledge" and "3.5. HTTP/2 Connection Preface" should be reworded to make it clear that the preface explicitly allows a server or intermediary to implement both HTTP/1.1 and H2 on the same cleartext port. Right now it only speaks about supporting it over "TCP" (letting one think on a dedicated port) and suggests that the preface avoids accidental processing by HTTP/1. Instead this should be worded in a way that makes it clear that an HTTP/1.1 server that detects the preface can safely switch to H2.

[essen]

I have implemented h2c in client and server, though only the direct knowledge method in client. I'm not sure how many people rely on it. At least a few. It's also very useful for development and testing.

I would suggest leaving it in but indicate that it is not recommended and/or historical.

[wtarreau]

Martin was speaking about removing only the upgrade mechanism, not the prior-knowledge one, which is absolutely essential, I agree, and about every server implements it. I think the upgrade can be classed as historic, just like RFC2817 that I'm not sure many implementations support.

[essen]

Ah that makes more sense, thanks. Sounds good.

[martinthomson]

Yeah, I don't think that we can retract the registration of the ALPN identifier either.

[wtarreau]

I think you're right, given that for now we basically say "you must not accept h2c in ALPN", so removing it is even simpler!

[LPardue]

Remove this please, there's evidence that it's being used for smuggling when implemented/configured improperly: https://labs.bishopfox.com/tech-blog/h2c-smuggling-request-smuggling-via-http/2-cleartext-h2c