The HttpKernel Component (Symfony Docs)

The HttpKernel component provides a structured process for converting a Request into a Response by making use of the EventDispatcher component. It's flexible enough to create a full-stack framework (Symfony) or an advanced CMS (Drupal).
If you install this component outside of a Symfony application, you must require the vendor/autoload.php file in your code to enable the class autoloading mechanism provided by Composer. Read this article for more details.
This article explains how to use the HttpKernel features as an independent component in any PHP application. In Symfony applications everything is already configured and ready to use. Read the Controller and Events and Event Listeners articles to learn how to use it to create controllers and define events in Symfony applications.
Every HTTP web interaction begins with a request and ends with a response. Your job as a developer is to create PHP code that reads the request information (e.g. the URL) and creates and returns a response (e.g. an HTML page or JSON string). This is a simplified overview of the request-response lifecycle in Symfony applications:
Typically, some sort of framework or system is built to handle all the repetitive tasks (e.g. routing, security, etc.) so that a developer can build each page of the application. Exactly how these systems are built varies greatly. The HttpKernel component provides an interface that formalizes the process of starting with a request and creating the appropriate response. The component is meant to be the heart of any application or framework, no matter how varied the architecture of that system:
Internally, HttpKernel::handle() - the concrete implementation of HttpKernelInterface::handle() - defines a lifecycle that starts with a Request and ends with a Response.
The exact details of this lifecycle are the key to understanding how the kernel (and the Symfony Framework or any other library that uses the kernel) works.
The HttpKernel::handle() method works internally by dispatching events. This makes the method both flexible and a bit abstract, since all the "work" of a framework/application built with HttpKernel is actually done in event listeners.
To help explain this process, this document looks at each step of the process and talks about how one specific implementation of the HttpKernel - the Symfony Framework - works.
Initially, using the HttpKernel does not take many steps. You create an event dispatcher and a controller and argument resolver (explained below). To complete your working kernel, you'll add more event listeners to the events discussed below:
See "A full working example" for a more concrete implementation.
For general information on adding listeners to the events below, see Creating an Event Listener.
There is a wonderful tutorial series on using the HttpKernel component and other Symfony components to create your own framework. See Introduction.
Typical Purposes: To add more information to the Request, initialize parts of the system, or return a Response if possible (e.g. a security layer that denies access).
Kernel Events Information Table
The first event that is dispatched inside HttpKernel::handle is kernel.request, which may have a variety of different listeners.
Listeners of this event can be quite varied. Some listeners - such as a security listener - might have enough information to create a Response object immediately. For example, if a security listener determined that a user doesn't have access, that listener may return a RedirectResponse to the login page or a 403 Access Denied response.
If a Response is returned at this stage, the process skips directly to the kernel.response event.
Other listeners initialize things or add more information to the request. For example, a listener might determine and set the locale on the Request object.
Another common listener is routing. A router listener may process the Request and determine the controller that should be rendered (see the next section). In fact, the Request object has an "attributes" bag which is a perfect spot to store this extra, application-specific data about the request. This means that if your router listener somehow determines the controller, it can store it on the Request attributes (which can be used by your controller resolver).
Overall, the purpose of the kernel.request event is either to create and return a Response directly, or to add information to the Request (e.g. setting the locale or setting some other information on the Request attributes).
When setting a response for the kernel.request event, the propagation is stopped. This means listeners with lower priority won't be executed.
kernel.request in the Symfony Framework
The most important listener to kernel.request in the Symfony Framework is the RouterListener. This class executes the routing layer, which returns an array of information about the matched request, including the _controller and any placeholders that are in the route's pattern (e.g. {slug}). See the Routing documentation.
This array of information is stored in the Request object's attributes array. Adding the routing information here doesn't do anything yet, but is used next when resolving the controller.
Assuming that no kernel.request listener was able to create a Response, the next step in HttpKernel is to determine and prepare (i.e. resolve) the controller. The controller is the part of the end-application's code that is responsible for creating and returning the Response for a specific page. The only requirement is that it is a PHP callable - i.e. a function, method on an object or a Closure.
But how you determine the exact controller for a request is entirely up to your application. This is the job of the "controller resolver" - a class that implements ControllerResolverInterface and is one of the constructor arguments to HttpKernel.
Your job is to create a class that implements the interface and fill in its method: getController(). In fact, one default implementation al