Extrait de l'émission CPU release Ex0213 : Disséquons une URL, première partie.
La toute première partie d'une URL est le protocole, ou plus exactement le scheme, le plan, la question du comment
.
Le nom du protocole s'écrit d'un seul mot, parfois de deux avec un + au milieu, il comporte les lettres alphabétiques romaines, peut avoir des chiffres, des tirets. Et pour signaler qu'on parle d'un protocole, on accole le symbole délimiteur : après.
Attention, il faut se méfier car on verra que ce protocole est lié à la manière dont votre client ou votre système d'exploitation va utiliser cette information.
Un protocole va expliquer comment on va dialoguer, et côté client, c'est à dire sur votre ordinateur, quel logiciel on va employer pour l'utiliser.
Parmi les protocoles les plus connus, vous avez sûrement vu http et https qui sont utilisés pour le web. D'autres sont plus vieux comme ftp, mailto, gopher ; certains servent exclusivement pour des réseaux intranet ou des contextes serveurs comme smb, mysql ; certains sont arrivés plus récemment que le web, comme tel (qui fait référence au téléphone) ou fax qu'on n'a quasiment jamais vu.
Actuellement, nous avons plus d'une centaine de protocoles logiciels qui sont en activité. Mais trois d'entre eux sont très spécifiques car liés à l'usage des URL au sein des navigateurs web :
Le protocole file, qui fait référence au stockage de fichier local du logiciel client. Ce qu'il y a dans votre ordinateur, par exemple, mais vraiment sur votre ordinateur, ce qui est accessible hors ligne. Le protocole file n'est pas censé être utilisé dans un contexte réseau. Et beaucoup d'applications peuvent empêcher de créer des liens dans des fichiers hypertextes vers des fichiers locaux, pour des raisons de sécurité.
OOooooh ! Merci Capitaine Évidence…
Le protocole data, lui, est très particulier, car il contient juste après dans l'adresse le contenu complet du document auquel il se réfère. On a le type-mime du document, l'encodage qui va être utilisé, et le document brut. En général, avec le protocole data, on fait des URL hyper-longues, pas lisibles, lourdingues, pas du tout optimisées, donc son usage est très franchement déconseillé. Y'a des outils soit-disant d'optimisation web qui encodent en protocole data des éléments complémentaires d'une page web, alors qu'on a de bien meilleures solutions depuis une dizaine d'années.
Si vous voyez ça généré par un outil, c'est mauvais signe sur la qualité de cet outil.
Et enfin, un troisième protocole très particulier aux URL, le protocole javascript. Celui-là, vous ne voulez pas le connaître : c'est une faille de sécurité en puissance, il n'aurait jamais dû exister. Il a été créé par Netscape en 1995 pour appeler une action dans une page web, et de nos jours, quand on conçoit un site, on doit indiquer aux navigateurs web de toujours ignorer ce protocole.
Donc, écartons file, data et javascript.
Les protocoles reconnus par toute l'industrie sont attribués par l'IANA, Internet Assigned Numbers Authority, l'autorité qui gérait l'attribution des adresses IP.
Y'a une liste officielle
à l'IANA avec une centaine de protocoles permanents
ou historiques
. Et à côté, des petits plaisantins comme Microsoft en ont ajouté quelques centaines pour leur usage perso.
Apple a ainsi créé
en 2005 un protocole itms… qui en fait fait exactement le même travail que le protocole http, il servait à reconnaître les liens qui doivent être ouverts par le logiciel iTunes. Il est devenu très vite à la mode avec l'incorporation des podcasts dans iTunes, sachant qu'un lien podcast est un flux XML hébergé sur un serveur web. Oui. Certains éditeurs de podcasts ont longtemps proposé que des liens en protocole itms pour leurs podcasts. Faut dire que les clients d'Apple ont plus de pouvoir d'achat donc les espaces pubs se vendent plus cher.
Au lieu de se baser sur le mime-type du document servi pour lancer son application cliente, Apple créa son propre protocole et le balance comme ça sur le web en concurrence du http. Apple a ainsi fragmenté le monde naissant des podcasts, car nombre d'éditeurs ne proposaient que les liens itms sans mettre un lien http à côté.
Chez Apple, dès 2006, ils ont failli privatiser complètement les podcasts. Ils l'ont jouée comme Microsoft, mais heureusement ça n'a pas pris. Mais le mal a été fait : selon des chiffres d'audience, les podcasts se consomment avant tout sur iPhone.
De nos jours, on peut faire la même erreur euh pardon, la même chose en ajoutant au navigateur des chargeurs de protocole. On le fait avec une fonction javascript : navigator.registerProtocolHandler()
Cette fonction a été créée pour faire la même chose en web-app qu'en applications natives Android et iOS. Elle date du début des années 2010 quand on essayait de transformer le bureau des OS de smartphones et frigos en navigateurs web, avec FirefoxOS, webOS et Tizen. Dans le web, cette fonction sert à faire un raccourci vers une requête GET avec un paramètre texte. En gros, on dit au navigateur web que si un lien comporte un protocole spécifique, il faut renvoyer sur une page d'un site web précis.
web+wiki, en n'utilisant plus que lui pour tous les liens internes à Wikipédia : on n'y trouverait que des liens avec des balises <a href= faisant référence au protocole web+wiki. Un peu privateur comme URL…Donc méfiez-vous de la fonction
registerProtocolHandler : elle peut être très utile, par exemple pour lier une info à un choix d'applications, genre proposer de passer un appel téléphonique, et laisser le choix au sein du navigateur de l'application à utiliser, mais les protocoles personnaliser peuvent fractionner encore plus un web qui n'en n'a pas besoin.
D'ailleurs, petite remarque critique : c'est pas parce qu'une fonction a pu être validée dans un standard qu'il faut l'utiliser à foison. J'aurais dû vous prévenir que les bêtises arrivaient même au plus haut, et j'espère que maintenant vous comprenez pourquoi il faut comprendre l'intention derrière un standard.
Dans le cas [fictif] de Wikipédia, on peut mieux faire : enregistrer un nouveau moteur de recherche dans votre navigateur web sans fractionner le web pour autant. Et d'ailleurs, si vous allez sur notre site cpu.pm, notre site signale à votre navigateur qu'il peut proposer notre moteur de recherche interne, à côté de Google, Duckduckgo et Bing. Et je m'en sers énormément.
Pour le voir, il faut avoir la barre d'URL séparée de la barre de recherche, et vous verrez l'icône de loupe avoir un indicateur +
pour certains sites dont le nôtre.
[Suite : How to : Le // des URL]
Texte : Da Scritch
Illustration : ethernet cables, royalty free via pxfuel, détail