Au sein du fichier autoload_runtime.php, un objet que l'on appellera simplement le runtime est instancié pour prendre en charge la fonction anonyme en provenance du front controller. (Par défaut, ce runtime est une instance de la classe Symfony\Component\Runtime\SymfonyRuntime.) Cette « prise en charge » va consister à :

• résoudre les arguments attendus par la fonction,
• appeler la fonction avec les arguments résolus pour récupérer en retour une « application »,
• déterminer le runner (lanceur) capable de lancer l'application,
• lancer l'application via le runner pour réaliser l'opération souhaitée par l'utilisateur.

Le but de la fonction anonyme retournée par le front controller est donc de fournir une « application » au runtime qu'il se chargera de lancer.

Dans le cas d'une application Symfony classique, la fonction anonyme du front controller retourne une instance de la classe App\Kernel que le runtime lancera ensuite à l'aide d'un runner de type HttpKernelRunner.

Si vous souhaitez en savoir plus sur le sujet, je vous invite à lire la documentation du composant Runtime.

Concentrons-nous donc sur la notion de kernel HTTP définie techniquement par le contrat de l'interface Symfony\Component\HttpKernel\HttpKernelInterface :

namespace Symfony\Component\HttpKernel;

use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;

interface HttpKernelInterface
{
    public const MAIN_REQUEST = 1;
    public const SUB_REQUEST = 2;

    public function handle(
        Request $request,
        int $type = self::MAIN_REQUEST,
        bool $catch = true
    ): Response;
}

(Les commentaires ont été retirés du code pour obtenir un aperçu concis.)

Il existe par défaut trois implémentations du kernel HTTP :

• Symfony\Component\HttpKernel\Kernel, déjà évoquée plus haut du fait que le kernel de l'application (App\Kernel) en hérite directement
• Symfony\Component\HttpKernel\HttpCache\HttpCache, qui ajoute un cache optionnel au processus
• Symfony\Component\HttpKernel\HttpKernel, qui se chargera concrètement de produire la réponse

La première implémentation s'appuie essentiellement sur les deux autres : quand le cache HTTP est activé (via la configuration du FrameworkBundle) elle fait appel à la seconde, HttpCache, sinon elle fait directement appel à la troisième, HttpKernel. L'implémentation HttpCache quant à elle n'est capable de restituer une réponse que lorsque celle-ci a déjà été produite et stockée en cache, elle sollicite donc l'implémentation HttpKernel pour produire toute réponse qu'elle ne retrouve pas en cache.

Bref, vous l'aurez compris, la suite du processus pour aboutir à une réponse va se dérouler dans la classe HttpKernel.

Le premier évènement émis par le kernel est le RequestEvent. Il annonce la réception de la requête, donnant ainsi l'opportunité aux systèmes annexes de la modifier, voire de fournir une réponse précoce au kernel pour des cas de figure ne nécessitant pas de poursuivre le traitement.

Une première étape importante dans la quête d'une réponse est réalisée à cette occasion par le RouterListener : il s'agit de l'identification de la route correspondant à la requête. Une fois identifiée, les informations de la route sont alors ajoutées à la requête sous forme d'attributs de façon à être disponibles dans la suite du processus. Lorsqu'aucune route n'a été identifiée, une exception est lancée pour interrompre le processus. Nous verrons comment sont gérés les cas d'erreur plus loin dans l'article.

Dans le cas où un listener venait à transmettre une réponse au kernel via l'évènement en question, toutes les étapes à suivre précédant l'étape 8 seraient alors sautées.

Toutes ces considérations ne sont cependant pas du ressort du kernel HTTP qui orchestre le processus sans en connaître les détails de l'implémentation. C'est le controller resolver, auquel il fait appel suite au RequestEvent, qui va récupérer la valeur de l'attribut _controller depuis la requête pour la transformer (si besoin) en un callable que le kernel pourra invoquer.

Si le controller resolver ne parvient pas à produire un callable à partir de l'attribut, une exception NotFoundHttpException est lancée. Nous ne citerons pas toutes les exceptions qui pourraient potentiellement survenir durant le processus. Vous aurez compris l'idée : à tout moment il peut être interrompu par une exception qui sera alors prise en charge par un système secondaire que nous détaillerons par la suite.

Suite à la résolution du controller, un deuxième évènement, le ControllerEvent, est lancé. Il est l'occasion de réaliser des initialisations en vue des opérations à suivre, voire de remplacer complètement le controller.

C'est alors au tour de l'argument resolver d'être sollicité par le kernel afin de déterminer et de collecter l'ensemble des valeurs attendues par le controller en tant qu'arguments. En arrière plan, l'argument resolver s'appuie sur les multiples implémentations de l'interface ValueResolverInterface dédiées à cet effet. Les arguments auxquels on peut faire appel à l'écriture d'un controller dépendent donc directement de ces implémentations. Parmi elles, certaines vont par exemple permettre de récupérer des services depuis le conteneur de dépendances, d'autres d'obtenir des données contenues dans la requête (implémentations liées aux attributs #[MapQueryParameter], #[MapQueryString] et #[MapRequestPayload]).

Un fois l'ensemble des arguments résolu, l'évènement ControllerArgumentsEvent est propagé. On peut s'y abonner afin d'intervenir sur les arguments ou, comme avec le précédent, réaliser des opérations préparatoires pour la suite du processus, voire remplacer le controller.

Le kernel est désormais en capacité d'invoquer le controller, l'instant fatidique de lui faire générer la réponse est enfin arrivé. Le processus se poursuit alors avec cette ligne on ne peut plus parlante :

$response = $controller(...$arguments);

Suite à cet appel du controller, nous devrions théoriquement être en possession d'une réponse. Néanmoins, cette réponse pourrait ne pas être une instance de la classe Symfony\Component\HttpFoundation\Response, le kernel laissant le controller libre de retourner n'importe quelle sorte de donnée. En ce cas, un évènement ViewEvent est lancé dans l'objectif qu'un listener transforme la réponse obtenue en une instance de la classe Response.

On pourrait alors imaginer que le controller puisse retourner directement le markup d'une page sous la forme d'une chaîne, ou même une entité Doctrine, et que des listeners soient chargés, à partir de telles données, de produire la réponse finale.

Quelle que soit la réponse du controller, cette étape ne peut se terminer par une réponse autre qu'une instance de la classe Response, sans quoi une exception est jetée.

Lorsqu'une exception est lancée au cours des étapes 3 à 6, le processus tel qu'il est décrit ci-dessus s'interrompt. L'exception est interceptée par le kernel qui déclenche alors un évènement ExceptionEvent dans le but de recueillir une réponse appropriée au cas d'erreur survenu.

Le ErrorListener présent dans le composant HttpKernel, abonné par défaut à l'évènement, est le point de départ du système de gestion des erreurs de Symfony. Ce système va consister à obtenir une réponse en faisant de nouveau appel au kernel HTTP. La requête alors transmise au kernel dans cette situation est une copie de la requête initiale, préconfigurée avec un controller dédié aux cas d'erreur (via l'attribut _controller), à laquelle est également ajoutée l'exception capturée.

Le scénario décrit tout au long de cet article est donc rejoué une seconde fois à partir de l'étape 3 en considérant cette copie. Mais cette fois-ci, le listener indiquera au kernel qu'il s'agit alors d'une « sous-requête » (voir HttpKernelInterface et sa constante SUB_REQUEST) afin de la distinguer de la requête initiale (MAIN_REQUEST), évitant ainsi que des opérations destinées uniquement à cette dernière ne soient exécutées.

Si suite à sa diffusion, l'évènement ExceptionEvent n'est pas porteur d'une réponse, le kernel émet au préalable l'évènement FinishRequestEvent que nous préciserons plus bas, puis il relance l'exception afin de stopper net l'application.

Dans le cas contraire, le processus continue à l'étape suivante, exactement comme il en eut été si aucune exception n'avait été jetée.

Nous avons à ce stade obtenu notre réponse. Mais avant qu'elle soit transmise à l'internaute, le kernel lance l'évènement ResponseEvent offrant la possibilité de la modifier, en y ajoutant par exemple des entêtes ou des cookies. Pour ne citer qu'eux, les entêtes relatifs au cache spécifiés via l'attribut PHP #[Cache] au sein du controller sont ajoutés à la réponse lors de cet évènement.

Le kernel enchaîne ensuite avec l'émission de l'évènement FinishRequestEvent, destiné notamment à la réinitialisation ou la restauration de certains états potentiellement modifiés pendant le traitement de la requête.

Son travail prend alors fin tandis qu'il restitue sa réponse au runner.

De retour au sein du runner après que le kernel ait accompli sa tâche, l'envoi de la réponse est effectué directement depuis l'instance de la classe Response issue du kernel par un simple appel à sa méthode send().

Avant que l'application n'arrive à son terme, le runner propage un dernier évènement, le TerminateEvent, moment adéquat pour effectuer des traitements complémentaires qui, réalisés plus tôt, auraient retardé la réponse.