Ah sorry it was a discussion IRL :) Calling the root middleware for the server apps is a much less widespread use case AFAIK. In existing implementations and de-facto standards (HttpKernelInterface and "PSR-7 middlewares") there is no such thing, so (IMO) it wouldn't make sense to create such a big break for no gain in most cases.
If a server-side middleware needs to call the root middleware it can still be injected in its constructor (dependency injection). The point of Joel was that it was a much more common scenario for HTTP clients IIRC. Le Jeu 03 nov 2016, à 14:38, Michael Mayer a écrit : > Hi Matthieu, > > calling the root middleware seem to be a valid use case for server > middlewares too: > If a middleware have to create (virgin) Requests, then calling the > root middleware makes a lot more sense than calling the next > middleware. > > May you give me a hint where Joel mentioned this? – I can't find it. > > Michael > > Am Donnerstag, 3. November 2016 08:47:15 UTC+1 schrieb Matthieu > Napoli: >> 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[1] 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); } >>>>> ________ >>>>> >>>>> >>>>> >>>>> >>>>> 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[2] use >>>>> asynchronous techniques like Promises (e.g. Guzzle Promises[3]), >>>>> 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[4]: >>>>> >>>>> 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[5] >>>>> >>>>> *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[6]. >>>>> 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/vBk0BRgDe2s/unsubscribe. > To unsubscribe from this group and all its topics, 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/e2169b71-0fcc-44f7-9a3d-433f041b331c%40googlegroups.com[7]. > For more options, visit https://groups.google.com/d/optout. Links: 1. https://github.com/php-fig/fig-standards/blob/82e2d1c1fd9a3782e0707cf0d4449b28cca8ffa9/proposed/http-middleware/middleware.md 2. https://github.com/guzzle/guzzle 3. https://github.com/guzzle/promises 4. https://github.com/guzzle/guzzle/blob/5a5893c19f798175869eb94a88bb0b73e7acfb05/src/Middleware.php#L17-L44 5. https://github.com/guzzle/guzzle/blob/113071af3b2b9eb96b05dab05472cbaed64a3df4/src/RetryMiddleware.php 6. https://groups.google.com/d/msgid/php-fig/f57bb59a-5784-4e6d-aaea-bd738e49a00b%40googlegroups.com?utm_medium=email&utm_source=footer 7. https://groups.google.com/d/msgid/php-fig/e2169b71-0fcc-44f7-9a3d-433f041b331c%40googlegroups.com?utm_medium=email&utm_source=footer -- 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/1478183173.471921.776301377.5A21E627%40webmail.messagingengine.com. For more options, visit https://groups.google.com/d/optout.
