<-
Apache > Serveur HTTP > Documentation > Version 2.4

Négociation de contenu

Langues Disponibles:  en  |  fr  |  ja  |  ko  |  tr 

Apache HTTPD supporte la négociation de contenu telle qu'elle est décrite dans la spécification HTTP/1.1. Il peut choisir la meilleure représentation d'une ressource en fonction des préférences du navigateur pour ce qui concerne le type de media, les langages, le jeu de caractères et son encodage. Il implémente aussi quelques fonctionnalités pour traiter de manière plus intelligente les requêtes en provenance de navigateurs qui envoient des informations de négociation incomplètes.

La négociation de contenu est assurée par le module mod_negotiation qui est compilé par défaut dans le serveur.

Support Apache!

Voir aussi

top

À propos de la négociation de contenu

Une ressource peut être disponible selon différentes représentations. Par exemple, elle peut être disponible en différents langages ou pour différents types de média, ou une combinaison des deux. Pour faire le meilleur choix, on peut fournir à l'utilisateur une page d'index, et le laisser choisir. Cependant, le serveur peut souvent faire ce choix automatiquement. Ceci est possible car les navigateurs peuvent envoyer des informations sur les représentations qu'ils préfèrent à l'intérieur de chaque requête. Par exemple, un navigateur peut indiquer qu'il préfère voir les informations en français, mais qu'en cas d'impossibilité l'anglais peut convenir. Les navigateurs indiquent leurs préférences à l'aide d'en-têtes dans la requête. Pour ne demander que des représentations en français, le navigateur peut utiliser l'en-tête :

Accept-Language: fr

Notez qu'il ne sera tenu compte de cette préférence que s'il existe un choix de représentations et que ces dernières varient en fonction du langage.

À titre d'exemple d'une requête plus complexe, ce navigateur a été configuré pour accepter le français et l'anglais, avec une préférence pour le français, et accepter différents types de média, avec une préférence pour HTML par rapport à au texte plat ("plain text") ou autres types de fichiers texte, et avec une préférence pour GIF ou JPEG par rapport à tout autre type de média, mais autorisant tout autre type de média en dernier ressort :

Accept-Language: fr; q=1.0, en; q=0.5
Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6, image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1

httpd supporte la négociation de contenu "server driven" (telle qu'elle est définie dans la spécification HTTP/1.1), où c'est le serveur qui décide quelle est la meilleure représentation à retourner pour la ressource demandée. Il supporte entièrement les en-têtes de requête Accept, Accept-Language, Accept-Charset et Accept-Encoding. httpd supporte aussi la négociation de contenu transparente, qui est un protocole de négociation expérimental défini dans les RFC 2295 et 2296. Il ne supporte pas la négociation de fonctionnalité (feature negotiation) telle qu'elle est définie dans ces RFCs.

Une ressource est une entité conceptuelle identifiée par une URI (RFC 2396). Un serveur HTTP comme le serveur HTTP Apache propose l'accès à des représentations de la ressource à l'intérieur de son espace de nommage, chaque représentation étant composée d'une séquence d'octets avec la définition d'un type de media, d'un jeu de caractères, d'un encodage, etc... A un instant donné, chaque ressource peut être associée avec zéro, une ou plusieurs représentations. Si plusieurs représentations sont disponibles, la ressource est qualifiée de négociable et chacune de ses représentations se nomme variante. Les différences entre les variantes disponibles d'une ressource négociable constituent les dimensions de la négociation.

top

La négociation avec httpd

Afin de négocier une ressource, on doit fournir au serveur des informations à propos de chacune des variantes. Il y a deux manières d'accomplir ceci :

Utilisation d'un fichier de correspondances de types (type-map)

Une liste de correspondances de types est un document associé au gestionnaire type-map (ou, dans un souci de compatibilité ascendante avec des configurations de httpd plus anciennes, le type MIME application/x-type-map). Notez que pour utiliser cette fonctionnalité, vous devez, dans le fichier de configuration, définir un gestionnaire qui associe un suffixe de fichier à une type-map; ce qui se fait simplement en ajoutant

AddHandler type-map .var

dans le fichier de configuration du serveur.

Les fichiers de correspondances de types doivent posséder le même nom que la ressource qu'ils décrivent, avec pour extension .var. Dans l'exemple ci-dessous, la ressource a pour nom foo, et le fichier de correspondances se nomme donc foo.var.

Ce fichier doit comporter une entrée pour chaque variante disponible; chaque entrée consiste en une ligne contiguë d'en-têtes au format HTTP. les entrées sont séparées par des lignes vides. Les lignes vides à l'intérieur d'une entrée sont interdites. Par convention, le fichier de correspondances de types débute par une entrée concernant l'entité considérée dans son ensemble (bien que ce ne soit pas obligatoire, et ignoré si présent). Un exemple de fichier de correspondance de types est fourni ci-dessous.

Les URIs de ce fichier sont relatifs à la localisation du fichier de correspondances de types. En général, ces fichiers se trouveront dans le même répertoire que le fichier de correspondances de types, mais ce n'est pas obligatoire. Vous pouvez utiliser des URIs absolus ou relatifs pour tout fichier situé sur le même serveur que le fichier de correspondances.

URI: foo

URI: foo.en.html
Content-type: text/html
Content-language: en

URI: foo.fr.de.html
Content-type: text/html;charset=iso-8859-2
Content-language: fr, de

Notez aussi qu'un fichier de correspondances de types prend le pas sur les extensions de noms de fichiers, même si les Multivues sont activées. Si les variantes sont de qualités différentes, on doit l'indiquer à l'aide du paramètre "qs" à la suite du type de média, comme pour cette image (disponible aux formats JPEG, GIF, ou ASCII-art) :

URI: foo

URI: foo.jpeg
Content-type: image/jpeg; qs=0.8

URI: foo.gif
Content-type: image/gif; qs=0.5

URI: foo.txt
Content-type: text/plain; qs=0.01

Les valeurs de qs peuvent varier de 0.000 à 1.000. Notez que toute variante possédant une valeur de qs de 0.000 ne sera jamais choisie. Les variantes qui n'ont pas de paramètre qs défini se voient attribuer une valeur de 1.0. Le paramètre qs indique la qualité relative de la variante comparée à celle des autres variantes disponibles, sans tenir compte des capacités du client. Par exemple, un fichier JPEG possède en général une qualité supérieure à celle d'un fichier ASCII s'il représente une photographie. Cependant, si la ressource représentée est à un ASCII art original, la représentation ASCII sera de meilleure qualité que la représentation JPEG. Ainsi une valeur de qs est associée à une variante en fonction de la nature de la ressource qu'elle représente.

La liste complète des en-têtes reconnus est disponible dans la documentation sur les correspondances de types du module mod_negotiation.

Multivues (option Multiviews)

MultiViews est une option qui s'applique à un répertoire, ce qui signifie qu'elle peut être activée à l'aide d'une directive Options à l'intérieur d'une section <Directory>, <Location> ou <Files> dans apache2.conf, ou (si AllowOverride est correctement positionnée) dans des fichiers .htaccess. Notez que Options All n'active pas MultiViews; vous devez activer cette option en la nommant explicitement.

L'effet de MultiViews est le suivant : si le serveur reçoit une requête pour /tel/répertoire/foo, si MultiViews est activée pour /tel/répertoire, et si /tel/répertoire/foo n'existe pas, le serveur parcourt le répertoire à la recherche de fichiers nommés foo.*, et simule littéralement une correspondance de types (type map) qui liste tous ces fichiers, en leur associant les mêmes types de média et encodages de contenu qu'ils auraient eu si le client avait demandé l'accès à l'un d'entre eux par son nom. Il choisit ensuite ce qui correspond le mieux aux besoins du client.

MultiViews peut aussi s'appliquer à la recherche du fichier nommé par la directive DirectoryIndex, si le serveur tente d'indexer un répertoire. Si les fichiers de configuration spécifient

DirectoryIndex index

le serveur va choisir entre index.html et index.html3 si les deux fichiers sont présents. Si aucun n'est présent, mais index.cgi existe, le serveur l'exécutera.

Si, parcequ'elle n'est pas reconnue par mod_mime, l'extension d'un des fichiers du répertoire ne permet pas de déterminer son jeu de caractères, son type de contenu, son langage, ou son encodage, alors le résultat dépendra de la définition de la directive MultiViewsMatch. Cette directive détermine si les gestionnaires (handlers), les filtres, et autres types d'extensions peuvent participer à la négociation MultiVues.

top

Les méthodes de négociation

Une fois obtenue la liste des variantes pour une ressource donnée, httpd dispose de deux méthodes pour choisir la meilleure variante à retourner, s'il y a lieu, soit à partir d'un fichier de