awslabs
Expose hyper 1.0 client builder behind not stable feature flag
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 https://github.com/awslabs/aws-sdk-rust/discussions/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
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?
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.
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.
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.
