1 <?xml version="1.0" encoding="ISO-8859-1" ?>
2 <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
3 <?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
4 <!-- French translation : Lucien GENTIS -->
5 <!-- Reviewed by : Vincent Deffontaines -->
6 <!-- English Revision: 1364312:1673932 (outdated) -->
9 Licensed to the Apache Software Foundation (ASF) under one or more
10 contributor license agreements. See the NOTICE file distributed with
11 this work for additional information regarding copyright ownership.
12 The ASF licenses this file to You under the Apache License, Version 2.0
13 (the "License"); you may not use this file except in compliance with
14 the License. You may obtain a copy of the License at
16 http://www.apache.org/licenses/LICENSE-2.0
18 Unless required by applicable law or agreed to in writing, software
19 distributed under the License is distributed on an "AS IS" BASIS,
20 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
21 See the License for the specific language governing permissions and
22 limitations under the License.
25 <manualpage metafile="content-negotiation.xml.meta">
27 <title>Négociation de contenu</title>
31 <p>Apache HTTPD supporte la négociation de
32 contenu telle qu'elle est décrite
33 dans la spécification HTTP/1.1. Il peut choisir la meilleure représentation
34 d'une ressource en fonction des préférences du navigateur pour ce qui
35 concerne le type de media, les langages, le jeu de caractères et son
36 encodage. Il implémente aussi quelques fonctionnalités pour traiter de
37 manière plus intelligente les requêtes en provenance de navigateurs qui
38 envoient des informations de négociation incomplètes.</p>
40 <p>La négociation de contenu est assurée par le module
41 <module>mod_negotiation</module> qui est compilé par défaut
45 <section id="about"><title>À propos de la négociation de contenu</title>
47 <p>Une ressource peut être disponible selon différentes représentations.
48 Par exemple, elle peut être disponible en différents langages ou pour
49 différents types de média, ou une combinaison des deux.
50 Pour faire le meilleur choix, on peut fournir à l'utilisateur une page
51 d'index, et le laisser choisir. Cependant, le serveur peut souvent faire
52 ce choix automatiquement. Ceci est possible car les navigateurs peuvent
53 envoyer des informations sur les
54 représentations qu'ils préfèrent à l'intérieur de chaque requête.
55 Par exemple, un navigateur peut indiquer
56 qu'il préfère voir les informations en français, mais qu'en cas
57 d'impossibilité l'anglais peut convenir. Les navigateurs indiquent leurs
58 préférences à l'aide d'en-têtes dans la requête. Pour ne demander que des
59 représentations en français, le navigateur peut utiliser l'en-tête :</p>
61 <example>Accept-Language: fr</example>
63 <p>Notez qu'il ne sera tenu compte de cette préférence que s'il existe un
64 choix de représentations et que ces dernières varient en fonction
67 <p>À titre d'exemple d'une requête plus complexe, ce navigateur a été
68 configuré pour accepter le français et l'anglais, avec une préférence pour
69 le français, et accepter différents types de média, avec une préférence
70 pour HTML par rapport à au texte plat ("plain text") ou autres types de fichiers texte, et
71 avec une préférence pour GIF ou JPEG par rapport à tout autre type de
72 média, mais autorisant tout autre type de média en dernier ressort :</p>
75 Accept-Language: fr; q=1.0, en; q=0.5<br />
76 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
79 <p>httpd supporte la négociation de contenu "server driven" (telle qu'elle
80 est définie dans la spécification HTTP/1.1), où c'est le serveur qui
81 décide quelle est la meilleure représentation à retourner pour la ressource
82 demandée. Il supporte entièrement les en-têtes de requête
83 <code>Accept</code>, <code>Accept-Language</code>,
84 <code>Accept-Charset</code> et <code>Accept-Encoding</code>.
85 httpd supporte aussi la négociation de contenu transparente, qui est un
86 protocole de négociation expérimental défini dans les RFC 2295 et 2296.
87 Il ne supporte pas la négociation de fonctionnalité (feature negotiation)
88 telle qu'elle est définie dans ces RFCs.</p>
90 <p>Une <strong>ressource</strong> est une entité conceptuelle identifiée
91 par une URI (RFC 2396). Un serveur HTTP comme le serveur HTTP Apache
92 propose l'accès à des
93 <strong>représentations</strong> de la ressource à l'intérieur de son
94 espace de nommage, chaque représentation étant composée d'une séquence
95 d'octets avec la définition d'un type de media, d'un jeu de caractères,
96 d'un encodage, etc... A un instant donné, chaque ressource peut être
97 associée avec zéro, une ou plusieurs représentations. Si plusieurs
98 représentations sont disponibles, la ressource est qualifiée de
99 <strong>négociable</strong> et chacune de ses représentations se nomme
100 <strong>variante</strong>. Les différences entre les
101 variantes disponibles d'une ressource négociable constituent les
102 <strong>dimensions</strong> de la négociation.</p>
105 <section id="negotiation"><title>La négociation avec httpd</title>
107 <p>Afin de négocier une ressource, on doit fournir au serveur des
108 informations à propos de chacune des variantes. Il y a deux manières
109 d'accomplir ceci :</p>
112 <li>Utiliser une liste de correspondances de type ("type-map") (<em>c'est à dire</em>
113 un fichier <code>*.var</code>) qui nomme explicitement les fichiers
114 contenant les variantes, ou</li>
116 <li>Utiliser une recherche "multivues", où le serveur effectue une
117 recherche de correspondance sur un motif de nom de fichier implicite et
118 fait son choix parmi les différents résultats.</li>
121 <section id="type-map"><title>Utilisation d'un fichier de
122 correspondances de types (type-map)</title>
124 <p>Une liste de correspondances de types est un document associé au
125 gestionnaire <code>type-map</code> (ou, dans un souci de compatibilité
126 ascendante avec des configurations de httpd plus anciennes, le
127 <glossary>type MIME</glossary>
128 <code>application/x-type-map</code>). Notez que pour utiliser cette
129 fonctionnalité, vous devez, dans le fichier de configuration, définir un
130 gestionnaire qui associe un suffixe de fichier à une <code>type-map</code>;
131 ce qui se fait simplement en ajoutant</p>
133 <highlight language="config">AddHandler type-map .var</highlight>
135 <p>dans le fichier de configuration du serveur.</p>
137 <p>Les fichiers de correspondances de types doivent posséder le même nom que
138 la ressource qu'ils décrivent, avec pour extension
139 <code>.var</code>. Dans l'exemple ci-dessous, la ressource a pour
140 nom <code>foo</code>, et le fichier de correspondances se nomme donc
141 <code>foo.var</code>.</p>
143 <p>Ce fichier doit comporter une entrée pour chaque variante
144 disponible; chaque entrée consiste en une ligne contiguë d'en-têtes au
145 format HTTP. les entrées sont séparées par des lignes vides. Les lignes
146 vides à l'intérieur d'une entrée sont interdites. Par convention, le
147 fichier de correspondances de types débute par une entrée concernant l'entité
148 considérée dans son ensemble (bien que ce ne soit pas obligatoire, et
149 ignoré si présent). Un exemple de fichier de
150 correspondance de types est fourni
153 <p>Les URIs de ce fichier sont relatifs à la localisation du fichier
154 de correspondances de types. En général, ces fichiers se trouveront dans le
155 même répertoire que le fichier de correspondances de types, mais ce
156 n'est pas obligatoire. Vous pouvez utiliser des URIs absolus ou
157 relatifs pour tout fichier situé sur le même serveur que le fichier
158 de correspondances.</p>
163 URI: foo.en.html<br />
164 Content-type: text/html<br />
165 Content-language: en<br />
167 URI: foo.fr.de.html<br />
168 Content-type: text/html;charset=iso-8859-2<br />
169 Content-language: fr, de<br />
172 <p>Notez aussi qu'un fichier de correspondances de types prend le pas sur
173 les extensions de noms de fichiers, même si les Multivues sont activées.
174 Si les variantes sont de qualités différentes, on doit l'indiquer
175 à l'aide du paramètre "qs" à la suite du type de média, comme pour cette
177 (disponible aux formats JPEG, GIF, ou ASCII-art) : </p>
183 Content-type: image/jpeg; qs=0.8<br />
186 Content-type: image/gif; qs=0.5<br />
189 Content-type: text/plain; qs=0.01<br />
192 <p>Les valeurs de qs peuvent varier de 0.000 à 1.000. Notez que toute
193 variante possédant une valeur de qs de 0.000 ne sera jamais choisie.
194 Les variantes qui n'ont pas de paramètre qs défini se voient attribuer
195 une valeur de 1.0. Le paramètre qs indique la qualité relative de la
196 variante comparée à celle des autres variantes disponibles, sans tenir
197 compte des capacités du client. Par exemple, un fichier JPEG possède
198 en général une qualité supérieure à celle d'un fichier ASCII s'il
199 représente une photographie. Cependant, si la ressource représentée est
200 à un ASCII art original, la représentation ASCII sera de meilleure qualité
201 que la représentation JPEG. Ainsi une valeur de qs est associée à une
202 variante en fonction de la nature de la ressource qu'elle représente.</p>
204 <p>La liste complète des en-têtes reconnus est disponible dans la
205 documentation sur les <a
206 href="mod/mod_negotiation.html#typemaps">correspondances de types du
207 module mod_negotiation</a>.</p>
210 <section id="multiviews"><title>Multivues (option Multiviews)</title>
212 <p><code>MultiViews</code> est une option qui s'applique à un répertoire,
213 ce qui signifie qu'elle peut être activée à l'aide d'une directive
214 <directive module="core">Options</directive> à l'intérieur d'une section
215 <directive module="core"
216 type="section">Directory</directive>, <directive module="core"
217 type="section">Location</directive> ou <directive module="core"
218 type="section">Files</directive> dans
219 <code>httpd.conf</code>, ou (si <directive
220 module="core">AllowOverride</directive> est correctement positionnée) dans
222 <code>.htaccess</code>. Notez que <code>Options All</code>
223 n'active pas <code>MultiViews</code>; vous devez activer cette option en
224 la nommant explicitement.</p>
226 <p>L'effet de <code>MultiViews</code> est le suivant : si le serveur reçoit
227 une requête pour <code>/tel/répertoire/foo</code>, si
228 <code>MultiViews</code> est activée pour
229 <code>/tel/répertoire</code>, et si
230 <code>/tel/répertoire/foo</code> n'existe <em>pas</em>, le serveur parcourt
231 le répertoire à la recherche de fichiers nommés foo.*, et simule
232 littéralement une correspondance de types (type map) qui liste tous ces
233 fichiers, en leur associant les mêmes types de média et encodages de
234 contenu qu'ils auraient eu si le client avait demandé l'accès à l'un
235 d'entre eux par son nom. Il choisit ensuite ce qui correspond le mieux
236 aux besoins du client.</p>
238 <p><code>MultiViews</code> peut aussi s'appliquer à la recherche du fichier
239 nommé par la directive <directive
240 module="mod_dir">DirectoryIndex</directive>, si le serveur tente d'indexer
241 un répertoire. Si les fichiers de configuration spécifient</p>
242 <highlight language="config">DirectoryIndex index</highlight>
243 <p>le serveur va choisir entre <code>index.html</code>
244 et <code>index.html3</code> si les deux fichiers sont présents. Si aucun
245 n'est présent, mais <code>index.cgi</code> existe,
246 le serveur l'exécutera.</p>
248 <p>Si, parcequ'elle n'est pas reconnue par <code>mod_mime</code>,
249 l'extension d'un des fichiers du répertoire ne permet pas de
250 déterminer son jeu de caractères, son type de contenu, son langage, ou son
252 le résultat dépendra de la définition de la directive <directive
253 module="mod_mime">MultiViewsMatch</directive>. Cette directive détermine
254 si les gestionnaires (handlers), les filtres, et autres types d'extensions
255 peuvent participer à la négociation MultiVues.</p>
259 <section id="methods"><title>Les méthodes de négociation</title>
261 <p>Une fois obtenue la liste des variantes pour une ressource donnée,
262 httpd dispose de deux méthodes pour choisir la meilleure variante à
263 retourner, s'il y a lieu, soit à partir d'un fichier de
264 correspondances de types, soit en se basant sur les noms de fichiers du
265 répertoire. Il n'est pas nécessaire de connaître en détails comment la
266 négociation fonctionne réellement pour pouvoir utiliser les fonctionnalités
267 de négociation de contenu de httpd. La suite de ce document explique
268 cependant les méthodes utilisées pour ceux ou celles qui sont
269 intéressés(ées). </p>
271 <p>Il existe deux méthodes de négociation :</p>
274 <li><strong>La négociation effectuée par le serveur selon l'algorithme
275 de httpd</strong> est normalement utilisée. l'algorithme de
277 expliqué plus en détails ci-dessous. Quand cet algorithme est utilisé,
278 httpd peut parfois "bricoler" le facteur de qualité (qs) d'une dimension
279 particulière afin d'obtenir un meilleur résultat.
280 La manière dont httpd peut modifier les facteurs de qualité est
281 expliquée plus en détails ci-dessous.</li>
283 <li><strong>La négociation de contenu transparente</strong> est utilisée
284 quand le navigateur le demande explicitement selon le mécanisme défini
285 dans la RFC 2295. Cette méthode de négociation donne au navigateur le
286 contrôle total du choix de la meilleure variante; le résultat dépend
287 cependant de la spécificité des algorithmes utilisés par le navigateur.
288 Au cours du processus de négociation transparente, le navigateur peut
289 demander à httpd d'exécuter l'"algorithme de sélection de variante à
290 distance" défini dans la RFC 2296.</li>
293 <section id="dimensions"><title>Les dimensions de la négociation</title>
296 <columnspec><column width=".15"/><column width=".85"/></columnspec>
304 <td>Type de média</td>
306 <td>Le navigateur affiche ses préférences à l'aide du champ d'en-tête
307 <code>Accept</code>. Chaque type de média peut se voir associé un facteur de
308 qualité. La description de la variante peut aussi avoir un facteur de
309 qualité (le paramètre "qs").</td>
315 <td>Le navigateur affiche ses préférences à l'aide du champ d'en-tête
316 <code>Accept-Language</code>. Chaque langue peut se voir associé un facteur de
317 qualité. Les variantes peuvent être associées avec zéro, un ou
318 plusieurs langages.</td>
324 <td>Le navigateur affiche ses préférences à l'aide du champ d'en-tête
325 <code>Accept-Encoding</code>. Chaque encodage peut se voir associé un facteur de
332 <td>Le navigateur affiche ses préférences à l'aide du champ d'en-tête
333 <code>Accept-Charset</code>. Chaque jeu de caractère peut se voir associé un facteur de
334 qualité. Les variantes peuvent préciser un jeu de caractères comme
335 paramètre du type de média.</td>
340 <section id="algorithm"><title>L'algorithme de négociation de
343 <p>httpd peut utiliser l'algorithme suivant pour choisir la "meilleure"
344 variante (s'il y en a une) à retourner au navigateur. Cet algorithme n'est pas
345 configurable. Il fonctionne comme suit :</p>
348 <li>En premier lieu, pour chaque dimension de la négociation, consulter
349 le champ d'en-tête <em>Accept*</em> approprié et assigner une qualité à
350 chaque variante. Si l'en-tête <em>Accept*</em> pour toute dimension
351 implique que la variante n'est pas acceptable, éliminer cette dernière.
352 S'il ne reste plus de variante, aller à l'étape 4.</li>
355 Choisir la "meilleure" variante par élimination. Chacun des tests
356 suivants est effectué dans cet ordre. Toute variante non sélectionnée
357 à l'issue d'un test est éliminée. Après chaque test, s'il reste une
358 seule variante, choisir cette dernière comme celle qui correspond le
359 mieux puis aller à l'étape 3. S'il reste plusieurs variantes, passer
363 <li>Multiplier le facteur de qualité de l'en-tête
364 <code>Accept</code> par le facteur de qualité "qs" pour le type de
365 média de ces variantes, et choisir la variante qui possède la valeur
366 la plus importante.</li>
368 <li>Sélectionner les variantes qui possèdent le facteur de qualité
369 de langage le plus haut.</li>
371 <li>Sélectionner les variantes dont le langage correspond le mieux,
372 en se basant sur l'ordre des langages de l'en-tête
373 <code>Accept-Language</code> (s'il existe), ou de la directive
374 <code>LanguagePriority</code> (si elle existe).</li>
376 <li>Sélectionner les variantes possédant le paramètre de média
377 "level" le plus élevé (utilisé pour préciser la version des types de
378 média text/html).</li>
380 <li>Sélectionner les variantes possédant le paramètre de média
381 "charset" (jeu de caractères) qui correspond le mieux, en se basant
382 sur la ligne d'en-tête <code>Accept-Charset</code> . Le jeu de
383 caractères ISO-8859-1 est acceptable sauf s'il est explicitement
384 exclus. Les variantes avec un type de média <code>text/*</code>
385 mais non explicitement associées avec un jeu de caractères
386 particulier sont supposées être en ISO-8859-1.</li>
388 <li>Sélectionner les variantes dont le paramètre de média "charset"
389 associé n'est <em>pas</em> ISO-8859-1. S'il n'en existe pas,
390 sélectionner toutes les variantes.</li>
392 <li>Sélectionner les variantes avec le meilleur encodage. S'il existe
393 des variantes avec un encodage acceptable pour le client,
394 sélectionner celles-ci. Sinon, s'il existe des variantes encodées et
395 des variantes non encodées, ne sélectionner que les variantes non
396 encodées. Si toutes les variantes sont encodées ou si aucune
397 ne l'est, sélectionner toutes les variantes.</li>
399 <li>Sélectionner les variantes dont le contenu a la longueur
402 <li>Sélectionner la première des variantes restantes. Il s'agira
403 soit de la première variante listée dans le fichier de
404 correspondances de types, soit, quand les variantes sont lues depuis
405 le répertoire, la première par ordre alphabétique quand elles sont
406 triées selon le code ASCII.</li>
410 <li>L'algorithme a maintenant sélectionné une variante considérée comme
411 la "meilleure", il la retourne donc au client en guise de réponse.
412 L'en-tête HTTP <code>Vary</code> de la réponse est renseigné de façon à
413 indiquer les dimensions de la négociation (les navigateurs et les caches
414 peuvent utiliser cette information lors de la mise en cache de la
415 ressource). Travail terminé.</li>
417 <li>Le passage par cette étape signifie qu'aucune variante n'a été
418 sélectionnée (parcequ'aucune n'est acceptable pour le navigateur).
419 Envoyer une réponse avec un code de statut 406 (qui signifie "Aucune
420 représentation acceptable") et un corps comportant un document HTML qui
421 affiche les variantes disponibles. Renseigner aussi l'en-tête HTTP
422 <code>Vary</code> de façon à indiquer les dimensions de la variante.</li>
427 <section id="better"><title>Ajustement des valeurs de qualité</title>
429 <p>Parfois httpd modifie les valeurs de qualité par rapport à celles qui
430 découleraient d'une stricte interprétation de l'algorithme de négociation
431 de httpd ci-dessus, ceci pour améliorer les résultats de l'algorithme pour
432 les navigateurs qui envoient des informations incomplètes ou inappropriées.
433 Certains des navigateurs les plus populaires envoient des informations dans
434 l'en-tête <code>Accept</code> qui, sans ce traitement, provoqueraient la
435 sélection d'une variante inappropriée dans de nombreux cas. Quand un
436 navigateur envoie des informations complètes et correctes ces ajustements
437 ne sont pas effectués.</p>
439 <section id="wildcards"><title>Types de média et caractères génériques</title>
441 <p>L'en-tête de requête <code>Accept:</code> indique les types de média
442 souhaités. Il peut aussi contenir des types de média avec caractères
443 génériques, comme "image/*" ou "*/*" où * correspond à n'importe quelle
444 chaîne de caractères. Ainsi une requête contenant :</p>
446 <example>Accept: image/*, */*</example>
448 <p>indiquerait que tout type de média est acceptable, avec une préférence
449 pour les types commençant par "image/".
450 Certains navigateurs ajoutent par défaut des types de média avec caractères
451 génériques aux types explicitement nommés qu'ils peuvent gérer.
455 Accept: text/html, text/plain, image/gif, image/jpeg, */*
457 <p>Ceci indique que les types explicitement listés sont préférés, mais
458 qu'une représentation avec un type différent de ces derniers conviendra
459 aussi. Les valeurs de qualités explicites,
460 afin de préciser ce que veut vraiment le navigateur, s'utilisent
463 Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01
465 <p>Les types explicites n'ont pas de facteur de qualité, la valeur par
466 défaut de leur préférence est donc de 1.0 (la plus haute). Le type avec
467 caractères génériques */* se voit attribuer une préférence basse de 0.01,
468 si bien que les types autres que ceux explicitement listés ne seront retournés
469 que s'il n'existe pas de variante correspondant à un type explicitement
472 <p>Si l'en-tête <code>Accept:</code> ne contient <em>pas</em> aucun
473 facteur de qualité, httpd positionne la valeur de qualité de
474 "*/*", si present, à 0.01 pour simuler l'effet désiré. Il positionne aussi
475 la valeur de qualité des types avec caractères génériques au format
476 "type/*" à 0.02 (ils sont donc préférés à ceux correspondant à "*/*"). Si
477 un type de média dans l'en-tête <code>Accept:</code> contient un facteur de
478 qualité, ces valeurs spéciales ne seront <em>pas</em> appliquées, de façon
479 à ce que les requêtes de navigateurs qui envoient les informations
480 explicites à prendre en compte fonctionnent comme souhaité.</p>
483 <section id="exceptions"><title>Exceptions dans la négociation du
486 <p>A partir de la version 2.0 de httpd, certaines exceptions ont été
487 ajoutées à l'algorithme de négociation afin de ménager une issue de secours
488 quand la négociation ne trouve aucun langage correspondant.</p>
490 <p>Quand un client demande une page sur votre serveur, si ce dernier ne
491 parvient pas à trouver une page dont la langue corresponde à l'en-tête
492 <code>Accept-language</code> envoyé par le navigateur, il enverra au client
493 une réponse "Aucune variante acceptable" ou "Plusieurs choix possibles".
494 Pour éviter ces
495 messages d'erreur, il est possible de configurer httpd de façon à ce que,
496 dans ces cas, il ignore l'en-tête <code>Accept-language</code> et fournisse
497 tout de même un document, même s'il ne correspond pas exactement à la
498 demande explicite du client. La directive <directive
499 module="mod_negotiation">ForceLanguagePriority</directive>
500 peut être utilisée pour éviter ces messages d'erreur et leur substituer une
501 page dont le langage sera déterminé en fonction du contenu de la directive
502 <directive module="mod_negotiation">LanguagePriority</directive>.</p>
504 <p>Le serveur va aussi essayer d'étendre sa recherche de correspondance aux
505 sous-ensembles de langages quand aucune correspondance exacte ne peut être
506 trouvée. Par exemple, si un client demande des documents possédant le
507 langage <code>en-GB</code>, c'est à dire anglais britannique, le standard
508 HTTP/1.1 n'autorise normalement pas le serveur à faire correspondre cette
509 demande à un document dont le langage est simplement <code>en</code>.
510 (Notez qu'inclure <code>en-GB</code> et non <code>en</code> dans l'en-tête
511 <code>Accept-Language</code> constitue une quasi-erreur de configuration,
512 car il est très peu probable qu'un lecteur qui comprend l'anglais
513 britannique, ne comprenne pas l'anglais en général. Malheureusement, de
514 nombreux clients ont réellement des configurations par défaut de ce type.)
515 Cependant, si aucune autre correspondance de langage n'est possible, et que le
516 serveur est sur le point de retourner une erreur "Aucune variable
517 acceptable" ou de choisir le langage défini par la directive <directive
518 module="mod_negotiation">LanguagePriority</directive>, le serveur ignorera
519 la spécification du sous-ensemble de langage et associera la demande en
520 <code>en-GB</code> à des documents en <code>en</code>. Implicitement,
521 httpd ajoute le langage parent à la liste de langues acceptés par le
522 client avec une valeur de qualité très basse. Notez cependant que si le
523 client demande "en-GB; q=0.9, fr; q=0.8", et le serveur dispose de
524 documents estampillés "en" et "fr", alors c'est le document "fr" qui sera
525 retourné, tout ceci dans un souci de compatibilité avec la spécification
526 HTTP/1.1 et afin de fonctionner efficacement avec les clients
527 correctement configurés.</p>
529 <p>Pour supporter les techniques avancées (comme les cookies ou les chemins
530 d'URL spéciaux) afin de déterminer le langage préféré de l'utilisateur, le
531 module <module>mod_negotiation</module> reconnaît la
532 <a href="env.html">variable d'environnement</a>
533 <code>prefer-language</code>
534 depuis la version 2.0.47 de httpd. Si elle est définie et contient un
535 symbole de langage approprié, <module>mod_negotiation</module> va essayer
536 de sélectionner une variante correspondante. S'il n'existe pas de telle
537 variante, le processus normal de négociation sera lancé.</p>
539 <example><title>Exemple</title>
540 <highlight language="config">
541 SetEnvIf Cookie "language=(.+)" prefer-language=$1
542 Header append Vary cookie
548 <section id="extensions"><title>Extensions à la négociation de contenu
551 <p>httpd étend le protocole de négociation de contenu transparente (RFC
552 2295) comme suit. Un nouvel élément <code>{encodage ..}</code> est utilisé dans
553 les listes de variantes pour marquer celles qui ne sont disponibles qu'avec un
554 encodage de contenu spécifique. L'implémentation de l'algorithme
555 RVSA/1.0 (RFC 2296) est étendue à la reconnaissance de variantes encodées dans
556 la liste, et à leur utilisation en tant que variantes candidates à partir du
557 moment où leur encodage satisfait au contenu de l'en-tête de requête
558 <code>Accept-Encoding</code>. L'implémentation RVSA/1.0 n'arrondit pas les
559 facteurs de qualité calculés à 5 décimales avant d'avoir choisi la meilleure
563 <section id="naming"><title>Remarques à propos des liens hypertextes et des
564 conventions de nommage</title>
566 <p>Si vous utilisez la négociation de langage, vous avez le choix entre
567 différentes conventions de nommage, car les fichiers peuvent posséder
568 plusieurs extensions, et l'ordre dans lequel ces dernières apparaissent
569 est en général sans rapport (voir la documentation sur le module <a
570 href="mod/mod_mime.html#multipleext">mod_mime</a>
571 pour plus de détails).</p>
573 <p>Un fichier type possède une extension liée au type MIME
574 (<em>par exemple</em>, <code>html</code>), mais parfois aussi une
575 extension liée à l'encodage (<em>par exemple</em>, <code>gz</code>),
576 et bien sûr une extension liée au langage
577 (<em>par exemple</em>, <code>en</code>) quand plusieurs variantes de
578 langage sont disponibles pour ce fichier.</p>
587 <li>foo.en.html.gz</li>
590 <p>Ci-dessous d'autres exemples de noms de fichiers avec des liens
591 hypertextes valides et invalides :</p>
593 <table border="1" cellpadding="8" cellspacing="0">
594 <columnspec><column width=".2"/><column width=".2"/>
595 <column width=".2"/></columnspec>
601 <th>Lien invalide</th>
605 <td><em>foo.html.en</em></td>
614 <td><em>foo.en.html</em></td>
622 <td><em>foo.html.en.gz</em></td>
632 <td><em>foo.en.html.gz</em></td>
642 <td><em>foo.gz.html.en</em></td>
652 <td><em>foo.html.gz.en</em></td>
662 <p>En regardant la table ci-dessus, vous remarquerez qu'il est toujours
663 possible d'utiliser le nom de fichier sans extension dans un lien
664 (<em>par exemple</em>, <code>foo</code>). L'avantage est de pouvoir
665 dissimuler le type réel du fichier associé à un document et de pouvoir
667 ultérieurement, <em>par exemple</em>, de <code>html</code> à
668 <code>shtml</code> ou <code>cgi</code> sans avoir à
669 mettre à jour aucun lien.</p>
671 <p>Si vous souhaitez continuer à utiliser un type MIME dans vos liens
672 (<em>par exemple </em> <code>foo.html</code>), l'extension liée au langage
673 (y compris une extension liée à l'encodage s'il en existe une)
674 doit se trouver à droite de l'extension liée au type MIME
675 (<em>par exemple</em>, <code>foo.html.en</code>).</p>
678 <section id="caching"><title>Remarque sur la mise en cache</title>
680 <p>Quand un cache stocke une représentation, il l'associe avec l'URL de la
681 requête. Lorsque cette URL est à nouveau demandée, le cache peut utiliser
682 la représentation stockée. Cependant, si la ressource est négociable au
683 niveau du serveur, il se peut que seule la première variante demandée soit
684 mise en cache et de ce fait, la correspondance positive du cache peut
685 entraîner une réponse inappropriée. Pour
686 éviter ceci, httpd marque par
687 défaut toutes les réponses qui sont retournées après une négociation de
688 contenu comme "non-cachables" par les clients HTTP/1.0. httpd supporte
689 aussi les fonctionnalités du protocole HTTP/1.1 afin de permettre la mise
690 en cache des réponses négociées.</p>
692 <p>Pour les requêtes en provenance d'un client compatible HTTP/1.0
693 (un navigateur ou un cache), la directive <directive
694 module="mod_negotiation">CacheNegotiatedDocs</directive> peut être utilisée
695 pour permettre la mise en cache des réponses qui ont fait l'objet d'une
696 négociation. Cette directive peut intervenir dans la configuration au
697 niveau du serveur ou de l'hôte virtuel, et n'accepte aucun argument. Elle
698 n'a aucun effet sur les requêtes en provenance de clients HTTP/1.1.</p>
700 <p>Pour les clients HTTP/1.1, httpd envoie un en-tête de réponse HTTP
701 <code>Vary</code> afin d'indiquer les dimensions de la négociation pour
702 cette réponse. Les caches peuvent
703 utiliser cette information afin de déterminer
704 si une requête peut être servie à partir de la copie locale. Pour inciter
705 un cache à utiliser la copie locale sans tenir compte des dimensions de la
706 négociation, définissez la
707 <a href="env.html#special">variable d'environnement</a>
708 <code>force-no-vary</code>.</p>
projects / apache / blob