I have to agree with Larry, having the behavior of a standard depend on
some configuration is risky. If the goal of the PSR is to be used by
libraries or frameworks (not end users) then it's fine to force a choice
IMO.
I have minor comments about the proposal, maybe it's too early to get into
details and create a proper thread but I would suggest making the
exceptions clearer:
* Exception for when a request failed. * Examples: * - Request is invalid
(eg. method is missing) * - Runtime request errors (like the body stream
is not seekable)interface RequestException extends Exception
How about InvalidRequestException? (I would suggest InvalidRequest but it
would be a waste of time :p)
We need to make it clear that the HTTP request did not fail, it's the
Request object that was invalid.
* Thrown when the request cannot be completed because of network issues. *
There is no response object as this exception is thrown when no response has
been received. * Example: the target host name can not be resolved or the
connection failed.interface NetworkException extends Exception
NetworkErrorException? OK maybe this one is too much (NetworkError would be
better but…)
And as said above HttpException should probably be removed entirely?
Matthieu
Le mardi 11 juillet 2017 18:33:15 UTC+2, Larry Garfield a écrit :
>
> I'm inclined to agree here. Error handling that may change based on some
> config not available to me in local scope, like PDO does, is a design flaw,
> as I then have to account for both possible error flows.
>
> I could be argued in favor of exceptions always or exceptions never (I'm
> leaning exceptions on all 4xx/xx right now, but could be convinced
> otherwise), but "exceptions sometimes" doesn't seem like a good choice.
>
> That said, that's a detail that doesn't block officially forming the WG;
> I'm +1 on approving this as a WG to hash out exactly those sorts of details.
>
> --Larry Garfield
>
> On 07/11/2017 11:12 AM, Josh Di Fabio wrote:
>
> Right, I see; I saw the *HttpException* class but I missed that it *MUST
> NOT be thrown when using the client's default configuration.*
>
> Having said that, I think the fact that the behaviour of *sendRequest()*
> varies
> based on some configuration which isn't available via the interface is
> actually worse than always throwing. Given that most people will be
> injecting their *HttpClient* instance into other objects and probably
> passing one instance around to multiple classes, the code which is calling
> *sendRequest()* won't generally have visibility over how the client is
> configured, so we'll have to be super defensive when calling the client to
> be sure we handle 4xx and 5xx responses correctly:
>
> try {
> $rep = $client->sendRequest($req);
> } catch (HttpException $e) {
> $rep = $e->getResponse();
> }
>
> It should either always throw or never throw. The behaviour of redirects
> should also be consistent or configurable via the interface or else
> autowiring will be useless for instances of *HttpClient*.
>
> On Tue, Jul 11, 2017 at 4:51 PM <tobias...@gmail.com <javascript:>> wrote:
>
>> I think I've been unclear or you misread something.
>> A HTTP client MUST NOT throw exceptions for any response.
>>
>> So I very much agree with you.
>>
>>
>> On 11 Jul 2017, at 17:45, Josh Di Fabio <joshd...@gmail.com <javascript:>>
>> wrote:
>>
>> This looks pretty good, but I don't like exceptions for 4xx and 5xx
>> responses, which smells of exceptions for flow control. Within the context
>> of HTTP there is nothing exceptional about 4xx and 5xx responses. Rather,
>> whether a certain response status is considered exceptional depends on the
>> context of the caller. For example, in many contexts a 3xx response would
>> be unexpected but a 404 response would not. Instead of throwing, the client
>> should simply return the response.
>>
>> On Tue, Jul 11, 2017 at 12:48 PM Alessandro Lai <alessand...@gmail.com
>> <javascript:>> wrote:
>>
>>> Very good suggestions.
>>> Also, it's very pleasant to see a PSR pushed this way and backed from
>>> the start by a working lib and all the interestend players. Really good job!
>>>
>>>
>>> Il giorno lunedì 10 luglio 2017 00:38:32 UTC+2, Larry Garfield ha
>>> scritto:
>>>
>>>> On 07/07/2017 12:20 PM, Tobias Nyholm wrote:
>>>>
>>>> Excellent questions. Thank you.
>>>>
>>>> The buy-in would be the same for every PSR, wouldn't it? Libraries do
>>>> not want to depend on an implementation or provide an implementation
>>>> themselves. They want the user to decide if a highly flexible client
>>>> (Guzzle) or a lightweight/fast client (php-http/curl-client). (Source:
>>>> https://github.com/joelwurtz/http-client-benchmark). Also, as you
>>>> probably noticed, there are representatives from all PSR7 compliant HTTP
>>>> clients in the workgroup.
>>>>
>>>>
>>>> That last point was what I was getting at, thank you. By buy-in, I
>>>> mean "do we have an indication that the major HTTP clients are going to
>>>> adopt it?" It sounds like the answer is a loud "yes", which is great to
>>>> see.
>>>>
>>>> The simplest answer of async or not is: There is not PSR for Promises
>>>> yet. I do not think the PSR for HTTP clients should define what the
>>>> industry standard for a Promise should be. I do also not think we should
>>>> wait with a PSR for HTTP clients until (if ever) a PSR for promises has
>>>> been released.
>>>>
>>>> We, php-http team, have followed discussions in
>>>> https://github.com/async-interop that sadly has been put on hold.
>>>>
>>>>
>>>> A fair reason, thanks. It may be worth mentioning in the metadoc,
>>>> including what a future Async version MIGHT look like if/when a Promises
>>>> PS
>>>> happens. (You don't need to implement it, just show that it could still
>>>> be
>>>> implemented.)
>>>>
>>>> --Larry Garfield
>>>>
>>>> On Friday, July 7, 2017 at 6:58:36 PM UTC+2, Larry Garfield wrote:
>>>>>
>>>>> The key for me is if the various HTTP clients have buy-in to implement
>>>>> the spec once completed. Is that the case?
>>>>>
>>>>> I would also ask why this is just for sync HTTP clients, not async.
>>>>> There's plenty of use cases for the latter. That may be scope creep, but
>>>>> I
>>>>> feel it's worth asking.
>>>>>
>>>>> --Larry Garfield
>>>>>
>>>>> On 07/07/2017 03:47 AM, Tuomas Koski wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> +1 for first creating working stuff and later doing effort to make it
>>>>> a good standard. Way better approach than the other way round :)
>>>>>
>>>>> Great work.
>>>>>
>>>>> Cheers and great weekends!
>>>>> --
>>>>> Tuomas
>>>>>
>>>>>
>>>>> On Thu, Jul 6, 2017 at 11:04 PM, Cees-Jan Kiewiet <cees...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hey,
>>>>>>
>>>>>> This looks interesting, would have to study this in detail but I do
>>>>>> like the simplicity from a quick read through.
>>>>>>
>>>>>> Cees-Jan
>>>>>>
>>>>>>
>>>>>> On Thu, Jul 6, 2017 at 6:08 PM, Tobias Nyholm <tobias...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hey.
>>>>>>>
>>>>>>> Im a co-creator of HTTPlug and a maintainer of a number of API
>>>>>>> clients. I would really like to see a PSR for synchronous HTTP clients.
>>>>>>> The
>>>>>>> HTTPlug has created a "meta-standard" which has been stable for 18
>>>>>>> months
>>>>>>> now. We believe it is a really good interface and would like it (or
>>>>>>> something similar) to be an official PSR.
>>>>>>>
>>>>>>> I would ask the Fig for an entrance vote.
>>>>>>>
>>>>>>> *Here is a first idea: *
>>>>>>> PSR:
>>>>>>> https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client.md
>>>>>>> Meta:
>>>>>>> https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client-meta.md
>>>>>>>
>>>>>>> *Workgroup*:
>>>>>>> These people has been contacted and said they are interested in
>>>>>>> participating in a workgroup.
>>>>>>>
>>>>>>> - Tobias Nyholm
>>>>>>> - Sara Golemon (cc)
>>>>>>> - Matthew O'Phinney (cc) (Maybe)
>>>>>>> - Mark Sagi-Kazar
>>>>>>> - Jermey Lindstrom
>>>>>>> - David Buchmann
>>>>>>> - Joel Wurtz
>>>>>>> - Simon Asika
>>>>>>> - Christian Lück
>>>>>>> - David De Boer
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "PHP Framework Interoperability Group" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to php-fig+u...@googlegroups.com.
>>>>>>> To post to this group, send email to php...@googlegroups.com.
>>>>>>> To view this discussion on the web visit
>>>>>>> https://groups.google.com/d/msgid/php-fig/0db70a2c-d528-44df-b7f5-62387eb67872%40googlegroups.com
>>>>>>>
>>>>>>> <https://groups.google.com/d/msgid/php-fig/0db70a2c-d528-44df-b7f5-62387eb67872%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>> .
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "PHP Framework Interoperability Group" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to php-fig+u...@googlegroups.com.
>>>>>> To post to this group, send email to php...@googlegroups.com.
>>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/d/msgid/php-fig/CAPY1sU_e%2BwDVGGm-3VGZzjNfPUpAyA3Ng6tk04%2BdtLcADMqAwA%40mail.gmail.com
>>>>>>
>>>>>> <https://groups.google.com/d/msgid/php-fig/CAPY1sU_e%2BwDVGGm-3VGZzjNfPUpAyA3Ng6tk04%2BdtLcADMqAwA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>>>>>>
>>>>>>
>>>>>>
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> --
>>>>> Tuomas
>>>>>
>>>>> Humap Software Ltd
>>>>> http://humapsoftware.com
>>>>> Twitter: @humapsoftware
>>>>> LinkedIn: https://www.linkedin.com/company/humap-software-ltd
>>>>> Facebook: http://facebook.com/humapsoftware/
>>>>> Instagram: @humapsoftware
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "PHP Framework Interoperability Group" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to php-fig+u...@googlegroups.com.
>>>>> To post to this group, send email to php...@googlegroups.com.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/php-fig/CAAND7_93GNv9R0_e%3DU-e%2B%3DfGWh%3D99hHR5RtkQb2Nde%2BvaSj5vA%40mail.gmail.com
>>>>>
>>>>> <https://groups.google.com/d/msgid/php-fig/CAAND7_93GNv9R0_e%3DU-e%2B%3DfGWh%3D99hHR5RtkQb2Nde%2BvaSj5vA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>>
>>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "PHP Framework Interoperability Group" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to php-fig+u...@googlegroups.com.
>>>> To post to this group, send email to php...@googlegroups.com.
>>>>
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/php-fig/6ac1a1f0-f62b-42e3-912c-74faa3e28950%40googlegroups.com
>>>>
>>>> <https://groups.google.com/d/msgid/php-fig/6ac1a1f0-f62b-42e3-912c-74faa3e28950%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "PHP Framework Interoperability Group" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to php-fig+u...@googlegroups.com <javascript:>.
>>> To post to this group, send email to php...@googlegroups.com
>>> <javascript:>.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/php-fig/f47fa29c-7176-44a5-bd0c-436df87f34a6%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/php-fig/f47fa29c-7176-44a5-bd0c-436df87f34a6%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>>
>> You received this message because you are subscribed to a topic in the
>> Google Groups "PHP Framework Interoperability Group" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/php-fig/iFZF6T9L2zA/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> php-fig+u...@googlegroups.com <javascript:>.
>>
>>
>> To post to this group, send email to php...@googlegroups.com
>> <javascript:>.
>>
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/php-fig/CAKiSzdBMhrjab-VzrASmu%2B5audhGt-KEbrsx7TM%2BBSwPgbwmcg%40mail.gmail.com
>>
>> <https://groups.google.com/d/msgid/php-fig/CAKiSzdBMhrjab-VzrASmu%2B5audhGt-KEbrsx7TM%2BBSwPgbwmcg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "PHP Framework Interoperability Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to php-fig+u...@googlegroups.com <javascript:>.
>> To post to this group, send email to php...@googlegroups.com
>> <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/php-fig/6383CD29-BA16-4253-91C3-72CBDB2EA9F6%40gmail.com
>>
>> <https://groups.google.com/d/msgid/php-fig/6383CD29-BA16-4253-91C3-72CBDB2EA9F6%40gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to php-fig+u...@googlegroups.com <javascript:>.
> To post to this group, send email to php...@googlegroups.com <javascript:>
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/CAKiSzdDmRdzeCjWghZSWpeHLskpUg-cq5xu%2B485GoAdyo7-%2BNg%40mail.gmail.com
>
> <https://groups.google.com/d/msgid/php-fig/CAKiSzdDmRdzeCjWghZSWpeHLskpUg-cq5xu%2B485GoAdyo7-%2BNg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/1d1ec08b-e479-47ef-a8d8-356ded488765%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
