CPU ⬜ Carré Petit Utile

Extrait de l'émission CPU release Ex0214 : Disséquons une URL, seconde partie.

Après le protocole, l'autorité, le chemin et le fichier, l'URL n'est pas terminée : on passe aux paramètres.

Lors de sa conception, le principe d'URL ne parle pas uniquement de la ressource, le document que l'on veut récupérer, mais aussi des dialogues avec ce fichier, qui peut être un programme actif.

J'avais déjà rapidement abordé le principe des paramètres, c'était dans le chemin de fichiers pour une fonction totalement… oubliable.
On va voir qu'il y a deux catégories de paramètres :

• ceux qui s'adressent au serveur où vous faites votre requête,
• ceux qui s'adressent au logiciel client avec lequel vous affichez le résultat de votre requête.

À noter que désormais, ces rôles ont tendance à remonter dans le chemin de fichiers, aussi bien pour les paramètres serveurs depuis une vingtaine d'années que les paramètres navigateurs depuis 5 ans, grâce aux boites à outils des single page applications, des applications javascripts côté navigateur. Mais ce dernier cas est extrêmement particulier, car il ne peut fonctionner hors du contexte d'un client ultra spécifique, ce qui trahit un peu l'intention universelle de l'URL.
On va parler du fonctionnement intentionnel de la norme, dans son mode natif.

Dans l'URL, après le chemin, le nom de fichier et après le symbole ?, suit le query, la requête, ou plus humainement, la question, qui indique au serveur les paramètres de la ressource qu'on demande. Ces paramètres s'adressent d'abord au serveur à qui vous envoyez l'URL.

Oui, dans une URL, le query se trouve après le ?, alors que… c'est une question… Tim Berners Lee, l'inventeur du web, devait somnoler en espagnol LV2.

¡ Ayayaya ! ¿ Te quiero la puntuación, muchacho ?
[dit dans un espagnol très très approximatif]

Le query exprime une demande. À l'origine d'ailleurs, cette requête était construite à partir d'un formulaire qu'on dit alors en mode GET, c'est-à-dire que les données entrées dans le formulaire sont renvoyées au serveur dans l'URL.
Ces données se présentent en général par des paires de mots-clés associés à des valeurs. Regardez la barre d'adresse de votre navigateur web, vous verrez souvent après le point d'interrogation des motifs clé=valeur avec des & en guise de séparateurs.

(oui, je dis esperluette, mais on dit parfois un et commercial et en anglais ampersand. Regardez bien, si si, ce symbole, qui est sur la touche du 1 représente le mot et français).

L'usage de la notation clé=valeur n'est que conventionnelle, de même que le séparateur &. Par exemple, sur certains serveurs, le séparateur dans le query peut être un ;. J'ai aussi vu des deux points à la place du signe =… Sauf que la notation clé=valeur et l'usage d'une esperluette en séparateur furent popularisés par les navigateurs web qui les utilisent nativement. C'est à dire que si vous construisez dans une page HTML un formulaire en mode GET avec quelques champs de données, un navigateur restituera toujours ces données dans la query avec les symboles = et &. Faire autrement marchera tant que vous ne mettez aucun formulaire dans vos pages.

Et en fait, pour votre navigateur, la notation n'est pas clé=valeur mais clé=valeur1,valeur2. C'est à dire que si le serveur web est bien fichu, il peut accepter plusieurs valeurs à la fois pour une même clé, pour construire un groupe de valeurs, une liste, ou un tableau. Quand je dis que c'est la notation préférée de votre navigateur, c'est qu'on la retrouve sur un formulaire en mode GET avec des valeurs multiples ou avec une image ismap.
Mettre dans un lien une image avec un attribut ismap est une vieille stratégie pour rendre une image cliquable avec plusieurs zones complexes menant à différentes destinations, comme par exemple une carte de France découpée en départements, ou un plan interactif des boutons d'acnée de votre petit neveu. Comme c'est une pratique du web du précédent millénaire, sa mise en place est assez primitive : Le navigateur ne connaît pas où mène chaque zone active, c'est le serveur qui l'interprète.

En gros, si vous cliquez sur une telle image, dans l'URL que vous suivrez, vous trouverez après le point d'interrogation deux valeurs numériques, pour les coordonnées X,Y où vous aurez cliqué, donc deux valeurs séparées par une virgule, oui, la clé est alors implicite. Cette notation n'a rien d'obsolète, elle existe toujours pour les navigateurs avec des applications plus récentes, par exemple sur un champ multiple d'e-mails <input type=email required multiple>.

Exemple

[C'est compliqué à expliquer à la radio mais puisque vous êtes sur la page web de cette chronique, voici un exemple à tester. Le champ ci-dessous n'accepte que les adresses e-mail, mais on peut en mettre plusieurs, séparés par des espaces. Avez-vous noté que les espaces sont tolérés près de la virgule, mais supprimés à l'envoi ? À noter que nous vous renvoyons sur votre adresse locale afin de ne pas stocker par erreur une adresse e-mail. Une fois envoyé, admirez la fin de l'URL et faites retour arrière pour revenir ici]

Suite de la chronique

Encore une fois, la syntaxe sur l'envoi de données listées, de tableaux de valeurs associés à une même clé, n'est que conventionnelle. Le standard de l'URL la décrit, mais ne donne qu'une suggestion d'usage. D'autres construiront les tableaux de valeurs différemment : Par exemple, le langage PHP, pour une liste (un array) attend un montage du type clé[]=valeur1&clé[]=valeur2.
Je développe du PHP depuis 25 ans, cette construction fonctionne parfaitement, même si sincèrement, cette notation me frustre un petit peu car elle tue l'unicité d'usage d'une clé. Mais bon,… ça passe, et entre les crochets on peut préciser l'index du tableau pour la valeur donnée, voire cumuler des crochets pour construire un tableau multidimensionnel.

[Suite : Histoire : Et Altavista montra son q=]

Interview : Da Scritch
Illustration : Requête Dall-E A sharp symbol and a question mark symbols floatting in a library, libéré en CC.