Mise à jour du 06/08/2024.
La mise au point d'applications web est parfois délicate et il est nécessaire de disposer de l'ensemble des données échangées entre serveur et hôte distant car les traces dans le journal peuvent ne pas être suffisantes. Cela peut être fait via des proxies spécialisés comme mitmproxy (Linux) ou fiddler (windows) (cf. plate-forme de test). Il est cependant plus simple de demander au serveur d'enregistrer les échanges. Cet article expose le principe retenu.
Un "échange" est constitué d'une requête HTTP suivie de sa réponse. Il est constitué de 3 parties :
Tout d'abord, il faut se rappeler que le corps HTTP d'une réponse du serveur peut être très volumineuse. Cela interdit de conserver les données en mémoire au-delà de l'échange. Ainsi, les données de la seconde et de la troisième partie seront enregistrées dans des fichiers dédiés. Les éléments propres à l'échange seront, eux, rassemblés en une seule ligne au format CSV (point-virgule comme séparateur) et enregistrés dans un fichier appelé table des échanges.
Ainsi un échange est entièrement enregistré via 3 fichiers. Cela permet de construire un programme capable à postériori de détailler chaque échange entre le serveur et les hôtes distants. Ce programme pourrait alors filtrer les échanges (même hôte par exemple, intervalle de temps, etc.). La table est conçue de façon à pouvoir être lue par un simple tableur.
Ce mécanisme a un impact non négligeable sur les performances du serveur et donc les temps de réponse. Il doit donc être débrayable. C'est le paramètre mitm.table dans le fichier de configuration du serveur qui active ou désactive le mécanisme suivant qu'il est défini ou non. S'il est défini, il doit indiquer le nom du fichier de la table des échanges.
La totalité du traçage des échanges est réalisé via un objet de la classe HttpDialog de la librairie webapp. C'est le gestionnaire des requêtes reçues (méthode WebServer::handleRequest()) qui procède à l'enregistrement de chaque requête reçue avant même qu'elle soit filtrée par l'agent de sécurité.
Elle commence par créer un objet de classe HttpDialog en transmettant à son constructeur la requête (objet de classe QHttpServerRequest). Cela a pour effet de sauvegarder dans son fichier dédié les en-têtes HTTP et le contenu du corps de la requête. Ce fichier est nommé Q-{nombre de ms depuis Epoch en hexadécimal}.req.
Lorsque la réponse est construite par le serveur, la méthode HttpDialog::setResponse() est alors invoquée en lui transmettant l'objet contenant la réponse avant sa mise en forme pour envoi (objet de classe HttpResponse).
L'invocation de cette méthode provoque la sauvegarde de la réponse dans un fichier nommé A-{nombre de ms depuis Epoch en hexadécimal}.rsp puis la sauvegarde des données propres à l'échange est sauvegardé en tant qu'entrée dans la table des échanges. Ceci fait, la totalité de l'échange a été sauvegardé sur disque et l'objet de classe HttpDialog est détruit.
Rédaction par Jean-Marie Piatte (1983-2021)