💾 Archived View for gemlog.lanterne.chilliet.eu › 2020-12-07%20IDN%2C%20IRI%2C%20parlons%20fran%C3%A… captured on 2023-09-08 at 15:58:52. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Une question intéressante de Stephane Bortzmeyer est arrivée sur la ML de gemini Vendredi 4 décembre.
Dans le thread qui en découle, se pose la question épineuse des adresses et liens contenant des caractères Unicode, de leur gestion, de la spécification et du comportement à adopter par les serveurs et les clients.
Il y a (malheureusement) deux questions séparées:
Pour le nom de domaine, il n’est pas possible de se passer complètement d’un encodage alternatif à unicode, puisque le DNS impose l’utilisation de punycode.
Il faut décider de l’encodage ou non en punycode du domaine dans:
Pour le chemin (et la query string), la spécification Gemini précise qu’il est obligatoire d’encoder les espaces comme %20 et renvoit à d’autres RFC pour le reste de la spécification des URI. Naivement j’avais pensé que tout autre charactère Unicode n’avait pas besoin d’être encodé, sauf cas très particulier comme le "/" qui sert de délimiteur de chemin, ou le "?" qui sert de délimiteur de query. En réalité il semble que d’après la spécification actuelle, de part sa référence à la RFC 3986, impose d’encoder derrière un % tout charactère non-ascii, dans le chemin et dans la query. Il est donc mentionné dans la mailing list qu’il faudrait passer aux IRI pour éviter cela. D’après les discussions qui en ont suivi, IRI est un standard complexe à implémenter qui nécessiterai donc forcément l’utilisation d’une bibliothèque externe pour les clients/serveurs gemini, ce qui provoque une levée de bouclier.
À première vue, je ne comprends pas pourquoi cette norme est si complexe (j’imagine que ça a à voir avec les différentes manière que Unicode peut avoir d’encoder un même caractère, ou un caractère qui a la même apparence), et j’ai du mal à comprendre comment justifier de ne pas simplement autoriser l’Unicode dans les liens, requêtes, et query string. Pour mon serveur, j’ai constaté qu’il acceptait l’utf-8 dans la requête sans broncher, alors que je ne l’avais pas pris en compte lors de son écriture. Refuser les requête en unicode me demanderai donc d’ajouter du code, et non pas d’en retirer. Les défenseur du tout-ascii prone des solutions où tout est punycodé/pourcentencodé dans les URI et les liens, quitte à mettre dans les serveurs des trucs qui encodent automatiquement les liens rencontrés, et dans les clients des trucs pour encoder automatiquement depuis la barre d’adresse. Ça me parait à première vue plutôt plus compliqué que de juste autoriser l’utf-8 partout. Je vais lire la RFC sur les IRI dans la journée pour essayer de comprendre les sources de complexité.
Vous pouvez tester comment réagit votre client sur les liens suivants, en utf-8: