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 <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
> <mailto:[email protected]>> 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
>> <[email protected] <mailto:[email protected]>>
>> 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
>>>> <[email protected]> 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
>>>> <[email protected]> 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
>>>> [email protected].
>>>> To post to this group, send email to
>>>> [email protected].
>>>> 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
>>>> [email protected].
>>>> To post to this group, send email to
>>>> [email protected].
>>>> 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
>>>> [email protected].
>>>> To post to this group, send email to
>>>> [email protected].
>>>> 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 [email protected].
>>> To post to this group, send email to
>>> [email protected].
>>
>>> 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 [email protected]
>> <mailto:[email protected]>.
>> To post to this group, send email to [email protected]
>> <mailto:[email protected]>.
>> 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 [email protected]
>> <mailto:[email protected]>.
>>
>> To post to this group, send email to [email protected]
>> <mailto:[email protected]>.
>> 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 [email protected]
> <mailto:[email protected]>.
> To post to this group, send email to [email protected]
> <mailto:[email protected]>.
> 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 [email protected]
> <mailto:[email protected]>.
> To post to this group, send email to [email protected]
> <mailto:[email protected]>.
> 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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/99036ff6-b78f-0cc4-ed76-d810fa5f66e5%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
