Add support for HTTP proxies and SSL Client certificates?

[nickygerritsen]

Q	A
Bug?	no
New Feature?	yes

We are currently using this great library in a library we are creating, but we have two things that I think the library currently doesn't support:

• Allow requests to go through an HTTP proxy
• Allow requests to use an SSL client certificate to authenticate

I think most of the clients actually implementing the interface do support one or both these features, but the question is can we easily add this?

Perhaps we could add the following to the HttpClient (and HttpAsyncClient) interface?

<?php
interface HttpClient {
  public function supportsFeature($feature) : boolean;
}

And then defines these features somewhere, maybe as an interface HttpClientFeature (and then $feature can also be the name of a class implementing that interface). Finally we could add a method sendRequestWithFeatures(RequestInterface $request, $features) where features is an array keyed on feature classnames and the values are instantiations of HttpClientFeatures. The sendRequest can then possibly do a check whether the features are actually supported and if so, apply these features. If features are not supported, either throw an exception or silently ignore them.

What are the thoughts on this? If desired I am willing to help with implementing this.

[fbourigault]

Features looks over-engineering to me. HttpClient is an interface intended to be substituable. This help library developers to not be stuck because of incompatible guzzle versions required by two libraries. Instead, the application developer choose one implementation and all is fine.

For your case, I would simply choose an implementation which allows you to do proxy and client certificate authentication. Guzzle supports proxy through environment variables (but only supports uppercase environment variables, see guzzle/guzzle#1821). You can also use cURL configuration.

Using the configuration would also allows you to do client authentication!

[nickygerritsen]

But ideally I do not want the users of my library to be forced to use Guzzle or cURL as a client, therefore I wanted to use HttpClient

[fbourigault]

IMHO client authentication and proxy are out of scope of HTTPlug as it's not about HTTP but about networking. This has probably be debated by php-http members before I join. I let them answering you!

[dbu]

in my understanding, httplug is an interface that defines how a client can send a web request to receive a response. it is not a client configurator. proxies and https are implementation details that the client does not care about.

as far as i can see, PSR-7 also does not specifically support ssl, at least i found nothing in a quick search how one could add a client certificate. thus, i think we can't even provide support for this with a plugin in client-common. the only place this can be done is in the actual client implementation.

so for your library, it would be in the setup instructions. if you want, you could provide a client factory implementation that can create a guzzle adapter with a correctly configured guzzle inside. that way, the rest of your library is still decoupled from a concrete http client implementation and your users can build a different httplug object if they need anything special.

[nickygerritsen]

The problem for my library is that it talks to a couple of API's and currently one needs to use a proxy and an SSL client certificate for authentication. The proxy part is not the biggest problem as indeed this could be used for all connections, but the client certificate is only for one specific endpoint.

[dbu]

then either use a specific guzzle plugin that only uses the certificate on certain domains, or inject 2 separate clients for the different end points. or write a httplug client that wraps the 2 clients and picks one or the other based on the domain.

from my point of view, it would be problematic if client code could change all kind of configuration in request arguments. i assume that the authors of PSR-7 also see it that way, as they did not add options to send along with a request to control how it should be sent.

[Nyholm]

As David says, It is way out of scope for a HTTP client interface. It is configuration of a specific client and we currently has no intention in creating an abstraction over configuration.