Les URLs ont l’air simples jusqu’à ce qu’il faille écrire du code qui les manipule. Vous découvrez alors que le chemin peut contenir des barres encodées qui ne sont pas des barres, que l’hôte peut porter un port que l’expression régulière n’a pas prévu, que la chaîne de requête peut répéter la même clé trois fois avec des valeurs différentes, et que le fragment est invisible au serveur mais très visible à un cadriciel JavaScript. La moitié des bogues qui partent en production dans le code de manipulation d’URL viennent de quelqu’un qui a reconnu l’URL à l’œil au lieu de l’analyser. L’Analyseur d’URL de PortJar est l’antidote — collez une URL, voyez exactement comment elle se décompose.
Ce que fait l’outil
L’Analyseur d’URL prend une chaîne d’URL et la casse en composants standards : protocole (schéma), hôte, port, chemin, requête, fragment et — quand présent — les informations d’utilisateur avant l’hôte. Chaque composant est affiché décodé et étiqueté, avec la chaîne de requête davantage décomposée en paires clé/valeur. La décomposition tourne entièrement dans le navigateur. Rien n’est envoyé aux serveurs de PortJar et rien n’est journalisé.
Le but est de régler les débats rapidement. Quand quelqu’un dit « l’URL a un paramètre ?token= », collez-la dans l’analyseur et vous verrez si le jeton est dans la requête, dans le fragment (où le serveur ne le verra jamais), ou dans le chemin (où il termine dans les journaux d’accès). L’analyseur ne normalise pas — ce que vous voyez est ce que l’URL contient réellement, y compris les clés en double, les valeurs vides, et les caractères encodés en pourcentage qui ont l’air inoffensifs jusqu’à ce qu’ils ne le soient plus.
Comment l’utiliser
Ouvrez portjar.com/tools/url-parser, collez l’URL dans le champ d’entrée, et lisez la décomposition en dessous. Il n’y a pas de bouton à appuyer — l’analyse se met à jour à mesure que vous tapez. La page fonctionne hors ligne, vous pouvez donc la lancer sur une URL d’un contexte sensible (un billet interne, une session de soutien client) sans que rien ne quitte votre navigateur.
Quand vous y recourriez
- Déboguer un bogue « le jeton n’est pas envoyé ». Collez l’URL que le client vous a montrée. Si le jeton est après le
#, le serveur ne le voit jamais — c’est un fragment, qui est exclusivement côté navigateur. S’il est après le?, c’est un paramètre de requête et le serveur devrait le voir. L’analyseur règle la question d’un écran. - Vérifier qu’une URL de rappel SSO est bien formée. Un
&mal placé ou un caractère encodé en pourcentage au mauvais endroit transformera un rappel fonctionnel en boucle de redirection ou en erreur « state mismatch ». L’analyseur vous montre ce que l’URL contient réellement, pas ce que vous vouliez qu’elle contienne. - Lire une longue URL S3 ou CDN signée sans perdre le fil. Les URLs présignées entassent la signature, l’expiration et une pile de paramètres de requête sur une ligne. L’analyseur les dispose pour que vous puissiez confirmer que l’expiration est celle réglée, que la signature est présente, et qu’aucun paramètre supplémentaire ne s’est faufilé.
- Attraper des motifs de path traversal dans une URL fournie par un client. Les segments
..encodés, les barres doublement encodées et les octets nuls intégrés apparaissent clairement dans la composante chemin décodée. Si vous triez une requête suspecte d’une ligne de journal, collez l’URL ici pour la lire sans deviner. - Réviser une cible de redirection avant de la publier. Quand une campagne ou un fournisseur vous remet une URL vers laquelle rediriger, l’analyseur vous dit exactement où elle mène. Un chemin de
/track/click?dest=…devrait être un indice que l’URL est un pisteur qui enveloppe la vraie destination.
Quoi faire de la sortie
Le protocole et l’hôte sont évidents ; les parties qui mordent sont celles en dessous. Surveillez le port. Un port explicite autre que 80 ou 443 dans une URL publique est soit volontaire, soit une fuite — dans tous les cas, à confirmer. Un port manquant ne signifie pas port 80 ou 443 ; ça signifie le port par défaut du schéma, qui est la même chose, mais qui vaut la peine d’être dit à voix haute quand vous expliquez l’URL à quelqu’un.
Le chemin est la partie la plus sujette à la mauvaise lecture. Les barres finales comptent pour certains cadriciels et pas pour d’autres, ne normalisez donc pas en silence. Les barres encodées (%2F) dans le chemin ne sont pas les mêmes que les vraies barres et sont explicitement interdites par certains serveurs web — si l’analyseur en montre une, c’est un constat.
La chaîne de requête est la source la plus courante de bogues « mais l’URL a l’air bien ». Chaque paire clé/valeur est affichée séparément. Si la même clé apparaît deux fois, l’analyseur l’affiche deux fois — différents cadriciels prennent la première, la dernière ou un tableau, et la différence compte. Les valeurs vides (?foo=) ne sont pas la même chose que les clés manquantes (?) ni que les clés sans valeur (?foo) ; l’analyseur montre la distinction.
Le fragment est invisible au serveur. Si quelque chose que le serveur est censé recevoir se trouve dans le fragment, le bogue est côté client.
Pour les environnements où la forme des URLs, l’hygiène des redirections et le comportement du CDN doivent rester cohérents sur plusieurs sites, Stack Harbor s’en occupe dans le cadre des environnements infogérés.