Re: The progress of HTTP client

The problem with dumping all of the error handling and redirection logic into the client itself is that it presumes what you want that error handling and redirection logic to be. If a response comes back with a 301 Moved Permanently, I may want to know that so I can update my own records (eg,

Re: The progress of HTTP client

I've reviewed the current doc and there are two points I highly disagree with and that does not seem to fit common use-cases. 1. The spec says, implementation must not follow redirects. This means any user of those interfaces must re-implement redirections themselves? I don't see how this

Re: The progress of HTTP client

Thank you Luis for the feedback. Here are some short answers: * Regarding async: See the meta document: https://github.com/php-fig/fig-standards/blob/master/proposed/http-client/http-client-meta.md * Method signature: We want to make sure that major libraries could implement this interface

Re: The progress of HTTP client

My 2p: - This PSR needs async, otherwise there's not much value on it - I'd recommend following closely what guzzle is already doing - sendRequest is redundant. public function send(RequestInterface $request): Response - Exceptions should be way more verbose: need

Re: The progress of HTTP client

Uri uri = new Uri("..."); try { HttpClient client = new HttpClient(); var downloadTask = client.GetAsync(uri); downloadTask.Progress = (result, progress) => {

Re: The progress of HTTP client

Good to hear it was just a typo :) > The specification looks good, we are currently deciding on an upgrade path from HTTPlug. We have a proposal that we think will work. Does that mean the interface is likely to remain the same? I'm currently working on an upgrade for Omnipay from Guzzle to

Re: The progress of HTTP client

As per our bylaws (see https://www.php-fig.org/bylaws/psr-workflow/#abandoned), abandonment must be explicitly declared either by an abandonment vote, or by a secretary, but with some prerequisites: - missing editor or sponsor for more than 60 days (not the case here) - no activity in 6

Re: The progress of HTTP client

As far as I know, PSR-18 has never been marked as abandoned, I don't even think the requirements to do so have ever been satisfied. Could the secretaries confirm, please? Il giorno gio 15 feb 2018 alle ore 08:47 Tobias Nyholm < tobias.nyh...@gmail.com> ha scritto: > Yeah, it has stalled for a

Re: The progress of HTTP client

Yeah, it has stalled for a few weeks. but we are working on it again. The specification looks good, we are currently deciding on an upgrade path from HTTPlug. We have a proposal that we think will work. I've invited a few to have a look on it (Sara included). If this small group think it is

Re: The progress of HTTP client

Apologies, I now see that PSR-18 is referenced in the Sunshine meetings (https://groups.google.com/forum/#!topic/php-fig/sjASl6ltjHI ) > > > PSR - 18 HTTP Client (*Abandoned*) > >- Tobias identified an issue and will be notifying the group to source >needed changes. > - Tobias

Re: The progress of HTTP client

The best way to go is using Windows.Web.Http.HttpClient instead of System.Net.Http.HttpClient. The first one supports progress. php training in chennai > -- You received this message because

Re: The progress of HTTP client

> > *Client:* > You are just referring to an example that show that if you modify the body > you must to the same modifications on the headers. > Yes, I guess that's rather a specific question, as it should be clear to other modifications. Should the `transfer-encoding: chunked` header be

Re: The progress of HTTP client

Thank you. *Client:* You are just referring to an example that show that if you modify the body you must to the same modifications on the headers. *Exceptions:* By "smaller issues" we mean: Things that do not stop you form sending a request. If you are using the wrong HTTP version in the

Re: The progress of HTTP client

I have just reviewed the current document, you can find my feedback below. *Client: *It specifies that a client that decodes a gzipped body must remove the corresponding header. Does it also have to remove a chunked encoding header? It's a requirement of the HTTP specification that a client

Re: The progress of HTTP client

On Tuesday, December 5, 2017 8:17:49 PM CST Sara Golemon wrote: > On Monday, December 4, 2017 at 8:44:41 AM UTC-5, Woody Gilk wrote: > > Regarding the exception interfaces: > > > > interface ClientException extends \Throwable > > > > Why Throwable instead of Exception or RuntimeException? > >

Re: The progress of HTTP client

On Monday, December 4, 2017 at 8:44:41 AM UTC-5, Woody Gilk wrote: > > A couple of notes: > > public function sendRequest($request) > > Could this be made shorter, without losing meaning? > > public function send($request) > > IMO interfaces should have more-expressive names to avoid colliding

Re: The progress of HTTP client

Thank you for the review. Using `send` would make us incompatible with Guzzle and Buzz. It would force php-http's clients to have two methods doing the same thing. So we are more pragmatic here by using `sendRequest`. About `\Throwable`... Im not sure. I will do some research and make a PR

Re: The progress of HTTP client

A couple of notes: public function sendRequest($request) Could this be made shorter, without losing meaning? public function send($request) Regarding the exception interfaces: interface ClientException extends \Throwable Why Throwable instead of Exception or RuntimeException? Everything