Négociation de contenu et portabilité multimédia
Besoins
- Les animations vidéo ou les fichiers de son sont souvent dans un format qui est propre à une plateforme spécifique (le standard MPEG, aussi bien audio que vidéo, n'est de loin pas encore assez répandu)
- Même s'il existe des logiciels de conversion de format pour la plupart des plateformes, il n'est pas du tout certain que le visiteur d'un site aura installé le logiciel permettant d'utiliser les fichiers audio ou vidéo du site.
- Si le fournisseur dispose de ces programmes de conversion, il peut préparer à l'avance des versions pour différentes plateformes.
- Pour que le mécanisme décrit ci-dessous fonctionne, il faut que le programme de visualisation envoie au serveur la liste détaillée des types de documents qu'il est capable de traiter. En l'absence de cette information, le mécanisme que vous mettrez en place ne pourra pas déterminer quel format envoyer. (si vous voulez voir ce que votre programme de visualisation fournit comme information dans le header HTTP-ACCEPT, utilisez ce script. Pour voir l'ensemble des variables d'environnement définies par le serveur à la réception d'une requête, utilisez cet autre script).
Réalisation par script CGI
-
Le mécanisme à utiliser sera le suivant:
- mettre toutes les différentes versions d'un même document audio ou vidéo dans le même répertoire, sous le même nom de fichier, en ne faisant varier que l'extension (qui permettra de déterminer le format du fichier)
- utiliser des URLs qui invoqueront un script cgi-bin et qui contiennent, à la suite du nom du script, le chemin d'accès au fichier sans l'extension. Exemple: si vous avez un document audio accessible aux URLs http://UnServeur/UnChemin/FichierAudio.xxx, vous utiliserez en fait une URL du type http://UnServeur/cgi-bin/snd/UnChemin/FichierAudio (où snd est le nom du script qui déterminera quelle version envoyer)
- installer un script équivalent à snd dans le répertoire cgi-bin de votre serveur (ce script devrait prévoir d'envoyer par défaut le format que vous pensez être le plus répandu parmi votre population de visiteurs, au cas où aucun des types fournis par le programme de visualisation ne correspond à un des types que vous avez prévu)
Négociation intégrée au serveur HTTP
Certains logiciels serveur WWW (par exemple le serveur Apache) intègrent des mécanismes de négociation de contenu qui permettent de ne pas devoir utiliser des scripts cgi-bin:
-
Le serveur est configuré pour reconnaître qu'un document HTML
dont le nom se termine par
.xx.htmlcorrespond à un document écrit dans une certaine langue. Par exemple, le serveur cuisung.unige.ch est configuré à l'aide des directives suivantes (fichier srm.conf):AddLanguage en .en AddLanguage fr .fr AddLanguage de .de AddLanguage da .da AddLanguage el .el AddLanguage it .it AddLanguage fr-CH .sr LanguagePriority en fr de
- Un document HTML peut contenir dans la section <head> une marque stipulant le jeu de caractères utilisé: <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
-
Si une URL correspond à un fichier qui n'existe pas, le serveur essaye
de trouver, dans le même répertoire, des fichiers dont le nom
commence par le nom de fichier stipulé dans l'URL. Par exemple, avec
l'URL
http://cuisung.unige.ch/readme,
le serveur remarque qu'il n'y a pas de fichier
readmedans le répertoire racine. Il recherche donc tous les fichiersreadme*. -
S'il trouve plusieurs fichiers, il déterminera lequel satisfait au
mieux les critères spécifiés par le client, en supposant
que des fichiers
xxx.en.htmlouxxx.fr.htmlfont référence à des traductions anglaises et françaises, respectivement, du même document, ou que des fichiersxxx.gif,xxx.xbmouxxx.jpgfont référence à différents formats de stockage de la même image. -
Les paramètres de négociation sont:
-
le type de média (mentionné dans le header
Accept:) -
la langue (mentionné dans le header
Accept-Language:) -
l'encodage (mentionné dans le header
Accept-Encoding:) -
le jeu de caractères (mentionné dans le header
Accept-Charset:)
-
le type de média (mentionné dans le header
-
Pour le type de média et la langue, chaque valeur mentionnée
peut avoir un facteur de qualité associé:
Accept: image/jpg; q=1.0, image/gif;q=0.5, image/*; q=0.2, text/plain; q=0.1
- Le serveur multiplie ce facteur de qualité avec un indice de qualité associé à chaque version du document spécifique.
- Si aucune version n'a pu être sélectionnée, le serveur retourne le code 406 ("No acceptable representation") avec la liste des variantes possibles, ce qui permettra à l'utilisateur de choisir.
N.B.: Pour que la négociation de contenu, il faut que les deux
protagonistes de la transaction fassent leur travail correctement. En
l'occurrence, trop peu de butineurs fournissent des informations complètes
dans le header Accept:. A l'heure actuelle, la négociation
de contenu basée sur les types de documents supportés par la
plateforme cliente est virtuellement impossible, par manque d'information
fournie par le client (butineur).
- Internet Draft: HTTP MIME Type Handler Detection
- Créez votre site Web multilingue
- HTTP International
- RFC 2295: Transparent Content Negotiation in HTTP
- RFC 2296: HTTP Remote Variant Selection Algorithm -- RVSA/1.0
- Internet Draft: Content Negotiation Header in HTTP Scenarios (31 oct. 2000)
- section sur la négociation de contenu de la documentation du serveur Apache
Bertrand Ibrahim 