Expose hyper 1.0 client builder behind not stable feature flag

[mattklein123]

Describe the feature

I'm trying to upgrade from the hyper 0.14 impl to hyper 1.x impl for the HTTP client. I use to customize things like HTTP client buffer sizes to constrain or expand memory usage in certain cases (favoring memory usage vs transfer speed depending on the case). I would like to control similar settings on the hyper 1.x implementation.

I see per #1261 that you don't want to expose the hyper_util stuff because it's unstable. Fair enough. However, can you possibly expose the ability to pass in a hyper builder behind some kind of unstable feature flag on the crate? Then users can opt-in and suffer the consequences of future breakages. This seems like a very small change with low risk to you which otherwise forces everyone to make a fully custom HTTP client which seems like overkill.

Thanks for considering.

Use Case

Customize the HTTP client without having to fully fork it.

Proposed Solution

No response

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

A note for the community

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue, please leave a comment

[ysaito1001]

Thank you for submitting a feature request. While topic has come up in our past discussions, we didn't expose an unstable feature at the time since we wanted to monitor how the hyper-util crate might evolve toward stability.

Just to take a step back, what are the problems you're running into, without the ability to constrain buffer sizes or to expand memory usage?

[mattklein123]

Just to take a step back, what are the problems you're running into, without the ability to constrain buffer sizes or to expand memory usage?

I can't change any settings without being able to call methods on the builder: https://docs.rs/hyper-util/latest/hyper_util/client/legacy/struct.Builder.html. Specifically things like forcing HTTP/1 if I want, setting HTTP/1 buffer sizes, settings HTTP/2 window sizes, etc. So I guess sure if you give me pass throughs for all of these methods that would be great but I would settle for just setting an unstable feature and being responsible for any future breakages.

[mattklein123]

Just to take a step back, what are the problems you're running into, without the ability to constrain buffer sizes or to expand memory usage?

Sorry at an even higher level I'm trying to better control S3 download and upload throughput in different scenarios which to do well requires different settings to be applied.

[aagmv]

The announcement also suggests this option

Bring your own HTTP client abstraction configured however you'd like by implementing the appropriate trait(s).

Some concise example code would help here, which can then be adapted to newer hyper-util versions as needed.

Sorry at an even higher level I'm trying to better control S3 download and upload throughput in different scenarios which to do well requires different settings to be applied.

Same here. S3 documentation recommends using multiple connections. So I suspect HTTP2's connection multiplexing is detrimental to throughput, to confirm I would have to experiment with http client settings which I can't do with the current default client.