Descargar sitios web que utilizan mod_perl

Acerca de mod_perl

Un software tan antiguo en un servidor activo rara vez es cuestión de moda. mod_perl data de 1996, lo que lo coloca entre las primeras respuestas serias al problema de una web lenta porque cada petición bifurcaba un intérprete nuevo. Escrito en C y publicado por Apache Software Foundation con licencia Apache 2.0, el módulo incrusta un intérprete de Perl dentro del propio proceso de Apache, lo mantiene caliente entre peticiones y da al código Perl acceso directo a la gestión interna de peticiones del servidor, en lugar de la pasarela reducida que permitía CGI.

El argumento de rendimiento que lo justificaba se ha ganado varias veces por otras vías y, aun así, el módulo persiste. La persistencia es el dato interesante. Reescribir una aplicación Perl que ha acumulado años de lógica de negocio sin documentar sale caro y no entrega nada que un cliente pueda ver, así que la decisión sensata, repetida año tras año, es dejarla funcionando. Una coincidencia suele señalar una aplicación más antigua que el equipo de ingeniería actual, una en la que el coste del cambio se conoce bien y las ganas de acometerlo son pocas.

La propiedad es lo otro que conviene tener presente. Los paneles de control de alojamiento compartido llevan muchísimo tiempo incluyendo el módulo como parte de una compilación estándar de Apache, lo que significa que una gran parte de las instalaciones nunca fue siquiera una elección del dueño del sitio. El módulo está ahí porque el proveedor lo compiló dentro. Leer cada coincidencia como prueba de que hay un equipo Perl propio exageraría mucho el caso, y las dos poblaciones, la de usuarios deliberados y la de valores por defecto heredados, se ven idénticas desde fuera.

La geografía afina ese cuadro. En octubre de 2026 vemos el módulo en 38.198 sitios, y 14.909 de ellos están en el Reino Unido, una parte lo bastante grande como para pedir explicación. El gusto nacional rara vez mueve tan lejos un módulo de servidor. Un puñado de grandes proveedores de alojamiento que construyen la misma imagen de Apache en todas sus máquinas sí lo hace, y un pico por país en un módulo compilado suele ser un hecho del proveedor disfrazado de etiqueta nacional.

Aquí sí hay datos de versión, algo poco habitual en un módulo de servidor y muy útil. Podemos separar 24 versiones distintas sobre el terreno, con 2.0.12 presente en buena parte de la población. Una dispersión así, en una base de código cuya cadencia de publicación se mide en años, indica cuánto tiempo llevan intactas estas instalaciones, y da a quien sigue un aviso de seguridad concreto una manera de dimensionar el conjunto afectado en lugar de suponerlo.

El recuento es una cota inferior y merece tratarse como tal. El módulo solo resulta visible cuando un servidor se ofrece a decirlo, normalmente en una cabecera de respuesta que enumera los módulos compilados, y muchísimos operadores acortan o eliminan esa cabecera precisamente por eso. Los proxies inversos y las redes de distribución de contenido la sustituyen del todo. Donde la cabecera sobrevive, además, puede ir por detrás de la realidad y describir lo que se compiló y no lo que una petición ejecuta de verdad. Lo que contiene el conjunto de datos son servidores que admiten tener el módulo, no todos los servidores que lo usan.

Preguntar por un dominio concreto devuelve un sí o un no que el servidor puede estar rebajando. La lista sostiene las preguntas que la gente tiene de verdad. Qué proveedores de alojamiento siguen incluyendo el módulo, cómo se reparte el parque entre versiones, qué sectores mantuvieron vivas sus aplicaciones Perl y con qué rapidez encoge la población de un año al siguiente. Para un equipo de seguridad que dimensiona su exposición, para una consultora de migración que busca candidatos o para quien investiga y escribe sobre la larga cola de la web, la respuesta está en el agregado y no en la consulta aislada.