Portail / Sujets autour de la programmation / Programmation C/C++ sous Linux / Serveur d'application avec Qt 6 / Concepts généraux(Sommaire)

Mise en oeuvre du routage.

Mise à jour du 15/06/2024.

Le routage décrit le mécanisme par lequel le serveur web Qt oriente vers une application donnée à partir de l'analyse du chemin de l'URL.

Notion de "règles" de routage.

Le mécanisme de routage d'un objet de classe QHttpServer repose sur la méthode route(). Cette méthode est une simplification d'appel de l'API de routage des URL. C'est un objet de classe QHttpRouter qui joue le rôle de routeur. Cet objet maintient une liste de "règles" de routage dont chaque règle est représentée par la classe QHttpServerRouterRule. Une règle est constituée d'une expression régulière sur le chemin de l'URL et d'une fonction de type QHttpServerRouterRule::RouterHandler. ce type est un alias pour le prototype de fonction :

std::function<void(const QRegularExpressionMatch &,const QHttpServerRequest &, QHttpServerResponder &&)>

L'objet serveur de classe QHttpServer ne connaît pas la notion d'application. Il reçoit une requête et si le chemin correspond à une règle il invoque la fonction liée à cette règle. Or dans un serveur d'application, il doit y avoir une bonne étanchéité entre chque application.

C'est notre second choix structurant : à une règle correspond une et une seule application web et à une application correspond une est une seule règle.

Cela revient à dire que l'identification d'un des services de l'application ne peut pas se faire via le chemin de l'URL.

Routage et services.

L'article de description des services montre que chaque service est responsable de la création d'un flux de réponse à une requête.

Le service est identifié par un paramètre HTTP nommé srv. Les autres paramètres HTTP représentent les arguments du service.

De manière abstraite on peut écrire {chemin URL} + {paramètre HTTP "srv"} = {service}.

Les paramètres HTTP, à l'exception de ceux issus de formulaires HTML, sont transportés chiffrés. Ce chiffrement est effectué avec la clef de chiffrement de la session. Il est donc différent d'un "client" à l'autre et une fois la session fermée, il n'est pas possible de "rejouer" un URL (mécanisme d'attaque classique). Notez que l'identifiant de session est aussi stocké chiffré mais avec la clef de chiffrement de l'application puisque l'on a besoin de le déchiffer afin de pouvoir récupérer en premier lieu la session. Là encore, en cas de conservation des cookies, une fois l'application achevée ou le serveur relancé, l'identifiant de session devient inutile puisque l'application dispose d'une nouvelle clef générée aléatoirement. C'est pour cette raison, que le service d'accueil doit impérativement rénitialiser ce cookie. Pour cette raison, il est recommandé de configurer les clients (navigateurs en particulier) pour ne gérer que des cookies "mémoire". Ces types de cookies sont automatiquement supprimés par le navigateur au plus trad à la fermeture de ce dernier.

Compte tenu des choix effectués, nous n'avons plus besoin d'utiliser le routage proposé car il est assez peu générique en raison de la fonction callback à passer à chaque règle de routage. Il a visiblement été conçu dans l'optique d'une seule application invoquant un code spécifique pour chaque URL en correspondance avec une règle.

Néanmoins, le routage doit prendre en compte deux particularités :

Il appartient à la fonction callback de la règle de routage d'identifier le service à invoquer en fonction des éléments transmis par la requête HTTP (chemin d'URL et paramètres HTTP). Pour permettre à la fonction callback de ne pas traiter l'accès à des ressources statiques de façon particulière, on associe à l'accès aux ressources statiques à un chemin racine d'URL qui correspond au répertoire racine des ressources auxquelles il est possible d'accéder. Ce chemin permet d'invoquer directement un service de chargement et d'anvoi de la ressource demandée. Notez que ce service ne s'appuie sur aucune sessionn et transcende la notion de contexte applicatif.

Dasn tous les autres cas, nous tous les chemins d'URL sont acceptés ("/") et est associé à une unique fonction callback. Cette fonction est chargée :

• Vérifier que seule la méthode POST ou GET a été invoquée. Si ce n'est pas le cas, le serveur invoque un objet chargé de gérer ce qui peut s'apparenter à une attaque et qu'il a reçu lors de son initialisation.
• Identifier l'application via le chemin de l'URL. Comme précédemment, si l'URL ne correspond à aucune route, le serveur invoque l'objet chargé de traiter les attaques.
• Une fois l'application liée au chemin de l'URL identifiée, la fonction callback invoque la méthode process() de la classe WebApplicationen lui transmettant l'objet de gestion du flux HTTP entrant (objet de classe QHttpServerRequest). En retour, elle reçoit le flux de la réponse via un objet de classe QHttpServerResponse.
• Lorsque la fonction callback reçoit le flux de réponse, elle le retourne au serveur qui est chargé de tranformer l'objet de classe QHttpServerResponse reçu en un flux réseau.