Repository navigation
Decompose Client into utils #3080
Description
Besides a connector and pool, the Client from 0.14.x did many small things that should be decomposed into pieces in hyper-util, so users can choose to compose the parts they want.
- Create a
SetHostservice layer (could also fit intower-http) (0.14.x code) - Create a
Http1RequestTargetservice layer (0.14.x code) - Create a
DelayedReleaseservice layer (0.14.x code) - Create an
AutoConnectionwhich can wrap HTTP/1 and HTTP/2 (and eventually 3) connections
Activity
seanmonstar commentedon Mar 2, 2023
@davidpdrsn hey! any thoughts about some of these things moving to tower-http? Or should they stay as hyper-util? Or a 3rd option?
tomkarw commentedon Jul 28, 2023
Is this issue up to date? If yes, I'd be happy to pick it up.
As for the
tower-httppart, I don't think it's a blocker for now, we can always move that part of code to a different crate once it's extracted.seanmonstar commentedon Jul 28, 2023
I believe so, yea!
tomkarw commentedon Aug 7, 2023
@seanmonstar How should we deal with information that was available in the broad context of
send_requestfunction, but won't be available now in the narrower context of the middleware?Both
Http1RequestTargetandDelayedResponserequirespooled(some context about the already established connection) which is not trivially available inServicemiddleware.seanmonstar commentedon Aug 30, 2023
@tomkarw Do you mind expanding on what you think is needed? Such as the
is_proxiedpart? I've been thinking that could go somewhere else and not be part of the connector anymore. Possibly a request extension...tomkarw commentedon Jan 26, 2024
Current
v0.14.xClient had following logic: if the connection info indicated that the request is being proxied, and the schema was exactly HTTPS, we normalize the URI to the origin form (stripping the host). When makingHttp1RequestTargetaService, we need to work with an interface that only exposesRequest. We loose this tight coupling with the connection pool and thus connection info.We need to decide whether we:
Request(like in theextentions?)is_proxiedwhen instanciating the Service, but that doesn't work, as theis_proxiedper-connection (and thus per-request) information and should be determined separetly for each request.