Résumé

  • La RFC 2397 définit data: pour de petites données « immédiates », avec un type de média facultatif, un marqueur ;base64 facultatif et une virgule séparant la déclaration des données.
  • Quand les octets voyagent dans l’URL, le point de décision n’est plus le chemin de récupération distant, mais le lecteur local, sa politique de type de média et ses limites de mémoire.

Une URL ordinaire promet un déplacement : le client lit une adresse, contacte un système extérieur et reçoit une représentation. La RFC 2397 raccourcit ce parcours. Dans data:[<mediatype>][;base64],<data>, la chaîne qui indique normalement où aller apporte aussi ce qui doit être lu.

Le texte parle d’« adressage immédiat ». Il n’existe pas de petit serveur derrière la virgule. Pour l’élément incorporé, le consommateur sépare la déclaration de la charge, reconstruit les octets et les interprète selon le type de média. Le pointeur et sa cargaison forment une seule entrée sérialisée.

Les omissions sont précisément définies. Sans type de média, la valeur par défaut est text/plain;charset=US-ASCII; text/plain peut rester implicite alors qu’un charset est indiqué. ;base64, dépourvu de signe égal, sélectionne base64 et se distingue ainsi d’un paramètre Content-Type. Sinon, les caractères URL sûrs représentent directement leurs octets et les autres passent par %xx. Base64 ne chiffre rien, n’authentifie rien et n’accorde aucun droit.

Le schéma ne possède aucune forme relative. Une référence relative emprunte une base à son contexte; data: fournit déjà le type et les données. Cette frontière le sépare de la mécanique des URL relatives : l’une hérite d’une adresse, l’autre transporte son contenu.

La RFC insiste sur la petitesse. Elle cite les contraintes SGML de HTML 2.0 : 1 024 caractères pour une valeur d’attribut, 2 100 pour l’ensemble des valeurs d’un élément et 2 100 pour l’élément entier. Même son petit GIF est présenté comme proche de la limite utile. Ces nombres ne sont pas une capacité universelle de data:. Ils montrent qu’une chaîne autorisée par une syntaxe peut dépasser le conteneur, l’allocation ou l’implémentation qui l’accueille.

La section sécurité rend le déplacement du contrôle explicite. Un proxy pare-feu sait refuser la récupération externe d’un type interdit. Il lui est plus difficile de filtrer par le même chemin un contenu déjà inclus dans une URL. La RFC confie donc la décision à l’application : elle ne devrait pas interpréter un type que sa configuration interdit. Le véritable verrou appartient au composant qui transforme des octets en comportement.

Le document signalait aussi que l’effet des URL très longues restait inconnu et qu’un logiciel pouvait réagir déraisonnablement au-delà de son tampon alloué. Deux questions demeurent donc distinctes : ce type est-il autorisé, et cette taille peut-elle être traitée sans danger ? L’absence de récupération pour l’objet incorporé ne répond à aucune des deux.

L’idée remontait à août 1995. Le texte mentionne VRML, les propositions d’incorporation dans HTML, des produits commerciaux et des paramètres d’objets Java ou ActiveX. La forme avait été resserrée : type de média élidable, indicateur base64 plus compact, disparition de quoted-printable puisque %xx suffisait déjà.

Les errata ultérieurs exigent la même précision. Deux corrections Verified remplacent l’impossible %fg et substituent uric au urlchar non défini de la RFC 2396. Les ambiguïtés concernant les paramètres cités et les délimiteurs restent Reported ou Held for Document Update : ce ne sont pas des textes normatifs approuvés. La proposition de remplacer partout « URL » par « URI » a été Rejected, car le vocabulaire original était historiquement correct.

La leçon de la RFC 2397 porte donc moins sur une notation que sur l’autorité opérationnelle. Supprimer un intermédiaire ne supprime pas le contrôle. Il le concentre dans le logiciel qui découpe, décode, interprète et autorise. Plus le chemin est court, plus cette frontière locale doit être visible.

Sources