I think that run() function could be helpful (in the same way than it's in Silex). It's just a shortcut, especially when we are going to use the Request from globals (but maybe there's a good reason to not to include it in StackedHttpKernel)

No type checking on the return of the factory, but I think it will be alright.

The use case that drove this was based on discussion in #silex-php, if I was mapping authentication schemes to certain paths, I'd want to do it like this:

$builder->push(function ($app) {
    return = new UrlMap($app, [
        '/api' => new Hawk($app, []),
        '/admin' => new BasicAuth($app, []),
    ]);
})

I guess that could start to generate a complicated stack, but it's the way I'd roll. I think you can add express.js middlewares with an url prefix, should really check there implementation.

I can't think of any other use cases at the moment, but this would make the builder very flexible going forward and it will be a lot easier for little builder helpers as well, e.g. we could quickly decorate a builder with a pushPrefixed method.

This is a much simpler and cheaper solution than #11.

We are defining terminables to never be conditional. They must always delegate. This makes it safe to always call them.

Now we must prevent terminables from being called more than once. If we assume that a terminable will delegate to the next terminable middleware in the chain, we can skip terminate calls while the previous middleware was terminable.

We only need to kick off the chain for two cases:

• If the first element in the chain is terminable
• Any terminable followed by a non-terminable

• Should not call terminate() more than once (it was potentially factorial of stack size)
• Allow middlewares to delegate terminate() calls
• Increases stack size by number of non-terminable middlewares wrapping a terminable

If possible, we should find a way to reduce stack size, as it is expensive for GC.

Note: This implementation implicitly defines the semantics of Terminable to be as follows. A middleware that implements Terminable must always delegate to the next layer. If Terminable is not implemented, it will be wrapped in a StackedHttpKernel that handles the terminate() delegation. The delegation must not be conditional.

A consequence of this is that all middlewares will be called every time, each one exactly once.

Now that Silex is in maintenance mode and Symfony 4 is recommended instead—I would suggest that Silex is removed as a dependency in dev.

This PR also updates the psr/log and symfony/polyfill-mbstring libraries.

Does this library need to require PHP 5.4 in the its composer.json? I did a quick scan of the code and nothing is jumping out at me that won't work on 5.3.

Drupal uses stack/builder and we're working on Symfony 6 compatibility for our upcoming Drupal 10 release. A new release with these constraints would be great if that's doable.

The kernelStack simplifise using stack middlewares.

example :

$app = new Silex\Application();

$app->get('/', function () {
    return 'Hello World!';
});

$app = new Stack\KernelStack($app);

$app->push('Stack\Session');

$request = Request::create('/');

$response = $app->handle($request);

$response->send();

$app->terminate($request,$response);

$args = $spec; variable $spec not used in code

$kernelClass = $firstArg;

$kernelClass only used as replacement $firstArg for new instance of reflection class

As a follow-up to #10, since we have established that terminate() should always delegate, we should document this properly.

• The README of stack/builder should explain what the expected behaviour of terminable middlewares is, and what happens if one of the middlewares in the chain is not terminable.
• There should be some information on the stack website (maybe a STACK-n convention) explaining that middlewares implementing Terminable MUST delegate terminate(), always and unconditionally.

Drupal uses stack/builder and so we need to add Symfony 6 compatibility here for us to be able to upgrade.

Locally the tests pass for me with these changes:

$ vendor/bin/phpunit
PHPUnit 9.5.11 by Sebastian Bergmann and contributors.

Warning:       Your XML configuration validates against a deprecated schema.
Suggestion:    Migrate your XML configuration using "--migrate-configuration"!

...............                                                   15 / 15 (100%)

Time: 00:00.021, Memory: 8.00 MB

OK (15 tests, 22 assertions)

However the new return type in StackedHttpKernel::handle() might mean this has to be a 2.0 release?