David Buchmann

this should be fixed in https://github.com/php-http/client-common/releases/tag/2.5.1 now. can you confirm and close the issue if its ok, please?

seems like a good idea to me. i would not want generic options on the psr client itself, but for discovery it seems fine. ideally, the discovery would also know...

that sounds useful! does it introduce any additional dependencies? even if not, i wonder if it should be part of client-common or its own repository. its a bit hidden away...

i guess `\SoapClient` is only available with the soap extension. not sure if it could be a problem for people without soap extension if this file exists and some tool...

i guess java people still sometimes do soap. or you build a system that needs to talk to a legacy system that is written in soap. in our projects we...

awesome, thanks for those links! do you want to add a sub-section "Third party PSR-18 clients" to https://docs.php-http.org/en/latest/clients.html that links to those 2 packages?

i think generally we are open to contributions. while this is quite expressive to read, i think this creates a lot of classes and method calls. how about a RequestMatcherFactory...

i think what we need is a cache that would give us all variants we currently have. we would look at each candidate and check our headers for the vary...

we could port (or reuse?) the store that symfony HttpCache uses: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpKernel/HttpCache/Store.php#L140-L165 symfony HttpCache\Store has two flaws for us: - it is written around the symfony Request and not PSR-7....

let whoever wants to work on this check what is easier. i am afraid that using the symfony httpkernel component is a lot of additional code for a class that...