5568 sujets

Sémantique web et HTML

Bonjour.
J'ai une question concernant les liens .

J'ai lu dans le Guidelines HTML, "Bonnes pratiques HTML en production", dans la partie "généralités", que les liens absolus ne devaient pas faire apparaître le protocole : "Les liens absolus ne doivent pas faire apparaître le protocole (par exemple href="//www.alsacreations.fr/" et non href="http://www.alsacreations.fr")."

J'aimerais comprendre pourquoi. Merci de vos éclaircissements.
Bonjour,

Je suis aussi intéressé par une explication si quelqu'un en a une !

D'ailleurs, pourrais-tu indiquer la source où tu as vu cette bonne pratique, parce que je ne trouve que des contres indications.

En effet, je trouve beaucoup plus logique d'indiquer le protocole de la requête que de l'omettre si on parle de bonne pratique. Parce que cela signifie qu'il est impossible, provenant d'une page servie en http, d'exister un quelconque lien sur cette page amenant sur un site servant sa ressource en autre chose que du http (je sais pas si je me suis fait comprendre ^^).
Bref, je suis intéressé de voir un argument en défaveur de la présence du protocole xD
En fait, je vais commenter à nouveaux. ^^

Je trouve que c'est stupide comme bonne pratique (sous réserve qu'il existe un argument valable bien entendu Smiley cligne ).

Par exemple, dire qu'il faut omettre le protocole, c'est (je trouve) la même chose que dire qu'il est bon d'omettre le port. Effectivement, personne ne le met car la plupart du temps, on passe par du http et donc le port "associé", c'est à dire le 80 (respectivement 443 pour https). Or, une adresse, c'est un host et un port, donc pourquoi serait-il "bon" d'omettre le port ? N'aurait-on pas le droit de lancer un serveur qui écoute sur un autre port, et que depuis une page servie en http (et donc sur le port 80), on affiche un lien vers une ressource servie par ce nouveau serveur ?
Bref, on parle ici d'implicite. Pas de port car le port est donné implicitement par le protocole.
Mais si on omet le protocole, ça veut dire quoi ? Protocole donné implicitement par ???? Le fait que ce soit du web ? Donc par défaut l'explorateur essaie du http ? Et donc si jamais le site n'est servi qu'en https, bah ça fonctionne pas ? ahh si ! c'est le serveur web qui demande de recommencer la requête, mais en https (etc, en fonction de la ressource demandée) ! Bah je trouve ça plus sale moi que de simplement mettre un lien qui indique de faire du https directement : au final, ça fait de la conf en plus et de la sémantique implicite (et donc plus dur à maintenir => plus d'erreur potentielles).

Je comprends le conseil dans le sens ou la manière de servir la ressource doit être détachée de la sémantique portée par la ressource. C'est à dire que quand le programmeur écrit le code source, ce qu'il veut afficher, c'est un lien, pas une méthode de communication pour avoir le lien. Déjà parce que c'est embêtant à écrire, et ensuite parce que la ressource peut changer d'emplacement, de manière d'être servie (migration de http vers https pour un site entier par exemple) etc…
Cependant, le web ne fonctionne pas comme ça. Malheureusement, actuellement, il n'y a pas de registre de ressource ou autre système d'indexation. C'est à dire que la sémantique (dire "je veux voir cette ressource") est strictement et entièrement défini par l'uri de la ressource (i.e. un url pour du web classique), et donc le lien doit comporter à la fois le nom de la ressource pour le programmeur (au moins quand il écrit son code source, après le lien peut être transformé, c'est autre chose), mais aussi la manière d'adressage (protocole, port, etc…). Et évidemment, comme dit juste au dessus, ce n'est pas compatible avec le changement. C'est à dire qu'un changement de nom d'hôte par exemple impliquera un changement de tout les liens nécessaire.

Pour moi, le conseil correct qu'il faudrait donner, c'est de détacher sémantique et méthode. Django le fait bien par exemple avec son tag "url" qui permet de factoriser à travers un résolveur d'url (au moins pour ce que le serveur lui-même dessert, pour le reste, bah faut prier pour que ça change pas trop souvent, sinon dans le meilleurs des cas on a inventé la 404 et les résolveurs de noms d'hôte, et dans le pire, le timeout xD ).

Enfin.. ^^ Je me suis emporté mdr, vraiment, si quelqu'un a un argument, je veux l'entendre ! =) Marre de rester inculte xD
Modifié par mistiru (29 Aug 2017 - 15:16)
Je pense qu'il n'y a aucun problème à ne pas mettre le protocole pour toutes les ressources internes d'une page présentes sur un même serveur. Cela suit le protocole de la page donc logiquement tout doit fonctionner.

Maintenant on peut effectivement se poser la question des ressources externes. Par exemple que se passe t'il si on inclus une ressource d'un site tiers et qu'un jour celui-ci oublie de renouveler son certificat ? Je suppose que notre site récupérera la ressource en http et donc que notre certificat sera compromis (j'ai pas fait le test). Est-ce bien que l'on veut ? (même si il y a très très peu de chance que cela arrive cela me paraît quand même dangereux).

Apparemment les urls sans protocole ne fonctionnent pas bien en local pour ce que j'ai pu trouver comme autre inconvénient. (https://stackoverflow.com/a/4832046/7963372).

Quand au fonctionnement si effectivement un site se retrouve à tester https puis http pour toute les ressources sans protocole ce serait évidemment une contre perf.
Administrateur
Pour les ressources externes, cela dépend bien sûr de ce que le serveur tiers a prévu. De nos jours, la plupart des URLs sont proposées par défaut en HTTPS.

D'ailleurs, inclure une ressource HTTPS dans une page HTTP passe très bien.
L'inverse non : si votre site est en HTTPS, appeler un fichier externe avec une URL en http:// sera bloqué par le navigateur (et il aura raison).