Découpeur d’URL

Les intégrations OAuth et OpenID Connect échouent pour des détails : barre finale, mauvais port ou http versus https. Les fournisseurs comparent le redirect_uri enregistré littéralement à la valeur envoyée dans la requête d'autorisation. Avant de le coller dans Google, Microsoft ou Okta, décomposez-le avec DN01 et vérifiez que schéma, hostname, path et query correspondent caractère par caractère à la liste autorisée. Si l'application construit les callbacks dynamiquement, collez la valeur d'une connexion échouée et comparez origin et URL normalisée à l'enregistrement. Une différence de casse sur hostname est généralement sans effet car DN01 met l'hôte en minuscules ; un paramètre query ou un path inattendu cassera le flux. Ce contrôle est gratuit et évite les allers-retours sur les pages d'erreur du fournisseur.

Les équipes marketing balisent les liens avec des paramètres UTM pour l'attribution. Au fil du temps apparaissent orthographes incohérentes, clés dupliquées ou encodages invisibles dans un tableur. Collez chaque URL de destination dans le séparateur et lisez le tableau de paramètres plutôt que de compter les esperluettes. Vérifiez utm_medium, utm_campaign et utm_content avant une campagne email et détectez les doubles ? lors de concaténations. L'analyse est locale : vous pouvez inspecter des liens non publiés contenant des slugs confidentiels.

Les opérateurs CDN et reverse proxy écrivent clés de cache et règles d'origine à partir des composants URL. Une règle /images/* ne doit pas inclure par erreur des query qui bustent le cache, et le routage par hostname doit distinguer www de l'apex. Décomposer une URL problématique montre si les segments alignent avec l'ordre des règles edge et si le port dans host affecte les environnements de dev. Lors d'une migration de préfixes vers segments, comparer les listes clarifie quels répertoires nécessitent des cartes de redirection.

Le débogage webhook commence souvent par une ligne de log avec l'URL de callback complète. Processeurs de paiement, GitHub et CI affichent l'adresse exacte tentée. Collez l'URL pour séparer le path à enregistrer dans votre routeur des paramètres query inclus ou ignorés par la vérification de signature. Si l'écouteur utilise un port non standard, le champ port confirme si :443 était explicite. C'est plus rapide que de chercher les deux-points dans une longue chaîne HTTPS.

Les SPA placent souvent l'état dans le fragment (#/dashboard?tab=billing) invisible dans les logs serveur. Quand un utilisateur signale « mauvaise page après connexion », décomposez l'URL de la barre d'adresse et inspectez le fragment séparément du path et de la query. Le support peut expliquer si le problème vient du routage serveur ou du routeur client. DN01 documente que le fragment est analysé mais n'apparaîtrait pas dans une ligne d'access log classique.

Les revues sécurité reçoivent parfois des liens suspects avec schémas interdits. DN01 accepte les URL http/https absolues et rejette javascript:, data: et file:, conformément aux pratiques sûres. L'analyste documente schéma et host pour le ticket sans exécuter de code ni fetch. Pour les liens https, extraire le hostname facilite WHOIS ou DNS dans d'autres outils tout en restant structural.

Les API gateways et meshes ajoutent des préfixes path en exposant des services internes. Extérieurement https://public.example.com/payments/v1/charges, intérieurement /v1/charges. Décomposer les deux représentations par segments rend visible le décalage de préfixe avant déploiement des tables de routes en production.

Si l'analyse échoue avec « absolute URL with scheme and host is required », ajoutez https:// (ou http://) avant l'hôte et supprimez les espaces superflus. example.com/path sans schéma n'est pas une URL absolue valide ici. Copiez depuis la barre d'adresse du navigateur si possible.

Les schémas javascript:, data: et file: sont bloqués intentionnellement : ce ne sont pas des navigations web pour redirect ou CDN. Réécrivez en https si vous étudiez une page d'un autre contexte ou retirez les charges exécutables avant analyse.

Si les paramètres semblent vides alors que vous attendiez des valeurs après ?, vérifiez l'encodage. Une séquence percent mal formée empêche l'analyse. Collez l'URL telle qu'elle apparaissait dans le log, l'email ou le JSON, pas une variante partiellement décodée.

Quand host et hostname diffèrent seulement par le port, la règle de routage peut exiger le port explicitement. https omet :443 par défaut ; :3000 affichera un port non vide. L'URL normalisée conserve le port personnalisé.

Les clés query dupliquées apparaissent comme lignes séparées. Certains frameworks ne gardent que la dernière valeur ; d'autres concatènent. Le séparateur montre ce qui est structurellement présent, pas le choix runtime de votre framework.

Le schéma fixe les attentes de transport. Les fournisseurs OAuth exigent https en production ; le dev local peut autoriser http sur localhost. Voir le schéma séparément de l'origin aide pour mixed content et HSTS sans relire le RFC. Pour des schémas non http que d'autres outils parsent, DN01 peut avertir qu'aucun accès réseau n'a eu lieu—http et https sont prioritaires ici.

Séparer host et hostname reflète RFC 3986 et de nombreuses API serveur. SNI TLS utilise hostname ; les sockets écoutent sur le port. Un health check CDN cible hostname:443 tandis qu'un service docker publie host:8080. Les deux champs réduisent la confusion quand « host » désigne informellement le seul nom DNS.

Path et segments couvrent pensée orientée chaîne et REST. Les proxys documentent des préfixes ; le code divise les segments pour l'autorisation. L'encodage percent dans path est la forme sur le fil—comparaison fidèle aux access logs. La liste omet les composants vides des barres initiales ou finales.

Requête brute et parsée comptent différemment pour analytics et signatures. Le marketing veut utm_campaign décodé ; la vérification HMAC peut exiger la sous-chaîne query exacte envoyée. Doublons et valeurs vides sont des cas distincts des clés absentes.

Le fragment est la partie la plus mal comprise. Lors d'un chargement classique le navigateur ne demande que la portion avant # ; le fragment est interprété localement. Changer le fragment ne crée donc pas de nouvelle ligne d'access log. Les flux OAuth implicites historiques renvoyaient des tokens dans le fragment—les revues sécurité doivent l'examiner même si nginx ne le voit pas. DN01 l'affiche pour formation et SPA, pas comme routage serveur.

Origin et URL normalisée soutiennent les comparaisons d'équivalence. Origin est la frontière CORS et de partition du stockage. La normalisation met schéma et host en minuscules selon les règles de l'outil. Utilisez-la pour les listes autorisées mais confirmez si votre IdP attend un path sensible à la casse.

Découper manuellement dans un éditeur convient pour une URL mais scale mal avec de longues query. Un & mal placé ou un = dans du base64 casse les scripts naïfs. DN01 utilise un analyseur URL formel aligné sur net/url de Go.

Le panneau Network de DevTools montre les URL seulement après requête. Pour redirect_uri ou campagnes sous embargo, requêter peut être indésirable. L'analyse locale structure sans effet réseau.

Les one-liners Python ou Node sont flexibles mais peu partageables avec marketing ou support. DN01 présente un tableau cohérent dans votre langue sans installer de runtime.

Les formules tableur peinent avec query encodée et clés dupliquées et cachent le fragment. Le séparateur affiche le fragment sur sa propre ligne.

Les analyseurs en ligne varient dans les composants exposés et fetch parfois la page distante. DN01 est dédié au parsing structurel http/https absolu sans fetch et avec rejet des schémas dangereux.

curl -I ou wget confirment l'accessibilité en mélangeant DNS, TLS et statut HTTP avec la structure URL. Utilisez-les après avoir validé path et query avec DN01.

Lire RFC 3986 apporte de la profondeur mais est lent en incident. DN01 opérationnalise les champs dont les répondeurs ont besoin en tableau.