Skip to content

Request lifecycle: from request to response

Beginning of HTTP request

When entering the server infrastructure, the HTTP request can be handled by several component such as a firewall, a load balancer, or a reverse proxy before arriving on the web server itself.

For an overview of what happens on a reverse proxy like Varnish or Fastly, see Context-aware HTTP cache / Request lifecycle.

When arriving at a web server, the request is filtered by Apache Virtual Host, Nginx Server Blocks or equivalent. There, requests of static resources are separated from requests to PHP interpreter.

As Ibexa DXP is a Symfony application, the handling of requests starts like in Symfony (see Symfony and HTTP Fundamentals).

If the HTTP request is to be treated by Ibexa DXP, it goes to the public/index.php of the Symfony Front Controller.

The front controller transforms the HTTP request into a PHP Request object and passes it to Symfony's Kernel to get a Response object that is transformed and sent back as an HTTP response.

The schemas start with a regular Request object from a browser that enters Symfony and Ibexa DXP. There is no ESI, no REST, and no GraphQL request performed.

Lifecycle flowcharts

Concept flowchart

The chart below introduces the logic of the request treatment.

Simplified request lifecycle flowchart

Kernel events flowchart

The following chart shows events, listeners and attributes added to the request or its wrapping event object.

Detailed request lifecycle flowchart organised around kernel events

This schema is described below event by event.


To list all listeners that listen to an event, run php bin/console debug:event-dispatcher <>, for example:

php bin/console debug:event-dispatcher kernel.request

To view details of a service (including class, arguments and tags), run php bin/console debug:container --show-arguments <>, for example:

php bin/console debug:container --show-arguments ezpublish.siteaccess_match_listener`

To list all services with a specific tag, run php bin/console debug:container --tag=<tag>, for example:

php bin/console debug:container --tag=router

Kernel's request event

When the request enters the Symfony's kernel (and goes underneath the HttpKernel, http_kernel), a kernel.request event (KernelEvents::REQUEST) is dispatched. Several listeners are called in decreasing priority.

SiteAccess matching

The FragmentListener (priority 48) handles the request first, and then it passes to the ezpublish.siteaccess_match_listener service (priority 45). This service can be either:

  • purely the SiteAccessMatchListener or
  • its UserContextSiteAccessMatchSubscriber decoration when HTTP cache is used.

The ezpublish.siteaccess_match_listener service:

  • finds the current SiteAccess using the SiteAccess\Router (ezpublish.siteaccess_router) regarding the SiteAccess Matching configurations,
  • adds the current SiteAccess to the Request object's siteaccess attribute,
  • then dispatches the ezpublish.siteaccess event (MVCEvents::SITEACCESS).

The SiteAccessListener (ezpublish.siteaccess_listener) subscribes to this ezpublish.siteaccess event with top priority (priority 255). The SiteAccessListener adds the semanticPathinfo attribute, the path without SiteAccess indications (URIElement, URIText, or Map\URI implementing the URILexer interface) to the request.


Finally, the Symfony\Component\HttpKernel\EventListener\RouterListener (router_listener) (priority 32), which also listens to the kernel.request event, calls eZ\Publish\Core\MVC\Symfony\Routing\ChainRouter::matchRequest and adds its returned parameters to the request.


The ChainRouter is a Symfony Content Management Framework (CMF) component. Ibexa DXP makes it a service named ezpublish.chain_router. It has a collection of prioritized routers where to find one matching the request. The ChainRouter router collection is built by the ChainRoutingPass, collecting the services tagged router. The DefaultRouter is always added to the collection with top priority (priority 255).


DefaultRouter (router.default): The DefaultRouter tries to match the semanticPathinfo against routes, close to the way pure Symfony does, by extending and using Symfony\Component\Routing\Router. If a route matches, the controller associated with it is responsible for building a View or Response object.


UrlWildcardRouter (ezpublish.urlwildcard_router): If URL Wildcards have been enabled, then the URLWildcardRouter is the next router tried. If a wildcard matches, the request's semanticPathinfo is updated and the router throws a ResourceNotFoundException to continue with the ChainRouter collection's next entry.


UrlAliasRouter (ezpublish.urlalias_router): This router uses the UrlAliasService to associate the semanticPathinfo to a Location. If it finds a Location, the request receives the attributes locationId and contentId, viewType is set to full, and the _controller is set to ez_content:viewAction for now.

The locale_listener (priority 16) sets the request's _locale attribute.

Permission control

Another kernel.request event listener is the EzSystems\EzPlatformAdminUi\EventListener\RequestListener (priority 13). When a route gets a siteaccess_group_whitelist parameter, this listener checks that the current SiteAccess is in one of the listed groups. For example, the Back Office sets an early protection of its routes by passing them a siteaccess_group_whitelist containing only the admin_group.

Now, when the Request knows its controller, the HttpKernel dispatches the kernel.controller event.

Kernel's controller event

View building and matching

When HttpKernel dispatches the kernel.controller event, the following things happen.

Listening to kernel.controller, the ViewControllerListener (ezpublish.view_controller_listener) (priority 10) checks if the _controller request attribute is associated with a ViewBuilder (a service tagged ibexa.view_builder) in the ViewBuilderRegistry (ezpublish.view_builder.registry). The ContentViewBuilder (ezpublish.view_builder.content) matches on controller starting with ez_content: (see eZ\Publish\Core\MVC\Symfony\View\Builder\ContentViewBuilder::matches). The ContentViewBuilder builds a ContentView.

First, the ContentViewBuilder loads the Location and the Content, and adds them to the ContentView object.

Permission control

content/read and/or content/view_embed permissions are controlled during this ContentView building.

Then, the ContentViewBuilder passes the ContentView to its View\Configurator (ezpublish.view.configurator). It's implemented by the View\Configurator\ViewProvider and its View\Provider\Registry. This registry receives the services tagged ezpublish.view_provider thanks to the ViewProviderPass. Among the view providers, the services using the eZ\Bundle\EzPublishCoreBundle\View\Provider\Configured have an implementation of the MatcherFactoryInterface (ezpublish.content_view.matcher_factory). Through service decoration and class inheritance, the ClassNameMatcherFactory is responsible for the view matching. The View\Configurator\ViewProvider uses the matched view rule to add possible templateIdentifier and controllerReference to the ContentView object.

The ViewControllerListener adds the ContentView to the Request as the view attribute. The ViewControllerListener eventually updates the request's _controller attribute with the ContentView's controllerReference.

The HttpKernel then dispatches a kernel.controller_arguments (KernelEvents::CONTROLLER_ARGUMENTS) but nothing from Ibexa DXP is listening to it.

Controller execution

The HttpKernel extracts from the request the controller and the arguments to pass to the controller. Argument resolvers work in a way similar to autowiring. The HttpKernel executes the controller with those arguments.

As a reminder, the controller and its argument can be:

  • A controller set by the matched route and the request as its argument.
  • The default ez_content:viewAction controller and a ContentView as its argument.
  • A custom controller set by the matched view rule and a View or the request as its argument (most likely a ContentView but there is no restriction).

Permission control

See Permissions for custom controller.

Kernel's view event and ContentView rendering

If the controller returns something other than Response, the HttpKernel dispatches a kernel.view event (KernelEvents::VIEW). In the case of a URL Alias, the controller most likely returns a ContentView. The ViewRendererListener (ezpublish.view.renderer_listener) uses the ContentView and the TemplateRenderer (ezpublish.view.template_renderer) to get the content of the Response and attach this new Response to the event. The HttpKernel retrieves the response attached to the event and continues.

Kernel's response event and Response sending

The HttpKernel sends a kernel.response event (KernelEvents::RESPONSE). For example, if HTTP cache is used, response's headers may be enhanced.

The HttpKernel sends a kernel.finish_request event (KernelEvents::FINISH_REQUEST). The VerifyUserPoliciesRequestListener (siso_core.verify_user_policies_request_listener) (priority 100) filters routes on its policy configuration.

Permission control

See Permissions for routes.

Finally, the HttpKernel send the response.

If an exception occurs during this chain of events, the HttpKernel sends a kernel.exception and tries to get a Response from its listeners.

The HttpKernel sends the last kernel.terminate event (KernelEvents::TERMINATE). For example, the BackgroundIndexingTerminateListener ( (priority 0) removes from the SearchService index possible content existing in the index but not in the database.


Summary of events and services

  • event=kernel.request
    • 45:ezpublish.siteaccess_match_listener
      • ezpublish.siteaccess_router
      • event=ezpublish.siteaccess
        • 255:ezpublish.siteaccess_listener
    • 32:router_listener
      • ezpublish.chain_router
        • tag=router
          • router.default
          • ezpublish.urlwildcard_router
          • ezpublish.urlalias_router
    • 16:locale_listener
    • 13:EzSystems\EzPlatformAdminUi\EventListener\RequestListener
  • event=kernel.controller
    • 10:ezpublish.view_controller_listener
      • ezpublish.view_builder.registry
        • tag=ibexa.view_builder
          • ezpublish.view_builder.content
            • ezpublish.view.configurator
  • event=kernel.controller_arguments
  • event=kernel.view
    • 0:ezpublish.view.renderer_listener
      • ezpublish.view.template_renderer
  • event=kernel.response
  • event=kernel.finish_request
    • 100:siso_core.verify_user_policies_request_listener
  • event=kernel.terminate

Examples request attributes timeline

Event Service Request attribute Example
http_kernel pathInfo /en/about
kernel.request ezpublish.siteaccess_match_listener siteaccess en
ezpublish.siteaccess ezpublish.siteaccess_listener semanticPathinfo /about
kernel.request router.default _route N/A
kernel.request router.default _controller N/A
kernel.request ezpublish.urlalias_router _route ez_urlalias
kernel.request ezpublish.urlalias_router _controller ez_content:viewAction
kernel.request ezpublish.urlalias_router viewType full
kernel.request ezpublish.urlalias_router contentId 1
kernel.request ezpublish.urlalias_router locationId 42
kernel.request locale_listener _locale en_GB
kernel.controller ezpublish.view_builder.content view.content Content
kernel.controller ezpublish.view_builder.content view.location Location
kernel.controller ezpublish.view.configurator view.templateIdentifier @EzPublishCore/default/content/full.html.twig
kernel.controller ezpublish.view.configurator view.controllerReference null
kernel.controller ezpublish.view_controller_listener view ContentView
kernel.controller ezpublish.view_controller_listener _controller ez_content:viewAction
(controller execution) http_kernel ContentView
kernel.view ezpublish.view.renderer_listener response Response

End of HTTP response

The web server outputs the HTTP response. Depending on the architecture, few things may still occur. For example, Varnish or Fastly can take specific headers into account when setting the cache or serving it.