Add support for PSR-15 middlewares #2379

bnf · 2018-01-10T13:59:12Z

PSR-15 middlewares can be registered using the existing API:
App::add() and Routable::add()
Those methods are extended to accept objects that implement
the MiddlewareInterface (or class names that refer to classes
which implement the MiddlewareInterface).

We do not add new entry points for middleware registration, as the type
of the middleware can be detecting through the MiddlewareInterface
which all PSR-15 middlewares implement.

Both, classes that do not implement MiddlewareInterface, and closures will
be handled as single pass middleware – as before.
That means there's no support for closures with a PSR-15 single-pass
signature.

The detection of the middleware type is implemented
in the callable resolver. While that might look like
something which is out of scope for the CallableResolver, reasons are:

The internal slim middleware stack stays at is – it handles callables only.
(and in cannot be changed anyway as long double-pass middlewares
need to be supported. Double-pass middlewares expect a Response object
that needs to be passed along the middleware stack. Therefore we'd need to
wrap PSR-15 middleware's in any case – which is what this change provides)
the CallableResolver resolves (in terms for transforms) a callable
from PSR-15 style middleware.

TODO: Add more tests for:

Adapter\SinglePassMiddleware
Routable with PSR-15 Middlewares

Resolves #2050

coveralls · 2018-01-10T14:00:38Z

Coverage increased (+0.1%) to 95.044% when pulling f5ec341 on bnf:4x-psr-15-v2 into 1306570 on slimphp:4.x.

coveralls · 2018-01-10T14:12:49Z

Coverage increased (+0.1%) to 95.044% when pulling 8958174 on bnf:4x-psr-15-v2 into 1306570 on slimphp:4.x.

geggleto · 2018-01-10T14:15:21Z

Thanks :) I will take a good look at this today or tomorrow, I know akrabat is at a conference this week so he might be able to get around to it next.

coveralls · 2018-01-10T14:50:49Z

Coverage increased (+0.1%) to 95.044% when pulling 405bd08 on bnf:4x-psr-15-v2 into 1306570 on slimphp:4.x.

coveralls · 2018-01-11T13:35:44Z

Coverage increased (+0.1%) to 95.044% when pulling 0c45802 on bnf:4x-psr-15-v2 into 1306570 on slimphp:4.x.

coveralls · 2018-01-12T07:30:21Z

Coverage increased (+0.05%) to 97.455% when pulling 950a541 on bnf:4x-psr-15-v2 into c39d69a on slimphp:4.x.

weierophinney · 2018-01-22T19:48:30Z

Slim/Adapter/SinglePassMiddleware.php

+
+    public function handle(ServerRequestInterface $request): ResponseInterface
+    {
+        return call_user_func($this->next, $request, $this->response);


Since $this->next is `callable, and this PR requires PHP 7 and up, that means you can simplify the above to:

return ($this->next)($request, $this->response);

My understanding is that call_user_func is slower than PHP's native dereferencing in PHP 7, so the above will also be more performant.

I used call_user_func since that was used throughout the Slim codebase. I think those occurrences should be changed in one go. Will push a patch for that.

weierophinney · 2018-01-22T19:50:56Z

Slim/CallableResolver.php

@@ -8,8 +8,10 @@
 */
 namespace Slim;

+use Interop\Http\Server\MiddlewareInterface;


Just a heads-up: PSR-15 passed today, though we're waiting to announce it until the packages are on Packagist — though that should be within the next few hours after I write this. As such, you'll be able to require psr/http-server-middleware instead of http-interop/http-server-middleware, and the above will become Psr\Http\Server\MiddlewareInterface.

Yes, I pushed a patch for the switch to psr/http-server-middleware.

weierophinney · 2018-01-22T19:53:32Z

Slim/Adapter/SinglePassMiddleware.php

+ * and is used only inside of the Slim  application; it is not visible
+ * to—and should not be used by—end users.
+ */
+final class SinglePassMiddleware implements RequestHandlerInterface


Instead of SinglePassMiddleware, may I suggest StandardsBasedMiddleware or PsrMiddleware here?

I've noted in communicating with ZF folks that many are not clear what is meant by "single-pass" and "double-pass", despite us having documented it. Having a name that indicates the type of middleware in terms of where you might find a definition helps.

Also, I'd add an @see annotation with a link to the accepted standard (we'll have that on the fig-standards repo shortly).

Well, I personally prefer a name that describes the functionality. With PsrMiddleware it's not that clear whether the middleware is implementing PSR 15 or (as in our case) adapts a PSR-15 middleware.
Anyway, I've no strong objections against PsrMiddleware so i'll push a patch that renames that one (consistent naming across frameworks is probably not that bad).

weierophinney · 2018-01-22T19:54:44Z

Slim/Routable.php

@@ -87,13 +87,13 @@ public function getCallableResolver()
    /**
     * Prepend middleware to the middleware collection
     *
-     * @param callable|string $callable The callback routine
+     * @param MiddlewareInterface|callable|string $middleware The middleware routine


Have you imported this interface within this class file?

I missed that one, will fix.

akrabat · 2018-02-10T20:07:15Z

.travis.yml

      env: COMPOSER_ARGS='--prefer-lowest'
    - php: nightly
  allow_failures:
+    - php: hhvm


Let's just take hhvm out - we're not supporting it in 4.x

akrabat · 2018-09-30T20:26:39Z

I've been thinking about this a bit. While I appreciate that it's easier to keep the internals the same as Slim 3, I'd like to explore if we can make PSR-15 the default internally and "wrap" the current signatures. Going forward, this makes more sense to me as we probably won't support the current signatures in Slim 5.

Thoughts?

l0gicgate · 2018-10-23T17:24:40Z

@bnf are you moving forward with this PR? I'm curious as I will tackle it after my next couple of PRs if you aren't.

bnf · 2019-01-24T09:46:53Z

Hi @akrabat, hi @l0gicgate,

Sorry, I missed your comments/thoughts. Therefore now my (very late) reaction:

I still think this is the right approach and actually considered it ready. Therefore I didn't do more work on this, because I was waiting for it to be merged. It's actually used in production as a backport for slim v3: https://packagist.org/packages/bnf/slim3-psr15
The main motivation for sticking with the old middleware dispatcher is the $response object. It needs to be handed over all the way from the first double-pass style middleware to the very last one.

I'd like to explore if we can make PSR-15 the default internally and "wrap" the current signatures

Going with a pure PSR-15 solution and adding a wrapper for double pass middlewares (as in #2555) results in (hard to detect) breaking behaviour, as the wrapper has to create a new $response object for every double pass middleware. That means upgrading to Slim v4 will be a bit of a pain. (IMO)
To illustrate that: The following code will no longer work with #2555, as the $response will not be passed, but rather silently dropped:

$response = $response->withStatus(403);
return $next($request, $response);

Existing middleware code that expect to be able to pass a modified $response to the $next middleware will fail with that change. I know that it's a technical limitation due to the changes in PSR-15.
For exactly that reason I decided to keep the existing dispatcher instead of creating a new pure PSR-15 one.
If you find that limitation of dropping $response to be ok, than please go ahead with #2555 otherwise I'd ask you to reconsider this approach.

Thanks, Benjamin

…ll tests

Use the `$callable()` syntax instead. See https://trowski.com/2015/06/20/php-callable-paradox/

…s other than handle() If 'FooBar:customMethod' is specified to be dispatched, the CallableResolver must not resolve to the handle() method even though FooBar implements the RequestHandlerInterface. It should only do that, if no method name is given.

… grasp Do not invoke objects that don't need them, rather use early retuns. No need to check is_callable for Closures or classes that implement RequestHandlerInterface where instanceof is sufficient to return early.

PSR-15 middlewares can be registered using the existing API: `App::add()` and `Routable::add()` Those methods are extended to accept objects that implement the MiddlewareInterface (or class names that refer to classes which implement the MiddlewareInterface). We do not add new entry points for middleware registration, as the type of the middleware can be detecting through the MiddlewareInterface which all PSR-15 middlewares implement. Both, classes that do not implement MiddlewareInterface, and closures will be handled as single pass middleware – as before. That means there's no support for closures with a PSR-15 style single-pass signature. The detection of the middleware type is implemented in the callable resolver. While that might look like something which is out of scope for the CallableResolver, reasons are: a) The internal slim middleware stack stays at is – it handles callables only. (and in cannot be changed anyway as long double-pass middlewares need to be supported. Double-pass middlewares expect a Response object that needs to be passed along the middleware stack. Therefore we'd need to wrap PSR-15 middleware's in any case – which is what this change provides) b) the CallableResolver resolves (in terms for transforms) a callable from PSR-15 style middleware. TODO: Add more tests for: - Adapter\PsrMiddleware - Routable with PSR-15 Middlewares Resolves slimphp#2050

l0gicgate · 2019-02-12T08:43:09Z

Closing this as we are moving forward with #2555. Thank you for your contribution @bnf

akrabat · 2019-02-12T11:19:30Z

Closing this as we are moving forward with #2555. Thank you for your contribution @bnf

To this point, we only need one PR to get PSR-15 support into Slim 4.

However, the BC problems that @bnf highlights (and @l0gicgate also highlighted in Slack at some point in the past to me) do need to be explicitly discussed I think.

My initial reaction as @l0gicgate noted is that passing the response down the chain is bad, so my natural reaction is that I don't mind breaking it in Slim 4. However, is that the right call? I could definitely be wrong.

geggleto requested review from akrabat and geggleto January 10, 2018 14:14

geggleto added improvement Slim 4 labels Jan 10, 2018

geggleto added this to the 4.0 milestone Jan 10, 2018

bnf force-pushed the 4x-psr-15-v2 branch from 8958174 to 405bd08 Compare January 10, 2018 14:48

bnf force-pushed the 4x-psr-15-v2 branch from 0c45802 to 3bc125c Compare January 12, 2018 07:27

weierophinney reviewed Jan 22, 2018

View reviewed changes

bnf changed the title ~~[RFC] Add support for PSR-15 style middlewares~~ Add support for PSR-15 middlewares Jan 23, 2018

damianopetrungaro mentioned this pull request Jan 23, 2018

PSR-15 compliant Strategy for the foundHandler #2259

Closed

akrabat reviewed Feb 10, 2018

View reviewed changes

akrabat mentioned this pull request Feb 14, 2018

Update route callable signature for PSR-15 #2052

Closed

akrabat mentioned this pull request Sep 2, 2018

Support using App as PSR-15 RequestHandler #2496

Merged

oscarotero mentioned this pull request Sep 10, 2018

Adding to Slim Framework middlewares/debugbar#9

Closed

l0gicgate mentioned this pull request Dec 21, 2018

PSR-15 Middleware Support #2555

Merged

1 task

bnf added 6 commits January 24, 2019 15:29

DeferredCallableTest: Ensure CallableTest::$CalledCount is zero for a…

10d5456

…ll tests

doc: CallableResolverInterface::resolve() does not invoke

20f127f

As we rely on PHP 7, drop call_user_func{,array} usage

c79f2bd

Use the `$callable()` syntax instead. See https://trowski.com/2015/06/20/php-callable-paradox/

README: Remove trailing whitespace

f8d56cf

bnf force-pushed the 4x-psr-15-v2 branch from de89805 to eccfac2 Compare January 24, 2019 17:19

bnf force-pushed the 4x-psr-15-v2 branch from eccfac2 to 950a541 Compare January 24, 2019 17:33

l0gicgate closed this Feb 12, 2019

bnf mentioned this pull request Feb 14, 2019

Fix dispatching of non handle() methods for PSR15 request handlers #2578

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for PSR-15 middlewares #2379

Add support for PSR-15 middlewares #2379

bnf commented Jan 10, 2018 •

edited by akrabat

Loading

coveralls commented Jan 10, 2018

coveralls commented Jan 10, 2018

geggleto commented Jan 10, 2018

coveralls commented Jan 10, 2018

coveralls commented Jan 11, 2018

coveralls commented Jan 12, 2018 •

edited

Loading

weierophinney Jan 22, 2018

bnf Jan 23, 2018

weierophinney Jan 22, 2018

bnf Jan 23, 2018

weierophinney Jan 22, 2018

bnf Jan 23, 2018

weierophinney Jan 22, 2018

bnf Jan 23, 2018

akrabat Feb 10, 2018

akrabat commented Sep 30, 2018

l0gicgate commented Oct 23, 2018

bnf commented Jan 24, 2019

l0gicgate commented Feb 12, 2019

akrabat commented Feb 12, 2019

Add support for PSR-15 middlewares #2379

Add support for PSR-15 middlewares #2379

Conversation

bnf commented Jan 10, 2018 • edited by akrabat Loading

coveralls commented Jan 10, 2018

coveralls commented Jan 10, 2018

geggleto commented Jan 10, 2018

coveralls commented Jan 10, 2018

coveralls commented Jan 11, 2018

coveralls commented Jan 12, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

akrabat commented Sep 30, 2018

l0gicgate commented Oct 23, 2018

bnf commented Jan 24, 2019

l0gicgate commented Feb 12, 2019

akrabat commented Feb 12, 2019

bnf commented Jan 10, 2018 •

edited by akrabat

Loading

coveralls commented Jan 12, 2018 •

edited

Loading