Serveur HTTP Apache Version 2.4

Apache > Serveur HTTP > Documentation > Version 2.4 > Modules

# Module Apache mod_negotiation

Langues Disponibles: en | fr | ja

Description: | Effectue la négociation de contenu
Statut: | Base
Identificateur de Module: | negotiation_module
Fichier Source: | mod_negotiation.c

### Sommaire

La négociation de contenu, ou plus précisément la sélection de contenu, est la sélection parmi plusieurs documents disponibles, du document qui "colle" au plus près des possibilités du client. Pour y parvenir, deux méthodes sont employées.

- Une table de correspondances de types (un fichier associé au gestionnaire `type-map`) qui contient une liste explicite des fichiers contenant les différentes variantes.
- Une recherche multivues (Multiviews) (activée par l'`Options` `Multiviews`), où le serveur effectue une recherche de correspondance de modèle de nom de fichier implicite, et fait son choix parmi les résultats.

### Sujets

- Tables de correspondances de types
- Multivues

### Directives

### Traitement des bugs

- Journal des modifications de httpd
- Problèmes connus
- Signaler un bug

### Voir aussi

- `Options`
- `mod_mime`
- Négociation de contenu
- Variables d'environnement

## Tables de correspondances de types ¶

Une table de correspondances de types possède un format similaire à celui des en-têtes de messagerie RFC822. Elle contient des descriptions de documents séparées par des lignes vides, toute ligne commençant par un dièse ('#') étant considérée comme un commentaire. Une description de document comporte plusieurs enregistrements d'en-têtes ; chaque enregistrement peut être réparti sur plusieurs lignes à condition que les lignes supplémentaires commencent par un ou plusieurs espaces. Lors du traitement, les espaces de début de ligne seront supprimés et les lignes concaténées. L'enregistrement d'un en-tête comprend un mot-clé qui se termine toujours par un caractère "deux-points" ':', suivi d'une valeur. Les espaces sont autorisés entre le nom d'en-tête et sa valeur, ainsi qu'entre les différents éléments de la valeur. Les en-têtes autorisés sont :

`Content-Encoding:`
  Le codage du fichier. Apache ne reconnaît que les codages définis par une directive `AddEncoding`. Sont normalement inclus les codages `x-compress` pour les fichiers compressés avec compress, et `x-gzip` pour les fichiers compressés avec gzip. Le préfixe `x-` est ignoré lors des comparaisons de codages.
`Content-Language:`
  Le(s) langage(s) de la variante, sous la forme d'un symbole de langage Internet standard (RFC 1766). Par exemple, `en` correspond à l'anglais. Si la variante contient plusieurs langages, ils sont séparés par des virgules.
`Content-Length:`
  La taille du fichier en octets. Si cet en-tête n'est pas présent, c'est la taille réelle du fichier qui est utilisée.
`Content-Type:`
  Le type MIME du document avec des paramètres optionnels. Chaque variante doit comporter un en-tête `Content-Type` ; dans le cas contraire, la négociation ne fonctionnera pas correctement. Les paramètres sont séparés du type de médium ainsi qu'entre eux par un point-virgule, et possèdent la syntaxe `nom=valeur`. Les paramètres courants sont :
  `level`
    un entier spécifiant la version du type de média. Pour `text/html`, la valeur par défaut est 2, sinon 0.
  `qs`
    un nombre en virgule flottante de 0[.000] à 1[.000], indiquant la "qualité" relative de la variante courante par rapport aux autres variantes disponibles, indépendamment des possibilités du client. Par exemple, un fichier jpeg est en général une source de qualité supérieure à un fichier ascii s'il est censé représenter une image. Cependant, si la ressource représentée est une image ascii, un fichier ascii possèdera une qualité supérieure à un fichier jpeg. Toutes les valeurs de `qs` sont donc spécifiques à une certaine ressource.

  ### Exemple

  `Content-Type: image/jpeg; qs=0.8`

`URI:`
  l'URI du fichier contenant la variante (du type de médium donné, codé selon le codage de contenu donné). Cet URI est considéré comme relatif au fichier de correspondances ; il doit être situé sur le même serveur, et doit faire référence au fichier auquel le client se verrait accorder l'accès s'il était requis directement.
`Body:`
  Le contenu réel de la ressource peut être inclus dans la table de correspondances en utilisant l'en-tête Body. Cet en-tête doit contenir une chaîne désignant un délimiteur pour le contenu du corps. Les lignes suivantes du fichier de correspondances de types seront alors considérées comme parties du corps de la ressource jusqu'à ce que le délimiteur soit détecté.

  ### Exemple:

  `Body:----xyz----
  <html>
  <body>
  <p>Contenu de la page.</p>
  </body>
  </html>
  ----xyz----`

Considérons une ressource, `document.html`, disponible en anglais, en français et en allemand. Les fichiers correspondants se nomment respectivement `document.html.en`, `document.html.fr`, et `document.html.de`. Le fichier de correspondances de types se nommera `document.html.var` et contiendra ce qui suit :

`URI: document.html
Content-language: en
Content-type: text/html
URI: document.html.en
Content-language: fr
Content-type: text/html
URI: document.html.fr
Content-language: de
Content-type: text/html
URI: document.html.de
`

Ces quatre fichiers doivent se trouver dans le même répertoire, et le fichier `.var` doit être associé au gestionnaire `type-map` via une directive `AddHandler` :

    AddHandler type-map .var

A l'arrivée d'une requête pour la ressource `document.html.var`, la variante de `document.html` qui correspond le mieux à la préference de langage spécifiée dans l'en-tête de la requête de l'utilisateur `Accept-Language` sera choisie.

Si `Multiviews` est activée, et si `MultiviewsMatch` est définie à "handlers" ou "any", une requête pour `document.html` va rechercher `document.html.var`, et continuer la négociation avec le gestionnaire explicite type-map.

D'autres directives de configuration, comme `Alias`, peuvent être utilisées pour associer `document.html` avec `document.html.var`.

## Multivues ¶

Une recherche Multivues est activée par l'`Options` `Multiviews`. Si le serveur reçoit une requête pour `/un/répertoire/foo`, et si `/un/répertoire/foo` n'existe pas, le serveur parcourt le répertoire à la recherche de tous les fichiers de nom `foo.*`, et simule véritablement une correspondance de type qui nomme tous ces fichiers en leur assignant les mêmes type de média et codage de contenu qu'ils auraient eus si le client avait requis l'un d'entre eux avec son nom complet. Il choisit ensuite le fichier qui correspond le mieux au profile du client, puis renvoie le document.

La directive `MultiviewsMatch` définit si Apache doit prendre en compte les fichiers qui ne comportent pas de métadonnées de négociation de contenu lors du choix du fichier à servir.

## Directive CacheNegotiatedDocs ¶

Description: | Permet la mise en cache au niveau des serveurs mandataires des documents dont le contenu a été négocié
Syntaxe: | `CacheNegotiatedDocs On|Off`
Défaut: | `CacheNegotiatedDocs Off`
Contexte: | configuration globale, serveur virtuel
Statut: | Base
Module: | mod_negotiation

Si elle est définie à "on", cette directive permet la mise en cache au niveau des serveurs mandataires des documents dont le contenu a été négocié. Le processus de mise en cache sera alors plus efficace, mais des clients se trouvant derrière le mandataire seront alors susceptibles de se voir servir des versions de documents qui ne correspondent pas forcément à leurs attentes.

Cette directive ne s'applique qu'aux requêtes en provenance de navigateurs HTTP/1.0. HTTP/1.1 fournit un bien meilleur contrôle de la mise en cache des documents au contenu négocié, et cette directive n'a aucun effet sur les réponses aux requêtes HTTP/1.1.

## Directive ForceLanguagePriority ¶

Description: | Action à entreprendre si un document acceptable unique n'est pas trouvé
Syntaxe: | `ForceLanguagePriority None|Prefer|Fallback [Prefer|Fallback]`
Défaut: | `ForceLanguagePriority Prefer`
Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées: | FileInfo
Statut: | Base
Module: | mod_negotiation

La directive `ForceLanguagePriority` utilise le langage défini par la directive `LanguagePriority` pour terminer la négociation lorsque le serveur n'est pas en mesure de trouver une solution satisfaisante unique.

`ForceLanguagePriority Prefer` utilise la directive `LanguagePriority` pour servir le résultat d'un choix unique, au lieu de renvoyer un résultat HTTP 300 (MULTIPLE CHOICES), lorsque que plusieurs choix équivalents sont disponibles. Par exemple, avec les deux directives ci-dessous, si l'en-tête `Accept-Language` de l'utilisateur assigne à `en` et `de` une qualité de `.500` (les deux langages sont également acceptables), alors c'est la première variante acceptable de langue `en` qui sera servie.

    LanguagePriority en fr de
    ForceLanguagePriority Prefer

`ForceLanguagePriority Fallback` utilise la directive `LanguagePriority` pour servir un résultat valide, au lieu de renvoyer un résultat HTTP 406 (NOT ACCEPTABLE). Avec les deux directives ci-dessous, si l'en-tête `Accept-Language` de l'utilisateur ne mentionne que les réponses de langage `es`, et si aucune variante dans cette langue n'est trouvée, c'est la première variante de la liste définie par la directive `LanguagePriority` qui sera servie.

    LanguagePriority en fr de
    ForceLanguagePriority Fallback

Les deux options, `Prefer` et `Fallback`, peuvent être spécifiées, de façon à ce que la variante servie soit la première variante qui convient définie par la directive `LanguagePriority` si plusieurs variantes sont également acceptables, ou le premier document disponible si aucune variante ne convient à la liste de langages acceptables fournie par le client.

`ForceLanguagePriority None` désactive les deux comportements `Prefer` et `Fallback` ; le serveur renverra alors 300 (MULTIPLE CHOICES) ou 406 (NOT ACCEPTABLE), selon le cas. `None` ne peut pas être combiné avec `Prefer` ou `Fallback`.

### Voir aussi

- `AddLanguage`

## Directive LanguagePriority ¶

Description: | L'ordre de priorité des variantes de langages pour les cas où le client n'a pas formulé de préférences
Syntaxe: | `LanguagePriority langage-MIME [langage-MIME] ...`
Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées: | FileInfo
Statut: | Base
Module: | mod_negotiation

La directive `LanguagePriority` permet de définir, au cours du traitement d'une requête Multivues, l'ordre de priorité des variantes de langages pour les cas où le client n'a pas formulé de préférences. La liste énumère les langages-MIME dans un ordre de préférences décroissantes.

    LanguagePriority en fr de

Dans le cas d'une requête pour `foo.html`, si `foo.html.fr` et `foo.html.de` existent, et si le client n'a pas formulé de préférences, c'est le fichier `foo.html.fr` qui sera renvoyé.

Notez que cette directive n'a d'effet que si le 'meilleur' langage n'a pas pu être déterminé d'une autre manière ou si la valeur de la directive `ForceLanguagePriority` est différente de `None`. En général, c'est le client qui détermine le langage préféré, non le serveur.

### Voir aussi

- `AddLanguage`

Langues Disponibles: en | fr | ja