Chaîne de requête

Une URL typique contenant une chaîne de requête est la suivante :

« https://example.com/over/there?name=ferret »

Lorsqu'un serveur reçoit une demande pour une telle page, il peut exécuter un programme, en transmettant la chaîne de requête, qui dans ce cas est name=ferret, inchangée au programme. Le point d'interrogation est utilisé comme séparateur et ne fait pas partie de la chaîne de requête[5] - [6].

Les frameworks Web peuvent fournir des méthodes pour analyser plusieurs paramètres dans la chaîne de requête, séparés par un délimiteur[7], en général l'esperluette, " & ", comme dans l'exemple d'URL ci-dessous :

« https://example.com/path/to/page?name=ferret&color=purple »

La structure exacte de la chaîne de requête n'est pas normalisée. Les méthodes utilisées pour analyser la chaîne de requête peuvent différer d'un site Web à l'autre.

Un lien dans une page Web peut pointer vers une URL qui contient une chaîne de requête. HTML définit trois manières pour un agent utilisateur de générer la chaîne de requête :

• un formulaire HTML via l'élément <form> ... </form>​
• une image cliquable côté serveur via l'attribut ismap​ sur l'élément <img ismap>​
• une recherche indexée via l'élément désormais obsolète <isindex>​

Certains caractères ne peuvent pas faire partie d'une URL (par exemple, l'espace) et certains autres caractères ont une signification particulière dans une URL : par exemple, le caractère # peut être utilisé pour spécifier davantage une sous-section (ou un fragment) d'un document. Dans les formulaires HTML, le caractère égal '=' est utilisé pour séparer un nom d'une valeur. La syntaxe générique d'URI utilise le codage d'URL pour traiter ce problème, tandis que les formulaires HTML effectuent des substitutions supplémentaires plutôt que d'appliquer un codage en pourcentage pour tous ces caractères. L'ESPACE est codé comme '+' ou "%20"[14].

HTML 5 spécifie la transformation suivante pour soumettre des formulaires HTML avec la méthode "GET" à un serveur Web[1]. Voici un bref résumé de l'algorithme :

• Les caractères qui ne peuvent pas être convertis dans le jeu de caractères correct sont remplacés par des références de caractères numériques HTML[15]
• L'ESPACE est codé comme '+' ou '%20'
• Lettres (A – Z et a – z), chiffres (0 – 9) et les caractères ' ~ ',' - ',' . ' et ' _ ' sont laissés tels quels
• + est encodé par %2B
• Tous les autres caractères sont encodés sous la forme d'une représentation hexadécimale %HH avec tous les caractères non ASCII encodés d'abord en UTF-8 (ou tout autre encodage spécifié)

L'octet correspondant au tilde (" ~ ") est autorisé dans les chaînes de requête par RFC3986 mais doit être codé en pourcentage dans les formulaires HTML en " %7E ".

L'encodage de SPACE en '+' et la sélection de caractères "tels quels" distinguent cet encodage de [rfc:3986 la RFC 3986].

Si un formulaire est intégré dans une page HTML comme suit :

<form action="/cgi-bin/test.cgi" method="get">
 <input type="text" name="first" />
 <input type="text" name="second" />
 <input type="submit" />
</form>

et l'utilisateur insère les chaînes "this is a field" et "was it clear (already)?" dans les deux champs de texte et appuie sur le bouton d'envoi, le programme test.cgi (le programme spécifié par l' attribut action de l'élément form dans l'exemple ci-dessus) recevra la chaîne de requête suivante : first=this+is+a+field & second=was+it+clear+%28already%29%3F .

Si le formulaire est traité sur le serveur par un script CGI, le script peut généralement recevoir la chaîne de requête sous la forme d'une variable d'environnement nommée QUERY_STRING.

Un programme recevant une chaîne de requête peut en ignorer une partie ou la totalité. Si l'URL demandée correspond à un fichier et non à un programme, toute la chaîne de requête est ignorée. Cependant, que la chaîne de requête soit utilisée ou non, l'intégralité de l'URL, y compris celle-ci, est stockée dans les fichiers journaux du serveur.

Ces faits permettent aux chaînes de requête d'être utilisées pour suivre les utilisateurs d'une manière similaire à celle fournie par les cookies HTTP. Pour que cela fonctionne, chaque fois que l'utilisateur télécharge une page, un identifiant unique doit être choisi et ajouté en tant que chaîne de requête aux URL de tous les liens que la page contient. Dès que l'utilisateur suit un de ces liens, l'URL correspondante est demandée au serveur. Ainsi, le téléchargement de cette page est lié à la précédente.

Par exemple, lorsqu'une page Web contenant les éléments suivants est demandée :

 <a href="foo.html">see my page!</a>
 <a href="bar.html">mine is better</a>

une chaîne unique, telle que e0a72cb2a2c7 est choisie, et la page est modifiée comme suit :

 <a href="foo.html?e0a72cb2a2c7">see my page!</a>
 <a href="bar.html?e0a72cb2a2c7">mine is better</a>

L'ajout de la chaîne de requête ne modifie pas la façon dont la page est présentée à l'utilisateur. Lorsque l'utilisateur suit, par exemple, le premier lien, le navigateur demande la page foo.html?e0a72cb2a2c7 au serveur, qui ignore ce qui suit le ? et envoie la page foo.html comme prévu, en ajoutant également la chaîne de requête à ses liens.

Ainsi, toute demande de page ultérieure de cet utilisateur portera la même chaîne de requête e0a72cb2a2c7, permettant d'établir que toutes ces pages ont été consultées par le même utilisateur. Les chaînes de requête sont souvent utilisées en association avec des pixels espion.

Les principales différences entre les chaînes de requête utilisées pour le suivi et les cookies HTTP sont les suivantes :

1. Les chaînes de requête font partie de l'URL et sont donc incluses si l'utilisateur enregistre ou envoie l'URL à un autre utilisateur ; les cookies peuvent être conservés d'une session de navigation à l'autre, mais ne sont ni enregistrés ni envoyés avec l'URL.
2. Si l'utilisateur arrive sur le même serveur Web par deux (ou plusieurs) chemins indépendants, deux chaînes de requête différentes lui seront attribuées, tandis que les cookies stockés sont les mêmes.
3. L'utilisateur peut désactiver les cookies, auquel cas l'utilisation de cookies pour le suivi ne fonctionne pas. Cependant, l'utilisation de chaînes de requête pour le suivi devrait fonctionner dans toutes les situations.
4. Différentes chaînes de requête transmises par différentes visites sur la page signifient que les pages ne sont jamais servies à partir du cache du navigateur (ou du proxy, le cas échéant), augmentant ainsi la charge sur le serveur Web et ralentissant l'expérience utilisateur.
5. Les chaînes de requêtes sont visibles explicitement dans la barre d'adresse du navigateur et l'utilisateur peut les voir.

Selon la spécification HTTP :

Diverses limitations ad hoc sur la longueur de la ligne de demande sont trouvées dans la pratique. Il est RECOMMANDÉ que tous les expéditeurs et destinataires HTTP prennent en charge, au minimum, des longueurs de ligne de demande de 8000 octets[16].

Si l'URL est trop longue, le serveur Web échoue avec le code d'état HTTP 414 Request-URI Too Long.

La solution de contournement courante pour ces problèmes consiste à utiliser POST au lieu de GET et à stocker les paramètres dans le corps de la requête. Les limites de longueur des corps de requête sont généralement beaucoup plus élevées que celles de la longueur des URL. Par exemple, la limite de taille POST, par défaut, est de 2 Mo sur IIS 4.0 et 128 Ko sur IIS 5.0. La limite est configurable sur Apache 2 à l'aide de la directive LimitRequestBody, qui spécifie le nombre d'octets de 0 (c'est-à-dire illimité) à 2147483647 (2 Go) qui sont autorisés dans un corps de requête[17].

• Nettoyer l'URL
• Identifiant du clic
• Interface de passerelle commune (CGI)
• Cookie HTTP
• Protocole de transfert hypertexte (HTTP)
• URL sémantiques
• Schéma d'URI
• Paramètres UTM
• Balise Web