I would like to propose the following namespace for our different package (goal is to have, in the future, possibility to assemble all package into a single one with subsplit):

• Httplug : Http\Client (not changed)
• Promise : Http\Promise (not changed)
• Message-Factory: Http\Message (not changed)
• Tools : Http\Tools (Http\Client\Tools actually)
• Utils : Http\Utils (Http\Client\Utils actually)
• Plugin : Http\Plugin (Http\Client\Plugin actually)
• Adapters (guzzle / react / ...) : Http\Adapters\[Adapter Name], so Guzzle6 will have this namespace for example : Http\Adapters\Guzzle6 (instead of Http\Adapter actually)
• Clients (socket / curl / ...) : Http\Clients\[Client Name], so Socket will have Http\Clients\Socket
• Discovery : Http\Discovery (not changed)

WDYT ?

The PHP HTTP client is an abstraction layer to separate general purpose libraries from concrete client implementations in order to make them move flexible. It is the successor of the Ivory HTTP adapter and we should not use Ivory anymore to keep it separate from all the other things under the Ivory name that do unrelated things.

Just calling it "php http" makes it impossible to find this thing in google, as almost website about web development has these keywords. We should have some additional name that makes it findable.

Ideas so far:

• CPHC/APHC for common php http client / abstract php http client by @dbu
• Klant by @hannesvdvreken
• Raspberry by @Zarkonnen
• Hunlet by @patkar
• Tupac by @greg0ire
• Straw by @Pierstoval
• Httplug (and variations) by @sandermarechal
• Phetch by @sandermarechal

• [x] Guzzle 6 (Implemented by @ddeboer)
• [x] Guzzle 5 (Implemented by @sagikazarmark and @Nyholm)
• [x] ~~Guzzle 4 (EOL)~~
• [x] ~~Guzzle 3 (EOL)~~
• [x] Curl (Implemented by @mekras)
• [x] Buzz (Implemented by @Nyholm)
• [x] Cake (Implemented by @joelwurtz)
• [x] ~~HTTPful~~ (Not important at the moment)
• [x] ~~PECL~~ (Not important at the moment)
• [x] React (Implemented by @shulard)
• [x] Socket (Implemented by @joelwurtz)
• [x] ~~Zend 1~~ (too old)
• [x] Zend 2 (Implemented by @joelwurtz)
• [x] ~~File get contents (?)~~ (Not important at the moment)
• [x] ~~Fopen (?)~~ (Not important at the moment)
• [x] ~~League Event (decorator)~~ (Hard to use with immutable messages)
• [x] ~~Symfony Event (decorator)~~ (Hard to use with immutable messages)
• [x] ~~Stopwatch (decorator)~~ (Implemented as plugin)

Currently each adapter of php-http will have his own repository, i'm afraid to see a big complexity if some days an interface need to be changed and all adapter will then have to be updated and match against the new version.

My proposal is to have all the code / issue / ... on one repository and make sub view (like symfony with its components), so a PR for updating a interface will also contain the modification for all corresponding adapter / client.

Hey @php-http/owners, @dbu and @ddeboer,

For the last few months I've made some progress with this project. Sadly, @egeloen disappeared so we couldn't work together or discuss the phases of the project. I really appreciate the help of everyone who participated. I think this will be a great part of the PHP community once it gets stable. I am completely commited to the project, and I already have some feedback that other projects would like to rely on it.

As said, @egeloen does not really respond to any of my attempts to contact him. @dbu agreed to contact him (or at least try it). Until then, I would like to make progress with the project and reach at least an alpha phase, so other projects can start working with the interface. This does not mean that @egeloen is not part of the team anymore, but we have been waiting for four months now...

The current proposal of the interfaces is in the terminology branch. Currently exceptions are being refactored. After that I am going to merge the terminology branch.

My purpose is to reach alpha till the end of September.

Now, that we are merging repositories together, the question comes up whether we should remove the deprecated repositories or not.

Pros:

• less repository, less confusion
• less repository, less maintenance

Cons:

• some of the repositories have already been tagged, which means they COULD be used somewhere. Fortunately packagist gives us information about dependent packages.
• we lose issues, PRs, history (which is probably not a big deal in the current phase of the project)

See #74 and #75 discussion for a more detailed description.

This PR intend to add asynchronous support for httplug by adding a new interface HttpAsyncClient which allow to send an asynchronous request and return a promise for the response.

The current Promise interface follow specification of https://promisesaplus.com/ from an user point of view (there is no method for fulfilling or rejecting the promise, it should be up to the implementation user only care on how to handle the return and not on how to resolve the promise)

We need to have a list of possible values for the options parameter. These are general options which should work with ALL the clients.

Possible options:

• timeout [0]
• exceptions [false]: whether the user wants 4xx and 5xx responses to be converted to exceptions
• base_uri [null]: from #36

This PR tries to solve #38

Some points to discuss:

• [x] Exceptions in the package: concrete implementations? Exception naming?
• [x] Interface names: PsrClient, HttpClient, Client? (proposed by @dbu HttpPsrClient, HttpMethodsClient, HttpClient)
• [x] Add ClientTemplate: better name?

To do before merging:

• ~~Squash commits!!!!!!!~~

To do after merging:

• [ ] Move the package to client (preserve the package here as well for historical reasons (0.1 release)?)

| Q | A | | --- | --- | | Bug fix? | yes | | New feature? | yes | | BC breaks? | no | | Deprecations? | no | | Related tickets | https://github.com/php-http/client-common/issues/34 | | Documentation | | | License | MIT |

This is not something that is meant to merge, it's to offer a point of view on this ticket https://github.com/php-http/client-common/issues/34 we should accept this or not based on the final decision.

Httplug interfaces does not provide a way to configure client behaviour such as timeouts, SSL settings or other parameters that cannot be set in the RequestInterface.

For example. In dev environments we want our HTTP client to ignore SSL errors. But we can do this only when instantiating particular implementation. It has two disadvantages:

1. we can't use HttpClientDiscovery;
2. code, where the client is introduced through the interface, can't change these settings.

I'd say PSR-18 was pretty successful. Guzzle, Buzz, Symfony and others support it natively, and some others support it via adapters.

However, this still doesn't help you very much if you need async HTTP requests. Although there is HttpAsyncClient in this package, it is still not standard, not many clients support it without adapters and some adapters seem to be outdated: Guzzle adapters do not support Guzzle 7 yet (which added PSR-18 support but does not support HttpAsyncClient promises), Buzz does not support HttpAsyncClient and adapter was discontinued... From popular clients, only Symfony supports it natively. This will become better when Guzzle 7 HttpAsyncClient adapter is released, but still not perfect.

So, will async HTTP clients (and promises which are requirement for async HTTP client PSR) ever become PSR standard and be directly supported in popular clients? What is current state of becoming standard? From quick (possibly incomplete) search through docs and closed issues, it seems there were some plans to make promise, event loop and async HTTP client PSR. However, discussions about this seem to have ended few years ago and some were "put on hold" until future.