Skip to content

Implement Support for ALPN #85

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Implement Support for ALPN #85

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions Cargo.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,8 +15,8 @@ vendored = ["native-tls/vendored"]

[dependencies]
bytes = "1"
native-tls = "0.2.1"
hyper = { version = "0.14.2", default-features = false, features = ["tcp", "client"] }
native-tls = { version = "0.2.7", features = ["alpn"] }
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even if its enabled by default, ALPN support should be behind a feature, since old versions of the TLS backends don't support it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Say more. You mean if built on a system with an old openssl/schannel/security-framework, it will probably fail with link errors of missing symbols?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm curious how likely it is that installations would be too old. I'd really wish to make it default enabled in reqwest, so people can use h2 more frequently...

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is specifically OpenSSL 1.0.1 (CentOS 6 for example), and macOS 10.12 and older.

hyper = { version = "0.14.2", default-features = false, features = ["tcp", "client", "http1", "http2"] }
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This forces http1 and http2 back in. It's unclear to me how to proceed here. I believe we either have to always activate these or have to add new public features of hyper-tls, which if you forget to activate them, you are not getting any ALPN. Though we could make those features active by default.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to enable them in this crate? As long as we don't send ALPN by default, the user can opt-in after enabling the features.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah we can definitely just not send ALPN by default. It could then either be a feature of this crate (which then probably should delegate it further) or be some kind of constructor / builder / configure method of the HttpsConnector (and hoping that the appropriate features are active for hyper). I'll leave that decision up to you before I proceed further.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking about this issue and the easiest implementation that comes to mind would be to have something like this in hyper:

/// Returns `true` if the `http2` feature is enabled
pub const fn http2_feature_enabled() -> bool {
    cfg!(feature = "http2")
}

The advantage is that enabling http2 in hyper would also enable it automatically in the TLS libraries. The downside is that it wouldn't be possible to disable the ALPN feature in hyper-tls. Also I've never seen something like this done in other crates so maybe it's a bad pattern to do in Rust?

tokio = "1"
tokio-native-tls = "0.3"

Expand Down
4 changes: 3 additions & 1 deletion src/client.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,9 @@ impl HttpsConnector<HttpConnector> {
/// To handle that error yourself, you can use the `HttpsConnector::from`
/// constructor after trying to make a `TlsConnector`.
pub fn new() -> Self {
native_tls::TlsConnector::new()
native_tls::TlsConnector::builder()
.request_alpns(&["h2", "http/1.1"])
.build()
.map(|tls| HttpsConnector::new_(tls.into()))
.unwrap_or_else(|e| panic!("HttpsConnector::new() failure: {}", e))
}
Expand Down
14 changes: 13 additions & 1 deletion src/stream.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -105,7 +105,19 @@ impl<T: AsyncRead + AsyncWrite + Connection + Unpin> Connection for MaybeHttpsSt
fn connected(&self) -> Connected {
match self {
MaybeHttpsStream::Http(s) => s.connected(),
MaybeHttpsStream::Https(s) => s.get_ref().get_ref().get_ref().connected(),
MaybeHttpsStream::Https(s) => {
let tls = s.get_ref();
if tls
.negotiated_alpn()
.ok()
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The error is somewhat silently ignored here, probably not great.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ignoring it here seems fine.

.flatten()
.map_or(false, |p| p == b"h2")
{
tls.get_ref().get_ref().connected().negotiated_h2()
} else {
tls.get_ref().get_ref().connected()
}
}
}
}
}