PSR-15 middleware in minutes!

Related tags

Middlewares php middleware microservice psr-11 zend-expressive psr-7 zend-framework php71 psr-15 microframework middleware-pipeline
Overview

zend-expressive

Repository abandoned 2019-12-31

This repository has moved to mezzio/mezzio.

Build Status Coverage Status

Develop PSR-7 middleware applications in minutes!

zend-expressive builds on zend-stratigility to provide a minimalist PSR-7 middleware framework for PHP, with the following features:

Installation

We provide two ways to install Expressive, both using Composer: via our skeleton project and installer, or manually.

Using the skeleton + installer

The simplest way to install and get started is using the skeleton project, which includes installer scripts for choosing a router, dependency injection container, and optionally a template renderer and/or error handler. The skeleton also provides configuration for officially supported dependencies.

To use the skeleton, use Composer's create-project command:

$ composer create-project zendframework/zend-expressive-skeleton <project dir>

This will prompt you through choosing your dependencies, and then create and install the project in the <project dir> (omitting the <project dir> will create and install in a zend-expressive-skeleton/ directory).

Manual Composer installation

You can install Expressive standalone using Composer:

$ composer require zendframework/zend-expressive

However, at this point, Expressive is not usable, as you need to supply minimally:

  • a router.
  • a dependency injection container.

We currently support and provide the following routing integrations:

  • Aura.Router: composer require zendframework/zend-expressive-aurarouter
  • FastRoute: composer require zendframework/zend-expressive-fastroute
  • zend-router: composer require zendframework/zend-expressive-zendrouter

We recommend using a dependency injection container, and typehint against PSR-11 Container. We can recommend the following implementations:

  • zend-servicemanager: composer require zendframework/zend-servicemanager
  • Pimple (see docs for more details): composer require zendframework/zend-pimple-config
  • Aura.Di (see docs for more details): composer require zendframework/zend-auradi-config

Additionally, you may optionally want to install a template renderer implementation, and/or an error handling integration. These are covered in the documentation.

Documentation

Documentation is in the doc tree, and can be compiled using mkdocs:

$ mkdocs build

Additionally, public-facing, browseable documentation is available at https://docs.zendframework.com/zend-expressive/

Comments
  • Url helpers produces unexpected results when querystring and/or optional route params in stage

    Url helpers produces unexpected results when querystring and/or optional route params in stage

    I hit this problem today when trying to implement a pagination template using Twig as template renderer.

    I have a catch-all route for user-related operations and trying to handle multiple actions in a single class like documented in cookbook.

    [
    'name'            => 'user',
    'path'            => '/user[/{action:add|edit|show|list}[/{id}]]',
    'middleware'      => Action\UserActions::class,
    'allowed_methods' => ['GET','POST'],
],

    And I want to generate a uri path with additional arguments using helper like below:

    {{ path("user", { "page" : 1 } ) }}

    Expected output: /user?page=1 Actual output: /user[/{action:add|edit|show|list}[/{id}]] Problem(s) : Helper exposing the original route in view layer and page argument is lost.

    Other examples:

    {{ path("user") }}

    Expected output: /user Actual output: /user[/{act:add|edit|show|list}[/{id}]]

    {{ path("user" { "act":null, "id":null } ) }}

    Expected output: /user Actual output: /location[/[/]]

    I have not tried yet with the the zend-router. I believe there should be a way to create routes with querystring arguments.

    Seems like generateUri() method of the Zend\Expressive\Router\FastrouteRouter is responsible but I'm not sure that.

    I have also tried switching the router from FastRouter to AuraRouter:

    [
    'name'            => 'user',
    'path'            => '/user{/act,id}',
    'middleware'      => Action\UserActions::class,
    'allowed_methods' => ['GET'],
    'options'         => [
        'tokens' => [
            'act'    => '(add|edit|show|list)?',
            'id'     => '\d+',
            ]
    ],
],

    Now, when I try to generate relative uri;

    {{ path("user", { "page" : 1 } ) }}

    Expected output: /user?page=1 Actual output: /user Result : My route definitions are not exposed but page argument is still lost.

    Am i missing something? what is the proper way to create URL's with querystring arguments in expressive?

    opened by edigu 55
  • Simplify the middleware pipeline configuration

    Simplify the middleware pipeline configuration

    This patch simplifies a number of features of Expressive:

    • It simplifies the middleware pipeline configuration, by removing the pre_routing and post_routing keys; all middleware is piped at the same level of configuration, including routing.
    • It splits the routing middleware into distinct routing and dispatch middleware. This allows replacing either process. This necessitates removal of autoregistration of the routing middleware; I consider this a feature, however, as it also ensures that you can form the middleware pipeline independent of when routes are added to the application.
    • Because of the above, this patch also deprecates the route result observer system, as it's redundant. You can create "route result observers" as middleware that introspects the route result (which is injected as a request attribute following routing), and inject it in the pipeline immediately following the routing middleware. This simplifies route result observer registration as well, by providing exactly one way to accomplish it, and doing it in a portable fashion (middleware!).

    I've noticed one potential issue with the change: configuration merging with indexed arrays means that we cannot guarantee order. This will potentially lead to issues if the middleware_pipeline is defined in multiple configuration files. To address this problem, this patch introduces a new middleware specification key, priority, which uses SplPriorityQueue semantics, and which can be used to guarantee the order in which middleware are piped to the application.

    TODO

    • [x] deprecate pre/post routing keys
    • [x] remove auto-registration of routing middleware
    • [x] split routing middleware into routing + dispatch middleware
    • [x] deprecate route result observers
    • [x] update flow diagram
    • [x] solve middleware_pipeline ordering issues post-merge (implement priority/order key)

    TODO post-merge:

    • [x] tag RC6 of zend-expressive.
    • [x] Update zend-expressive-helpers to modify the UrlHelper to remove the RouteResultObserverInterface implementation, and update the UrlHelperMiddleware to push the route result from the request, if present, into the UrlHelper. Once complete, a new version should be tagged.
    • [x] Update zend-expressive-router to mark the RouteResult(Observer|Subject)Interfaces as deprecated.
    • [x] Update zend-expressive-skeleton:
      • [x] update the default middleware pipeline to follow that demonstrated in this patch.
      • [x] update the zend-expressive-helpers version to pull in the new tag.
      • [x] update the zend-expressive version to rc6.
    enhancement BC Break 
    opened by weierophinney 42
  • App does not route by default

    App does not route by default

    Hi,

    I had trouble with figuring out how to set up a separate /api middleware pipe. My system set up:

    1. A root middleware pipe (Zend\Expressive\Application) with a home route / serving the layout + assets for a SPA.
    2. A API middleware pipe (also Zend\Expressive\Application) with a programmatic created router following the docs

    This is how my index.php initializes the pipes:

    $services = new \Zend\ServiceManager\ServiceManager(new \Zend\ServiceManager\Config(require 'config/services.php'));

$app = $services->get('Zend\Expressive\Application');

$cargoBackend = $services->get('cargo.backend');

$app->pipe('/api', $cargoBackend);

$app->run();

    And this is the factory responsible for the cargo.backend middleware pipe:

        public function __invoke(ContainerInterface $container)
    {
        $router = $container->get('cargo.backend.router');

        $app = AppFactory::create($container, $router);

        //This is the problem a want to address with the issue!!!
        $app->pipe("/", [$app, 'routeMiddleware']);

        return $app;
    }

    I was not aware that I have to pipe the router manually when using the AppFactory. When passing a router to it I expect that the router gets activated automatically by the factory. I would like to submit a PR that fixes the problem, but want to ask first if this would have side effects and if such a change is wanted/needed? Otherwise we should document it. The cookbook would be a good place.

    I have a second problem but currently don't know what causes it: Before I added the line $app->pipe("/", [$app, 'routeMiddleware']) to the factory my route was not invoked (/api/locations) but I got an empty response with a 200 ok status code instead of a 404 not found. Maybe this happens because the api app is set up with its own emitter and final handler by default, so the final handler of the root app is not invoked?

    bug enhancement 
    opened by codeliner 36
  • Implement programmatic pipeline features

    Implement programmatic pipeline features

    This patch implements the Programmatic Pipelines RFC requirements.

    TODO

    • [x] Create Zend\Expressive\Middleware\ErrorResponseGenerator
    • [x] Create Zend\Expressive\Middleware\WhoopsErrorResponseGenerator
    • [x] Create Zend\Expressive\Middleware\NotFoundHandler
    • [x] Create Zend\Expressive\Container\ErrorResponseGeneratorFactory
    • [x] Create Zend\Expressive\Container\WhoopsErrorResponseGeneratorFactory
    • [x] Create Zend\Expressive\Container\NotFoundHandlerFactory
    • [x] Create Zend\Expressive\Container\ErrorHandlerFactory
    • [x] Create Zend\Expressive\ApplicationConfigInjectionTrait, and compose it into Application.
    • [x] Update Zend\Expressive\Container\ApplicationFactory to vary creation and return of the Application instance based on the zend-expressive.programmatic_pipeline configuration flag.
    • [x] Update Zend\Expressive\Container\ApplicationFactory to use the methods defined in ApplicationConfigInjectionTrait to inject pipeline and routed middleware from configuration into the Application instance.
    • [x] Update Zend\Expressive\Application to emit a deprecation notice from pipeErrorMiddleware().
    • [x] Update Zend\Expressive\MarshalMiddlewareTrait to allow marshalling http-interop middleware.
    • [x] Add support for "raise throwables" flag to ApplicationFactory.
    • [x] Documentation

    Tooling support

    The following tools were written in zendframework/zend-expressive-tooling to support user migrations to work with the above changes:

    • [x] Tool for generating programmatic pipelines and routing from existing configuration.
    • [x] Tool for migrating getOriginal*() calls to getAttribute(*) calls on the request object.
    • [x] Tool for identifying error middleware in an existing application.

    References

    enhancement 
    opened by weierophinney 32
  • Documentation build chain for gh-pages

    Documentation build chain for gh-pages

    This pull-request provides a new documentation build chain to allow publishing to gh-pages for commits to master. It serves as a sandbox for how we can do the ZF component documentation going forward as well.

    It implements the following:

    • Removes all usage of bookdown. Unfortunately, I found templating with it far too cumbersome, and it is missing features we could use (e.g. sidebar nav, top nav, etc.), but which would take some time to develop.
    • Implements a more thorough MkDocs build configuration, with fewer top-level items, more nesting, and specifying configuration features such as custom templates, extension directives to disable pygments highlighting, etc.
    • Reorganizes the documentation a fair bit to provide more natural groupings.

    I implemented a custom MkDocs theme based on Cinder, which I have proposed at weierophinney/zf-mkdoc-theme. You can see it in action at https://zendframework.github.io/zend-expressive/

    ~~At this time, I still need to test the travis -> gh-pages workflow, and, for that reason, I'm marking it as a WIP. If it works as expected, I'll update the issue to indicate readiness.~~

    documentation 
    opened by weierophinney 30
  • FinalHandler trying to display exceptions is freezing the system

    FinalHandler trying to display exceptions is freezing the system

    Hi, I am not sure if this should be called as a bug.

    But when there is an exception occured and if the exception is happening from di, the system is getting freezed trying to dump all the di values and configurations :-( .

    Probably there need a better way to handle the exception ?

    opened by harikt 26
  • [Docs] When to choose Zend\Expressive over Zend\Mvc

    [Docs] When to choose Zend\Expressive over Zend\Mvc

    In the "Announcing the Zend Framework 3 Roadmap" blog entry, someone asked an interesting question which probably will be asked by many others.

    http://framework.zend.com/blog/announcing-the-zend-framework-3-roadmap.html#comment-2476333814

    Thank you Ralf for your answer ;) . Another question, is there a guideline to check which method i can use, because right now i do not know which method (Zend\Mvc or Zend\Expressive) i can choose.

    I will reask here: When should someone choose Zend\Expressive and when Zend\Mvc?

    Any ideas?

    I will be glad to sum it up for the docs. Maybe could be added to the Zend\Mvc docs as well

    opened by RalfEggert 23
  • This repo seems to be the next monolithic library.

    This repo seems to be the next monolithic library.

    It's good to provide support for the most common/popular third party implementations but I think each one of them should be developed on individual packages.

    opened by Maks3w 23
  • Refactor: extract middleware marshaling, routing, and app running

    Refactor: extract middleware marshaling, routing, and app running

    This patch implements the changes as outlined in the RFC: Expressive 3 Design Changes, as well as those as outlined in this comment and this comment, below.

    In particular:

    • Updates to consume and implement PSR-15.

    • The following changes were made to middleware marshaling:

      • A new class, MiddlewareContainer, implementing PSR-11's ContainerInterface and decorating a ContainerInterface. This class ensures that middleware pulled from the container implements the PSR-15 MiddlewareInterface. It also allows retrieving middleware by class name if the class does not require constructor arguments.

      • A new class, MiddlewareFactory, accepts a PSR-11 ContainerInterface to its constructor, which it decorates internally as a MiddlewareContainer. It then exposes methods for marshaling middleware:

        • callable(callable $middleware) : CallableMiddlewareDecorator
        • lazy(string $middleware) : LazyLoadingMiddleware
        • pipeline(...$middleware) : MiddlewarePipeline
        • path(string $path, $middleware) : PathMiddlewareDecorator
        • prepare($middleware) : MiddlewareInterface; this one proxies to the other methods.

        Double-pass middleware is not supported.

    • A new class, ApplicationRunner, composes:

      • A RequestHandlerInterface instance (typically, a MiddlewarePipeInterface)
      • An EmitterInterface instance (typically, an EmitterStack composing a SapiEmitter)
      • A callable factory for generating a ServerRequestInterface instance
      • A callable response generator, used when the server request factory raises a throwable or exception.

      When run() is called, the class marshals a request, potentially generates an error response, and otherwise passes handling of the request to the handler; it then passes the returned response to the emitter.

      This class can potentially be extracted to its own library.

    • The RouteMiddleware has been updated to add the methods route, get, post, etc. from Application. Unlike Application, they only accept MiddlewareInterface instances.

    • New factories (in the Zend\Expressive\Container namespace):

      • RouteMiddlewareFactory
      • DispatchMiddlewareFactory
      • EmitterFactory should be mapped to Zend\Diactros\Response\EmitterInterface.
      • ServerRequestFactoryFactory should be mapped to Zend\Expressive\ServerRequestFactory
      • ServerRequestErrorResponseGeneratorFactory should be mapped to Zend\Expressive\ServerRequestErrorResponseGenerator.

    • Application has been completely rewritten. It now composes:

      • A MiddlewareFactory instance
      • A MiddlewarePipeInterface instance, generally a MiddlewarePipe
      • A RouteMiddleware instance
      • An ApplicationRunner instance

      It implements RequestHandlerInterface and MiddlewareInterface, and composes the ApplicationConfigInjectionTrait. It defines the same public API as previously, minus the various getters (as none of them are applicable anymore). Each method now proxies to the appropriate collaborator, pre-processing arguments as necessary:

      • handle() delegates to the MiddlewarePipeInterface
      • process() delegates to the MiddlewarePipeInterface
      • run() delegates to the ApplicationRunner
      • pipe() delegates to the MiddlewarePipeInterface, after first passing its arguments to the MiddlewareFactory, and, in the case of two arguments, the Zend\Stratigility\path() utility function.
      • route() and related methods delegate to the RouteMiddleware, after first passing the $middleware argument to the MiddlewareFactory
      • pipeRoutingMiddleware and pipeDispatchMiddleware are removed; users will now pipe these middleware just like any other middleware.

    • Zend\Expressive\Delegate\NotFoundDelegate was renamed to Zend\Expressive\Handler\NotFoundHandler.

    • Zend\Expressive\Middleware\NotFoundHandler was renamed to Zend\Expressive\Middleware\NotFoundMiddleware; its related factory in the Zend\Expressive\Container namespace was similarly renamed.

    • Tests were updated to reflect the changes, as necessary.

    Updates

    • 2018-01-30: Updated to reflect refactors of routing and app running.
    enhancement BC Break WIP 
    opened by weierophinney 21
  • Separate routing from dispatching

    Separate routing from dispatching

    I have a middleware that needs a matched route param to perform some pre-dispatching logic, therefore this middleware should run after routing and before the "action" middleware.

    Currently this can be achieved by injecting the router instance into a pre-routing middleware and calling $router->match($request) just to get the matched route params, but I think this is a very common use case and could be achieved more elegantly with a middleware registered between routing and dispatching.

    It's possible to break the Application#routeMiddleware() into 2 middlewares?

    enhancement Awaiting author updates 
    opened by danizord 21
  • [Cookbook] How to setup localization

    [Cookbook] How to setup localization

    A suggestion for the cookbook: How to setup the localization?

    Let's say in the routing is a lang parameter which defines the current language. This should be used to set the locale for the application. How can this be archieved? Are their multiple ways to handle this? Which way is the most recommended way?

    question 
    opened by RalfEggert 19
  • Zend Expressive vs Zend Framework 3 vs Zend Apigility for REST API with Swagger docs?

    Zend Expressive vs Zend Framework 3 vs Zend Apigility for REST API with Swagger docs?

    Hi all,

    I have read https://github.com/zendframework/zend-expressive/issues/342 and I still have a few questions. Firstly, let me describe the scenario.

    Current situation Web application written in Zend Framework 1. There are two modules in the ZF1 app structure:

    • "default" model used for the publicly accessible website

    • "admin" model used for web administrators (accessible only by employees of the company) to update the website content and much more things covering the internal processes of the mentioned company

    The future Convert the "default" module to an rest API to let 3rd party companies create the public website using this to be developed API to deliver the content. The "admin" module will stay untouched for now.

    The question I know I could probably simply tweak the old ZF1 "default" module to serve as an API (remove all the views and update all the controllers to return some JSON structure). But I would like to take this as an opportunity to get my hands on something new. So I am thinking about ZF3, Expressive or Apigility.

    I want to deliver simple REST API which would basically serve to:

    • deliver content (texts, images) to the website
    • offer form validation for the website
    • creating few things in the connected DB via posting several forms on the website

    What I believe is a must have is a self-generated documentation (I would prefer Swagger) because the API will be used by 3rd party companies to create/redesign the website.

    Which of the Zend "frameworks" mentioned above is suited for such a task? What do you guys think?

    I pretty much like the Zend Expressive as it is kind of minimalistic and can be tweaked to whatever needed however I am not able to find out whether there is a swagger component. I have found Swagger component for ZF3. And Apigility is a bit mystery to me. It seems like it is a online tool for creating rest apis which sounds interesting and scary at the same time as I cannot imagine myself writing a controller code in a browser but I might be missing something about Apigility.

    Thanks you very much and if you want me to clarify anything just let me know.

    question 
    opened by starkskalle 3
  • Add docs for extension config parameter for zend view renderer

    Add docs for extension config parameter for zend view renderer

    Provide a narrative description of what you are trying to accomplish:

    2.2.0 release of zendframework/zend-expressive-zendviewrenderer adds support for extension parameter for default suffix to be used by zend-view resolver, in line with other template renderers.

    • [x] Is this related to documentation? Add documentation entry for extension config parameter.
    opened by Xerkus 2
  • Unable to handle errors in v1

    Unable to handle errors in v1

    I cannot see a proper stack trace of errors while I'm developing, which is obviously very frustrating. However, when I switch php error reporting on I can see an exception raised by Diactoros (...Unsupported response reason phrase; must be a string, received NULL...zendframework/zend-diactoros/src/Response.php:185 Stack trace...) , but no trace/indication of where the problem actually occurred, when php error reporting is off then I get a blank screen with server 500 error.

    I thought Zend Expressive has default exception and other response handling built in i.e. 404, methodNotAllowed etc, instead of just bombing out on all problems... or is it up to the developer to write this core functionality? I've wasted so much time searching for examples, but as usual nothing that that works... I cannot believe this is so badly documented (or an architecture flaw in v1?)

    I mostly use PHP Slim and it has the above baked in, the developer can also override it with custom handlers...simple and to-the-point. I can unfortunately not use Slim and have to solve this error reporting issue with Zend Expressive.. please help

    opened by plasid 3
  • Path segregation - pipeline middleware - config-driven

    Path segregation - pipeline middleware - config-driven

    @weierophinney

    Good morning,

    I've an expressive application with a config-driven pipeline. That application exposes different UI levels such as /admin, /reseller and /client, among others...

    Right now, I've a specific pipeline middleware that I want to execute only for specific paths:

    ...
protected function getPipeline()
{
    return [
        [
            'path' => '/admin',
            'middleware' => \Zend\Expressive\Navigation\Middleware\NavigationMiddleware::class
        ],
        [
            'path' => 'reseller',
            'middleware' => \Zend\Expressive\Navigation\Middleware\NavigationMiddleware::class
        ],
        [
            'path' => '/client',
            'middleware' => \Zend\Expressive\Navigation\Middleware\NavigationMiddleware::class
        ],
    ];
}
...

    This is working but, I would rather be able to do something like this:

    ...
protected function getPipeline()
{
    return [
        [
            'paths' => ['/admin', '/reseller', '/client'],
            'middleware' => \Zend\Expressive\Navigation\Middleware\NavigationMiddleware::class
        ],
    }
}
...

    Of course, I could use a custom delegator but I think this could be integrated in the default \Zend\Expressive\Container\ApplicationConfigInjectionDelegator delegator as follows:

    ...
    public static function injectPipelineFromConfig(Application $application, array $config) : void
    {
        if (empty($config['middleware_pipeline'])) {
            return;
        }

        // Create a priority queue from the specifications
        $queue = array_reduce(
            array_map(self::createCollectionMapper(), $config['middleware_pipeline']),
            self::createPriorityQueueReducer(),
            new SplPriorityQueue()
        );

        foreach ($queue as $spec) {
            $paths = $spec['path'] ?? ($spec['paths'] ?? '/');
            foreach((array) $paths as $path) {
                $application->pipe($path, $spec['middleware']);
            }
        }
    }
...

    instead of

    ....
    public static function injectPipelineFromConfig(Application $application, array $config) : void
    {
        if (empty($config['middleware_pipeline'])) {
            return;
        }

        // Create a priority queue from the specifications
        $queue = array_reduce(
            array_map(self::createCollectionMapper(), $config['middleware_pipeline']),
            self::createPriorityQueueReducer(),
            new SplPriorityQueue()
        );

        foreach ($queue as $spec) {
            $path = $spec['path'] ?? '/';
            $application->pipe($path, $spec['middleware']);
        }
    }
....

    Thank you.

    opened by nuxwin 4
  • NotFoundHandler generateTemplatedResponse Content Type missing

    NotFoundHandler generateTemplatedResponse Content Type missing

    I believe "Content-Type" header is missing from the newly created response object when a 404 error is handled.

    /src/Handler/NotFoundHandler.php

    /**
     * Generates a response using a template.
     *
     * Template will receive the current request via the "request" variable.
     */
    private function generateTemplatedResponse(
        TemplateRendererInterface $renderer,
        ServerRequestInterface $request
    ) : ResponseInterface {

        $response = ($this->responseFactory)()->withStatus(StatusCodeInterface::STATUS_NOT_FOUND);
        $response->getBody()->write(
            $renderer->render($this->template, ['request' => $request, 'layout' => $this->layout])
        );

        return $response;
    }

    Should be

    /**
     * Generates a response using a template.
     *
     * Template will receive the current request via the "request" variable.
     */
    private function generateTemplatedResponse(
        TemplateRendererInterface $renderer,
        ServerRequestInterface $request
    ) : ResponseInterface {

        $response = ($this->responseFactory)()
                 ->withHeader('Content-Type', 'text/html')
                 ->withStatus(StatusCodeInterface::STATUS_NOT_FOUND);
        $response->getBody()->write(
            $renderer->render($this->template, ['request' => $request, 'layout' => $this->layout])
        );

        return $response;
    }
    opened by cgaube 2
Releases(3.2.1)

  • 3.2.1(Nov 8, 2018)

    Added

    • Nothing.

    Changed

    • Nothing.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • #646 fixes behavior in the MiddlewareContainer when retrieving services that implement both RequestHandlerInterface and MiddlewareInterface. Previously, it incorrectly cast these values to RequestHandlerMiddleware, which could cause middleware pipelines to fail if they attempted to delegate back to the application middleware pipeline. These values are now correctly returned verbatim.
    Source code(tar.gz)
    Source code(zip)

  • 3.2.0(Sep 27, 2018)

    Added

    • #637 adds support for zendframework/zend-diactoros 2.0.0. You may use either a 1.Y or 2.Y version of that library with Expressive applications.

    Changed

    • Nothing.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • #634 provides several minor performance and maintenance improvements.
    Source code(tar.gz)
    Source code(zip)

  • 3.0.3(Jul 25, 2018)

    Added

    • #615 adds a cookbook entry for accessing common data in templates.

    Changed

    • Nothing.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • #627 fixes an issue in the Whoops response generator; previously, if an error or exception occurred in an ErrorHandler listener or prior to handling the pipeline, Whoops would fail to intercept, resulting in an empty response with status 200. With the patch, it properly intercepts and displays the errors.
    Source code(tar.gz)
    Source code(zip)

  • 3.0.2(Apr 10, 2018)

    Added

    • Nothing.

    Changed

    • Nothing.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • #612 updates the ApplicationConfigInjectionDelegator delegator factory logic to cast the $config value to an array before passing it to its injectPipelineFromConfig() and injectRoutesFromConfig() methods, ensuring it will work correctly with containers that store the config service as an ArrayObject instead of an array.
    Source code(tar.gz)
    Source code(zip)

  • 3.0.1(Mar 19, 2018)

    Added

    • Nothing.

    Changed

    • #596 updates the ApplicationConfigInjectionDelegator::injectRoutesFromConfig() method to use the key name associated with a route specification if no name member is provided when creating a Route instance. This can help enforce name uniqueness when defining routes via configuration.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • Nothing.
    Source code(tar.gz)
    Source code(zip)

  • 2.2.1(Mar 17, 2018)

    Added

    • Nothing.

    Changed

    • Nothing.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • #592 fixes a v3 to v2 backwards port issue where the Router\Middleware\DispatchMiddleware is registered as an invokable and it should be registered with the Router\Middleware\DispatchMiddlewareFactory. This caused a "DispatchMiddleware already exists and cannot be overridden" exception.
    Source code(tar.gz)
    Source code(zip)

  • 3.0.0(Mar 15, 2018)

    Added

    • #543 adds support for the final PSR-15 interfaces, and explicitly depends on psr/http-server-middleware.

    • #538 adds scalar and return type hints to methods wherever possible.

    • #562 adds the class Zend\Expressive\Response\ServerRequestErrorResponseGenerator, and maps it to the Zend\Expressive\Container\ServerRequestErrorResponseGeneratorFactory. The class generates an error response when an exeption occurs producing a server request instance, and can be optionally templated.

    • #543 adds a new class, Zend\Expressive\MiddlewareContainer. The class decorates a PSR-11 ContainerInterface, and adds the following behavior:

      • If a class is not in the container, but exists, has() will return true.
      • If a class is not in the container, but exists, get() will attempt to instantiate it, caching the instance locally if it is valid.
      • Any instance pulled from the container or directly instantiated is tested. If it is a PSR-15 RequestHandlerInterface, it will decorate it in a zend-stratigility RequestHandlerMiddleware instance. If the instance is not a PSR-15 MiddlewareInterface, the container will raise a Zend\Expressive\Exception\InvalidMiddlewareException.

    • #543 adds a new class, Zend\Expressive\MiddlewareFactory. The class composes a MiddlewareContainer, and exposes the following methods:

      • callable(callable $middleware) : CallableMiddlewareDecorator
      • handler(RequestHandlerInterface $handler) : RequestHandlerMiddleware
      • lazy(string $service) : LazyLoadingMiddleware
      • prepare($middleware) : MiddlewareInterface: accepts a string service name, callable, RequestHandlerInterface, MiddlewareInterface, or array of such values, and returns a MiddlewareInterface, raising an exception if it cannot determine what to do.
      • pipeline(...$middleware) : MiddlewarePipe: passes each argument to prepare(), and the result to MiddlewarePipe::pipe(), returning the pipeline when complete.

    • #543 adds the following factory classes, each within the Zend\Expressive\Container namespace:

      • ApplicationPipelineFactory: creates and returns a Zend\Stratigility\MiddlewarePipe to use as the application middleware pipeline.
      • DispatchMiddlewareFactory: creates and returns a Zend\Expressive\Router\DispatchMiddleware instance.
      • EmitterFactory: creates and returns a Zend\HttpHandlerRunner\Emitter\EmitterStack instance composing an SapiEmitter from that same namespace as the only emitter on the stack. This is used as a dependency for the Zend\HttpHandlerRunner\RequestHandlerRunner service.
      • MiddlewareContainerFactory: creates and returns a Zend\Expressive\MiddlewareContainer instance decorating the PSR-11 container passed to the factory.
      • MiddlewareFactoryFactory: creates and returns a Zend\Expressive\MiddlewareFactory instance decorating a MiddlewareContainer instance as pulled from the container.
      • RequestHandlerRunnerFactory: creates and returns a Zend\HttpHandlerRunner\RequestHandlerRunner instance, using the services Zend\Expressive\Application, Zend\HttpHandlerRunner\Emitter\EmitterInterface, Zend\Expressive\ServerRequestFactory, and Zend\Expressive\ServerRequestErrorResponseGenerator.
      • ServerRequestFactoryFactory: creates and returns a callable factory for generating a PSR-7 ServerRequestInterface instance; this returned factory is a dependency for the Zend\HttpHandlerRunner\RequestHandlerRunner service.
      • ServerRequestErrorResponseGeneratorFactory: creates and returns a callable that accepts a PHP Throwable in order to generate a PSR-7 ResponseInterface instance; this returned factory is a dependency for the Zend\HttpHandlerRunner\RequestHandlerRunner service, which uses it to generate a response in the scenario that the ServerRequestFactory is unable to create a request instance.

    • #551 and #554 add the following constants under the Zend\Expressive namespace:

      • DEFAULT_DELEGATE can be used to refer to the former DefaultDelegate FQCN service, and maps to the Zend\Expressive\Handler\NotFoundHandler service.
      • IMPLICIT_HEAD_MIDDLEWARE can be used to refer to the former Zend\Expressive\Middleware\ImplicitHeadMiddleware service, and maps to the Zend\Expressive\Router\Middleware\ImplicitHeadMiddleware service.
      • IMPLICIT_OPTIONS_MIDDLEWARE can be used to refer to the former Zend\Expressive\Middleware\ImplicitOptionsMiddleware service, and maps to the Zend\Expressive\Router\Middleware\ImplicitOptionsMiddleware service.
      • NOT_FOUND_MIDDLEWARE can be used to refer to the former Zend\Expressive\Middleware\NotFoundMiddleware service, and maps to the Zend\Expressive\Handler\NotFoundHandler service.

    Changed

    • #579 updates the version constraint for zend-expressive-router to use 3.0.0rc4 or later.

    • #579 updates the version constraint for zend-stratigility to use 3.0.0rc1 or later.

    • #543 adds a dependency on zendframework/zend-httphandlerrunner 1.0.0

    • #542 modifies the composer.json to no longer suggest the pimple/pimple package, but rather the zendframework/zend-pimple-config package.

    • #542 modifies the composer.json to no longer suggest the aura/di package, but rather the zendframework/zend-auradi-config package.

    • #543 updates the Zend\Expressive\ConfigProvider to reflect new, removed, and updated services and their factories.

    • #554 updates the ConfigProvider to add entries for the following constants as follows:

      • IMPLICIT_HEAD_MIDDLEWARE aliases to the Zend\Expressive\Router\Middleware\ImplicitHeadMiddleware service.
      • IMPLICIT_OPTIONS_MIDDLEWARE aliases to the Zend\Expressive\Router\Middleware\ImplicitOptionsMiddleware service.

    • #543 updates Zend\Expressive\Handler\NotFoundHandler to implement the PSR-15 RequestHandlerInterface. As Zend\Expressive\Middleware\NotFoundHandler is removed, Zend\Expressive\Container\NotFoundHandlerFactory has been re-purposedto create an instance of Zend\Expressive\Handler\NotFoundHandler.

    • #561 modifies the Zend\Expressive\Handler\NotFoundHandler to compose a response factory instead of a response prototype.

    • #543 refactors Zend\Expressive\Application completely.

      The class no longer extends Zend\Stratigility\MiddlewarePipe, and instead implements the PSR-15 MiddlewareInterface and RequestHandlerInterface.

      It now requires the following dependencies via constructor injection, in the following order:

      • Zend\Expressive\MiddlewareFactory
      • Zend\Stratigility\MiddlewarePipe; this is the pipeline representing the application.
      • Zend\Expressive\Router\RouteCollector
      • Zend\HttpHandlerRunner\RequestHandlerRunner

      It removes all "getter" methods (as detailed in the "Removed" section of this release), but retains the following methods, with the changes described below. Please note: in most cases, these methods accept the same arguments as in the version 2 series, with the exception of callable double-pass middleware (these may be decorated manually using Zend\Stratigility\doublePassMiddleware()), and http-interop middleware (no longer supported; rewrite as PSR-15 middleware).

      • pipe($middlewareOrPath, $middleware = null) : void passes its arguments to the composed MiddlewareFactory's prepare() method; if two arguments are provided, the second is passed to the factory, and the two together are passed to Zend\Stratigility\path() in order to decorate them to work as middleware. The prepared middleware is then piped to the composed MiddlewarePipe instance.

        As a result of switching to use the MiddlewareFactory to prepare middleware, you may now pipe RequestHandlerInterface instances as well.

      • route(string $path, $middleware, array $methods = null, string $name) : Route passes its $middleware argument to the MiddlewareFactory::prepare() method, and then all arguments to the composed RouteCollector instance's route() method.

        As a result of switching to use the MiddlewareFactory to prepare middleware, you may now route to RequestHandlerInterface instances as well.

      • Each of get, post, patch, put, delete, and any now proxy to route() after marshaling the correct $methods.

      • getRoutes() : Route[] proxies to the composed RouteCollector instance.

      • handle(ServerRequestInterface $request) : ResponseInterface proxies to the composed MiddlewarePipe instance's handle() method.

      • process(ServerRequestInterface $request, RequestHandlerInterface $handler) : ResponseInterface proxies to the composed MiddlewarePipe instance's process() method.

      • run() : void proxies to the composed RequestHandlerRunner instance. Please note that the method no longer accepts any arguments.

    • #543 modifies the Zend\Expressive\Container\ApplicationFactory to reflect the changes to the Zend\Expressive\Application class as detailed above. It pulls the following services to inject via the constructor:

      • Zend\Expressive\MiddlewareFactory
      • Zend\Stratigility\ApplicationPipeline, which should resolve to a MiddlewarePipe instance; use the Zend\Expressive\Container\ApplicationPipelineFactory.
      • Zend\Expressive\Router\RouteCollector
      • Zend\HttpHandlerRunner\RequestHandlerRunner

    • #581 changes how the ApplicationConfigInjectionDelegator::injectPipelineFromConfig() method works. Previously, it would auto-inject routing and dispatch middleware if routes were configured, but no middleware_pipeline was present. Considering that this method will always be called manually, this functionality was removed; the method now becomes a no-op if no middleware_pipeline is present.

    • #568 updates the ErrorHandlerFactory to pull the Psr\Http\Message\ResponseInterface service, which returns a factory capable of returning a response instance, and passes it to the Zend\Stratigility\Middleware\ErrorHandler instance it creates, as that class changes in 3.0.0alpha4 such that it now expects a factory instead of an instance.

    • #562 extracts most logic from Zend\Expressive\Middleware\ErrorResponseGenerator to a new trait, Zend\Expressive\Response\ErrorResponseGeneratorTrait. A trait was used as the classes consuming it are from different namespaces, and thus different inheritance trees. The trait is used by both the ErrorResponseGenerator and the new ServerRequestErrorResponseGenerator.

    • #551 removes Zend\Expressive\Container\RouteMiddlewareFactory, as zend-expressive-router now provides a factory for the middleware.

    • #551 removes Zend\Expressive\Container\DispatchMiddlewareFactory, as zend-expressive-router now provides a factory for the middleware.

    • #551 removes Zend\Expressive\Middleware\ImplicitHeadMiddleware, as it is now provided by the zend-expressive-router package.

    • #551 removes Zend\Expressive\Middleware\ImplicitOptionsMiddleware, as it is now provided by the zend-expressive-router package.

    Deprecated

    • Nothing.

    Removed

    • #529 removes support for PHP versions prior to PHP 7.1.

    • #529 removes support for http-interop/http-middleware (previous PSR-15 iteration).

    • #543 removes support for http-interop/http-server-middleware.

    • #580 removes zend-diactoros as a requirement; all usages of it within the package are currently conditional on it being installed, and can be replaced easily with any other PSR-7 implementation at this time.

    • #543 removes the class Zend\Expressive\Delegate\NotFoundDelegate; use Zend\Expressive\Handler\NotFoundHandler instead.

    • #546 removes the service Zend\Expressive\Delegate\DefaultDelegate, as there is no longer a concept of a default handler invoked by the application. Instead, developers MUST pipe a request handler or middleware at the innermost layer of the pipeline guaranteed to return a response; we recommend using Zend\Expressive\Handler\NotFoundHandler for this purpose.

    • #543 removes the class Zend\Expressive\Middleware\RouteMiddleware. Use the RouteMiddleware from zend-expressive-router instead.

    • #543 removes the class Zend\Expressive\Middleware\DispatchMiddleware. Use the DispatchMiddleware from zend-expressive-router instead; the factory Zend\Expressive\Container\DispatchMiddlewareFactory will return an instance for you.

    • #543 removes the class Zend\Expressive\Emitter\EmitterStack; use the class Zend\HttpHandlerRunner\Emitter\EmitterStack instead.

    • #543 removes the following methods from Zend\Expressive\Application:

      • pipeRoutingMiddleware(): use pipe(\Zend\Expressive\Router\RouteMiddleware::class) instead.
      • pipeDispatchMiddleware(): use pipe(\Zend\Expressive\Router\DispatchMiddleware::class) instead.
      • getContainer()
      • getDefaultDelegate(): ensure you pipe middleware or a request handler capable of returning a response at the innermost layer; Zend\Expressive\Handler\NotFoundHandler can be used for this.
      • getEmitter(): use the Zend\HttpHandlerRunner\Emitter\EmitterInterface service from the container.
      • injectPipelineFromConfig(): use the new ApplicationConfigInjectionDelegator and/or the static method of the same name it defines.
      • injectRoutesFromConfig(): use the new ApplicationConfigInjectionDelegator and/or the static method of the same name it defines.

    • #543 removes the class Zend\Expressive\AppFactory.

    • The internal Zend\Expressive\MarshalMiddlewareTrait, Zend\Expressive\ApplicationConfigInjectionTrait, and Zend\Expressive\IsCallableMiddlewareTrait have been removed.

    Fixed

    • #574 updates the classes Zend\Expressive\Exception\InvalidMiddlewareException and MissingDependencyException to implement the PSR-11 ContainerExceptionInterface.
    Source code(tar.gz)
    Source code(zip)

  • 3.0.0rc5(Mar 14, 2018)

    This release contains a breaking change.

    This release updates to zend-expressive-router 3.0.0rc5, which renames Zend\Expressive\Router\Middleware\PathBasedRoutingMiddleware to Zend\Expressive\Router\RouteCollector, and drops its extension of RouteMiddleware. This was done to prevent confusion between the two route middleware implementations in the final release, and because the primariy duty of the (newly renamed) RouteCollector is to produce and inject Route instances into the composed router.

    This release of zend-expressive required one change to comply: Zend\Expressive\Application now composes a RouteCollector instead of a PathBasedRoutingMiddleware instance.

    Below is a cumulative list of changes for the 3.0.0 release, including all changes from previous alpha and RC releases. References to PathBasedRoutingMiddleware have been updated to reference RouteCollector or RouteMiddleware based on context:

    Added

    • #543 adds support for the final PSR-15 interfaces, and explicitly depends on psr/http-server-middleware.

    • #538 adds scalar and return type hints to methods wherever possible.

    • #562 adds the class Zend\Expressive\Response\ServerRequestErrorResponseGenerator, and maps it to the Zend\Expressive\Container\ServerRequestErrorResponseGeneratorFactory. The class generates an error response when an exeption occurs producing a server request instance, and can be optionally templated.

    • #543 adds a new class, Zend\Expressive\MiddlewareContainer. The class decorates a PSR-11 ContainerInterface, and adds the following behavior:

      • If a class is not in the container, but exists, has() will return true.
      • If a class is not in the container, but exists, get() will attempt to instantiate it, caching the instance locally if it is valid.
      • Any instance pulled from the container or directly instantiated is tested. If it is a PSR-15 RequestHandlerInterface, it will decorate it in a zend-stratigility RequestHandlerMiddleware instance. If the instance is not a PSR-15 MiddlewareInterface, the container will raise a Zend\Expressive\Exception\InvalidMiddlewareException.

    • #543 adds a new class, Zend\Expressive\MiddlewareFactory. The class composes a MiddlewareContainer, and exposes the following methods:

      • callable(callable $middleware) : CallableMiddlewareDecorator
      • handler(RequestHandlerInterface $handler) : RequestHandlerMiddleware
      • lazy(string $service) : LazyLoadingMiddleware
      • prepare($middleware) : MiddlewareInterface: accepts a string service name, callable, RequestHandlerInterface, MiddlewareInterface, or array of such values, and returns a MiddlewareInterface, raising an exception if it cannot determine what to do.
      • pipeline(...$middleware) : MiddlewarePipe: passes each argument to prepare(), and the result to MiddlewarePipe::pipe(), returning the pipeline when complete.

    • #543 adds the following factory classes, each within the Zend\Expressive\Container namespace:

      • ApplicationPipelineFactory: creates and returns a Zend\Stratigility\MiddlewarePipe to use as the application middleware pipeline.
      • DispatchMiddlewareFactory: creates and returns a Zend\Expressive\Router\DispatchMiddleware instance.
      • EmitterFactory: creates and returns a Zend\HttpHandlerRunner\Emitter\EmitterStack instance composing an SapiEmitter from that same namespace as the only emitter on the stack. This is used as a dependency for the Zend\HttpHandlerRunner\RequestHandlerRunner service.
      • MiddlewareContainerFactory: creates and returns a Zend\Expressive\MiddlewareContainer instance decorating the PSR-11 container passed to the factory.
      • MiddlewareFactoryFactory: creates and returns a Zend\Expressive\MiddlewareFactory instance decorating a MiddlewareContainer instance as pulled from the container.
      • RequestHandlerRunnerFactory: creates and returns a Zend\HttpHandlerRunner\RequestHandlerRunner instance, using the services Zend\Expressive\Application, Zend\HttpHandlerRunner\Emitter\EmitterInterface, Zend\Expressive\ServerRequestFactory, and Zend\Expressive\ServerRequestErrorResponseGenerator.
      • ServerRequestFactoryFactory: creates and returns a callable factory for generating a PSR-7 ServerRequestInterface instance; this returned factory is a dependency for the Zend\HttpHandlerRunner\RequestHandlerRunner service.
      • ServerRequestErrorResponseGeneratorFactory: creates and returns a callable that accepts a PHP Throwable in order to generate a PSR-7 ResponseInterface instance; this returned factory is a dependency for the Zend\HttpHandlerRunner\RequestHandlerRunner service, which uses it to generate a response in the scenario that the ServerRequestFactory is unable to create a request instance.

    • #551 and #554 add the following constants under the Zend\Expressive namespace:

      • DEFAULT_DELEGATE can be used to refer to the former DefaultDelegate FQCN service, and maps to the Zend\Expressive\Handler\NotFoundHandler service.
      • IMPLICIT_HEAD_MIDDLEWARE can be used to refer to the former Zend\Expressive\Middleware\ImplicitHeadMiddleware service, and maps to the Zend\Expressive\Router\Middleware\ImplicitHeadMiddleware service.
      • IMPLICIT_OPTIONS_MIDDLEWARE can be used to refer to the former Zend\Expressive\Middleware\ImplicitOptionsMiddleware service, and maps to the Zend\Expressive\Router\Middleware\ImplicitOptionsMiddleware service.
      • NOT_FOUND_MIDDLEWARE can be used to refer to the former Zend\Expressive\Middleware\NotFoundMiddleware service, and maps to the Zend\Expressive\Handler\NotFoundHandler service.

    Changed

    • #579 updates the version constraint for zend-expressive-router to use 3.0.0rc4 or later.

    • #579 updates the version constraint for zend-stratigility to use 3.0.0rc1 or later.

    • #543 adds a dependency on zendframework/zend-httphandlerrunner 1.0.0

    • #542 modifies the composer.json to no longer suggest the pimple/pimple package, but rather the zendframework/zend-pimple-config package.

    • #542 modifies the composer.json to no longer suggest the aura/di package, but rather the zendframework/zend-auradi-config package.

    • #543 updates the Zend\Expressive\ConfigProvider to reflect new, removed, and updated services and their factories.

    • #554 updates the ConfigProvider to add entries for the following constants as follows:

      • IMPLICIT_HEAD_MIDDLEWARE aliases to the Zend\Expressive\Router\Middleware\ImplicitHeadMiddleware service.
      • IMPLICIT_OPTIONS_MIDDLEWARE aliases to the Zend\Expressive\Router\Middleware\ImplicitOptionsMiddleware service.

    • #543 updates Zend\Expressive\Handler\NotFoundHandler to implement the PSR-15 RequestHandlerInterface. As Zend\Expressive\Middleware\NotFoundHandler is removed, Zend\Expressive\Container\NotFoundHandlerFactory has been re-purposedto create an instance of Zend\Expressive\Handler\NotFoundHandler.

    • #561 modifies the Zend\Expressive\Handler\NotFoundHandler to compose a response factory instead of a response prototype.

    • #543 refactors Zend\Expressive\Application completely.

      The class no longer extends Zend\Stratigility\MiddlewarePipe, and instead implements the PSR-15 MiddlewareInterface and RequestHandlerInterface.

      It now requires the following dependencies via constructor injection, in the following order:

      • Zend\Expressive\MiddlewareFactory
      • Zend\Stratigility\MiddlewarePipe; this is the pipeline representing the application.
      • Zend\Expressive\Router\RouteCollector
      • Zend\HttpHandlerRunner\RequestHandlerRunner

      It removes all "getter" methods (as detailed in the "Removed" section of this release), but retains the following methods, with the changes described below. Please note: in most cases, these methods accept the same arguments as in the version 2 series, with the exception of callable double-pass middleware (these may be decorated manually using Zend\Stratigility\doublePassMiddleware()), and http-interop middleware (no longer supported; rewrite as PSR-15 middleware).

      • pipe($middlewareOrPath, $middleware = null) : void passes its arguments to the composed MiddlewareFactory's prepare() method; if two arguments are provided, the second is passed to the factory, and the two together are passed to Zend\Stratigility\path() in order to decorate them to work as middleware. The prepared middleware is then piped to the composed MiddlewarePipe instance.

        As a result of switching to use the MiddlewareFactory to prepare middleware, you may now pipe RequestHandlerInterface instances as well.

      • route(string $path, $middleware, array $methods = null, string $name) : Route passes its $middleware argument to the MiddlewareFactory::prepare() method, and then all arguments to the composed RouteCollector instance's route() method.

        As a result of switching to use the MiddlewareFactory to prepare middleware, you may now route to RequestHandlerInterface instances as well.

      • Each of get, post, patch, put, delete, and any now proxy to route() after marshaling the correct $methods.

      • getRoutes() : Route[] proxies to the composed RouteCollector instance.

      • handle(ServerRequestInterface $request) : ResponseInterface proxies to the composed MiddlewarePipe instance's handle() method.

      • process(ServerRequestInterface $request, RequestHandlerInterface $handler) : ResponseInterface proxies to the composed MiddlewarePipe instance's process() method.

      • run() : void proxies to the composed RequestHandlerRunner instance. Please note that the method no longer accepts any arguments.

    • #543 modifies the Zend\Expressive\Container\ApplicationFactory to reflect the changes to the Zend\Expressive\Application class as detailed above. It pulls the following services to inject via the constructor:

      • Zend\Expressive\MiddlewareFactory
      • Zend\Stratigility\ApplicationPipeline, which should resolve to a MiddlewarePipe instance; use the Zend\Expressive\Container\ApplicationPipelineFactory.
      • Zend\Expressive\Router\RouteCollector
      • Zend\HttpHandlerRunner\RequestHandlerRunner

    • #581 changes how the ApplicationConfigInjectionDelegator::injectPipelineFromConfig() method works. Previously, it would auto-inject routing and dispatch middleware if routes were configured, but no middleware_pipeline was present. Considering that this method will always be called manually, this functionality was removed; the method now becomes a no-op if no middleware_pipeline is present.

    • #568 updates the ErrorHandlerFactory to pull the Psr\Http\Message\ResponseInterface service, which returns a factory capable of returning a response instance, and passes it to the Zend\Stratigility\Middleware\ErrorHandler instance it creates, as that class changes in 3.0.0alpha4 such that it now expects a factory instead of an instance.

    • #562 extracts most logic from Zend\Expressive\Middleware\ErrorResponseGenerator to a new trait, Zend\Expressive\Response\ErrorResponseGeneratorTrait. A trait was used as the classes consuming it are from different namespaces, and thus different inheritance trees. The trait is used by both the ErrorResponseGenerator and the new ServerRequestErrorResponseGenerator.

    • #551 removes Zend\Expressive\Container\RouteMiddlewareFactory, as zend-expressive-router now provides a factory for the middleware.

    • #551 removes Zend\Expressive\Container\DispatchMiddlewareFactory, as zend-expressive-router now provides a factory for the middleware.

    • #551 removes Zend\Expressive\Middleware\ImplicitHeadMiddleware, as it is now provided by the zend-expressive-router package.

    • #551 removes Zend\Expressive\Middleware\ImplicitOptionsMiddleware, as it is now provided by the zend-expressive-router package.

    Deprecated

    • Nothing.

    Removed

    • #529 removes support for PHP versions prior to PHP 7.1.

    • #529 removes support for http-interop/http-middleware (previous PSR-15 iteration).

    • #543 removes support for http-interop/http-server-middleware.

    • #580 removes zend-diactoros as a requirement; all usages of it within the package are currently conditional on it being installed, and can be replaced easily with any other PSR-7 implementation at this time.

    • #543 removes the class Zend\Expressive\Delegate\NotFoundDelegate; use Zend\Expressive\Handler\NotFoundHandler instead.

    • #546 removes the service Zend\Expressive\Delegate\DefaultDelegate, as there is no longer a concept of a default handler invoked by the application. Instead, developers MUST pipe a request handler or middleware at the innermost layer of the pipeline guaranteed to return a response; we recommend using Zend\Expressive\Handler\NotFoundHandler for this purpose.

    • #543 removes the class Zend\Expressive\Middleware\RouteMiddleware. Use the RouteMiddleware from zend-expressive-router instead.

    • #543 removes the class Zend\Expressive\Middleware\DispatchMiddleware. Use the DispatchMiddleware from zend-expressive-router instead; the factory Zend\Expressive\Container\DispatchMiddlewareFactory will return an instance for you.

    • #543 removes the class Zend\Expressive\Emitter\EmitterStack; use the class Zend\HttpHandlerRunner\Emitter\EmitterStack instead.

    • #543 removes the following methods from Zend\Expressive\Application:

      • pipeRoutingMiddleware(): use pipe(\Zend\Expressive\Router\RouteMiddleware::class) instead.
      • pipeDispatchMiddleware(): use pipe(\Zend\Expressive\Router\DispatchMiddleware::class) instead.
      • getContainer()
      • getDefaultDelegate(): ensure you pipe middleware or a request handler capable of returning a response at the innermost layer; Zend\Expressive\Handler\NotFoundHandler can be used for this.
      • getEmitter(): use the Zend\HttpHandlerRunner\Emitter\EmitterInterface service from the container.
      • injectPipelineFromConfig(): use the new ApplicationConfigInjectionDelegator and/or the static method of the same name it defines.
      • injectRoutesFromConfig(): use the new ApplicationConfigInjectionDelegator and/or the static method of the same name it defines.

    • #543 removes the class Zend\Expressive\AppFactory.

    Fixed

    • #574 updates the classes Zend\Expressive\Exception\InvalidMiddlewareException and MissingDependencyException to implement the PSR-11 ContainerExceptionInterface.
    Source code(tar.gz)
    Source code(zip)

  • 3.0.0rc4(Mar 13, 2018)

    Added

    • Nothing.

    Changed

    • Forward ports a change made in #581 to how the ApplicationConfigInjectionDelegator::injectPipelineFromConfig() method works. Previously, it would auto-inject routing and dispatch middleware if routes were configured, but no middleware_pipeline was present. Considering that this method will always be called manually, this functionality was removed; the method now becomes a no-op if no middleware_pipeline is present.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • Nothing.
    Source code(tar.gz)
    Source code(zip)

  • 2.2.0(Mar 12, 2018)

    Added

    • #581 adds the class Zend\Expressive\ConfigProvider, and exposes it to the zend-component-installer Composer plugin. We recommend updating your config/config.php to reference it, as well as the Zend\Expressive\Router\ConfigProvider shipped with zend-expressive-router versions 2.4 and up.

    • #581 adds the class Zend\Expressive\Container\ApplicationConfigInjectionDelegator. The class can act as a delegator factory, and, when enabled, will inject routes and pipeline middleware defined in configuration.

      Additionally, the class exposes two static methods:

      • injectPipelineFromConfig(Application $app, array $config)
      • injectRoutesFromConfig(Application $app, array $config)

      These may be called to modify an Application instance based on an array of configuration. See thd documentation for more details.

    • #581 adds the class Zend\Expressive\Handler\NotFoundHandler; the class takes over the functionality previously provided in Zend\Expressive\Delegate\NotFoundDelegate.

    Changed

    • #581 updates the minimum supported zend-stratigility version to 2.2.0.

    • #581 updates the minimum supported zend-expressive-router version to 2.4.0.

    Deprecated

    • #581 deprecates the following classes and traits:

      • Zend\Expressive\AppFactory: if you are using this, you will need to switch to direct usage of Zend\Expressive\Application or a Zend\Stratigility\MiddlewarePipe instance.

      • Zend\Expressive\ApplicationConfigInjectionTrait: if you are using it, it is marked internal, and deprecated; it will be removed in version 3.

      • Zend\Expressive\Container\NotFoundDelegateFactory: the NotFoundDelegate will be renamed to Zend\Expressive\Handler\NotFoundHandler in version 3, making this factory obsolete.

      • Zend\Expressive\Delegate\NotFoundDelegate: this class becomes Zend\Expressive\Handler\NotFoundHandler in v3, and the new class is added in version 2.2 as well.

      • Zend\Expressive\Emitter\EmitterStack: the emitter concept is extracted from zend-diactoros to a new component, zend-httphandlerrunner. This latter component is used in version 3, and defines the EmitterStack class. Unless you are extending it or interacting with it directly, this change should not affect you; the Zend\Diactoros\Response\EmitterInterface service will be directed to the new class in that version.

      • Zend\Expressive\IsCallableInteropMiddlewareTrait: if you are using it, it is marked internal, and deprecated; it will be removed in version 3.

      • Zend\Expressive\MarshalMiddlewareTrait: if you are using it, it is marked internal, and deprecated; it will be removed in version 3.

      • Zend\Expressive\Middleware\DispatchMiddleware: this functionality has been moved to zend-expressive-router, under the Zend\Expressive\Router\Middleware namespace.

      • Zend\Expressive\Middleware\ImplicitHeadMiddleware: this functionality has been moved to zend-expressive-router, under the Zend\Expressive\Router\Middleware namespace.

      • Zend\Expressive\Middleware\ImplicitOptionsMiddleware: this functionality has been moved to zend-expressive-router, under the Zend\Expressive\Router\Middleware namespace.

      • Zend\Expressive\Middleware\NotFoundHandler: this will be removed in version 3, where you can instead pipe Zend\Expressive\Handler\NotFoundHandler directly instead.

      • Zend\Expressive\Middleware\RouteMiddleware: this functionality has been moved to zend-expressive-router, under the Zend\Expressive\Router\Middleware namespace.

    • #581 deprecates the following methods from Zend\Expressive\Application:

      • pipeRoutingMiddleware()
      • pipeDispatchMiddleware()
      • getContainer(): this method is removed in version 3; container access will only be via the bootstrap.
      • getDefaultDelegate(): the concept of a default delegate is removed in version 3.
      • getEmitter(): emitters move to a different collaborator in version 3.
      • injectPipelineFromConfig() andd injectRoutesFromConfig() are methods defined by the ApplicationConfigInjectionTrait, which will be removed in version 3. Use the ApplicationConfigInjectionDelegator instead.

    Removed

    • Nothing.

    Fixed

    • Nothing.
    Source code(tar.gz)
    Source code(zip)

  • 2.1.1(Mar 9, 2018)

    Added

    • Nothing.

    Changed

    • Nothing.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • #583 provides a number of minor fixes and test changes to ensure the component works with the zend-expressive-router 2.4 version. In particular, configuration-driven routes will now work properly across all versions, without deprecation notices.

    • #582 fixes redirects in the documentation.

    Source code(tar.gz)
    Source code(zip)

  • 3.0.0rc3(Mar 7, 2018)

    Added

    • Nothing.

    Changed

    • #579 updates the version constraint for zend-expressive-router to use 3.0.0rc4 or later.

    • #579 updates the version constraint for zend-stratigility to use 3.0.0rc1 or later.

    Deprecated

    • Nothing.

    Removed

    • #580 removes zend-diactoros as a requirement; all usages of it within the package are currently conditional on it being installed, and can be replaced easily with any other PSR-7 implementation at this time.

    Fixed

    • Nothing.
    Source code(tar.gz)
    Source code(zip)

  • 3.0.0rc2(Mar 6, 2018)

    Added

    • Nothing.

    Changed

    • Nothing.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • #578 fixes the version constraint used with zend-stratigility to allow it to update to later versions when released.
    Source code(tar.gz)
    Source code(zip)

  • 3.0.0rc1(Feb 27, 2018)

    Added

    • Nothing.

    Changed

    • Nothing.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • #574 updates the classes Zend\Expressive\Exception\InvalidMiddlewareException and MissingDependencyException to implement the PSR-11 ContainerExceptionInterface.
    Source code(tar.gz)
    Source code(zip)

  • 3.0.0alpha9(Feb 22, 2018)

    Added

    • #562 adds the class Zend\Expressive\Response\ServerRequestErrorResponseGenerator, and maps it to the Zend\Expressive\Container\ServerRequestErrorResponseGeneratorFactory. The class generates an error response when an exeption occurs producing a server request instance, and can be optionally templated.

    Changed

    • #568 updates the zendframework/zend-stratigility dependency to require at least 3.0.0alpha4.

    • #568 updates the ErrorHandlerFactory to pull the Psr\Http\Message\ResponseInterface service, which returns a factory capable of returning a response instance, and passes it to the Zend\Stratigility\Middleware\ErrorHandler instance it creates, as that class changes in 3.0.0alpha4 such that it now expects a factory instead of an instance.

    • #562 modifies the Zend\Expressive\Container\RequestHandlerRunnerFactory to depend on the Zend\Expressive\Response\ServerRequestErrorResponseGenerator service instead of the Zend\Expressive\SERVER_REQUEST_ERROR_RESPONSE_GENERATOR virtual service.

    • #562 extracts most logic from Zend\Expressive\Middleware\ErrorResponseGenerator to a new trait, Zend\Expressive\Response\ErrorResponseGeneratorTrait. A trait was used as the classes consuming it are from different namespaces, and thus different inheritance trees. The trait is used by both the ErrorResponseGenerator and the new ServerRequestErrorResponseGenerator.

    Deprecated

    • Nothing.

    Removed

    • #562 removes the constant Zend\Expressive\SERVER_REQUEST_ERROR_RESPONSE_GENERATOR. It was only used internally previously.

    Fixed

    • Nothing.
    Source code(tar.gz)
    Source code(zip)

  • 3.0.0alpha8(Feb 21, 2018)

    Added

    • Nothing.

    Changed

    • #559 reverts the changes performed for #556 to the ApplicationFactory. It now uses the canonical service name for the PathBasedRoutingMiddleware instead of the ROUTE_MIDDLEWARE constant.

    • #561 updates to zend-expressive-router 3.0.0alpha3.

    • #561 renames Zend\Expressive\Container\ResponseFactory to Zend\Expressive\Container\ResponseFactoryFactory, and the factory now returns a callable that will return a zend-diactoros Response instance, instead of returning the instance itself. Each of the various services named after zend-expressive-router response constants were removed in favor of a single Psr\Http\Message\ResponseInterface service resolving to the ResponseFactoryFactory.

    • #561 modifies the Zend\Expressive\Handler\NotFoundHandler to compose a response factory instead of a response prototype. This approach allows it to use the Psr\Http\Message\ResponseInterface service defined per the above note.

    • #561 renames the Zend\Expressive\Router\IMPLICIT_HEAD_MIDDLEWARE_STREAM_FACTORY service to Psr\Http\Message\StreamInterface, as this is what zend-expressive-router now expects.

    • #561 renames the Zend\Expressive\ServerRequestFactory service to Psr\Http\Message\ServerRequestInterface. The Zend\Expressive\SERVER_REQUEST_FACTORY constant now resolves to the interface name.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • #558 adds a missing import statement for the PSR-7 StreamInterface to the StreamFactoryFactory.

    • #555 adds tests to better ensure that the entries in the ConfigProvider resolve to valid factories, aliases, etc.

    Source code(tar.gz)
    Source code(zip)

  • 3.0.0alpha7(Feb 14, 2018)

    Added

    • Nothing.

    Changed

    • #556 modifies the ApplicationFactory such that it now uses the Zend\Expressive\ROUTE_MIDDLEWARE constant in order to retrieve the Zend\Expressive\Router\Middleware\PathBasedRoutingMiddleware instance. This is done to help smooth upgrades from v2 to v3, as it prevents a manual step when updating the config/pipeline.php, and ensures that the instance composed in the application is the same instance piped to the application.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • Nothing.
    Source code(tar.gz)
    Source code(zip)

  • 3.0.0alpha6(Feb 14, 2018)

    Added

    • #551 and #553 add Zend\Expressive\Container\StreamFactoryFactory, for producing an callable capable of producing an empty, writable PSR-7 StreamInterface instance using zend-diactoros. The stream produced is backed by a php://temp stream.

    • #551 and #554 add the following constants under the Zend\Expressive namespace:

      • DEFAULT_DELEGATE can be used to refer to the former DefaultDelegate FQCN service.
      • IMPLICIT_HEAD_MIDDLEWARE can be used to refer to the former Zend\Expressive\Router\Middleware\ImplicitHeadMiddleware service.
      • IMPLICIT_OPTIONS_MIDDLEWARE can be used to refer to the former Zend\Expressive\Router\Middleware\ImplicitOPTIONSMiddleware service.
      • NOT_FOUND_MIDDLEWARE can be used to refer to the former Zend\Expressive\Middleware\NotFoundMiddleware service.
      • NOT_FOUND_RESPONSE can be used to refer to the former Zend\Expressive\Response\NotFoundResponseInterface service.
      • SERVER_REQUEST_ERROR_RESPONSE_GENERATOR can be used to refer to the former Zend\Expressive\ServerRequestErrorResponseGenerator service.
      • SERVER_REQUEST_FACTORY can be used to refer to the former Zend\Expressive\ServerRequestFactory service.

    Changed

    • #551 updates dependencies to pin to zend-expressive-router 3.0.0alpha2 or later.

    • #551 renames Zend\Expressive\Middleware\NotFoundMiddleware to Zend\Expressive\Handler\NotFoundHandler, which allows it to be used as a PSR-15 request handler, and, when piped or routed to, also as middleware. The original class name was aliased to the renamed class in the ConfigProvider.

    • #551 modifies the ApplicationConfigInjectionDelegator to raise an exception if the callback passed to it does not produce an Application instance, instead of returning the instance without changes. This allows developers to understand what they need to correct in their service configuration.

    • #551 updates the ConfigProvider to add entries for the following zend-expressive-router constants as follows:

      • IMPLICIT_HEAD_MIDDLEWARE_RESPONSE maps to the ResponseFactory.
      • IMPLICIT_HEAD_MIDDLEWARE_STREAM_FACTORY maps to the StreamFactory.
      • IMPLICIT_OPTIONS_MIDDLEWARE_RESPONSE maps to the ResponseFactory.

    • #554 updates the ConfigProvider to add entries for the following constants as follows:

      • IMPLICIT_HEAD_MIDDLEWARE aliases to the Zend\Expressive\Router\Middleware\ImplicitHeadMiddleware service.
      • IMPLICIT_OPTIONS_MIDDLEWARE aliases to the Zend\Expressive\Router\Middleware\ImplicitOptionsMiddleware service.

    Deprecated

    • Nothing.

    Removed

    • #551 removes Zend\Expressive\Container\RouteMiddlewareFactory, as zend-expressive-router now provides a factory for the middleware.

    • #551 removes Zend\Expressive\Container\DispatchMiddlewareFactory, as zend-expressive-router now provides a factory for the middleware.

    • #551 removes Zend\Expressive\Middleware\ImplicitHeadMiddleware, as it is now provided by the zend-expressive-router package.

    • #551 removes Zend\Expressive\Middleware\ImplicitOptionsMiddleware, as it is now provided by the zend-expressive-router package.

    Fixed

    • Nothing.
    Source code(tar.gz)
    Source code(zip)

  • 3.0.0alpha5(Feb 7, 2018)

    Added

    • Nothing.

    Changed

    • #547 modifies the ConfigProvider, the NotFoundMiddlewareFactory, and the RouteMiddlewareFactory to remove the concept of the unshared ResponseInterface service, as service sharing is not always configurable in container implementations. To resolve the ability to provide discrete instances, the ConfigProvider defines two new virtual services that each resolve to the Zend\Expressive\Container\ResponseFactory:

      • Zend\Expressive\Response\NotFoundResponseInterface
      • Zend\Expressive\Response\RouterResponseInterface

      The related factories now consume these services in order to receive a response prototype for the services they produce.

    • #542 modifies the composer.json to no longer suggest the pimple/pimple package, but rather the zendframework/zend-pimple-config package.

    • #542 modifies the composer.json to no longer suggest the aura/di package, but rather the zendframework/zend-auradi-config package.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • Nothing.
    Source code(tar.gz)
    Source code(zip)

  • 3.0.0alpha4(Feb 7, 2018)

    Added

    • Nothing.

    Changed

    • Nothing.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • #549 modifies how the ServerRequestFactoryFactory returns the ServerRequestFactory::fromGlobals() mechanism, wrapping it in an anonymous function. This ensures compatibility across all containers.

    • #550 fixes how the ConfigProvider references the ErrorResponseGenerator, using the Zend\Expressive\Middleware namespace instead of the Zend\Stratigility\Middleware namespace.

    Source code(tar.gz)
    Source code(zip)

  • 3.0.0alpha3(Feb 6, 2018)

    Added

    • Nothing.

    Changed

    • #546 merges Zend\Expressive\Middleware\NotFoundHandler into Zend\Expressive\Middleware\NotFoundMiddleware, as well as merges Zend\Expressive\Container\NotFoundHandlerFactory into Zend\Expressive\Container\NotFoundMiddlewareFactory. NotFoundMiddleware now does the work of the former Zend\Expressive\Delegate\NotFoundDelegate, and, as such, accepts the following constructor arguments:

      • PSR-7 ResponseInterface $responsePrototype (required)
      • Zend\Expressive\Template\TemplateRendererInterface $renderer (optional)
      • string $template = self::TEMPLATE_DEFAULT (optional; defaults to "error::404")
      • string $layout = self::LAYOUT_DEFAULT (optional; defaults to "layout::default")

    Deprecated

    • Nothing.

    Removed

    • #546 removes the class Zend\Expressive\Delegate\DefaultDelegate, as there is no longer a concept of a default handler invoked by the application. Instead, developers MUST pipe middleware at the innermost layer of the pipeline guaranteed to return a response; we recommend using Zend\Expressive\Middleware\NotFoundMiddleware for this purpose.

    Fixed

    • Nothing.
    Source code(tar.gz)
    Source code(zip)

  • 3.0.0alpha2(Feb 5, 2018)

    Added

    • #543 adds support for the final PSR-15 interfaces, and explicitly depends on psr/http-server-middleware.

    • #543 adds a new class, Zend\Expressive\MiddlewareContainer. The class decorates a PSR-11 ContainerInterface, and adds the following behavior:

      • If a class is not in the container, but exists, has() will return true.
      • If a class is not in the container, but exists, get() will attempt to instantiate it, caching the instance locally if it is valid.
      • Any instance pulled from the container or directly instantiated is tested. If it is a PSR-15 RequestHandlerInterface, it will decorate it in a zend-stratigility RequestHandlerMiddleware instance. If the instance is not a PSR-15 MiddlewareInterface, the container will raise a Zend\Expressive\Exception\InvalidMiddlewareException.

    • #543 adds a new class, Zend\Expressive\MiddlewareFactory. The class composes a MiddlewareContainer, and exposes the following methods:

      • callable(callable $middleware) : CallableMiddlewareDecorator
      • handler(RequestHandlerInterface $handler) : RequestHandlerMiddleware
      • lazy(string $service) : LazyLoadingMiddleware
      • prepare($middleware) : MiddlewareInterface: accepts a string service name, callable, RequestHandlerInterface, MiddlewareInterface, or array of such values, and returns a MiddlewareInterface, raising an exception if it cannot determine what to do.
      • pipeline(...$middleware) : MiddlewarePipe: passes each argument to prepare(), and the result to MiddlewarePipe::pipe(), returning the pipeline when complete.

    • #543 adds the following factory classes, each within the Zend\Expressive\Container namespace:

      • ApplicationPipelineFactory: creates and returns a Zend\Stratigility\MiddlewarePipe to use as the application middleware pipeline.
      • DispatchMiddlewareFactory: creates and returns a Zend\Expressive\Router\DispatchMiddleware instance.
      • EmitterFactory: creates and returns a Zend\HttpHandlerRunner\Emitter\EmitterStack instance composing an SapiEmitter from that same namespace as the only emitter on the stack. This is used as a dependency for the Zend\HttpHandlerRunner\RequestHandlerRunner service.
      • MiddlewareContainerFactory: creates and returns a Zend\Expressive\MiddlewareContainer instance decorating the PSR-11 container passed to the factory.
      • MiddlewareFactoryFactory: creates and returns a Zend\Expressive\MiddlewareFactory instance decorating a MiddlewareContainer instance as pulled from the container.
      • RequestHandlerRunnerFactory: creates and returns a Zend\HttpHandlerRunner\RequestHandlerRunner instance, using the services Zend\Expressive\Application, Zend\HttpHandlerRunner\Emitter\EmitterInterface, Zend\Expressive\ServerRequestFactory, and Zend\Expressive\ServerRequestErrorResponseGenerator.
      • RouteMiddlewareFactory: creates and returns a Zend\Expressive\Router\PathBasedRoutingMiddleware instance.
      • ServerRequestFactoryFactory: creates and returns a callable factory for generating a PSR-7 ServerRequestInterface instance; this returned factory is a dependency for the Zend\HttpHandlerRunner\RequestHandlerRunner service.
      • ServerRequestErrorResponseGeneratorFactory: creates and returns a callable that accepts a PHP Throwable in order to generate a PSR-7 ResponseInterface instance; this returned factory is a dependency for the Zend\HttpHandlerRunner\RequestHandlerRunner service, which uses it to generate a response in the scenario that the ServerRequestFactory is unable to create a request instance.

    • #543 adds the class Zend\Expressive\Container\ApplicationConfigInjectionDelegator. This class may be used either as a delegator factory on the Zend\Expressive\Application instance, or you may use the two static methods it defines to inject pipeline middleware and/or routes from configuration:

      • injectPipelineFromConfig(Application $application, array $config) : void
      • injectRoutesFromConfig(Application $application, array $config) : void

      These methods work the same way as the associated Application methods from version 2, accepting the same configuration.

    • #543 adds Zend\Expressive\ConfigProvider, which details the default service mappings.

    Changed

    • #543 adds dependencies on each of:

      • zend-stratigility 3.0.0alpha3
      • zend-expressive-router 3.0.0alpha1
      • zend-httphandlerrunner 1.0.0

      and removes the dependency http-interop/http-server-middleware.

    • #543 renames Zend\Expressive\Middleware\NotFoundHandler to Zend\Expressive\Middleware\NotFoundMiddleware, and its accompanying factory Zend\Expressive\Container\NotFoundHandlerFactory to Zend\Expressive\Container\NotFoundMiddlewareFactory.

    • #543 renames Zend\Expressive\Delegate\NotFoundDelegate to Zend\Expressive\Handler\NotFoundHandler, updating it to implement the PSR-15 RequestHandlerInterface. It also renames the factory Zend\Expressive\Container\NotFoundDelegateFactory to Zend\Expressive\Container\NotFoundHandlerFactory.

    • #543 refactors Zend\Expressive\Application completely.

      The class no longer extends Zend\Stratigility\MiddlewarePipe, and instead implements the PSR-15 MiddlewareInterface and RequestHandlerInterface.

      It now requires the following dependencies via constructor injection, in the following order:

      • Zend\Expressive\MiddlewareFactory
      • Zend\Stratigility\MiddlewarePipe; this is the pipeline representing the application.
      • Zend\Expressive\Router\PathBasedRoutingMiddleware
      • Zend\HttpHandlerRunner\RequestHandlerRunner

      It removes all "getter" methods (as detailed in the "Removed" section of this release), but retains the following methods, with the changes described below. Please note: in most cases, these methods accept the same arguments as in the version 2 series, with the exception of callable double-pass middleware (these may be decorated manually using Zend\Stratigility\doublePassMiddleware()), and http-interop middleware (no longer supported; rewrite as PSR-15 middleware).

      • pipe($middlewareOrPath, $middleware = null) : void passes its arguments to the composed MiddlewareFactory's prepare() method; if two arguments are provided, the second is passed to the factory, and the two together are passed to Zend\Stratigility\path() in order to decorate them to work as middleware. The prepared middleware is then piped to the composed MiddlewarePipe instance.

        As a result of switching to use the MiddlewareFactory to prepare middleware, you may now pipe RequestHandlerInterface instances as well.

      • route(string $path, $middleware, array $methods = null, string $name) : Route passes its $middleware argument to the MiddlewareFactory::prepare() method, and then all arguments to the composed PathBasedRoutingMiddleware instance's route() method.

        As a result of switching to use the MiddlewareFactory to prepare middleware, you may now route to RequestHandlerInterface instances as well.

      • Each of get, post, patch, put, delete, and any now proxy to route() after marshaling the correct $methods.

      • getRoutes() : Route[] proxies to the composed PathBasedRoutingMiddleware instance.

      • handle(ServerRequestInterface $request) : ResponseInterface proxies to the composed MiddlewarePipe instance's handle() method.

      • process(ServerRequestInterface $request, RequestHandlerInterface $handler) : ResponseInterface proxies to the composed MiddlewarePipe instance's process() method.

      • run() : void proxies to the composed RequestHandlerRunner instance. Please note that the method no longer accepts any arguments.

    • #543 modifies the Zend\Expressive\Container\ApplicationFactory to reflect the changes to the Zend\Expressive\Application class as detailed above. It pulls the following services to inject via the constructor:

      • Zend\Expressive\MiddlewareFactory
      • Zend\Stratigility\ApplicationPipeline, which should resolve to a MiddlewarePipe instance; use the Zend\Expressive\Container\ApplicationPipelineFactory.
      • Zend\Expressive\Router\PathBasedRoutingMiddleware
      • Zend\HttpHandlerRunner\RequestHandlerRunner

    Deprecated

    • Nothing.

    Removed

    • #543 removes support for http-interop/http-server-middleware.

    • #543 removes the class Zend\Expressive\Middleware\RouteMiddleware. Use the PathBasedRoutingMiddleware or RouteMiddleware from zend-expressive-router instead; the factory Zend\Expressive\Container\RouteMiddlewareFactory will return a PathBasedRoutingMiddleware instance for you.

    • #543 removes the class Zend\Expressive\Middleware\DispatchMiddleware. Use the DispatchMiddleware from zend-expressive-router instead; the factory Zend\Expressive\Container\DispatchMiddlewareFactory will return an instance for you.

    • #543 removes the class Zend\Expressive\Emitter\EmitterStack; use the class Zend\HttpHandlerRunner\Emitter\EmitterStack instead.

    • #543 removes the following methods from Zend\Expressive\Application:

      • pipeRoutingMiddleware(): use pipe(\Zend\Expressive\Router\PathBasedRoutingMiddleware::class) instead.
      • pipeDispatchMiddleware(): use pipe(\Zend\Expressive\Router\DispatchMiddleware::class) instead.
      • getContainer()
      • getDefaultDelegate(): ensure you pipe middleware capable of returning a response at the innermost layer; this can be done by decorating a request handler using Zend\Stratigility\Middleware\RequestHandlerMiddleware, using Zend\Expressive\Middleware\NotFoundMiddleware, or other approaches.
      • getEmitter(): use the Zend\HttpHandlerRunner\Emitter\EmitterInterface service from the container.
      • injectPipelineFromConfig(): use the new ApplicationConfigInjectionDelegator and/or the static method of the same name it defines.
      • injectRoutesFromConfig(): use the new ApplicationConfigInjectionDelegator and/or the static method of the same name it defines.

    • #543 removes the class Zend\Expressive\AppFactory.

    Fixed

    • Nothing.
    Source code(tar.gz)
    Source code(zip)

  • 3.0.0alpha1(Feb 5, 2018)

    Added

    • #529 adds support for http-interop/http-server-middleware (PSR-15 pre-cursor).

    • #538 adds scalar and return type hints to methods wherever possible.

    Changed

    • Nothing.

    Deprecated

    • Nothing.

    Removed

    • #529 removes support for PHP versions prior to PHP 7.1.

    • #529 removes support for http-interop/http-middleware (previous PSR-15 iteration).

    Fixed

    • Nothing.
    Source code(tar.gz)
    Source code(zip)

  • 2.1.0(Dec 11, 2017)

    Added

    • #480 updates the ImplicitHeadMiddleware to add a request attribute indicating the request was originally generated for a HEAD request before delegating the request; you can now pull the attribute Zend\Expressive\Middleware\ImplicitHeadMiddleware::FORWARDED_HTTP_METHOD_ATTRIBUTE in your own middleware in order to vary behavior in these scenarios.

    Changed

    • #505 modifies Zend\Expressive\Application to remove implementation of __call() in favor of the following new methods:

      • get($path, $middleware, $name = null)
      • post($path, $middleware, $name = null)
      • put($path, $middleware, $name = null)
      • patch($path, $middleware, $name = null)
      • delete($path, $middleware, $name = null)

      This change is an internal implementation detail only, and will not affect existing implementations or extensions.

    • #511 modifies the NotFoundDelegate to accept an optional $layout argument to its constructor; the value defaults to layout::default if not provided. That value will be passed for the layout template variable when the delegate renders a template, allowing zend-view users (and potentially other template systems) to customize the layout template used for reporting errors.

      You may provide the template via the configuration zend-expressive.error_handler.layout.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • Nothing.
    Source code(tar.gz)
    Source code(zip)

  • 2.0.6(Dec 11, 2017)

    Added

    • Nothing.

    Changed

    • Nothing.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • #534 provides a fix for how it detects callable middleware. Previously, it relied on PHP's is_callable(), but that function can result in false positives when provided a 2-element array where the first element is an object, as the function does not verify that the second argument is a valid method of the first. We now implement additional verifications to prevent such false positives.
    Source code(tar.gz)
    Source code(zip)

  • 2.0.5(Oct 9, 2017)

    Added

    • Nothing.

    Changed

    • Nothing.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • #521 adds an explicit requirement on http-interop/http-middleware ^0.4.1 to the package. This is necessary as newer builds of zend-stratigility instead depend on the metapackage webimpress/http-middleware-compatibility instead of the http-interop/http-middleware package — but middleware shipped in Expressive requires it. This addition fixes problems due to missing http-middleware interfaces.
    Source code(tar.gz)
    Source code(zip)

  • 2.0.4(Oct 9, 2017)

    Added

    • #508 adds documentation covering Zend\Expressive\Helper\ContentLengthMiddleware, introduced in zend-expressive-helpers 4.1.0.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • #479 fixes the WhoopsErrorResponseGenerator::$whoops dockblock Type to support Whoops 1 and 2.
    • #482 fixes the Application::$defaultDelegate dockblock Type.
    • #489 fixes an edge case in the WhoopsErrorHandler whereby it would emit an error if $_SERVER['SCRIPT_NAME'] did not exist. It now checks for that value before attempting to use it.
    Source code(tar.gz)
    Source code(zip)

  • 2.0.3(Mar 28, 2017)

    Added

    • Nothing.

    Changed

    • #468 updates references to DefaultDelegate::class to instead use the string 'Zend\Expressive\Delegate\DefaultDelegate'; using the string makes it clear that the service name does not resolve to an actual class.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • #476 fixes the WhoopsErrorResponseGenerator to ensure it returns a proper error status code, instead of using a 200 OK status.
    Source code(tar.gz)
    Source code(zip)

  • 2.0.2(Mar 13, 2017)

    Added

    • Nothing.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • #467 fixes an issue when passing invokable, duck-typed, interop middleware to the application without registering it with the container. Prior to the patch, it was incorrectly being decorated by Zend\Stratigility\Middleware\CallableMiddlewareWrapper instead of Zend\Stratigility\Middleware\CallableInteropMiddlewareWrapper.
    Source code(tar.gz)
    Source code(zip)

  • 2.0.1(Mar 9, 2017)

    Added

    • Nothing.

    Deprecated

    • Nothing.

    Removed

    • Nothing.

    Fixed

    • #464 fixes the WhoopsErrorResponseGenerator to provide a correct Content-Type header to the response when a JSON request occurs.
    Source code(tar.gz)
    Source code(zip)
Owner
Zend Framework
Zend Framework
GitHub
PSR-15 middleware for Symfony framework.

PSR-15 middleware now in Symfony Contents Installation Configuration Usage Examples Customization Caching Real World Example Middlewares Testing Licen

kafkiansky 60 Dec 14, 2022
Slim Framework 2 middleware

Slim Framework Middleware This repository contains a library of optional middleware for your Slim Framework application. How to Install Update your co

Slim Framework 47 Nov 7, 2022
[DEPRECATED] Collection of PSR-7 middlewares

This package is deprecated in favor of the new PSR-15 standard. Check it out here psr7-middlewares Collection of PSR-7 middlewares. Requirements PHP >

Oscar Otero 669 Dec 27, 2022
A PSR-15 server request handler.

Relay A PSR-15 request handler. This package is installable and PSR-4 autoloadable via Composer as "relay/relay": "~2.0". Alternatively, download a re

Relay 304 Dec 30, 2022
A simple and flexible PHP middleware dispatcher based on PSR-7, PSR-11, and PSR-15

Woohoo Labs. Harmony Woohoo Labs. Harmony is a PSR-15 compatible middleware dispatcher. Harmony was born to be a totally flexible and almost invisible

Woohoo Labs. 153 Sep 5, 2022
YCOM Impersonate. Login as selected YCOM user 🧙‍♂️in frontend.

YCOM Impersonate Login as selected YCOM user in frontend. Features: Backend users with admin rights or YCOM[] rights, can be automatically logged in v

Friends Of REDAXO 17 Sep 12, 2022
PSR-7 middleware foundation for building and dispatching middleware pipelines

laminas-stratigility From "Strata", Latin for "layer", and "agility". This package supersedes and replaces phly/conduit. Stratigility is a port of Sen

Laminas Project 47 Dec 22, 2022
Middleware for PHP built on top of PSR-7 and PSR-15

zend-stratigility Repository abandoned 2019-12-31 This repository has moved to laminas/laminas-stratigility. From "Strata", Latin for "layer", and "ag

Zend Framework 236 Sep 9, 2022
Fast PSR-7 based routing and dispatch component including PSR-15 middleware, built on top of FastRoute.

Route This package is compliant with PSR-1, PSR-2, PSR-4, PSR-7, PSR-11 and PSR-15. If you notice compliance oversights, please send a patch via pull

The League of Extraordinary Packages 608 Dec 30, 2022
PSR-7 and PSR-15 JWT Authentication Middleware

PSR-7 and PSR-15 JWT Authentication Middleware This middleware implements JSON Web Token Authentication. It was originally developed for Slim but can

Mika Tuupola 782 Dec 18, 2022
PSR-7 and PSR-15 HTTP Basic Authentication Middleware

PSR-7 and PSR-15 Basic Auth Middleware This middleware implements HTTP Basic Authentication. It was originally developed for Slim but can be used with

Mika Tuupola 430 Dec 30, 2022
A small, modern, PSR-7 compatible PSR-17 and PSR-18 network library for PHP, inspired by Go's net package.

Net A small, modern, PSR-7 compatible PSR-17 and PSR-18 network library for PHP, inspired by Go's net package. Features: No hard dependencies; Favours

Minibase 16 Jun 7, 2022
A small, modern, PSR-7 compatible PSR-17 and PSR-18 network library for PHP, inspired by Go's net package.

Net A small, modern, PSR-7 compatible PSR-17 and PSR-18 network library for PHP, inspired by Go's net package. Features: No hard dependencies; Favours

Minibase 16 Jun 7, 2022
Disable Google's FLoC with help of PSR-15 middleware

Disable Google's FLoC with PSR-15 middleware This package will help you disable Google's FLoC. Installation You can install the package via composer:

P7V 9 Dec 14, 2022
PSR-15 middleware for Symfony framework.

PSR-15 middleware now in Symfony Contents Installation Configuration Usage Examples Customization Caching Real World Example Middlewares Testing Licen

kafkiansky 60 Dec 14, 2022
PSR-15 middleware with various cache utilities

middlewares/cache Middleware components with the following cache utilities: CachePrevention Expires Cache Requirements PHP >= 7.2 A PSR-7 http library

Middlewares 15 Oct 25, 2022
PSR-15 middleware to geolocate the client using the ip address

middlewares/geolocation ![SensioLabs Insight][ico-sensiolabs] Middleware to geolocate the client using the ip address and Geocoder and save the result

Middlewares 10 Mar 22, 2022
A PSR-15 middleware adapter for react/http

A PSR-15 middleware adapter for react/http Wraps PSR-15 middleware into coroutines using RecoilPHP making them usable within react/http as middleware.

Friends of ReactPHP 22 Nov 12, 2022
PSR-15 middleware to use Whoops as error handler

middlewares/whoops Middleware to use Whoops as error handler. Requirements PHP >= 7.2 A PSR-7 http library A PSR-15 middleware dispatcher Installation

Middlewares 31 Jun 23, 2022
A PSR-15 middleware to handle content negotiation

Content negotiation middleware Motivation Packages like middlewares/negotiation do a very good job to detect the correct content type based on the Acc

Luís Cobucci 47 Nov 16, 2022