Analyseur d’URL

Le Parseur d'URL décompose n'importe quelle URL en ses composants selon la spécification RFC 3986, montrant exactement comment les navigateurs et les clients HTTP interprètent chaque segment. Collez une URL comme https://www.example.com:8443/api/v2/users?status=active&limit=50#results et visualisez chaque composant extrait : schéma, hôte, port, chemin, paramètres de requête et fragment.

Comprendre la structure des URL

Les URL sont les adresses du web, mais leur structure est plus nuancée que ce que la plupart des développeurs réalisent, jusqu'à ce qu'ils rencontrent un cas particulier de parsing. Une URL n'est pas simplement "ce que vous tapez dans le navigateur" -- c'est un format précisément défini spécifié dans la RFC 3986, avec des règles sur les caractères autorisés à quel endroit, comment les caractères spéciaux doivent être encodés, et comment chaque composant est délimité du suivant. Se tromper sur ces détails cause de vrais bugs : des chaînes de redirection cassées, des appels API mal routés, des vulnérabilités de sécurité liées à la confusion d'URL, et des échecs de suivi analytique causés par des paramètres de requête perdus.

La structure de base d'une URL est scheme://userinfo@host:port/path?query#fragment, mais la plupart des URL omettent plusieurs de ces composants. Le schéma indique au client quel protocole utiliser (http, https, ftp). L'hôte identifie le serveur, soit par un nom de domaine, soit par une adresse IP. Le port est généralement implicite -- 443 pour HTTPS, 80 pour HTTP -- mais peut être spécifié explicitement lorsqu'un service fonctionne sur un port non standard. Le chemin identifie la ressource spécifique sur ce serveur. La chaîne de requête transporte les paramètres sous forme de paires clé-valeur. Et le fragment pointe vers une section spécifique au sein de la ressource, traité entièrement par le client et jamais envoyé au serveur.

Ce qui pose problème, ce sont les cas particuliers. Une URL peut contenir des identifiants (user:password@host), bien que ce soit déprécié pour HTTP. Les adresses IPv6 doivent être encadrées par des crochets ([2001:db8::1]). Les valeurs des paramètres de requête peuvent elles-mêmes contenir des caractères ? et = s'ils sont encodés en pourcentage. Le premier ? sépare le chemin de la requête, mais les caractères ? suivants font littéralement partie de la requête. Ce parseur gère tous ces cas et affiche chaque composant séparément, rendant la structure de l'URL non ambiguë.

Comment analyser une URL en ses composants

1. Collez n'importe quelle URL complète dans le champ de saisie
2. Le parseur extrait chaque composant : schéma, informations utilisateur, hôte, port, chemin, requête, fragment
3. Les chaînes de requête sont décomposées en paires clé-valeur individuelles
4. Les ports par défaut sont identifiés en fonction du schéma (ex. : 443 pour https)
5. Les problèmes d'encodage ou les constructions non standard sont signalés

Exemples d'analyse d'URL

URL HTTPS standard

Entrée : https://www.example.com:8443/api/v2/users?status=active&limit=50#results

Paramètres de requête :

URL avec authentification

Entrée : ftp://admin:[email protected]/pub/reports/2024/

URL avec hôte IPv6

Entrée : http://[2001:db8::1]:8080/index.html

Chaîne de requête complexe

Entrée : https://search.example.com/results?q=url+encoding&lang=en&page=3&sort=relevance

Paramètres de requête :

Quand utiliser le parseur d'URL

• Débogage des chaînes de redirection pour inspecter chaque URL de la séquence et identifier où les paramètres sont perdus ou modifiés
• Analyse des URL de callback OAuth pour vérifier les URI de redirection, les paramètres state et les codes d'autorisation
• Extraction des paramètres de requête depuis des URL longues dans les payloads de webhooks, les liens de suivi analytique ou les réponses d'API
• Inspection des deep links dans les applications mobiles pour comprendre le routage et le passage de paramètres
• Analyse de sécurité d'URL potentiellement malveillantes pour identifier l'obfuscation dans l'hôte, le chemin ou les composants de requête
• Comparaison d'URL pour déterminer si deux URL d'apparence différente pointent en réalité vers la même ressource

Fonctionnement de la structure d'URL (RFC 3986)

Anatomie d'une URL

Une URL suit cette structure générale :

scheme://userinfo@host:port/path?query#fragment

Chaque composant remplit un rôle spécifique :

• Schéma (scheme) -- identifie le protocole (http, https, ftp, ssh, mailto)
• Informations utilisateur (userinfo) -- identifiants optionnels (user:password@), déprécié pour HTTP/HTTPS
• Hôte (host) -- nom de domaine (example.com) ou adresse IP (192.0.2.1 ou [2001:db8::1])
• Port -- numéro de port TCP optionnel ; les valeurs par défaut dépendent du schéma (80 pour HTTP, 443 pour HTTPS)
• Chemin (path) -- identifiant hiérarchique de la ressource (/api/v2/users)
• Requête (query) -- paramètres clé-valeur après ?, séparés par & (status=active&limit=50)
• Fragment -- ancre côté client après #, non envoyé au serveur (#section-2)

Encodage percent

Les caractères spéciaux dans les URL doivent être encodés en pourcentage avec % suivi de deux chiffres hexadécimaux. Encodages courants :

Ports par défaut par schéma

Lorsque le port par défaut est utilisé, il est généralement omis de l'URL. Le parseur identifie les ports explicites et implicites.

Parsing d'URL en pratique

La raison la plus courante pour laquelle les développeurs utilisent un parseur d'URL est le débogage. Vous examinez une chaîne de redirection et l'URL finale est manquante d'un paramètre de requête qui était présent dans l'URL originale. Le paramètre a-t-il été supprimé par la redirection ? A-t-il été renommé ? A-t-il été absorbé dans le chemin ? Analyser chaque URL de la chaîne côte à côte révèle exactement où le paramètre a disparu. C'est particulièrement courant dans les flux OAuth, où les URI de redirection transportent des paramètres state, des codes d'autorisation et des valeurs de scope qui doivent survivre intacts à travers plusieurs redirections.

Un autre cas d'usage fréquent est le travail d'intégration d'API. Lorsque vous recevez un payload de webhook ou une URL de callback d'un service tiers, vous devez extraire des paramètres de requête spécifiques pour traiter l'événement. L'URL peut être profondément imbriquée dans une réponse JSON, encodée dans une autre URL, ou tronquée dans un fichier de log. La décomposer en composants vous donne un accès propre à chaque paramètre sans découpage manuel de chaînes qui casse sur les cas particuliers comme les caractères & encodés dans les valeurs de paramètres.

Pour l'analyse de sécurité, le parsing d'URL révèle des techniques d'obfuscation qui sont invisibles en regardant l'URL brute. Un attaquant pourrait utiliser un caractère @ encodé (%40) pour faire apparaître une URL comme pointant vers un domaine de confiance alors qu'elle s'authentifie en réalité auprès d'un domaine malveillant. Ou il pourrait utiliser des séparateurs de chemin encodés pour contourner les contrôles d'accès basés sur le chemin. Analyser l'URL avec un parseur conforme aux standards montre la structure réelle après décodage, rendant ces techniques visibles.

Questions fréquentes

Pourquoi le fragment n'est-il pas envoyé au serveur ?

L'identifiant de fragment (tout ce qui suit #) est traité entièrement par le client (navigateur). Il est supprimé de l'URL avant l'envoi de la requête HTTP. Le serveur ne voit jamais le fragment. Ceci est défini dans la RFC 3986 et est utilisé pour la navigation côté client au sein d'une page, le routage des applications monopage (SPA) et les liens d'ancrage.

Comment le parseur gère-t-il les URL avec plusieurs caractères ? ou # ?

Selon la RFC 3986, seul le premier ? sépare le chemin de la requête, et seul le premier # (après la requête) sépare la requête du fragment. Les caractères ? supplémentaires au sein de la requête sont traités comme des caractères littéraux. Les caractères # supplémentaires au sein du fragment sont également littéraux. Le parseur suit ce comportement standard.

Le parseur peut-il gérer les noms de domaine internationalisés (IDN) ?

Oui. Les noms de domaine internationalisés comme beispiel.de (avec des accents ou des caractères non-ASCII) sont affichés tels quels et le parseur montre également l'encodage Punycode (ex. : xn--bsp-jma.example.com) utilisé lors de la résolution DNS effective.

Quelle est la différence entre %20 et + pour les espaces ?

Les deux représentent un caractère espace, mais ils sont utilisés dans des contextes différents. %20 est l'encodage percent standard pour un espace et est valide partout dans une URL. L'encodage + pour les espaces est spécifique au format application/x-www-form-urlencoded utilisé dans les soumissions de formulaires HTML et les chaînes de requête. Dans le composant chemin, + est un signe plus littéral, pas un espace. Le parseur gère les deux encodages correctement en fonction de leur contexte.

Comment savoir si deux URL différentes pointent vers la même ressource ?

Analysez les deux URL et comparez leurs composants. Les URL qui ne diffèrent que par le port par défaut (par ex. http://example.com vs http://example.com:80), les barres obliques finales, l'ordre des paramètres de requête ou les différences d'encodage peuvent résoudre vers la même ressource. Utilisez le URL Normalizer pour canonicaliser les URL avant comparaison.

Pourquoi mon URL est-elle analysée différemment selon les langages de programmation ?

Différentes bibliothèques de parsing d'URL peuvent gérer les cas particuliers différemment. urllib.parse de Python, le constructeur URL de JavaScript et net/url de Go suivent généralement la RFC 3986 mais peuvent diverger sur les URL malformées, les références relatives ou les patterns d'encodage inhabituels. Ce parseur suit strictement la spécification RFC 3986 et est utile comme implémentation de référence à comparer avec le parseur de votre langage.

Outils associés

• URL Normalizer - Normaliser les URL en supprimant les valeurs par défaut et en triant les paramètres
• Query String Parser/Builder - Analyser et construire des chaînes de requête URL
• Port Validator - Valider les numéros de port (0-65535)
• HTTP Header Formatter - Convertir entre les formats d'en-têtes bruts et clé/valeur
• Bulk Add/Remove Query Params - Ajouter ou supprimer des paramètres de requête de plusieurs URL