![[ICO]](/icons/blank.gif){kind=icon}
![[PARENTDIR]](/icons/back.gif){kind=icon}
Pour le moment, les pages sont servies par le module d'auto index en format HTML 3.2, ce qui n'est pas antédiluvien, mais presque. Le code source lui-même est daté du 23 février 1993. C'est plusieurs mois avant la sortie de la distribution de Debian, ou même de Slackware, et c'est antérieur au mois de Septembre 1993 éternel, mois de la mise à disposition d'Internet à des fins commerciales, et à l'ouverture au grand public. En tant que tel, le code automatiquement produit ne passe pas les validations de conformité au HTML, ce qui est assez surprenant pour un comportement par défaut.
L'utilisation d'une en-tête au format HTML 5 passe beaucoup mieux auprès du script de validation du W3C. Toutefois, appliquer ce changement nécessite de modifier et recompiler le code en C du module. Ce n'est pas techniquement un problème, mais fondamentalement, transférer les modifications adéquates en amont serait probablement bienvenu. Sinon, toute mise à jour d'Apache remettrait à zéro la modification et nécessiterait d'appliquer à nouveau le patch et de refaire une compilation.
Afin de minimiser les modifications sur les millions de sites Apache existant, le HTML 3.2 devrait probablement rester le comportement par défaut, même si incorrect. Ce serait pas mal que le fichier de configuration du mod_autoindex permette le choix d'en-tête plus récentes. Ce n'est pas faute de ne pas avoir les différentes en-têtes disponibles dans le fichier include/httpd.h, mais l'en-tête du HTML 3.2 est fournie en dur dans la fonction emit_preamble du fichier mod_autoindex.c dans le répertoire modules/generators du code source d'Apache.
Je suppose que l'utilisation de mécanismes autres que le module d'auto index a laissé ce composant en arrière plan. De plus, certains considèrent l'activation du mod_autoindex comme une faille de sécurité en soi.
En attendant les pages sont lisibles. Même si ce n'est pas très propre en tant que tel, ce problème n'est pas prioritaire, comparé à la mise en place du chiffrement, par exemple.
Peut-être que le choix d'utiliser Apache était un choix malheureux dans une optique de simplicité. Des serveurs web au poids plume, il y en a quelques uns. Ils ont en commun de séparer la production du fichier HTML et sa distribution, en utilisant un compilateur de pages statiques. Cette approche résout également un certain nombre de problèmes pour la production et la maintenance du roulement d'un flux RSS : la question de supprimer le plus ancien article du flux, arrivé à un certain seuil, n'est pas évidente à traiter avec html2rss sans utiliser un véritable analyseur lexical dédié au XML.
Cependant les modules de génération automatique ont ceci d'efficace : vous donnez un répertoire public_html à un gentil débutant en informatique, vous lui montrez comment y accéder, et ce qu'il se passe quand des fichiers sont copiés dedans. Vous venez de susciter des velléités d'auto hébergement chez cette personne.
J'aurais probablement l'occasion de me concentrer à nouveau sur cette question dans le futur. On verra comment se comportent ces autres serveurs.
| Name | Last modified | Size |
|---|---|---|---|
| Parent Directory | - |