Groupe de travail Réseau

L. Masinter, Xerox Corporation

Request for Comments : 2397

août 1998

Catégorie : En cours de normalisation

Traduction Claude Brière de L'Ilse

 

 

Le schéma d'URL "data"

 

Statut de ce mémoire

Le présent document spécifie une proposition de norme de protocole Internet pour la communauté de l'Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l'édition courante de "Normes officielles de protocoles de l'Internet" (STD 1) pour connaître l'état de normalisation et le statut de ce protocole. La distribution du présent mémoire n'est soumise à aucune restriction.

 

Notice de droits d'auteur

Copyright (C) The Internet Society (1998). Tous droits réservés.

 

Résumé

Un nouveau schéma d'URL, "data", est défini. Il permet l'inclusion de petits éléments de données comme données "immédiates", comme si elles avaient été incluses en externe.

 

2.   Description

 

Certaines applications qui utilisent les URL ont aussi besoin d'incorporer directement en ligne de (petites) données de type de support. Le présent document définit un nouveau schéma d'URL qui devrait fonctionner comme un "adressage immédiat". Les URL sont de la forme :

 

data:[<typedesupport>][;base64],<données>

 

Le <typedesupport> est une spécification de type de support Internet (avec des paramètres facultatifs). L'apparition du ";base64" signifie que les données sont codées en base64. Sans ";base64", les données (en tant que séquence d'octets) sont représentées en utilisant le codage ASCII pour les octets à l'intérieur de la gamme des caractères sûrs pour les URL et en utilisant le codage hexadécimal standard %xx des URL pour les octets en dehors de cette gamme. Si <typedesupport> est omis, la valeur par défaut est texte/clair;charset=US-ASCII. En résumé, "text/clair" peut être omis mais le paramètre charset (jeu de caractères) fourni.

 

Le schéma d'URL "data:" n'est utile que pour les valeurs courtes. Noter que certaines applications qui utilisent des URL peuvent imposer une limite de longueur ; par exemple, les URL incorporées au sein d'ancres <A> en HTML ont une limite de longueur déterminée par la déclaration SGML pour HTML [RFC1866]. LITLEN (1024) limite le nombre des caractères qui peuvent apparaître dans un seul littéral de valeur d'attribut, ATTSPLEN (2100) limite la somme de toutes les longueurs de toutes les spécifications de valeur d'attribut qui apparaissent dans une étiquette, et TAGLEN (2100) limite la longueur globale d'une étiquette.

 

Le schéma d'URL "data" n'a pas de forme d'URL relative.

 

3.   Syntaxe

 

dataurl :   = "data:" [ mediatype ] [ ";base64" ] "," données

mediatype :   = [ type "/" sous-type ] *( ";" paramètre )

data :   = *urlchar

parameter :   = attribut "=" valeur

 

où "urlchar" est importé de la [RFC2396], et "type", "sous-type", "attribut" et "valeur" sont les jetons correspondants tirés de la [RFC2045], représentés en utilisant le codage d'URL à échappement de la [RFC2396] en tant que de besoin.

 

Les valeurs d'attribut de la [RFC2045] peuvent être représentées comme jetons ou comme chaînes entre guillemets. Cependant, au sein d'unes URL "data", la représentation "chaîne entre guillemets" serait étrange, dans la mesure ou les guillemets ne sont pas eux-mêmes un caractère d'URL (urlchar) valide. Pour cette raison, les valeurs de paramètre devraient utiliser le codage d'URL à échappement plutôt que la chaîne codée si les valeurs de paramètre contienne des "tspecial".

 

L'extension ";base64" se distingue d'un paramètre Type de contenu par le fait qu'elle n'a pas de signe "=" à la suite.

 

4.   Exemples

 

Une URL data pourrait être utilisée pour des types de données arbitraires. L'URL data:,A%20brief%20note code la chaîne de texte en clair "A brief note", qui peut être utile dans un lien de note de base de page.

 

Le fragment HTML :

<IMG

SRC="data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAwAAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFzByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSpa/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJlZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uisF81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PHhhx4dbgYKAAA7"

ALT="Larry">

pourrait être utilisé pour une petite image en ligne dans un document HTML. (L'image incorporée est probablement proche de la limite utilisable. Pour tout ce qui est plus grand, les URL data sont vraisemblablement inappropriées.)

 

Une spécification de type de support d'URL data peut inclure d'autres paramètres ; par exemple, on peut spécifier un paramètre charset : data:text/plain;charset=iso-8859-7,%be%fg%be peut être utilisé pour une brève séquence de caractères grecs.

 

Certaines applications peuvent utiliser le schéma d'URL "data" afin de fournir des paramètres d'établissement pour d'autres sortes d'applications de réseautage. Par exemple, on peut créer un type de support application/vnd-xxx-query dont le contenu consiste en une chaîne d'interrogation et un identifiant de base de données pour les bases de données du fabricant "xxx". Une URL de la forme : data:application/vnd-xxx-query,select_vcount,fcol_from_fieldtable/local pourrait alors être utilisée dans une application locale pour lancer "l'aide" pour application/vnd-xxx-query et lui donner les données immédiates incluses.

 

5.   Historique

 

Cette idée a été à l'origine proposée en août 1995. Certaines versions du schéma d'URL data ont été utilisées dans la définition de VRML, et une version est apparue au titre d'une proposition de données incorporées dans HTML.

 

Divers changements ont été faits, sur la base de demandes, pour élider le type de support, encadrer plus étroitement l'indication du codage en base64, et éliminer "quoted printable" comme codage car il ne donnerait pas facilement d'URL valides sans codage %xx supplémentaire, qui est suffisant par lui-même. Le schéma d'URL "data" est utilisé dans VRML, de nouvelles applications de HTML, et divers produits commerciaux. Il est utilisé pour les paramètres d'objets dans Java et des applications ActiveX.

 

6.   Sécurité

 

L'interprétation des données au sein d'une URL "data" ont les mêmes considérations pour la sécurité que toute mise en œuvre du type de support en question. Une application ne devrait pas interpréter le contenu d'une URL data qui est marquée avec un type de support dont la configuration d'application n'autorise pas le traitement.

 

Les sites qui utilisent des mandataires de pare-feu pour interdire la restitution de certains types de supports (comme des langages d'écriture d'application ou des types posant des problèmes de sécurité connus) trouveront difficile d'empêcher l'affichage à l'écran de tels types qui utilisent le schéma d'URL "data". Cependant, il devraient être conscients de la menace et prendre toutes précautions qui pourraient être considérées comme nécessaires au sein de leur domaine.

 

Les effets de l'utilisation d'URL "data" longues dans les applications n'est pas actuellement connu ; certains paquetages de logiciels pourraient afficher des comportements déraisonnables lorsqu'ils seront confrontés à des données qui excèdent la taille allouée à leur mémoire tampon.

 

7.   Références

 

[RFC2396]   T. Berners-Lee, R. Fielding et L. Masinter, "Identifiants de ressource uniformes (URI) : Syntaxe générique", août 1998.

 

[RFC1866]   T. Berners-Lee, D. Connolly, "Langage de balisage Hypertext - 2.0", novembre 1995. (Obsolète, voirRFC2854)

 

[RFC2045]   N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 1 : Format des corps de message Internet", novembre 1996.

 

Informations pour contacter l'auteur :

 

Larry Masinter

Xerox Palo Alto Research Center

3333 Coyote Hill Road

Palo Alto, CA 94304

mél : masinter@parc.xerox.com

 

Déclaration complète de droits de reproduction

 

Copyright (C) The Internet Society (1998). Tous droits réservés.

 

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les copyrights définis dans les processus de normes pour Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

 

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.

 

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et L'INTERNET SOCIETY ET L'INTERNET ENGINEERING TASK FORCE DÉCLINE TOUTE GARANTIE, EXPRESSE OU IMPLICITE, Y COMPRIS MAIS SANS S'Y LIMITER, TOUTE GARANTIE QUE L'UTILISATION DE L'INFORMATION ICI PRÉSENTE N'ENFREINDRA AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D'ADAPTATION A UN OBJET PARTICULIER.