feat(client): allow to specify a specific remote adress on client request

[joelwurtz]

This add the possibility to set a specific socket address for a request which can be useful during testing or when you already know the target server ip address / port

[fakeshadow]

Wouldn't make more sense to just overwrite the uri accordingly for use case like this? That way your logic is not bound to any http client crate and can be self contained in http types.

[joelwurtz]

It depends on the use case: actually the host in the uri will do 3 things :

• Set the host header (or authority pseudo header) in the request
• Set the sni name for certificate verification
• Used for resolving the socket addr

I have use case where i may need different value for this 3 behavior :

• Forcing the use of a specific server for dev purpose
• Proxying content to a web server but keeps host intact
• Using a specific sni name (that's why i have also done feat(client): allow to set a specific sni hostname per request #1171 )

So changing it in the url would break other behavior (not the correct host / sni on the targeted backend as an example)

Our current use case is that we are building a proxy server where our client can configure this 3 fields independently since some of them have this need, (was already the case when using another lib, but there was a lot of hack to make this configurable)

[fakeshadow]

We are very careful when extending http types. Reason being they are already large with big memory footprint which can be problematic when moving the ownership around. (compiler can have difficulty eliding memory copy)

Any type bloat for niche use case would be an overhead for otherwise and for now I would suggest using extension together with a customized resolver for it. We can look into how resolver's API can be reworked to co-op with it.

[joelwurtz]

My main problem on the resolve API for that is that it happens after fetching the connection from the pool

Which means, even if i use an extension point and we allow custom resolver to look at extensions, if i have 2 requests on the same host but with a different address extension, the second one will use the connection of the first one (since connection was already existing).

I began to look at changing this order (first resolve, then pool based on resolved socket address) but not sure if you want to allow that since it's a pretty big change in terms of how things work for the client.

[joelwurtz]

Also this means that current client will not handle DNS change if there is an existing connection until the connection is dropped

[fakeshadow]

We can also look into the pool api and it's interaction with resolver. My guess is it's OK to outsource fast DNS look up to user implemented resolver and do unconditional look up for ever request. As for dns changes infecting connection pool it would be another story for another issue.

[fakeshadow]

I have been looking into making connection pool into a generic service that can be provided by user code. It would help to enable this use case of conditional override of pooling and/or customized connection object and it's identifier.
@joelwurtz Do you think this approach would work for your use case?

[joelwurtz]

I think it would,

I was also thinking that it would be the best approach.
Does this service is also responsible for creating the connection ?

I think the best approach would be for the client to depend on a service that gives us a stream from the request, something like

async fn call(&self, req: &Request) -> HttpStream

where HttpStream can be either a H1 / H2 / H3 connection implementing the Stream interface (so we could forward it to the correct dispatcher)

Then resolve + pool + connection creating could be delegated to this service (and we could define our own if it's possible)

This would allow a lot of features that may not be suitable here but could be implemented by replacing those services (such as load balancing / forcing socket address / specific connection implementation / etc ...)