Proposed guideline for the client:
- If it's possible to return an accurate HTTP response object, do so,
whatever it is. (Even if it's a 500 or 418, it's still a valid response
object.)
- If it's not possible to return an accurate HTTP response object, throw
an appropriate exception. Because there's no legit return value to
return, an exception is the appropriate alternative.
Does that seem reasonable?
--Larry Garfield
On 08/26/2017 07:35 AM, Jason Judge wrote:
> This is my preference too. A 40x or 50x being returned from the remote
> endpoint is an exception /at the remote end/. Whether it is an
> exception in your application is up to your application. The response
> should still be available in full, which can be difficult or at least
> a little clunky to get hold of if the client is throwing exceptions on
> behalf of your application. So IMO the client should get the HTTP
> response, provide the result, then leave the application to decide for
> itself whether has now entered an exceptional state that it cannot get
> out of.
>
> There may be exceptions raised locally, for example if the URL is
> invalid (if that is even possible, if the URL is an object that /must/
> be valid just to be instantiated), but they are local exceptions for
> which there is not even a response to see. Not sure if timeouts are in
> this category.
>
> -- Jason
>
> On Friday, 25 August 2017 09:10:06 UTC+1, Barry vd. Heuvel wrote:
>
> So given the unanimous support for the HTTP Client and the current
> implementations, the only actual point of discussion is the
> throwing of Exceptions on 4xx/5xx responses, right?
>
> As a library maintainer, I'd like to rely on the behavior of the
> Client, so either ALWAYS or NEVER, not depending om some hidden
> config. Otherwise I'd have to check both cases again every time.
> And in that case my preference would be to NOT throw exceptions on
> 4xx/5xx errors.
>
> Hope this will make it to a real PSR soon :) Good job!
>
> Op vrijdag 4 augustus 2017 10:25:03 UTC+2 schreef Márk Sági-Kazár:
>
> Hi all,
>
> Joining the discussion as one of the PHP-HTTP founders.
>
> I am not 100% aware of all major HTTP clients wanting to
> implement this PSR, but I can speak for Guzzle where the
> answer is clearly YES. As for other clients: PHP-HTTP has
> adapters for major HTTP clients, so there is proof that the
> interface can work together with those clients, but given how
> adoption looks like now, I have the impression that it's not
> going to be a problem.
>
> As for exceptions: we had quite a few discussions about
> throwing exceptions for HTTP errors. We decided that clients
> should never throw such exceptions, not even with a secret
> configuration. The reason behind is simply what's already been
> said above.
>
> There are two common exceptions to this rule:
>
> - In case of adapters (if the underlying client supports this
> feature) we do not forbid this behavior, but we require that
> with the default configuration the client does not throw
> exceptions. When a client implements this PSR, it should stop
> throwing exceptions.
> - There is a PHP-HTTP plugin which converts 4xx/5xx HTTP
> errors to exceptions, but it has been said a thousand times (I
> think it's mentioned in the documentation as well) that this
> plugin should only be used when there is no business logic
> wrapped around the HTTP workflow or for testing purposes.
>
> Except the two points above, throwing exceptions is already
> forbidden I think.
>
> Mark
>
> 2017. július 13., csütörtök 14:17:23 UTC+2 időpontban Tobias
> Nyholm a következőt írta:
>
> Thank you for all your comments and suggestions. I will
> bring these to the work group if/when it is approved.
>
> I lean towards NEVER throw exceptions.
>
> And about the exceptions: I agree, they could maybe need
> some renaming and updates to be more clear.
>
>
>
> On Tuesday, July 11, 2017 at 11:18:30 PM UTC+2, Matthieu
> Napoli wrote:
>
> 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
>> <[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]> 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]> 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
>>>>
>>>> <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
>>>> <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
>>>>>
>>>>> <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
>>>>>
>>>>> <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
>>>>>
>>>>> <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
>>>>>
>>>>> <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
>>>>>
>>>>> <https://www.linkedin.com/company/humap-software-ltd>
>>>>> Facebook:
>>>>> http://facebook.com/humapsoftware/
>>>>> <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
>>>>> <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
>>>> <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/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
>>> <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
>>>
>>> <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].
>>>
>>> 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/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
>>> <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/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
>> <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/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
>> <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/5aa5e0d1-81db-4ee0-a618-a7fb6a2b2a86%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/5aa5e0d1-81db-4ee0-a618-a7fb6a2b2a86%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/e69abcaa-a18f-6648-40b5-c107927fca68%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
