Encore une idée qui vient des 6 semaines noires de l’internet.
Dans la famille « faire sentir l’infrastructure d’internet » à ses usagers : Transformer le temps de chargement infini des pages Web lorsque le serveur est indisponible en un message d’erreur personnalisé et actualisable.
Ce dont je rêverai :
code d’erreur
Renvoyer un code d’erreur HTTP 503 : Service Unavailable documentation sur MDN.
À quoi ça sert ? Pour les humains pas grand chose. Par contre, ça indique au navigateur que ce n’est pas la bonne page qui lui est servie. D’habitude, quand tout vas bien, il reçoit le code 200. Et par exemple pour les robots qui indexent le Web (moteurs de recherches et autre), cela va être interprété comment n’étant pas la page recherchée.
Par exemple : si le robot de la Wayback Internet Machine toque à la porte du serveur pendant qu’il est indisponible, ça lui évitera sûrement d’ajouter ce message d’erreur à son archive pour un des sites CLUB1.
Message
Pour envoyer le message, quoi de mieux que du bon vieux HTML ??? On pourrait avoir un message par défaut défini par un repo Git (solution de versionnage pour fichiers statiques). On pourrait ensuite le mettre à jour en proposant des modification via Git lorsqu’on est en live.
Cet ensemble de fichier nous permettrait de s’amuser un peu avec l’identité visuelle de notre message. On pourrait par exemple le styliser, mettre une image, ou même un GIF ! Une version plus poussée pourrait intégrer un petit jeu vidéo 🤣.
Évidement, on aura la possibilité de mettre des liens vers d’autres page ou des adresses emails.
Nom de domaines non-CLUB1
Je veux parler des sites Web qui n’utilisent pas un sous-domaine de CLUB1 (monsite.fr et non pas monsite.club1.fr). Si des membres ont choisi leur propre nom de domaine pour un de leurs sites, ils ne veulent peut être pas que leurs visiteureuses les identifient à CLUB1. Ils n’auraient donc peut être pas envie qu’iels voient s’afficher un message d’erreur CLUB1 lorsqu’il y a une panne. Il faudrait donc que le système technique permette aux personnes qui louent leur propre nom de domaine puisse garder le contrôle et choisir de renvoyer ou nom ce message d’erreur.
Pour les sites utilisant un sous-domaine de CLUB1, je pars du principe qu’ils assument une filiation induite par le sous-domaine lui même.
Mise en place technique
Le soucis technique de base est que pour renvoyer une réponse (notre message d’erreur) alors le serveur CLUB1 est en panne, il faut (au moins) un deuxième serveur.
Un autre soucis est que pour l’instant, nous hébergeons notre serveur DNS sur le serveur CLUB1. Cela implique qu’il faudrait le dupliquer et l’annoncer au registraire (entreprise à qui on loue club1.fr). Pour cela, il semblerait que l’on puisse avoir un deuxième serveurs DNS primaire. Lorsque le serveur CLUB1 est hors ligne, on aurait alors accès au deuxième serveur DNS et l’on pourrait alors rediriger toutes les requêtes vers notre fameux message d’erreur.
Concrètement, ce deuxième serveur pourrait être un serveur ami sur lequel il y aurait une configuration hyper simple : Un serveur DNS, un serveur Web (Ngnix), et la dernière version de nos fichiers statiques définie par notre repo Git. Une piste pourrait être d’aller voir du côté du serveur d’Étienne, qui héberge déjà nos backups off-site.
C.f :article dans le journal concernant les backups et un le paragraphe sur les backups dans la doc