Definitely agree with making PSR-15 about server side middlewares only. Joel mentioned several reasons why client-side middlewares needed something different (e.g. the ability to reference the root middleware, for example to follow a redirect through the whole stack again).
Also that would maybe mean we can get rid of the dual "MiddlewareInterface" and "ServerMiddlewareInterface"? Matthieu Le mercredi 2 novembre 2016 23:28:59 UTC+1, Michael Mayer a écrit : > > Woody, > > I have no experience in standardization processes, hence everything is > acceptable to me. However, I see an additional benefit of two PSRs: it > would be much easier to superseded them independently – hopefully that does > never happen ;) > > Best regards, > Michael > > Am Montag, 31. Oktober 2016 14:50:39 UTC+1 schrieb Woody Gilk: >> >> Michael, >> >> Thanks for bringing this up. For historical context, I have always >> thought of "client middleware" as middleware that does not require the >> additional methods defined in ServerRequestInterface. The consideration of >> async vs sync requests was never something that entered my mind. >> >> Reviewing the Guzzle docs again (as the most mature PSR-7 client-focused >> package I know of) it certainly appears that the current PSR-15 signatures >> would not work there. That is obviously a serious flaw. >> >> However, since there is not currently a ratified PSR for async, perhaps >> the best thing to do would be to repurpose PSR-15 to be entirely >> server-focused middleware? I would rather defer the creation of a spec for >> client middleware until the async PSR is complete. >> >> Would that be an acceptable situation for you? I don't want to create >> something that async clients will never be able to use. >> >> Regards, >> >> -- >> Woody Gilk >> http://about.me/shadowhand >> >> On Sat, Oct 29, 2016 at 4:47 PM, Michael Mayer <mic...@schnittstabil.de> >> wrote: >> >>> Hi everyone, >>> >>> I'm a little bit surprised to see so many suggestions about how >>> ServerMiddlewareInterface and ClientMiddlewareInterface should look like, >>> obviously without much knowledge about the client-side. >>> >>> The current state >>> <https://github.com/php-fig/fig-standards/blob/82e2d1c1fd9a3782e0707cf0d4449b28cca8ffa9/proposed/http-middleware/middleware.md> >>> >>> is: >>> >>> interface MiddlewareInterface {} >>> >>> interface ClientMiddlewareInterface extends MiddlewareInterface >>> { >>> public function process(RequestInterface $request, DelegateInterface >>> $next); >>> } >>> >>> interface ServerMiddlewareInterface extends MiddlewareInterface >>> { >>> public function process(ServerRequestInterface $request, >>> DelegateInterface $frame); >>> } >>> >>> interface DelegateInterface >>> { >>> public function next(RequestInterface $request); >>> } >>> >>> >>> <https://github.com/php-fig/fig-standards/blob/master/proposed/http-middleware/middleware.md#23-psrhttpmiddlewareclientmiddlewareinterface> >>> >>> >>> >>> Here are some falsehoods about the client-side, the list seems, by far, >>> not exhaustive. >>> >>> *1. HTTP Clients return their results synchronously* >>> It would be very clumsy to load a web page nowadays with all its assets >>> sequentially. Thus HTTP clients like Guzzle >>> <https://github.com/guzzle/guzzle> use asynchronous techniques like >>> Promises (e.g. Guzzle Promises <https://github.com/guzzle/promises>), >>> callbacks (e.g. node.js), generator based control flow, etc. >>> >>> An example: >>> >>> $request = new \GuzzleHttp\Psr7\Request('GET', 'http://httpbin.org'); >>> $promise = $client->sendAsync($request)->then(function ($response) { >>> echo 'I completed! ' . $response->getBody(); >>> }); >>> >>> >>> *2. Client Middlewares just transform Requests to Responses, doing it >>> **synchronously >>> is not a problem* >>> Maybe, this is appropriate on the server side, but not on the client. >>> Just think about a Middleware which adds cookies to requests. >>> >>> From GuzzleHttp/Middleware >>> <https://github.com/guzzle/guzzle/blob/5a5893c19f798175869eb94a88bb0b73e7acfb05/src/Middleware.php#L17-L44> >>> : >>> return function ($request, array $options) use ($handler) { >>> // … >>> $request = $cookieJar->withCookieHeader($request); >>> return $handler($request, $options) >>> ->then(function ($response) use ($cookieJar, $request) { >>> $cookieJar->extractCookies($request, $response); >>> return $response; >>> } >>> ); >>> }; >>> >>> The Middleware have to: >>> >>> 1. add the current cookie to the header: ->withCookieHeader($request) >>> 2. call the delegate: $handler($request, $options) >>> 3. extract the cookie >>> >>> As the delegate returns a promise, we need to: $handler(…)->then(…). >>> Can we do better, e.g. use a sync delegate/handler? Nope, this would >>> lead to call $promise->wait() within the delegate, which isn't >>> performant. >>> >>> *3. Client Middlewares call their delegate almost once* >>> For the client-side it's absolutely valid to retry a request, e.g. >>> GuzzleHttp/RetryMiddleware >>> <https://github.com/guzzle/guzzle/blob/113071af3b2b9eb96b05dab05472cbaed64a3df4/src/RetryMiddleware.php> >>> >>> *4. Client Middlewares don't need to create requests, they can modify >>> the given $request* >>> Just think about an authorization middleware, e.g. for OAuth or similar. >>> It would be dangerous or at least very odd to reuse $request for login >>> endpoints: >>> class AuthMiddleware implements ClientMiddlewareInterface >>> { >>> // … >>> public function process(RequestInterface $request, DelegateInterface >>> $next) >>> { >>> if ($this->accessToken === null) { >>> $loginRequest = $this->createLoginRequest(); >>> $this->accessToken = $next->next($loginRequest)->getBody()-> >>> getContents(); >>> } >>> >>> $request = $request->withHeader('Authorization', $this-> >>> accessToken); >>> return $next($request); >>> } >>> >>> >>> private function createLoginRequest() >>> { >>> $req = $this->requestFactory->createRequest('POST', '/login'); >>> // add $login, $password… >>> return $req; >>> } >>> } >>> >>> This was just some food for thought, hopefully pushing PSR-15 a bit >>> forward. >>> >>> Best regards, >>> Michael >>> >>> -- >>> 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/f57bb59a-5784-4e6d-aaea-bd738e49a00b%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/php-fig/f57bb59a-5784-4e6d-aaea-bd738e49a00b%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+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/30f8bc9c-2acc-448d-bc09-fe46e5ef20a4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
