reqwest

reqwest copied to clipboard

#1558

• [x] Add small pool of HTTP/3 connections.
• [x] Using (Rustls) TLS config for setting up connection.
• [x] Use the SendRequest to start sending a request.
• [x] Reuse DNS resolvers.

It would be great to get some feedback. Thanks in advance.

Reuse DNS resolvers.

Resolution is done internally in hyper so there is no way to reuse the resolvers without re-implementing most of what is already in hyper. Thoughts?

This is so so exciting. I've noticed you kept pushing changes, so I wasn't sure when you felt it was "ready". Or maybe you felt it always was and just kept tweaking things to be a little better while waiting for me, in which case sorry!

This is so so exciting. I've noticed you kept pushing changes, so I wasn't sure when you felt it was "ready". Or maybe you felt it always was and just kept tweaking things to be a little better while waiting for me, in which case sorry!

No problem! I did run some tests and found things that needed to be improved but now I think it's ready for another round of review. :blush:

Ok, this is phenomenal! Now I'm left wondering what the best way to expose an "experimental" features is...

• Ideally it'd just require RUSTFLAGS=--cfg reqwest_unstable_h3 and we write cfg(reqwest_unstable_h3) internally.
• But we can't publish a version to crates.io that has a git dependency on h3.
  • Is there a way around this?
    • Can we abuse a build script to check for the flag and then edit the Cargo.toml? I know, sounds horrible. :shrug:
      • Probably won' work, though...
• So, do we just publish 0.0.0-breaking-galore.1 versions of h3 that reqwest can depend on?
• Any other suggestions? 🙈

Ideally it'd just require RUSTFLAGS=--cfg reqwest_unstable_h3 and we write cfg(reqwest_unstable_h3) internally.

Instead of leaving it behind feature flag, I'd say do a beta version and call for testing, and if an issue is found after a final is release that requires a breaking API, do a breaking release. You can just mention that it's experimental in docs to be clear it's fresh code.

* But we can't publish a version to crates.io that has a git dependency on `h3`.
  
  * Is there a way around this?
    
    * Can we abuse a build script to check for the flag and then edit the `Cargo.toml`? I know, sounds horrible. shrug
      
      * Probably won' work, though...

* So, do we just publish `0.0.0-breaking-galore.1` versions of `h3` that `reqwest` can depend on?

The h3 people can be encouraged to publish an alpha version perhaps.

So, do we just publish 0.0.0-breaking-galore.1 versions of h3 that reqwest can depend on?

Yes, I think this would be better. Please let me know if I can help with that over in h3.

Using (Rustls) TLS config for setting up connection.

Can you please implement it also for native-tls?

Native-tls uses openssl on Linux, and they don't have the needed methods to start a QUIC connection.