Skip to content
This repository has been archived by the owner on Sep 17, 2019. It is now read-only.

Support h2c (HTTP/2 without TLS) #59

Closed
kennylevinsen opened this issue May 6, 2015 · 9 comments
Closed

Support h2c (HTTP/2 without TLS) #59

kennylevinsen opened this issue May 6, 2015 · 9 comments

Comments

@kennylevinsen
Copy link

This library currently supports h2, which negotiates over TLS. However, it appears that it does not support the Upgrade negotiation of h2c, which requires a bit deeper integration with the http lib, rather than hijacking the protocol at the TLS level.

Some people seem to find TLS-less HTTP to be a controversial subject, for some peculiar reason, but it is part of the spec. I unfortunately also happened to look at this project because I needed it. Oh well.

@bradfitz
Copy link
Owner

bradfitz commented May 6, 2015

There's PR #48 open for this, but it'll probably live elsewhere in the end. I think this server will support the hooks necessary for people to add h2c support when they want it, but it won't be enabled by default, and definitely not for Go's standard library for users of the net/http package.

@kennylevinsen
Copy link
Author

Pardon my curiosity, but why would h2c support not be enabled by default? I presume you mean that a ListenAndServe would not provide the upgrade mechanism without further intervention, and only ListenAndServeTLS would provide a way for HTTP/2 to be negotiated?

But I'm glad that there will be at least some way to use h2c.

@bradfitz
Copy link
Owner

bradfitz commented May 6, 2015

Read sections 5.1 and 5.2 of http://daniel.haxx.se/http2/http2-v1.10.pdf ... actually all of section 5, and that whole document is great actually.

@kennylevinsen
Copy link
Author

Ah, indeed, it is actually a good reference. Thanks!

However, I read section 5 (including Firefox/Chrome teams opinions against h2c), and I still do not see why the server shouldn't provide h2c. I get that the various browser teams only implement h2, as a sort of attempt to deprecate non-TLS traffic (Which will take a while, as I don't see HTTP/1.1 being deprecated any time in the near future, which is what a failed h2c upgrade would automatically default to). But the fact that things like curl supports h2c, and Internet Explorer intents to do it as well, mean that we have a set of clients with differing opinions about what they want to support. Larger networks that would like to benefit from HTTP/2 will also most likely only deploy h2c, as they would normally terminate the TLS connection right before load balancers and caches.

Seeing that it is their own decision what they ask for, my personal opinion is that the server should be completely un-opinionated in the matter, serving what the programmer asked it to when a client decides to ask. If a net/http user does not want non-TLS traffic, then I think the proper procedure would be a redirect to :443, rather than a downgrade to HTTP/1.1 that no regular user will ever notice, as browsers don't show the protocol to the user. Even if the browser did tell them, seeing that people are susceptible to phishing attacks on obscure and clearly incorrect URL's, I doubt that the majority would pay attention to it.

I apologize if I'm about to reignite some debate regarding this matter. I'm just really, really fond of Go's extensive standard library, and would be saddened if some features ended up being intentionally made harder to use.

@bradfitz
Copy link
Owner

bradfitz commented May 8, 2015

From that doc: "Reasons for choosing TLS-only include respect for user's privacy and early measurements showing that new protocols have a higher success rate when done with TLS. This because of the widespread assumption that anything that goes over port 80 is HTTP 1.1 makes some middle-boxes interfere and destroy traffic when instead other protocols are communicated there."

@kennylevinsen
Copy link
Author

Ah, damn, I missed the argument of middleware breaking the protocol. That is indeed a good argument against opening for h2c by default. But I still seriously doubt that h2 would see widespread adoption past those previously mentioned TLS terminators, due to things like certificate management nightmares, and some companies potentially not wanting to waste power on crypto between their servers. Without h2c, they'll probably end up sticking to HTTP/1.1, either internally or all the way through, which would be annoying as well...

I will cross my fingers for it not to be too difficult to enable. I apologise for taking that much of your time. Thanks!

@ernado
Copy link

ernado commented Jun 5, 2015

Any updates on this?
Optional h2c would be great

@alehano
Copy link

alehano commented Jun 6, 2015

+1

@bradfitz
Copy link
Owner

This repo just moved into the official Go repo.

See https://github.com/bradfitz/http2/blob/master/README for the move details.

File new bugs at: https://github.com/golang/go/issues/new?title=x/net/http2:+

Closing this bug, but please copy it to the main repo if still relevant or desired. Thanks!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants