Chaîne de requête

Une chaîne de requête fait partie d’un Localisateur de ressources uniforme (URL) qui attribue des valeurs aux paramètres spécifiés. Une chaîne de requête comprend généralement des champs ajoutés à une URL de base par un navigateur Web ou une autre application cliente, par exemple dans le cadre d’un code HTML, en choisissant l’apparence d’une page ou en sautant vers des positions dans le contenu multimédia. ^{[1] [2] [3]}

Une barre d’adresse sur Google Chrome affichant une URL avec la chaîne de requête title=Query_string&action=edit.

Un serveur Web peut gérer une Requête HTTP ( Hypertext Transfer Protocol ) soit en lisant un fichier à partir de son système de fichiers en fonction du chemin de l’ URL , soit en gérant la requête à l’aide d’une logique spécifique au type de ressource. Dans les cas où une logique spéciale est invoquée, la chaîne de requête sera disponible pour cette logique pour être utilisée dans son traitement, avec le composant de chemin de l’URL.

Structure

L’URL type 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, 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. ^{[4] [5]}

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. ^[6] Dans l’exemple d’URL ci-dessous, plusieurs paramètres de requête sont séparés par l’ esperluette ” &” :

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 avoir 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’ <form>…</form>élément
• une image cliquable côté serveur via l’ ismapattribut sur l’ <img>élément avec une <img ismap>construction
• une recherche indexée via l’ <isindex>élément désormais obsolète

Formulaires Web

L’une des utilisations initiales était de contenir le contenu d’un formulaire HTML , également appelé formulaire Web. En particulier, lorsqu’un formulaire contenant les champs field1, field2, field3est soumis, le contenu des champs est encodé sous forme de chaîne de requête comme suit :

field1=value1&field2=value2&field3=value3…

• La chaîne de requête est composée d’une série de paires champ-valeur.
• Dans chaque paire, le nom et la valeur du champ sont séparés par un signe égal ” =”.
• La série de paires est séparée par l’ esperluette , ” &” (ou le point- virgule , ” ;” pour les URL incorporées dans HTML et non générées par un <form>…</form>. Voir ci-dessous).

Bien qu’il n’existe pas de norme définitive, la plupart des frameworks Web permettent d’associer plusieurs valeurs à un seul champ (par exemple field1=value1&field1=value2&field2=value3). ^{[7] [8]}

Pour chaque champ du formulaire, la chaîne de requête contient une paire . Les formulaires Web peuvent inclure des champs qui ne sont pas visibles pour l’utilisateur ; ces champs sont inclus dans la chaîne de requête lorsque le formulaire est soumis.field=value

Cette convention est une recommandation du W3C . ^[6] Le W3C recommande que tous les serveurs Web prennent en charge les séparateurs point-virgule en plus des séparateurs esperluette ^[9] pour autoriser les chaînes de requête codées application/x-www-form-urlen dans les URL des documents HTML sans avoir à échapper les esperluettes.

Le contenu du formulaire est uniquement encodé dans la chaîne de requête de l’URL lorsque la méthode de soumission du formulaire est GET . Le même encodage est utilisé par défaut lorsque la méthode de soumission est POST , mais le résultat est soumis en tant que corps de Requête HTTP plutôt que d’être inclus dans une URL modifiée. ^[1]

Recherche indexée

Avant que les formulaires ne soient ajoutés au HTML, les navigateurs rendaient l’ <isindex>élément sous la forme d’un contrôle de saisie de texte sur une seule ligne. Le texte entré dans ce contrôle a été envoyé au serveur en tant qu’ajout de chaîne de requête à une requête GET pour l’URL de base ou une autre URL spécifiée par l’ actionattribut. ^[10] Cela visait à permettre aux serveurs Web d’utiliser le texte fourni comme critère de requête afin qu’ils puissent renvoyer une liste de pages correspondantes. ^[11]

Lorsque le texte entré dans le contrôle de recherche indexé est soumis, il est encodé comme une chaîne de requête comme suit :

argument1+argument2+argument3…

• La chaîne de requête est composée d’une série d’arguments en analysant le texte en mots au niveau des espaces.
• La série est séparée par le Signe plus , ‘ +’.

Bien que l’ <isindex>élément soit obsolète et que la plupart des navigateurs ne le prennent plus en charge ou ne le rendent plus, il existe encore des vestiges de recherche indexée. Par exemple, c’est la source de la gestion spéciale du Signe plus , ‘ +’ dans le codage en pourcentage de l’URL du navigateur (qui aujourd’hui, avec la dépréciation de la recherche indexée, est presque redondant avec %20). De plus, certains serveurs Web prenant en charge CGI (par exemple, Apache ) traiteront la chaîne de requête en arguments de ligne de commande si elle ne contient pas de signe égal , ‘ =’ (conformément à la section 4.4 de CGI 1.1). Certains scripts CGI dépendent et utilisent encore ce comportement historique pour les URL intégrées dans HTML.

Encodage d’URL

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 =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″. ^[12]

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 ^[13]
• L’ESPACE est codé comme ‘ +’ ou ‘ %20’
• Les lettres ( A– Zet a– z), les 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 forme de représentation %HH hexadécimale 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 tant que ‘ +’ et la sélection de caractères “tels quels” distinguent cet encodage de la RFC 3986.

Exemple

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 = “soumettre” /> </ formulaire >

et l’utilisateur insère les chaînes “ceci est un champ” et “était-ce clair (déjà) ?” dans les deux champs de texte et appuie sur le bouton Soumettre, le programme test.cgi(le programme spécifié par l’ action attribut de l’ form élément 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

Suivi

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” > voir ma page ! </ a > < a href = “bar.html” > le mien est meilleur </ a >

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

< a href = “foo.html?e0a72cb2a2c7” > voir ma page ! </ a > < a href = “bar.html?e0a72cb2a2c7” > le mien est meilleur </ 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?e0a72cb2a2c7au serveur, qui ignore ce qui suit ?et envoie la page foo.htmlcomme 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 balises Web .

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.

Problèmes de compatibilité

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. ^[14]

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 de 128 Ko sur IIS 5.0. La limite est configurable sur Apache2 à l’aide de la LimitRequestBodydirective, qui spécifie le nombre d’octets de 0 (c’est-à-dire illimité) à 2147483647 (2 Go) autorisés dans un corps de requête. ^[15]

Voir également

• 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

Références

1. ^ ^{a b c} [1] , HTML5.2, recommandation du W3C, 14 décembre 2017
2. ^ 4 façons différentes d’ajouter des horodatages sur YouTube
3. ^ Paramètres de index.php – MediaWiki
4. ^ T. Berners-Lee; R. Fielding; L. Masinter (janvier 2005). “RFC3986” . “Composants de syntaxe” (section 3).
5. ^ T. Berners-Lee; R. Fielding; L. Masinter (janvier 2005). “RFC3986” . “Requête” (section 3.4).
6. ^ ^{a b} Formulaires dans les documents HTML . W3.org. Consulté le 2013-09-08.
7. ^ “ServletRequest (Java EE 6)” . docs.oracle.com . 2011-02-10 . Récupéré le 08/09/2013 .
8. ^ “uri – Position faisant autorité des clés de Requête HTTP GET en double” . Débordement de pile . 2013-06-09 . Récupéré le 08/09/2013 .
9. ^ Performances, implémentation et notes de conception . W3.org. Consulté le 2013-09-08.
10. ^ “<isindex>” . HTML (langage de balisage hypertexte) .
11. ^ “HTML/Éléments/isindex” . Wiki du W3C .
12. ^ “Référence de codage d’URL HTML” . W3Schools . Consulté le 1er mai 2013 .
13. ^ L’ algorithme d’encodage Application/x-www-form-urlencoded , HTML5.2, recommandation W3C, 14 décembre 2017
14. ^ Syntaxe et routage des messages HTTP/1.1 . ietf.org. Consulté le 2014-07-31.
15. ^ noyau – Serveur HTTP Apache . httpd.apache.org. Consulté le 2013-09-08.