Closed ColonelThirtyTwo closed 2 weeks ago
Due to how HTTP/2 works with most servers, you need to enable a TLS feature which will use ALPN. That's either native-tls-alpn
, or rustls-tls
(and make sure your client builds with use_rustls_tls()
). It's not enabled by default for native-tls because not all machines will have the necessary support (rustls does out of the box).
Adding features = ["native-tls-alpn"]
makes it work, thank you.
Seems like a footgun though - the native-tls-alpn
feature on reqwests just mentions the corresponding feature on the native-tls crate, which itself doesn't have any documentation. I'd be nice if either the http2 feature or native-tls had a note mentioning you need native-tls-alpn for http/2 to work.
Due to how HTTP/2 works with most servers, you need to enable a TLS feature which will use ALPN. That's either
native-tls-alpn
, orrustls-tls
(and make sure your client builds withuse_rustls_tls()
). It's not enabled by default for native-tls because not all machines will have the necessary support (rustls does out of the box).
Does reqwest automatically reuse http2 connections? For example, I want to send multiple requests to the same URL.
let url = "https:://example.com";
let mut handles = vec![];
for i in 0..10 {
let client = client.clone();
let url = url.to_string();
let handle = task::spawn(async move {
let resp = client.get(&url).send().await?;
let text = resp.text().await?;
// println!("Response {}: {}", i + 1, text);
Ok::<(), reqwest::Error>(())
});
handles.push(handle);
}```
Requesting HTTP/2 on a request does not work:
Example code:
Cargo.toml:
Output:
In my app I'm developing, the warning "Connection is HTTP/1, but request requires HTTP/2" emits but the request goes through anyway using HTTP/1.1, which is causing issues because unfortunately the site I'm connecting to has different behavior when connecting with HTTP/2.
Adding
http2_prior_knowledge()
to the builder causes a different error (and that API is annoying because it applies to the entire client):The same error happens with
https://www.google.com
, so I don't think it's an issue with the particular server.Requests without
http2_prior_knowledge
orversion
don't seem to be upgraded to HTTP/2 at any point either.