MultiHttpClient

[joelwurtz]

Having a client that accept multi http clients, when it receives a request it will duplicate the call to all the underlying client and return a BatchResponse (like the batchclient)

It should done the call in async mode if possible or in sync mode if no async is available.

One of the use case can be for FosHttpCache when we need to send a request over multiple varnish instance.

[sagikazarmark]

I don't think we can use BatchResponse in this case, as Responses are indexed by request, which is only one in this case. You either have to clone the requests or create a response object which indexes responses by client.

[joelwurtz]

Good point, we will need to map the response with the httpclient in this case IMO.

[dbu]

in FriendsOfSymfony/FOSHttpCacheBundle#283 we found that we should be able to use the --resolve option of curl [http://serverfault.com/questions/443949/how-to-test-a-https-url-with-a-given-ip-address](to force the IP of a domain), which translates to CURLOPT_RESOLVE in php .

it would be great if the multiplexer could handle this situation. any idea how we could achieve this in a generic way? or can / should we somehow pass information down to the actual implementation?

[sagikazarmark]

Maybe your Capability idea could work here. Pair a client with a (set of) RequestMatcher and send the request with the matching client.

[dbu]

but that only delegates the problem to the matching client. we need to send the same request to various IPs, and we found that if HTTPS is used, the certificate will be for the HOST header, but curl at least verifies based on the IP that was used, not on the hostname.

[dbu]

in FOSHttpCache, this is what we currently do: https://github.com/FriendsOfSymfony/FOSHttpCache/blob/master/src/ProxyClient/HttpDispatcher.php#L188

its a very specific scenario, however. and i think all scenarios that require sending a request to multiple hosts are very specific. you also would need to change the requests one way or another in each client, to make this actually do anything. therefore i am not sure if we should provide something here.