Analyser un query string

Rien dans la spécification ne dit qu’un nom de paramètre ne peut apparaître qu’une fois, et beaucoup de systèmes s’appuient dessus : `?tag=a&tag=b` est la façon dont arrive une sélection multiple, et dont la plupart des bibliothèques de formulaires sérialisent une liste de cases à cocher. La lecture correcte est une liste de paires.

L’implémentation évidente range cela dans un objet, et un objet ne peut pas contenir deux fois la même clé — l’une des deux valeurs est donc perdue en silence, et laquelle dépend du fait que le code garde la première ou la dernière. C’est un défaut qu’on découvre bien plus tard, quand un filtre s’applique mystérieusement à une étiquette sur deux. Cette page affiche les deux.

Un query string est en général du `application/x-www-form-urlencoded`, c’est-à-dire le format dans lequel un formulaire HTML poste — et dans ce format une espace s’écrit `+`. L’encodage-pourcent simple n’a pas cette règle, donc dans un chemin un `+` est simplement un caractère plus.

Cette page emploie la lecture du format de formulaire, parce que c’est ce qu’un query string est presque toujours. La conséquence à surveiller est une valeur qui contient un vrai plus : un numéro de téléphone au format international `+33`, une recherche sur `C++`, un segment de Base64. Ceux-là doivent arriver en `%2B` sinon ils seront lus comme des espaces, et si vous les générez le problème est du côté de l’encodage.

Les cibles de redirection, les callbacks, les paramètres `next` et `retour_a` transportent tous une URL entière comme valeur. Elle doit être encodée, donc ses propres `?`, `&` et `=` deviennent des séquences de pourcentage, et le résultat est illisible d’un coup d’œil et facile à tronquer à l’œil.

Décoder une ligne la restitue intacte, avec son propre query string. Si cette URL intérieure porte des paramètres que vous devez lire aussi, recollez-la ici — cette page extrait la partie query d’une adresse entière, donc une chaîne de redirection à deux niveaux demande deux passages et aucun traitement particulier.

Les cinq paramètres UTM — source, medium, campaign, term et content — sont une convention plutôt qu’une norme, ce qui explique qu’ils soient si souvent incohérents : la casse varie, les noms de campagne arrivent avec des espaces encodées de trois façons différentes, et un lien d’une série porte une faute de frappe que les autres n’ont pas.

Les voir sous forme de liste est ce qui rend cela visible. Deux liens qui paraissent identiques dans un courriel diffèrent fréquemment sur un paramètre, et une campagne dont les chiffres semblent étranges a d’ordinaire été étiquetée de façon incohérente plutôt que mal suivie.

Un query string est journalisé. Il est dans le journal d’accès de chaque serveur et de chaque intermédiaire traversé, dans l’historique du navigateur, dans l’en-tête de référent envoyé au site suivant, et souvent dans une charge de mesure d’audience. Rien en lui n’est éphémère.

Un token, un code de réinitialisation de mot de passe, un identifiant de session ou une adresse électronique placés dans un query string ont donc été enregistrés à plusieurs endroits que personne n’avait prévus. Cela arrive constamment — les liens de réinitialisation en sont le cas classique — et regarder un query string décomposé est fréquemment la façon dont quelqu’un s’en aperçoit.

Un nom de campagne français — `soldes_d_été`, `rentrée-2026` — est encodé caractère par caractère, et chaque accent devient deux séquences de pourcentage. La valeur triple presque de longueur et devient illisible dans le lien, ce qui est correct et sans conséquence tant que l’encodage a été fait une seule fois.

Le problème apparaît quand deux outils encodent différemment le même nom : l’un produit `%C3%A9`, l’autre `%E9` parce qu’il travaille encore en Latin-1, et un troisième remplace l’accent par la lettre nue. Vos statistiques comptent alors trois campagnes là où il y en a une. C’est la raison pratique pour laquelle les noms de campagne sont souvent écrits sans accents.

Un query string peut contenir `?debug` sans signe égal, ce qui donne un paramètre dont la valeur est une chaîne vide. Il peut aussi contenir `?=valeur`, un paramètre sans nom, qui est syntaxiquement légal et presque toujours accidentel.

Les deux sont affichés tels quels ici plutôt qu’écartés, parce que la différence entre « absent », « présent et vide » et « présent avec une valeur » est réelle et que beaucoup de systèmes la traitent différemment. Un drapeau qui ne fonctionne pas est souvent un drapeau que quelque chose en amont a transformé de l’un de ces états vers un autre.

Aucune spécification ne donne de sens à l’ordre des paramètres, et deux liens qui ne diffèrent que par l’ordre désignent la même ressource. Cette page conserve pourtant l’ordre d’arrivée, parce qu’il est parfois le seul indice sur le système qui a construit le lien.

L’exception est la signature de requêtes : OAuth 1.0 et AWS SigV4 exigent un ordre canonique avant de calculer l’empreinte, précisément parce que l’ordre n’a pas de sens et qu’il faut donc en imposer un. Si une requête signée échoue sans raison apparente, l’ordre des paramètres est la deuxième chose à vérifier après l’échappement.

Les liens de campagne s’allongent vite : cinq paramètres UTM, un identifiant de clic, un identifiant de session et une cible de redirection encodée dépassent facilement mille caractères. Les serveurs plafonnent couramment la ligne de requête autour de huit kilooctets, et certains intermédiaires bien avant.

Le symptôme est un lien qui fonctionne partout sauf chez un annonceur, ou qui fonctionne jusqu’au jour où un paramètre s’ajoute. Décomposer le query string montre immédiatement lequel des paramètres pèse le plus, et c’est presque toujours la cible de redirection encodée deux fois.