Perso, je la trouve bien aussi.
C'est vérifiable via des outils comme securityheaders, le novice comme l'expérimenté peuvent le comprendre de manière immédiate, c'est durable (je ne vois pas le web revenir du HTTPS, trop d'APIs en ont besoin => service workers/etc., et le web tout court en a besoin... et ça fait des années que la lame de fond HTTPS est là, là elle a déferlé avec tous les gros acteurs (navigateurs/Google/etc.)... maintenant je vois pas des gens parler sérieusement de faire sans HTTPS)
Tout à fait une BP utile, et ça laisse la possibilité de mettre en place HSTS sous la forme décidé par la personne créant le site. Vérifiable, via l'entête, durable c'est un pari (si demain Chrome/Google décide de dire "tout site n'ayant pas "preload" n'est plus chargé", parce que preload le met en dur dans le code du navigateur…), consensuelle : c'est forcé à utiliser HTTPS, donc oui.
Grégoire, est-ce que la formulation actuelle {Les pages utilisant HTTPS ont un en-tête de transport strict} te semble répondre à une BP utile, vérifiable en ligne, durable et consensuelle ?
Pour HSTS (qui est la solution technique), si on met en place le "preload" (ce qui est la solution la plus stricte, avec le "subdomain") la 301 ne DOIT PAS (c'est le sens fort de l'anglais ici) exister. Mais HSTS ça peut très bien aussi être simplement l'entête avec un "max-age". Donc la question ici : est-ce qu'on fait une BP stricte (et donc contraignante à plusieurs égards), ou est-ce que l'on se limite à "HSTS" et chacun ira de sa configuration selon ses besoin.
Pour l'instant, la dernière formulation est {Les en-têtes envoyés par le serveur forcent le navigateur à utiliser une connexion sécurisée}. On va la mettre en discussion mais Nicolas, aurais-tu une idée de formulation claire pour prendre en compte ta remarque sur 301.
Petit souci avec {Les en-têtes envoyés par le serveur forcent le navigateur à utiliser une connexion sécurisée}, ça peut être validé par une redirection 301, alors que l'idée est justement de ne pas attendre une 301 et d'aller plus loin en forçant l'agent utilisateur à utiliser direct du https.
Côté use case, c'est bien expliqué ici https://www.bortzmeyer.org/6797.html
habile retour de HSTS ;-) Je vais demander un user case, que tout le monde puisse plus facilement suivre MitM, détournement de cookie ;-) Sinon, pour des questions d'harmonisation des formulations, une proposition : {Les en-têtes envoyés par le serveur forcent le navigateur à utiliser une connexion sécurisée} ?
