Extrait de l'émission CPU release Ex0213 : Disséquons une URL, première partie.
Dans une URL, après le // vient l'authority, en Français, l'autorité, la question du chez qui
. Et l'autorité, elle ne se discute pas. C'est un argument… d'autorité.
— Oh, merci Capitaine Évidence.
—Oui, pardon, je suis lourd.
En gros, ce gros segment de l'URL indique à quel serveur physique vous allez frapper à la porte, et avec quelle identité.
Comme pour l'ensemble de l'URL, son autorité se décompose en plusieurs éléments uniques qui peuvent être facultatifs, et ces éléments sont séparés par des symboles, symboles qui servent à les identifier. Attention, reprenez le stylo, je dicte sa formule :
user : password @ host : port
En français :
utilisateur : mot_de_passe @ hôte : port
Alors, vous avez remarqué que pour les symboles utilisés pour reconnaître chaque atome, on a un gag : le symbole : apparaît deux fois. Et si vous voulez vous amuser, mettez des :
, des /
et une @
dans le mot de passe, vous allez rendre fou des utilisateurs. Mais je vais un peu vite…
Donc, dans l'authority, on trouve comment s'identifier, sur quel serveur et quel numéro de port. En plus de préciser le nom de la machine, on précise les conditions d'accès. Implicitement, et sans aucun des autres symboles séparateurs, c'est l'hôte qui est identifié, en général un nom de domaine. [Un peu quand on vous dit à la radio pour l'URL de l'émission cpu.pm
].
Et si on a une @ avant le nom de domaine, on a une identification : le nom d'utilisateur.
À une époque, on mettait le mot de passe après le nom d'utilisateur et : avant l'@. Ne le faites pas, c'est hyper-dangereux, et déprécié dans l'URL. Si par exemple vous utilisez une URL pour paramétrer la base de données de votre application, il vaut mieux que le mot de passe n'y soit pas en clair. Même si ça marche encore dans les navigateurs web, si vous tentez
Oui, je sais, mettre un mot de passe dans une URL, ça marche encore sur le web, techniquement c'est du Basic Auth, de l'Authentification Basique, où le nom d'utilisateur et le mot de passe sont envoyés dans les entêtes de votre requête… Alors qu'on a un truc vraiment génial : la clé SSL côté client, qu'on vient de ressusciter 20 ans après avec le protocole standard WebAuthn… mais c'est pas le sujet.
L'adresse du serveur hôte est souvent identifiée par son nom de domaine. Pour rappel, un nom de domaine est un alias dans un annuaire pour ne pas avoir à retenir tous les numéros de téléphone des serveurs, parce que sinon, il faudrait mettre une adresse numérique quand on veut aller sur un site web. Par exemple, celui de notre site cpu.pm renvoie à l'adresse IP 217.70.184.55, et c'est pas dit que je le change prochainement. [Évidemment, nous avons dû la changer le lendemain du montage de cette release]
Je viens d'exprimer une adresse numérique en IPv4 par octets. Par exemple, l'adresse qui renvoie localhost, l'ordinateur sur lui-même, est 127.0.0.1. Une adresse numérique nettement plus drôle dite en base 10 : 2130706433. Oui, vous rentrez ce nombre, elle passe dans une URL.
Et on peut utiliser une adresse IPv6 dans une URL, sauf qu'on doit encapsuler cette adresse dans des crochets, par exemple, pour localhost [::1] car le :
séparateur d'une adresse IPv6 pourrait être confondu avec le :
séparateur pour le numéro de port, ce qui commence à faire beaucoup trop de deux-points dans l'autorité ! C'est l'un des rares cas où utiliser en brut un symbole délimiteur tel quel en clair avant l'endroit où il peut apparaître ne cause pas trop de soucis.
Oui, l'IPv6 a commencé à être définie en 1995, et à l'époque, peu de gens avaient songé à vérifier si ce nouveau concept d'URL pouvait péter.
[Suite : How to : Les parties cachées d'un nom de domaine dans une URL]
Texte : Da Scritch
Photo : PremiSys card access CC-By PremiSys photos