Cette pratique est maintenant dépréciée (anti-pattern, carrément) d'une part, et d'autre part les navigateurs commencent à ne plus le gérer (j'ai un exemple sous les yeux avec LibreWolf 87.0) et donc les dévs doivent le gérer en amont pour remettre le protocole, qu'il faut donc maintenant deviner, youpi :)
Coté utilisateur, très concrètement ce que ça veut dire, c'est que de moins en moins de lecteurs des flux verront les images.
# [err...] pas le bon ticket, l'autre ticket "image" n'est pas encore passé !
Posté par Patrick Trauquesègues . Évalué à -3 (+0/-0). Dernière modification le 11 septembre 2021 à 08:36.
probable erreur de copié-collage du lien par l'auteur
testé les liens et d'autres avec des url bizarres de twitter.com
tout fonctionne, y compris le favicon linuxfr.org
[https://linuxfr.org/favicon.png](https://linuxfr.org/favicon.png)
# https:// partout
Posté par nud . Évalué à 2 (+0/-0).
Quand LinuxFR est passé aux liens sans protocole, c'était parce que le site était servi en HTTP et en HTTPS, et les liens internes étaient un joyeux mélange. C'était en 2012.
Comme en 2023 on utilise HTTPS partout, peut-être que tout ça ne sert plus à rien et qu'on pourrait juste mettre des
https://partout. La seule question est relative à l'environnement de développement.[^] # Re: https:// partout
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Oui, tu as tout a entièrement raison.
Pour l'environnement de développement je préfèrerai pouvoir garder la possibilité de fonctionner sans TLS pour ne pas compliquer encore plus la mise en place.
Si on fait cette modification, il faut aussi en profiter pour pouvoir choisir le port d'écoute.
Cela permettrai d'utiliser un port plus grand que 1024 et donc d'exécuter l'environnement de développement sans accès root (par exemple avec podman au lieu de docker).
Ce que je ferai donc, ça serait: remplacer la variable
MY_DOMAIN=dlfp.lopar quelque chose du genreBASE_URL=http://localhost:3000. De même pour la variableIMG_DOMAIN.Il faudrait aussi répercuter ce changement pour tous les projets de services (img, epub, board…).
[^] # Re: https:// partout
Posté par nud . Évalué à 3 (+0/-0). Dernière modification le 03 janvier 2023 à 09:15.
Après, en y regardant de plus près, dans le commit lié ci-dessus il s'agit d'enlever protocole et domaine, donc c'est toujours valide. Si le browser ne supporte pas de tels liens il faut corriger le bug dans le browser.
Des commits plus pertinents sont:
Mais l'analyse reste juste. Ces URLs sont utilisées pour e.g. intégrer des images et intégrer une image en HTTP posait problème quand on voyait le site en HTTPS. Dans la mesure où DLFP utilise maintenant HTTPS partout, ça ne sert à rien de les conserver. C'est aussi la décision qu'a prise Wikipedia apparemment: mettre à jour les liens sans URL pour inclure
https://.Comme les commits ci-dessus impliquent surtout que DLFP a accepté les URLs sans scheme dans les contenus, il faudra soit modifier les contenus existants soit silencieusement ajouter le préfixe
https://.Ceci dit, AMHA le bug est avec le browser s'il casse la compatibilité ascendante de la sorte…
[^] # Re: https:// partout
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2 (+0/-0). Dernière modification le 20 septembre 2024 à 13:53.
J'ai commencé une branche pour utiliser des URLs complètes dans le code de LinuxFr (pas dans le contenu) et permettre de choisir le port publique: https://github.com/linuxfrorg/linuxfr.org/pull/395
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.