Analyser une URL

La grammaire du RFC 3986 a plus de recoins qu’il n’y paraît : des informations d’utilisateur avec un deux-points dans le mot de passe, des adresses IPv6 entre crochets, un port vide après un deux-points, des caractères encodés dans l’hôte, un chemin qui n’est fait que de points. Chaque motif écrit à la main diverge du navigateur quelque part, et la divergence est toujours trouvée par une adresse réelle plutôt que par un test.

Cette page appelle `new URL()`, c’est-à-dire le même code que celui qui résout l’adresse quand vous appuyez sur Entrée. Là où les deux ne sont pas d’accord, il n’y a pas de discussion à avoir : le navigateur a raison par définition, puisque c’est lui qui va chercher la ressource.

Le schéma et l’hôte reviennent en minuscules. Les `.` et `..` du chemin sont résolus. Un port qui est celui par défaut du schéma — 443 pour https, 80 pour http — est retiré, parce qu’il est implicite. Les caractères qui doivent être encodés le sont.

Rien de tout cela n’est une perte d’information. C’est ce que l’adresse *signifie*, qui est la question posée ; le texte que vous avez tapé est encore dans le champ au-dessus si vous voulez comparer. `HTTPS://Exemple.FR:443/a/./b/../c` et `https://exemple.fr/a/c` sont la même requête, et voir cela énoncé est souvent toute la raison d’être ici.

Le schéma, l’hôte et le port pris ensemble forment l’origine, et c’est l’unité dans laquelle raisonnent la politique de même origine, CORS et la portée des cookies. Deux adresses sont de même origine seulement si les trois coïncident — donc `http://exemple.fr` et `https://exemple.fr` sont deux origines différentes, et `exemple.fr` et `www.exemple.fr` aussi.

C’est pourquoi l’origine est affichée séparément plutôt que laissée à assembler à l’œil. La plupart des perplexités sur une requête bloquée ou un cookie qui n’est pas envoyé se dissipent dès que quelqu’un compare deux origines caractère par caractère au lieu de jeter un œil à deux noms d’hôte.

Tout ce qui suit le `#` est traité entièrement côté client. Il n’est pas envoyé dans la requête, il n’atteint pas le serveur, il est absent des journaux d’accès. C’est un fait sur HTTP plutôt qu’une fonctionnalité de confidentialité, et cela coupe dans les deux sens.

Cela veut dire qu’un fragment est un mauvais endroit où chercher quelque chose dans un journal serveur — il n’y a jamais été. Cela veut dire aussi qu’un fragment est là où les applications monopages rangent leur état, et là où le flux implicite d’OAuth plaçait autrefois un token, précisément pour qu’il ne soit pas journalisé par tous les intermédiaires du trajet.

La forme `utilisateur:motdepasse@hote` est encore légale et apparaît encore dans des fichiers de configuration, des chaînes de connexion et des scripts. Les navigateurs l’ont progressivement restreinte parce que c’est un excellent outil d’hameçonnage — une adresse qui se lit `https://[email protected]/` a pour hôte `attaquant.example`, et cette page vous le montrera.

Le mot de passe est signalé comme présent, avec sa longueur, plutôt qu’imprimé. Une URL contenant des identifiants est presque toujours une URL que quelqu’un est en train de déboguer, et l’écran sur lequel elle se trouve est presque toujours sur le point de devenir une capture d’écran dans un ticket. Le constat est qu’un secret est là ; le secret lui-même ne l’est pas.

Les navigateurs masquent le schéma dans la barre d’adresse, donc ce que les gens copient commence souvent à l’hôte. `new URL()` refuse cela, à juste titre — une URL sans schéma n’est pas une URL — et le refuser ici serait techniquement correct et inutile.

Alors `https://` est supposé et une note apparaît pour le dire. Les deux cas sont tenus séparés délibérément : un schéma mal orthographié, `htp://exemple.fr`, n’est pas réparé. Il s’analyse, avec `htp` comme schéma, ce qui est le diagnostic que vous êtes venu chercher. Lui préfixer `https://` produirait une adresse dont l’hôte serait `htp` — une erreur confiante, ce qui est pire que les deux autres possibilités.

Un hôte comme `café.example` n’est pas envoyé tel quel. Il est converti en Punycode — `xn--caf-dma.example` — par le mécanisme des noms de domaine internationalisés, et c’est cette forme que le DNS voit, que les certificats portent et que les journaux enregistrent.

Cette page affiche l’hôte tel que le navigateur le normalise, ce qui rend la conversion visible. C’est utile parce que la forme `xn--` est celle qu’il faut recopier dans une configuration ou un enregistrement DNS, et parce qu’un domaine accentué qui « ne marche pas » est très souvent un domaine dont la forme Punycode n’a jamais été déclarée quelque part.

Certains alphabets contiennent des lettres visuellement identiques aux latines : le `а` cyrillique ne se distingue pas du `a` latin à l’écran. Un domaine composé avec ces lettres s’affiche comme une marque connue et pointe ailleurs.

La défense des navigateurs est d’afficher la forme Punycode quand un nom mélange des alphabets, ce qui rend le piège visible. Coller ici une adresse dont vous doutez donne la même information : si l’hôte revient sous une forme `xn--` que vous n’attendiez pas, il ne contient pas les lettres que vous croyiez lire.

Elle ne dit pas si l’adresse existe. Un hôte parfaitement bien formé peut ne correspondre à aucun enregistrement DNS, et un chemin parfaitement structuré peut renvoyer un 404. Cette page ne va rien chercher, précisément parce qu’aller chercher serait une requête vers une adresse que quelqu’un est en train de déboguer.

Elle ne suit pas non plus les redirections. Une URL raccourcie reste une URL raccourcie : vous en verrez le schéma, l’hôte et le chemin, et non la destination. Pour cela il faut une requête, et faire cette requête depuis cette page révélerait à un tiers l’adresse que vous inspectez — ce qui est exactement ce que le reste du site refuse de faire.