1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
|
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<!-- English Revision : 1174747 -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<manualpage metafile="content-negotiation.xml.meta">
<title>Négociation de contenu</title>
<summary>
<p>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.</p>
<p>La négociation de contenu est assurée par le module
<module>mod_negotiation</module> qui est compilé par défaut
dans le serveur.</p>
</summary>
<section id="about"><title>À propos de la négociation de contenu</title>
<p>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 :</p>
<example>Accept-Language: fr</example>
<p>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.</p>
<p>À 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 :</p>
<example>
Accept-Language: fr; q=1.0, en; q=0.5<br />
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
</example>
<p>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
<code>Accept</code>, <code>Accept-Language</code>,
<code>Accept-Charset</code> et <code>Accept-Encoding</code>.
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.</p>
<p>Une <strong>ressource</strong> est une entité conceptuelle identifiée
par une URI (RFC 2396). Un serveur HTTP comme le serveur HTTP Apache
propose l'accès à des
<strong>représentations</strong> 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
<strong>négociable</strong> et chacune de ses représentations se nomme
<strong>variante</strong>. Les différences entre les
variantes disponibles d'une ressource négociable constituent les
<strong>dimensions</strong> de la négociation.</p>
</section>
<section id="negotiation"><title>La négociation avec httpd</title>
<p>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 :</p>
<ul>
<li>Utiliser une liste de correspondances de type ("type-map") (<em>c'est à dire</em>
un fichier <code>*.var</code>) qui nomme explicitement les fichiers
contenant les variantes, ou</li>
<li>Utiliser une recherche "multivues", où le serveur effectue une
recherche de correspondance sur un motif de nom de fichier implicite et
fait son choix parmi les différents résultats.</li>
</ul>
<section id="type-map"><title>Utilisation d'un fichier de
correspondances de types (type-map)</title>
<p>Une liste de correspondances de types est un document associé au
gestionnaire <code>type-map</code> (ou, dans un souci de compatibilité
ascendante avec des configurations de httpd plus anciennes, le
<glossary>type MIME</glossary>
<code>application/x-type-map</code>). Notez que pour utiliser cette
fonctionnalité, vous devez, dans le fichier de configuration, définir un
gestionnaire qui associe un suffixe de fichier à une <code>type-map</code>;
ce qui se fait simplement en ajoutant</p>
<example>AddHandler type-map .var</example>
<p>dans le fichier de configuration du serveur.</p>
<p>Les fichiers de correspondances de types doivent posséder le même nom que
la ressource qu'ils décrivent, avec pour extension
<code>.var</code>. Dans l'exemple ci-dessous, la ressource a pour
nom <code>foo</code>, et le fichier de correspondances se nomme donc
<code>foo.var</code>.</p>
<p>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.</p>
<p>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.</p>
<example>
URI: foo<br />
<br />
URI: foo.en.html<br />
Content-type: text/html<br />
Content-language: en<br />
<br />
URI: foo.fr.de.html<br />
Content-type: text/html;charset=iso-8859-2<br />
Content-language: fr, de<br />
</example>
<p>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) : </p>
<example>
URI: foo<br />
<br />
URI: foo.jpeg<br />
Content-type: image/jpeg; qs=0.8<br />
<br />
URI: foo.gif<br />
Content-type: image/gif; qs=0.5<br />
<br />
URI: foo.txt<br />
Content-type: text/plain; qs=0.01<br />
</example>
<p>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.</p>
<p>La liste complète des en-têtes reconnus est disponible dans la
documentation sur les <a
href="mod/mod_negotiation.html#typemaps">correspondances de types du
module mod_negotiation</a>.</p>
</section>
<section id="multiviews"><title>Multivues (option Multiviews)</title>
<p><code>MultiViews</code> est une option qui s'applique à un répertoire,
ce qui signifie qu'elle peut être activée à l'aide d'une directive
<directive module="core">Options</directive> à l'intérieur d'une section
<directive module="core"
type="section">Directory</directive>, <directive module="core"
type="section">Location</directive> ou <directive module="core"
type="section">Files</directive> dans
<code>httpd.conf</code>, ou (si <directive
module="core">AllowOverride</directive> est correctement positionnée) dans
des fichiers
<code>.htaccess</code>. Notez que <code>Options All</code>
n'active pas <code>MultiViews</code>; vous devez activer cette option en
la nommant explicitement.</p>
<p>L'effet de <code>MultiViews</code> est le suivant : si le serveur reçoit
une requête pour <code>/tel/répertoire/foo</code>, si
<code>MultiViews</code> est activée pour
<code>/tel/répertoire</code>, et si
<code>/tel/répertoire/foo</code> n'existe <em>pas</em>, 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.</p>
<p><code>MultiViews</code> peut aussi s'appliquer à la recherche du fichier
nommé par la directive <directive
module="mod_dir">DirectoryIndex</directive>, si le serveur tente d'indexer
un répertoire. Si les fichiers de configuration spécifient</p>
<example>DirectoryIndex index</example>
<p>le serveur va choisir entre <code>index.html</code>
et <code>index.html3</code> si les deux fichiers sont présents. Si aucun
n'est présent, mais <code>index.cgi</code> existe,
le serveur l'exécutera.</p>
<p>Si, parcequ'elle n'est pas reconnue par <code>mod_mime</code>,
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 <directive
module="mod_mime">MultiViewsMatch</directive>. Cette directive détermine
si les gestionnaires (handlers), les filtres, et autres types d'extensions
peuvent participer à la négociation MultiVues.</p>
</section>
</section>
<section id="methods"><title>Les méthodes de négociation</title>
<p>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
correspondances de types, soit en se basant sur les noms de fichiers du
répertoire. Il n'est pas nécessaire de connaître en détails comment la
négociation fonctionne réellement pour pouvoir utiliser les fonctionnalités
de négociation de contenu de httpd. La suite de ce document explique
cependant les méthodes utilisées pour ceux ou celles qui sont
intéressés(ées). </p>
<p>Il existe deux méthodes de négociation :</p>
<ol>
<li><strong>La négociation effectuée par le serveur selon l'algorithme
de httpd</strong> est normalement utilisée. l'algorithme de
httpd est
expliqué plus en détails ci-dessous. Quand cet algorithme est utilisé,
httpd peut parfois "bricoler" le facteur de qualité (qs) d'une dimension
particulière afin d'obtenir un meilleur résultat.
La manière dont httpd peut modifier les facteurs de qualité est
expliquée plus en détails ci-dessous.</li>
<li><strong>La négociation de contenu transparente</strong> est utilisée
quand le navigateur le demande explicitement selon le mécanisme défini
dans la RFC 2295. Cette méthode de négociation donne au navigateur le
contrôle total du choix de la meilleure variante; le résultat dépend
cependant de la spécificité des algorithmes utilisés par le navigateur.
Au cours du processus de négociation transparente, le navigateur peut
demander à httpd d'exécuter l'"algorithme de sélection de variante à
distance" défini dans la RFC 2296.</li>
</ol>
<section id="dimensions"><title>Les dimensions de la négociation</title>
<table>
<columnspec><column width=".15"/><column width=".85"/></columnspec>
<tr valign="top">
<th>Dimension</th>
<th>Notes</th>
</tr>
<tr valign="top">
<td>Type de média</td>
<td>Le navigateur affiche ses préférences à l'aide du champ d'en-tête
<code>Accept</code>. Chaque type de média peut se voir associé un facteur de
qualité. La description de la variante peut aussi avoir un facteur de
qualité (le paramètre "qs").</td>
</tr>
<tr valign="top">
<td>Langage</td>
<td>Le navigateur affiche ses préférences à l'aide du champ d'en-tête
<code>Accept-Language</code>. Chaque langue peut se voir associé un facteur de
qualité. Les variantes peuvent être associées avec zéro, un ou
plusieurs langages.</td>
</tr>
<tr valign="top">
<td>Encoding</td>
<td>Le navigateur affiche ses préférences à l'aide du champ d'en-tête
<code>Accept-Encoding</code>. Chaque encodage peut se voir associé un facteur de
qualité.</td>
</tr>
<tr valign="top">
<td>Charset</td>
<td>Le navigateur affiche ses préférences à l'aide du champ d'en-tête
<code>Accept-Charset</code>. Chaque jeu de caractère peut se voir associé un facteur de
qualité. Les variantes peuvent préciser un jeu de caractères comme
paramètre du type de média.</td>
</tr>
</table>
</section>
<section id="algorithm"><title>L'algorithme de négociation de
httpd</title>
<p>httpd peut utiliser l'algorithme suivant pour choisir la "meilleure"
variante (s'il y en a une) à retourner au navigateur. Cet algorithme n'est pas
configurable. Il fonctionne comme suit :</p>
<ol>
<li>En premier lieu, pour chaque dimension de la négociation, consulter
le champ d'en-tête <em>Accept*</em> approprié et assigner une qualité à
chaque variante. Si l'en-tête <em>Accept*</em> pour toute dimension
implique que la variante n'est pas acceptable, éliminer cette dernière.
S'il ne reste plus de variante, aller à l'étape 4.</li>
<li>
Choisir la "meilleure" variante par élimination. Chacun des tests
suivants est effectué dans cet ordre. Toute variante non sélectionnée
à l'issue d'un test est éliminée. Après chaque test, s'il reste une
seule variante, choisir cette dernière comme celle qui correspond le
mieux puis aller à l'étape 3. S'il reste plusieurs variantes, passer
au test suivant.
<ol>
<li>Multiplier le facteur de qualité de l'en-tête
<code>Accept</code> par le facteur de qualité "qs" pour le type de
média de ces variantes, et choisir la variante qui possède la valeur
la plus importante.</li>
<li>Sélectionner les variantes qui possèdent le facteur de qualité
de langage le plus haut.</li>
<li>Sélectionner les variantes dont le langage correspond le mieux,
en se basant sur l'ordre des langages de l'en-tête
<code>Accept-Language</code> (s'il existe), ou de la directive
<code>LanguagePriority</code> (si elle existe).</li>
<li>Sélectionner les variantes possédant le paramètre de média
"level" le plus élevé (utilisé pour préciser la version des types de
média text/html).</li>
<li>Sélectionner les variantes possédant le paramètre de média
"charset" (jeu de caractères) qui correspond le mieux, en se basant
sur la ligne d'en-tête <code>Accept-Charset</code> . Le jeu de
caractères ISO-8859-1 est acceptable sauf s'il est explicitement
exclus. Les variantes avec un type de média <code>text/*</code>
mais non explicitement associées avec un jeu de caractères
particulier sont supposées être en ISO-8859-1.</li>
<li>Sélectionner les variantes dont le paramètre de média "charset"
associé n'est <em>pas</em> ISO-8859-1. S'il n'en existe pas,
sélectionner toutes les variantes.</li>
<li>Sélectionner les variantes avec le meilleur encodage. S'il existe
des variantes avec un encodage acceptable pour le client,
sélectionner celles-ci. Sinon, s'il existe des variantes encodées et
des variantes non encodées, ne sélectionner que les variantes non
encodées. Si toutes les variantes sont encodées ou si aucune
ne l'est, sélectionner toutes les variantes.</li>
<li>Sélectionner les variantes dont le contenu a la longueur
la plus courte.</li>
<li>Sélectionner la première des variantes restantes. Il s'agira
soit de la première variante listée dans le fichier de
correspondances de types, soit, quand les variantes sont lues depuis
le répertoire, la première par ordre alphabétique quand elles sont
triées selon le code ASCII.</li>
</ol>
</li>
<li>L'algorithme a maintenant sélectionné une variante considérée comme
la "meilleure", il la retourne donc au client en guise de réponse.
L'en-tête HTTP <code>Vary</code> de la réponse est renseigné de façon à
indiquer les dimensions de la négociation (les navigateurs et les caches
peuvent utiliser cette information lors de la mise en cache de la
ressource). Travail terminé.</li>
<li>Le passage par cette étape signifie qu'aucune variante n'a été
sélectionnée (parcequ'aucune n'est acceptable pour le navigateur).
Envoyer une réponse avec un code de statut 406 (qui signifie "Aucune
représentation acceptable") et un corps comportant un document HTML qui
affiche les variantes disponibles. Renseigner aussi l'en-tête HTTP
<code>Vary</code> de façon à indiquer les dimensions de la variante.</li>
</ol>
</section>
</section>
<section id="better"><title>Ajustement des valeurs de qualité</title>
<p>Parfois httpd modifie les valeurs de qualité par rapport à celles qui
découleraient d'une stricte interprétation de l'algorithme de négociation
de httpd ci-dessus, ceci pour améliorer les résultats de l'algorithme pour
les navigateurs qui envoient des informations incomplètes ou inappropriées.
Certains des navigateurs les plus populaires envoient des informations dans
l'en-tête <code>Accept</code> qui, sans ce traitement, provoqueraient la
sélection d'une variante inappropriée dans de nombreux cas. Quand un
navigateur envoie des informations complètes et correctes ces ajustements
ne sont pas effectués.</p>
<section id="wildcards"><title>Types de média et caractères génériques</title>
<p>L'en-tête de requête <code>Accept:</code> indique les types de média
souhaités. Il peut aussi contenir des types de média avec caractères
génériques, comme "image/*" ou "*/*" où * correspond à n'importe quelle
chaîne de caractères. Ainsi une requête contenant :</p>
<example>Accept: image/*, */*</example>
<p>indiquerait que tout type de média est acceptable, avec une préférence
pour les types commençant par "image/".
Certains navigateurs ajoutent par défaut des types de média avec caractères
génériques aux types explicitement nommés qu'ils peuvent gérer.
Par exemple :</p>
<example>
Accept: text/html, text/plain, image/gif, image/jpeg, */*
</example>
<p>Ceci indique que les types explicitement listés sont préférés, mais
qu'une représentation avec un type différent de ces derniers conviendra
aussi. Les valeurs de qualités explicites,
afin de préciser ce que veut vraiment le navigateur, s'utilisent
comme suit :</p>
<example>
Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01
</example>
<p>Les types explicites n'ont pas de facteur de qualité, la valeur par
défaut de leur préférence est donc de 1.0 (la plus haute). Le type avec
caractères génériques */* se voit attribuer une préférence basse de 0.01,
si bien que les types autres que ceux explicitement listés ne seront retournés
que s'il n'existe pas de variante correspondant à un type explicitement
listé.</p>
<p>Si l'en-tête <code>Accept:</code> ne contient <em>pas</em> aucun
facteur de qualité, httpd positionne la valeur de qualité de
"*/*", si present, à 0.01 pour simuler l'effet désiré. Il positionne aussi
la valeur de qualité des types avec caractères génériques au format
"type/*" à 0.02 (ils sont donc préférés à ceux correspondant à "*/*"). Si
un type de média dans l'en-tête <code>Accept:</code> contient un facteur de
qualité, ces valeurs spéciales ne seront <em>pas</em> appliquées, de façon
à ce que les requêtes de navigateurs qui envoient les informations
explicites à prendre en compte fonctionnent comme souhaité.</p>
</section>
<section id="exceptions"><title>Exceptions dans la négociation du
langage</title>
<p>A partir de la version 2.0 de httpd, certaines exceptions ont été
ajoutées à l'algorithme de négociation afin de ménager une issue de secours
quand la négociation ne trouve aucun langage correspondant.</p>
<p>Quand un client demande une page sur votre serveur, si ce dernier ne
parvient pas à trouver une page dont la langue corresponde à l'en-tête
<code>Accept-language</code> envoyé par le navigateur, il enverra au client
une réponse "Aucune variante acceptable" ou "Plusieurs choix possibles".
Pour éviter ces
messages d'erreur, il est possible de configurer httpd de façon à ce que,
dans ces cas, il ignore l'en-tête <code>Accept-language</code> et fournisse
tout de même un document, même s'il ne correspond pas exactement à la
demande explicite du client. La directive <directive
module="mod_negotiation">ForceLanguagePriority</directive>
peut être utilisée pour éviter ces messages d'erreur et leur substituer une
page dont le langage sera déterminé en fonction du contenu de la directive
<directive module="mod_negotiation">LanguagePriority</directive>.</p>
<p>Le serveur va aussi essayer d'étendre sa recherche de correspondance aux
sous-ensembles de langages quand aucune correspondance exacte ne peut être
trouvée. Par exemple, si un client demande des documents possédant le
langage <code>en-GB</code>, c'est à dire anglais britannique, le standard
HTTP/1.1 n'autorise normalement pas le serveur à faire correspondre cette
demande à un document dont le langage est simplement <code>en</code>.
(Notez qu'inclure <code>en-GB</code> et non <code>en</code> dans l'en-tête
<code>Accept-Language</code> constitue une quasi-erreur de configuration,
car il est très peu probable qu'un lecteur qui comprend l'anglais
britannique, ne comprenne pas l'anglais en général. Malheureusement, de
nombreux clients ont réellement des configurations par défaut de ce type.)
Cependant, si aucune autre correspondance de langage n'est possible, et que le
serveur est sur le point de retourner une erreur "Aucune variable
acceptable" ou de choisir le langage défini par la directive <directive
module="mod_negotiation">LanguagePriority</directive>, le serveur ignorera
la spécification du sous-ensemble de langage et associera la demande en
<code>en-GB</code> à des documents en <code>en</code>. Implicitement,
httpd ajoute le langage parent à la liste de langues acceptés par le
client avec une valeur de qualité très basse. Notez cependant que si le
client demande "en-GB; q=0.9, fr; q=0.8", et le serveur dispose de
documents estampillés "en" et "fr", alors c'est le document "fr" qui sera
retourné, tout ceci dans un souci de compatibilité avec la spécification
HTTP/1.1 et afin de fonctionner efficacement avec les clients
correctement configurés.</p>
<p>Pour supporter les techniques avancées (comme les cookies ou les chemins
d'URL spéciaux) afin de déterminer le langage préféré de l'utilisateur, le
module <module>mod_negotiation</module> reconnaît la
<a href="env.html">variable d'environnement</a>
<code>prefer-language</code>
depuis la version 2.0.47 de httpd. Si elle est définie et contient un
symbole de langage approprié, <module>mod_negotiation</module> va essayer
de sélectionner une variante correspondante. S'il n'existe pas de telle
variante, le processus normal de négociation sera lancé.</p>
<example><title>Exemple</title>
SetEnvIf Cookie "language=(.+)" prefer-language=$1<br />
Header append Vary cookie
</example>
</section>
</section>
<section id="extensions"><title>Extensions à la négociation de contenu
transparente</title>
<p>httpd étend le protocole de négociation de contenu transparente (RFC
2295) comme suit. Un nouvel élément <code>{encodage ..}</code> est utilisé dans
les listes de variantes pour marquer celles qui ne sont disponibles qu'avec un
encodage de contenu spécifique. L'implémentation de l'algorithme
RVSA/1.0 (RFC 2296) est étendue à la reconnaissance de variantes encodées dans
la liste, et à leur utilisation en tant que variantes candidates à partir du
moment où leur encodage satisfait au contenu de l'en-tête de requête
<code>Accept-Encoding</code>. L'implémentation RVSA/1.0 n'arrondit pas les
facteurs de qualité calculés à 5 décimales avant d'avoir choisi la meilleure
variante.</p>
</section>
<section id="naming"><title>Remarques à propos des liens hypertextes et des
conventions de nommage</title>
<p>Si vous utilisez la négociation de langage, vous avez le choix entre
différentes conventions de nommage, car les fichiers peuvent posséder
plusieurs extensions, et l'ordre dans lequel ces dernières apparaissent
est en général sans rapport (voir la documentation sur le module <a
href="mod/mod_mime.html#multipleext">mod_mime</a>
pour plus de détails).</p>
<p>Un fichier type possède une extension liée au type MIME
(<em>par exemple</em>, <code>html</code>), mais parfois aussi une
extension liée à l'encodage (<em>par exemple</em>, <code>gz</code>),
et bien sûr une extension liée au langage
(<em>par exemple</em>, <code>en</code>) quand plusieurs variantes de
langage sont disponibles pour ce fichier.</p>
<p>Exemples :</p>
<ul>
<li>foo.en.html</li>
<li>foo.html.en</li>
<li>foo.en.html.gz</li>
</ul>
<p>Ci-dessous d'autres exemples de noms de fichiers avec des liens
hypertextes valides et invalides :</p>
<table border="1" cellpadding="8" cellspacing="0">
<columnspec><column width=".2"/><column width=".2"/>
<column width=".2"/></columnspec>
<tr>
<th>Nom fichier</th>
<th>lien valide</th>
<th>Lien invalide</th>
</tr>
<tr>
<td><em>foo.html.en</em></td>
<td>foo<br />
foo.html</td>
<td>-</td>
</tr>
<tr>
<td><em>foo.en.html</em></td>
<td>foo</td>
<td>foo.html</td>
</tr>
<tr>
<td><em>foo.html.en.gz</em></td>
<td>foo<br />
foo.html</td>
<td>foo.gz<br />
foo.html.gz</td>
</tr>
<tr>
<td><em>foo.en.html.gz</em></td>
<td>foo</td>
<td>foo.html<br />
foo.html.gz<br />
foo.gz</td>
</tr>
<tr>
<td><em>foo.gz.html.en</em></td>
<td>foo<br />
foo.gz<br />
foo.gz.html</td>
<td>foo.html</td>
</tr>
<tr>
<td><em>foo.html.gz.en</em></td>
<td>foo<br />
foo.html<br />
foo.html.gz</td>
<td>foo.gz</td>
</tr>
</table>
<p>En regardant la table ci-dessus, vous remarquerez qu'il est toujours
possible d'utiliser le nom de fichier sans extension dans un lien
(<em>par exemple</em>, <code>foo</code>). L'avantage est de pouvoir
dissimuler le type réel du fichier associé à un document et de pouvoir
le modifier
ultérieurement, <em>par exemple</em>, de <code>html</code> à
<code>shtml</code> ou <code>cgi</code> sans avoir à
mettre à jour aucun lien.</p>
<p>Si vous souhaitez continuer à utiliser un type MIME dans vos liens
(<em>par exemple </em> <code>foo.html</code>), l'extension liée au langage
(y compris une extension liée à l'encodage s'il en existe une)
doit se trouver à droite de l'extension liée au type MIME
(<em>par exemple</em>, <code>foo.html.en</code>).</p>
</section>
<section id="caching"><title>Remarque sur la mise en cache</title>
<p>Quand un cache stocke une représentation, il l'associe avec l'URL de la
requête. Lorsque cette URL est à nouveau demandée, le cache peut utiliser
la représentation stockée. Cependant, si la ressource est négociable au
niveau du serveur, il se peut que seule la première variante demandée soit
mise en cache et de ce fait, la correspondance positive du cache peut
entraîner une réponse inappropriée. Pour
éviter ceci, httpd marque par
défaut toutes les réponses qui sont retournées après une négociation de
contenu comme "non-cachables" par les clients HTTP/1.0. httpd supporte
aussi les fonctionnalités du protocole HTTP/1.1 afin de permettre la mise
en cache des réponses négociées.</p>
<p>Pour les requêtes en provenance d'un client compatible HTTP/1.0
(un navigateur ou un cache), la directive <directive
module="mod_negotiation">CacheNegotiatedDocs</directive> peut être utilisée
pour permettre la mise en cache des réponses qui ont fait l'objet d'une
négociation. Cette directive peut intervenir dans la configuration au
niveau du serveur ou de l'hôte virtuel, et n'accepte aucun argument. Elle
n'a aucun effet sur les requêtes en provenance de clients HTTP/1.1.</p>
<p>Pour les clients HTTP/1.1, httpd envoie un en-tête de réponse HTTP
<code>Vary</code> afin d'indiquer les dimensions de la négociation pour
cette réponse. Les caches peuvent
utiliser cette information afin de déterminer
si une requête peut être servie à partir de la copie locale. Pour inciter
un cache à utiliser la copie locale sans tenir compte des dimensions de la
négociation, définissez la
<a href="env.html#special">variable d'environnement</a>
<code>force-no-vary</code>.</p>
</section>
</manualpage>
|