Il évite le mitm actif où le 302 de redirection http => https n'est pas transmis au client.
Au passage, le cookie d'auth n'est pas transmis en clair.

Cela empêche l'utilisateur de passer outre une erreur de certificat.

Cela empêche l'utilisateur de passer outre une erreur de certificat.

La notion d'erreur de certificat n'est pas bien définie. Il y a des messages d'erreurs de certificat, mais ce qui est considéré comme un certificat acceptable dépend de la subjectivité du navigateur.

Introduire une telle close dans la norme (*) montre à quel point l'esprit critique se fait rare!

Le navigateur pourrait très bien demander à l'utilisateur :

Ce certificat n'est pas considéré comme valide a priori. Voulez-vous que le navigateur génère une erreur de certificat (qui sera fatale) ou voulez-vous accepter ce certificat?

Je cherche d'ailleurs un moyen d'obtenir ce comportement dans un navigateur.

Bref cette histoire de passer outre est une arnaque intellectuelle qui fait que je rejette viscéralement HTTP Strict Transport Security.

(*) même comme non normatif(sic) : pourquoi encombrer une norme avec du non-normatif?

Définis "logiciel libre".

C'est un logiciel qui libère, ou bien?

Je n'ai envie de recompiler aucun de ces bousins à coté desquels un diplodocus passe pour un nain!

Téléportation acceptée.

À bientôt pour de nouvelles aventures.