Télécharger les sites web qui utilisent mod_perl

À propos de mod_perl

Un logiciel aussi ancien sur un serveur en production relève rarement de la mode. mod_perl date de 1996, ce qui le place parmi les premières réponses sérieuses au problème d’un web lent parce que chaque requête créait un interpréteur neuf. Écrit en C et publié par Apache Software Foundation sous licence Apache 2.0, le module embarque un interpréteur Perl à l’intérieur même du processus Apache, le garde chaud entre deux requêtes et donne au code Perl un accès direct au traitement interne des requêtes du serveur, au lieu de la passerelle étroite que permettait le CGI.

L’argument de performance qui le justifiait a été gagné plusieurs fois par d’autres moyens, et pourtant le module persiste. La persistance est le fait intéressant ici. Réécrire une application Perl qui a accumulé des années de logique métier non documentée coûte cher et n’apporte rien qu’un client puisse voir, si bien que la décision raisonnable, répétée année après année, consiste à la laisser tourner. Une détection a tendance à marquer une application plus vieille que l’équipe technique actuelle, une application dont le coût du changement est bien compris et pour laquelle l’appétit est faible.

La question de savoir qui a décidé est l’autre point à garder en tête. Les panneaux de contrôle d’hébergement mutualisé livrent le module dans une compilation Apache standard depuis très longtemps, ce qui veut dire qu’une grande part des installations ne résulte d’aucun choix du propriétaire du site. Le module est là parce que l’hébergeur l’a compilé. Lire chaque détection comme la preuve d’une équipe Perl en interne forcerait gravement le trait, et les deux populations, les usagers délibérés et les valeurs par défaut héritées, sont identiques vues de l’extérieur.

La géographie précise le tableau. En octobre 2026 nous voyons le module sur 38 198 sites, dont 14 909 au Royaume-Uni, une part assez large pour demander une explication. Le goût national déplace rarement un module serveur à ce point. Une poignée de grands hébergeurs qui construisent la même image Apache sur tout leur parc le fait, et un pic national sur un module compilé est le plus souvent un fait d’hébergeur qui porte une étiquette nationale.

Des données de version existent ici, ce qui est inhabituel pour un module serveur et bien utile. Nous distinguons 24 versions distinctes sur le terrain, 2.0.12 revenant sur une large part de la population. Un tel étalement, sur une base de code dont la cadence de publication se mesure en années, indique depuis combien de temps ces installations restent intouchées, et il donne à qui suit une alerte précise un moyen de dimensionner l’ensemble concerné plutôt que de le deviner.

Le décompte est un plancher et mérite d’être traité comme tel. Le module n’est visible que si un serveur le déclare de lui-même, en général dans un en-tête de réponse qui liste les modules compilés, et bien des exploitants raccourcissent ou suppriment cet en-tête pour exactement cette raison. Les proxys inverses et les réseaux de diffusion de contenu le remplacent purement et simplement. Là où l’en-tête survit, il peut aussi retarder sur la réalité et décrire ce qui a été compilé plutôt que ce qu’une requête exécute vraiment. Ce que contient le dataset, ce sont les serveurs qui avouent le module, pas tous les serveurs qui le font tourner.

Interroger un seul domaine donne un oui ou un non que le serveur peut très bien sous-estimer. La liste, elle, porte les questions que les gens se posent vraiment. Quels hébergeurs livrent encore le module, comment le parc se répartit entre les versions, quels secteurs ont gardé leurs applications Perl en vie, et à quelle vitesse la population se réduit d’une année à l’autre. Pour une équipe de sécurité qui dimensionne son exposition, un cabinet de migration en quête de candidats ou un chercheur qui écrit sur la longue traîne du web, c’est l’agrégat qui répond, pas la requête unique.