WIP: Use an intermediate file as an HTTP response cache.

[JulienPalard]

En lien, indirect, avec :

• https://github.com/etalab/noms-de-domaine-organismes-publics/issues/29
• https://github.com/etalab/noms-de-domaine-organismes-publics/issues/6

Avec peu de domaine, au début, consolidate.py mettait moins d'une heure à tourner, ça m'allait.

Depuis peu, consolidate.py met plus de 8h à faire son travail, ça ne me convient plus.

Le souci c'est qu'il doit tester tous les domaines qui sont dans sources/ mais pas dans urls.txt, c'est à dire tous ceux qui ont été rajoutés (bonne idée de les vérifier) et tous ceux qui n'ont pas répondu les dernières fois (c'est ça qui grossit et prend du temps).

L'objectif : pouvoir, après avoir rajouté une poignée de domaines dans sources/* les ajouter à urls.py en quelques secondes.

Je propose donc de stocker, en plus de la liste des domaines qui répondent en HTTP, la liste de ceux qui ne répondent pas, ainsi on peut obtenir la liste des domaines fraîchement rajoutés, et les tester rapidement.

Pour ne pas polluer urls.txt, je propose d'utiliser un fichier "intermédiaire", domains.csv, dans lequel on pourrait stocker tout ce qui pourrait être utile au traitement, pour le moment j'y stocke :

• nom de domaine
• date de la dernière requête HTTP
• résultat de la dernière requête HTTP
• date de la dernière requête HTTPS
• résultat de la dernière requête HTTPS

L'idée de ce format est de se laisser la posibilité à l'avenir de rajouter des paires :

• date du dernier scan SSH
• résultat du dernier scan SSH
• date de la dernière tentative de connexion SMTP
• résultat de la dernière connexion SMTP
• ...

Et si on va un jour par là, on pourra avoir des outils différents pour mettre à jour différentes colonnes, un script pourrait s'occuper du http, un autre du SMTP, un autre du SSH, …

On pourrait aussi profiter de la date de dernier test pour maintenir l'ensemble frais sans avoir à tout re-tester : avec --limit on peut relancer une vérification des n domaines les moins frais, qu'ils aient répondu ou non la dernière fois, et donc en actualiser 1/30 par jour pour tous les toucher au moins une fois par mois, ou 1/365 par jour, …

Ce n'est pas terminé, il manque clairement une option qui permettrai de ne requêter que ceux qui viennent d'être ajoutés, qui est l'objectif initial, on pourrait le simuler en ajoutant n domaines et en exécutant http_check.py --limit n, si domains.csv était entièrement peuplé, ce qui n'est pas le cas dans cette PR non plus.

Je n'ai pas d'avis tranché sur le statut de domains.csv, on peut considérer que c'est un produit du repo, au même titre que urls.txt, comme on peut considérer que c'est un cache, un fichier intermédiaire, pas destiné à être réutilisé.

Bien que j'avoue apprécier pouvoir faire un grep 'certificate has expired' domains.csv.

[villesinternet]

Bravo, j'adhère complètement à cette méthode :

• Les scripts de contrôle qualité doivent pouvoir être déclenchés automatiquement et régulièrement : grâce à ce cache, on peut réduire le temps d'exécution et faire preuve de sobriété, c'est un très bon point.
• Cela n'empêche pas d'avoir un script de validation exhaustive qui peut être déclenché "à la demande" selon un calendrier rationnalisé, ou avec le mécanisme de date de péremption du test que tu proposes avec limit

Pour le statut de domain .csv :

• C'est bien une réutilisation, tout comme urls.txt (données enrichies sur la base du repo)
• ...avec la particularité d'être réutilisé par le repo lui-même (en tant que cache)
• avec le recul, on pourra peut-être identifier un champ qui fait partie du modèle du repo (par exemple scheme ok ou ko pour http, https, ssh, ...) mais la frontière est à tracer.

[mfaure]

Cela me parait fort intéressant !

Je retiens que nous avons deux besoins :

• vérifier les nouveaux ajouts
• vérifier la totalité de la liste

et donc, vraisemblablement, deux manières d'y répondre