Serveur HTTP Apache Version 2.5
Description: | Effectue la négociation de contenu |
---|---|
Statut: | Base |
Identificateur de Module: | negotiation_module |
Fichier Source: | mod_negotiation.c |
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.
type-map
) qui contient une liste
explicite des fichiers contenant les différentes variantes.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.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:
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:
en
correspond à l'anglais. Si la variante
contient plusieurs langages, ils sont séparés par des
virgules.Content-Length:
Content-Type:
nom=valeur
. Les paramètres
courants sont :
level
text/html
, la valeur par défaut est 2, sinon
0.qs
qs
sont donc spécifiques à une certaine
ressource.
Content-Type: image/jpeg; qs=0.8
URI:
Body:
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
.
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.
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.
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.
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.