Stabilize HTTP/3 feature

[seanmonstar]

This is a tracking issue to stabilize the HTTP/3 support in reqwest. These are the minimum things that are needed before we can promote HTTP/3 from unstable.

Work needed

• [x] Support streaming requests in HTTP/3
• [x] Ensure no types from h3 or quic are exposed
• [x] #2322

[ducaale]

• [ ] Support streaming requests in HTTP/3

Can this be considered done with https://github.com/seanmonstar/reqwest/pull/2673?

[seanmonstar]

Nice, thank you!

[matty-kuhn]

What further work needs to be done for this? I'm interested in contributing, as it seems like this is blocking HTTP/3 support in multiple libraries (hyper, tonic), and I can't seem to find anywhere else that would help move the progress along

[seanmonstar]

This isn't blocking support in other libraries (well, not the ones you listed). See https://github.com/hyperium/hyper/issues/1818 for work in hyper.

It's true that feature seems to be more robust here in reqwest. I'd be happy to move it along. I believe @ducaale also was asking if the cfg(reqwest_unstable) part could be removed, and it just have some other way to indicate that it's maybe beta level.

However, I also just now started wondering what would happen as the hyper work progresses, how could reqwest depend on it. Especially if we got rid of the cfg(reqwest_unstable) flag. We might need some way to indicate wanting to opt-in to using the code directly in hyper, once its unstable support is merged in.

At the same time, the code in-tree in reqwest seems to work well. Perhaps one possibility is:

• Change http3_prior_knowledge() to http3_experimental_intree_prior_knowledge(), not requiring a cfg(). It works, but using the new stuff will likely need opting in a different way. All the other methods don't need to change, perhaps just the ones to turn it on.
• Then as hyper releases a version with hyper_unstable_http3 available, we add in some http3_experimental_hyper_prior_knowledge(), that does require cfg(reqwest_unstable) (or maybe just cfg(hyper_unstable_http3)?).

Thoughts?

[matty-kuhn]

Thanks for pointing out the hyper ticket! In regard to stabilizing the features in reqwest, since I haven't contributed to the project, I'd say take my suggestions with a grain of salt, but as a consumer, I tend to prefer feature gates over convoluted function names, simply from an ergonomics perspective, so I'd like something like http3_prior_knowledge() behind a reqwest_unstable flag

[TroyKomodo]

Please consider this too https://github.com/seanmonstar/reqwest/issues/2566