summaryrefslogtreecommitdiffstats
path: root/rubbos/app/apache2/manual/content-negotiation.html.fr
blob: d800ca77eddf8103280ea1bf71a27caab7092934 (plain)
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
711
712
713
714
715
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="fr" xml:lang="fr"><head><!--
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
              This file is generated from xml source: DO NOT EDIT
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
      -->
<title>N�gociation de Contenus - Serveur Apache HTTP</title>
<link href="./style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
<link href="./style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
<link href="./style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" />
<link href="./images/favicon.ico" rel="shortcut icon" /></head>
<body id="manual-page"><div id="page-header">
<p class="menu"><a href="./mod/">Modules</a> | <a href="./mod/directives.html">Directives</a> | <a href="./faq/">FAQ</a> | <a href="./glossary.html">Glossaire</a> | <a href="./sitemap.html">Plan du site</a></p>
<p class="apache">Serveur Apache HTTP Version 2.0</p>
<img alt="" src="./images/feather.gif" /></div>
<div class="up"><a href="./"><img title="&lt;-" alt="&lt;-" src="./images/left.gif" /></a></div>
<div id="path">
<a href="http://www.apache.org/">Apache</a> &gt; <a href="http://httpd.apache.org/">Serveur HTTP</a> &gt; <a href="http://httpd.apache.org/docs/">Documentation</a> &gt; <a href="./">Version 2.0</a></div><div id="page-content"><div id="preamble"><h1>N�gociation de Contenus</h1>
<div class="toplang">
<p><span>Langues Disponibles: </span><a href="./en/content-negotiation.html" hreflang="en" rel="alternate" title="English">&nbsp;en&nbsp;</a> |
<a href="./fr/content-negotiation.html" title="Fran�ais">&nbsp;fr&nbsp;</a> |
<a href="./ja/content-negotiation.html" hreflang="ja" rel="alternate" title="Japanese">&nbsp;ja&nbsp;</a> |
<a href="./ko/content-negotiation.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a> |
<a href="./tr/content-negotiation.html" hreflang="tr" rel="alternate" title="T�rk�e">&nbsp;tr&nbsp;</a></p>
</div>
<div class="outofdate">Cette traduction peut �tre p�rim�e. Consultez la version
            Anglaise pour les changements r�cents.</div>


    <p>Apache suit les sp�cifications HTTP/1.1 en ce qui concerne 
    les n�gociations de contenus. Il est ainsi possible d'utiliser
    les informations fournies par le navigateur (pr�f�rences de langues,
    jeu de caract�res, encodage et types de m�dias). Apache essaye
    aussi d'optimiser les cas des navigateurs envoyant des 
    informations incompl�tes.</p>

    <p>C'est le module <code class="module"><a href="./mod/mod_negotiation.html">mod_negotiation</a></code> qui fournit
    la n�gociation de contenus&nbsp;; ce module est inclus dans Apache 
    par d�faut.</p>
</div>
<div id="quickview"><ul id="toc"><li><img alt="" src="./images/down.gif" /> <a href="#about">� propos de la N�gociation de Contenus</a></li>
<li><img alt="" src="./images/down.gif" /> <a href="#negotiation">N�gociations avec Apache</a></li>
<li><img alt="" src="./images/down.gif" /> <a href="#methods">M�thodes de N�gociations</a></li>
<li><img alt="" src="./images/down.gif" /> <a href="#better">Tricher sur les Facteurs de Qualit�</a></li>
<li><img alt="" src="./images/down.gif" /> <a href="#extensions">Extensions vers la N�gociation de Contenu
Transparente</a></li>
<li><img alt="" src="./images/down.gif" /> <a href="#naming">� propos des liens hypertextes et des conventions de nommage</a></li>
<li><img alt="" src="./images/down.gif" /> <a href="#caching">� propos des Caches</a></li>
<li><img alt="" src="./images/down.gif" /> <a href="#more">Plus d'Information</a></li>
</ul></div>
<div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="about" id="about">� propos de la N�gociation de Contenus</a></h2>

    <p>Diff�rentes repr�sentations peuvent �tre utilis�es pour 
    communiquer une ressource. Par exemple, plusieurs langues peuvent
    �tre disponibles, ou plusieurs types de m�dias, voire parfois une
    combinaison de ces possibilit�s.
    Une m�thode pour g�rer cela est de donner le choix au visiteur,
    en lui proposant un index g�n�ral, qui lui permet par exemple de
    choisir sa langue. Cependant, il est souvent possible de faire ce 
    choix de mani�re automatique car les navigateurs peuvent pr�ciser 
    avec leurs requ�tes, la repr�sentation qu'ils pr�f�rent recevoir. Par
    exemple, un navigateur pourrait sp�cifier qu'il pr�f�re recevoir les
    informations en fran�ais si elles sont disponibles, ou en anglais 
    dans le cas contraire. Ce type d'information est communiqu� par les
    navigateurs, dans les en-t�tes de chaque requ�te. Un navigateur ne
    demandant que des documents en fran�ais enverrait</p>
    
<div class="example"><p><code>Accept-Language: fr</code></p></div>

    <p>Notez que cette pr�f�rence ne sera g�r�e par le serveur que
    s'il existe un choix de langues du c�t� du serveur.</p>

    <p>Voici un exemple plus complet, o� le navigateur est configur� pour
    accepter le fran�ais et l'anglais, mais avec une pr�f�rence pour le
    fran�ais, et pour accepter divers types de m�dias, en pr�f�rant le 
    HTML au texte brut, et en pr�f�rant le GIF ou le JPEG aux autres types
    de m�dias (sans pour autant refuser ces derniers, le cas �ch�ant)&nbsp;:</p>

<div class="example"><p><code>
  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
</code></p></div>

    <p>Apache supporte les n�gociations de contenus 'g�r�s par
    le serveur', telles que sp�cifi�es dans HTTP/1.1. Les en-t�tes
    <code>Accept</code>, <code>Accept-Language</code>, 
    <code>Accept-Charset</code> et <code>Accept-Encoding</code> 
    sont g�r�s. Apache supporte �galement les n�gociations de 
    contenus 'transparentes', telles que d�finies dans les RFC
    2295 et 2296. En revanche les fonctions de 'feature 
    negotiation' d�finies dans ces RFCs ne sont pas support�es.</p>
    
    <p>On appelle <strong>ressource</strong> une entit� conceptuelle
    identifi�e par un URI (RFC 2396). Le travail d'un serveur HTTP,
    tel Apache, est de donner un acc�s � des 
    <strong>repr�sentations</strong> des ressources � sa disposition,
    chaque repr�sentation �tant envoy�e sous la forme d'une s�quence 
    d'octets d�finie selon un type de m�dia, un jeu de caract�res, 
    un encodage, etc. � tout moment, chaque ressource est associ�e 
    � z�ro, une ou plusieurs repr�sentations. Si plusieurs repr�sentations
    sont disponibles pour une ressource, on dit que cette derni�re est
    <strong>n�gociable</strong> et chacune de ses repr�sentations
    possibles est appel�e une <strong>variante</strong>.
    Les diff�rentes possibilit�s de choisir les variantes d'une ressource
    n�gociable sont appel�es <strong>dimensions</strong> de la 
    n�gociation.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="negotiation" id="negotiation">N�gociations avec Apache</a></h2>

    <p>Pour qu'Apache puisse proc�der � la n�gociation d'une ressource,
    il faut qu'il dispose d'informations � propos de chacune des variantes.
    Deux m�thodes sont possibles&nbsp;:</p>

    <ul>
      <li>R�aliser une "Table de Types" (<em>c'est-�-dire</em>,
      un fichier <code>*.var</code>) qui pr�cise explicitement les fichiers
      d�finissant les variantes, ou</li>
      
      <li>Utiliser une recherche 'MultiViews', m�thode par laquelle
      le serveur r�alise une recherche par motifs implicites,
      et choisit parmi les r�sultats.</li>
    </ul>

   <h3><a name="type-map" id="type-map">Utilisation d'une Table de Types (Type Map)</a></h3>

    <p>Une table de types est un document qui est associ� avec le 
    gestionnaire <code>type-map</code> (ou, dans les plus anciennes 
    versions d'Apache, le type mime <code>application/x-type-map</code>).
    Notez que pour impl�menter cette m�thode, un 'handler' doit �tre
    d�fini dans la configuration pour associer une extension de fichier � 
    <code>type-map</code>&nbsp;; ce qui est g�n�ralement obtenu au moyen de</p>
    
<div class="example"><p><code>AddHandler type-map .var</code></p></div>

    <p>dans le fichier de configuration du serveur.</p>

    <p>Les fichiers de table de types portent g�n�ralement le nom de la 
    ressource qu'ils d�crivent, et contiennent une entr�e correspondant
    � chaque variante possible&nbsp;; ces entr�es sont constitu�es de lignes
    au format d'en-t�tes HTTP. Les entr�es de deux variantes distinctes
    sont � s�parer par des lignes vides. Il n'est pas permis d'utiliser
    des lignes vides au sein d'une entr�e. Il est courant de placer en 
    d�but de fichier une entr�e pour l'entit� combin�e 
    dans son ensemble (bien que cela ne soit pas n�cessaire, et ignor�
    par Apache). Un exemple de fichier de table est donn� en exemple
    ci-apr�s. Le nom de ce fichier serait <code>foo.var</code>, puisque
    le fichier d�crit une ressource appel�e <code>foo</code>.</p>
    
<div class="example"><p><code>
  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 />
</code></p></div>

    <p>Notez que les fichiers de table de types sont toujours
    utilis�s en priorit� par Apache par rapport � l'extension du
    nom du fichier, et ce m�me si l'option Multiviews est activ�e.
    Des variantes pr�sentant des qualit�s in�gales peuvent �tre indiqu�es
    au moyen du param�tre de type de m�dia&nbsp;: "qs", comme dans le cas de 
    cette image (disponible en JPEG, GIF ou ASCII-art)&nbsp;: </p>
    
<div class="example"><p><code>
  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 />
</code></p></div>

    <p>Les valeurs de qs acceptables sont comprises entre 0.000
    et 1.000. Notez qu'une variante avec un qs de 0.000 ne sera
    jamais choisie. La valeur de qs par d�faut est de 1.0. Le
    param�tre qs sert � indiquer la qualit� de la variante, par
    rapport aux autres variantes disponibles, et ce ind�pendamment
    des possibilit�s du navigateur. Par exemple, un fichier JPEG
    est g�n�ralement de meilleure qualit� qu'un fichier ASCII, si
    les 2 documents sont destin�s � repr�senter une photographie.
    Bien s�r, si la ressource originale est elle-m�me un fichier
    ASCII, la repr�sentation ASCII sera consid�r� comme de meilleure
    qualit� que la repr�sentation JPEG. La valeur de qs d�pend donc
    de la nature de la ressource que l'on souhaite repr�senter.</p>
    
    <p>La liste compl�te des en-t�tes utilisables est disponible
    dans la documentation de 
    <a href="mod/mod_negotiation.html#typemaps">mod_negotation</a>.</p>


<h3><a name="multiviews" id="multiviews">Multiviews</a></h3>

    <p>L'option <code>MultiViews</code> est � sp�cifier par r�pertoire,
    ce qui signifie qu'elle peut �tre utilis�e au moyen d'une directive
    <code class="directive"><a href="./mod/core.html#options">Options</a></code> dans une section 
    <code class="directive"><a href="./mod/core.html#directory">&lt;Directory&gt;</a></code>, 
    <code class="directive"><a href="./mod/core.html#location">&lt;Location&gt;</a></code> ou 
    <code class="directive"><a href="./mod/core.html#files">&lt;Files&gt;</a></code> 
    du fichier <code>httpd.conf</code>, ou dans les fichiers 
    <code>.htaccess</code> (� condition que l'option <code class="directive"><a href="./mod/core.html#allowoverride">AllowOverride</a></code> soit param�tr�e pour cela).
    Notez que <code>Options All</code> n'active pas l'option
    <code>MultiViews</code>&nbsp;; cette derni�re doit �tre positionn�e
    explicitement.</p>
    
    <p>Voici comment fonctionne <code>MultiViews</code>&nbsp;: supposons qu'un
    serveur re�oive une requ�te pour <code>/some/dir/foo</code>, que l'option
    <code>MultiViews</code> soit activ�e pour <code>/some/dir</code>, 
    et que le fichier <code>/some/dir/foo</code> <em>n'</em>existe 
    <em>pas</em>&nbsp;; alors le serveur cherche les fichiers nomm�s foo.* 
    dans le r�pertoire /some/dir, et construit une table de types � 
    partir de ces noms de fichiers. Dans la table, chaque fichier se 
    voit assigner les types de m�dias et les encodages de contenu 
    tels qu'ils seraient envoy�s si le client les demandait par leur
    nom propre. Apache choisit alors la meilleure repr�sentation � 
    envoyer au client, en fonction de ses pr�f�rences.</p>
    
    <p>L'option <code>MultiViews</code> sert aussi lors du choix d'un
    index, lorsque la directive <code class="directive"><a href="./mod/mod_dir.html#directoryindex">DirectoryIndex</a></code> est pr�cis�e. 
    Par exemple, si la configuration contient</p>
<div class="example"><p><code>DirectoryIndex index</code></p></div>
    <p>le serveur devra choisir entre les fichiers <code>index.html</code> et
    <code>index.html3</code>, dans le cas o� ces deux fichiers existent. Si
    aucun de ces fichiers n'existe, mais qu'un fichier <code>index.cgi</code>
    est pr�sent, ce dernier sera ex�cut� par le serveur.</p>

    <p>Si � la lecture du r�pertoire, un fichier est trouv� 
    dont l'extension n'est pas reconnue par <code>mod_mime</code> 
    comme pr�cisant son jeu de caract�res, sa langue, son type de 
    contenu (Content-Type) ou son encodage, alors tout d�pendra de la 
    directive <code class="directive"><a href="./mod/mod_mime.html#multiviewsmatch">MultiViewsMatch</a></code>.
    Cette directive pr�cise en effet quels gestionnaires, filtres, et
    autres types d'extensions peuvent contribuer � la n�gociation
    MultiViews.</p>

</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="methods" id="methods">M�thodes de N�gociations</a></h2>

    <p>Apr�s qu'Apache ait d�fini la liste de variantes possibles 
    pour une ressource, que ce soit via un fichier de tables de 
    types ou � partir des noms de fichiers contenus dans le r�pertoire, 
    deux m�thodes peuvent �tre invoqu�es pour choisir la 'meilleure' 
    variante qui sera envoy�e, pour autant qu'il en existe au moins 
    une. Il n'est pas n�cessaire de conna�tre ce fonctionnement pour 
    utiliser les n�gociations de contenu avec Apache&nbsp;; cependant pour 
    le lecteur int�ress� la suite de ce document s'attache � d�crire 
    ce fonctionnement.</p>
    
    <p>Il existe deux m�thodes de n�gociations&nbsp;:</p>

    <ol>
      <li><strong>La n�gociation men�e par le serveur, selon 
      l'algorithme d'Apache</strong>, est utilis�e dans la plupart 
      des cas. L'algorithme d'Apache est d�taill� dans la suite de 
      ce document. Dans les cas o� cet algorithme est utilis�, il 
      arrive qu'Apache 'triche' sur le facteur qualit� (qs) d'une 
      dimension donn�e pour parvenir � un meilleur r�sultat. Les cas 
      o� cela se produit sont pr�sent�s dans la suite de ce document.</li>

      <li><strong>La n�gociation transparente de contenu</strong> 
      est utilis�e sur demande sp�cifique du navigateur, selon la 
      m�thode d�finie dans la RFC 2295. Cette m�thode de n�gociation 
      donne au navigateur les pleins pouvoirs pour choisir la 
      'meilleure' variante, les r�sultats d�pendent donc des algorithmes 
      de choix propres � chaque navigateur. Cette m�thode permet 
      �galement au navigateur de demander � Apache d'utiliser 
      l'algorithme de 's�lection de variante � distance', tel que d�fini 
      par la RFC 2296.</li>
    </ol>
      
<h3><a name="dimensions" id="dimensions">Dimensions d'une N�gociation</a></h3>

    <table>
      
      <tr valign="top">
        <th>Dimension</th>

        <th>Notes</th>
      </tr>

      <tr valign="top">
        <td>Type de M�dia</td>

        <td>Le navigateur pr�sente ses pr�f�rences au moyen du 
        champ <code>Accept</code> de l'en-t�te. � chaque �l�ment peut �tre 
        associ� un facteur de qualit�. De la m�me mani�re, la description 
        de la variante peut pr�senter un facteur de qualit� (le 
        param�tre "qs").</td>
      </tr>

      <tr valign="top">
        <td>Langues</td>

        <td>Le navigateur pr�sente ses pr�f�rences au moyen du champ 
        <code>Accept-Language</code> de l'en-t�te. � chaque �l�ment 
        peut �tre associ� un facteur de qualit�. Les diff�rentes 
        variantes peuvent �galement �tre associ�es ou non � une 
        ou plusieurs langues.</td>
      </tr>

      <tr valign="top">
        <td>Encodage</td>

        <td>Le navigateur pr�sente ses pr�f�rences au moyen du champ 
        <code>Accept-Encoding</code> de l'en-t�te. � chaque �l�ment 
        peut �tre associ� un facteur de qualit�.</td>
      </tr>

      <tr valign="top">
        <td>Jeu de caract�res</td>

        <td>Le navigateur pr�sente ses pr�f�rences au moyen du champ 
        <code>Accept-Charset</code> de l'en-t�te. � chaque �l�ment 
        peut �tre associ� un facteur de qualit�. Les diff�rentes 
        variantes peuvent se voir associer un jeu de caract�res 
        comme type de m�dia.</td>
      </tr>
    </table>


<h3><a name="algorithm" id="algorithm">Algorithme de N�gociation d'Apache</a></h3>

    <p>Apache peut utiliser l'algorithme pr�sent� ci-apr�s pour choisir la
    'meilleure' variante, si elle existe, � renvoyer au navigateur. Cet
    algorithme n'est pas configurable. Il fonctionne de cette mani�re&nbsp;:</p>

    <ol>
      <li>En premier lieu, pour chaque dimension de la n�gociation, 
      v�rifier le champ d'en-t�te <em>Accept*</em> appropri� et 
      attribuer un facteur de qualit� � chacune des variantes. Si 
      l'en-t�te <em>Accept*</em> d'une dimension indique que cette 
      variante n'est pas acceptable, �liminer cette variante. S'il 
      ne reste aucune variante, aller � l'�tape 4.</li>

      <li>
        Choisir la 'meilleure' des variantes par �limination. 
        Chacun des tests suivants est appliqu� dans cet ordre. 
        Toutes les variantes ne passant pas un test sont 
        syst�matiquement �limin�es. Apr�s chacun des tests, s'il 
        ne reste qu'une variante, la choisir comme la meilleure 
        et aller � l'�tape 3. S'il reste plus d'une variante, aller 
        � l'�tape suivante.
	
        <ol>
          <li>Multiplier le facteur de qualit� de l'en-t�te 
          <code>Accept</code> par le facteur qualit� de la source du 
          type de m�dia de cette variante, et choisir les variantes 
          avec le plus grand r�sultat.</li>
	  
          <li>Choisir les variantes qui pr�sentent le plus grand 
          facteur de qualit� de langue.</li>

          <li>Choisir les variantes dont la langue correspond le 
          mieux, soit � l'ordre de pr�f�rence des langues dans 
          l'en-t�te <code>Accept-Language</code> (s'il existe), 
          soit � l'ordre des langues de la directive 
          <code>LanguagePriority</code> (si elle existe).</li>
	  
          <li>Choisir les variantes pr�sentant le param�tre de niveau 
          ('level') de m�dia le plus grand (c'est ce qui est utilis� 
          pour conna�tre la version des types de m�dias text/html).</li>

          <li>Choisir les variantes dont le jeu de caract�res est le 
          meilleur, par rapport � l'en-t�te <code>Accept-Charset</code>. 
          Le jeu de caract�res ISO-8859-1 est toujours acceptable, � 
          moins qu'il n'ait �t� explicitement refus�. Les variantes 
          avec un type de m�dia <code>test/*</code> et qui ne sont 
          pas explicitement associ�es � un jeu de caract�re donn� 
          sont suppos�es encod�es en ISO-8859-1.</li>

          <li>Choisir les variantes qui ont un jeu de caract�res 
          d�fini et qui <em>n'</em>est <em>pas</em> ISO-8859-1. 
          S'il n'existe pas de telles variantes, alors les 
          choisir toutes.</li>

          <li>Choisir les variantes pr�sentant le meilleur encodage. 
          S'il existe des variantes avec un encodage acceptable par 
          le 'user-agent' du navigateur, choisir ces variantes seules. 
          Dans le cas contraire, s'il existe � la fois des variantes 
          encod�es et non encod�es, ne choisir que les variantes 
          non encod�es. Dans les autres cas, choisir toutes les 
          variantes.</li>

          <li>Choisir les variantes pr�sentant la plus petite taille.</li>

          <li>Choisir la premi�re variante de celles qui restent. Ce 
          sera donc soit la premi�re variante list�e dans le fichier 
          des tables de types, soit, si les variantes sont lues d'un 
          r�pertoire, celle dont le nom appara�t en premier dans un 
          classement par code ASCII.</li>
        </ol>
      </li>

      <li>Cet algorithme a permis de choisir la 'meilleure' des 
      variantes, qui est renvoy�e en r�ponse � la requ�te du 
      navigateur. L'en-t�te <code>Vary</code> de la r�ponse HTTP 
      est utilis� pour indiquer les dimensions de la n�gociation 
      (les navigateurs et les serveurs mandataires sont capables de 
      prendre en compte cette information quand il gardent une 
      ressource en cache). Fin des op�rations.</li>
      
      <li>Arriver � ce point signifie qu'aucune variante n'a pu �tre 
      choisie, car aucune n'est acceptable aux yeux du navigateur. 
      Renvoyer une erreur 406 ("No acceptable representation" - NdT&nbsp;: 
      "Aucune repr�sentation acceptable") dans un document HTML 
      pr�sentant les diverses variantes possibles. L'en-t�te HTTP 
      <code>Vary</code> est �galement renseign� pour pr�senter les 
      dimensions de la n�gociation.</li>
    </ol>

</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="better" id="better">Tricher sur les Facteurs de Qualit�</a></h2>

    <p>Il arrive qu'Apache modifie les facteurs de qualit� par rapport 
    � la valeur qu'ils devraient avoir en suivant strictement 
    l'algorithme d�crit plus haut. Ceci permet d'obtenir de meilleurs 
    r�sultats pour g�rer les navigateurs qui n'envoient pas toutes 
    les informations ou envoient des informations erron�es. Ainsi, 
    certains navigateurs, parmi les plus r�pandus du march�, envoient 
    des en-t�tes <code>Accept</code> qui entra�neraient l'envoi de la 
    mauvaise variante dans de nombreux cas. Si le navigateur envoie 
    des informations correctes, Apache ne trichera pas sur les facteurs 
    de qualit�.</p>

<h3><a name="wildcards" id="wildcards">Types de M�dias et Jokers</a></h3>

    <p>L'en-t�te de requ�te <code>Accept:</code> indique les pr�f�rences 
    des types de m�dias. Elle peut comporter des 'jokers' tels que 
    "image/*" ou "*/*", o� * signifie "n'importe quoi". Ainsi, une 
    requ�te pr�sentant&nbsp;:</p>

<div class="example"><p><code>Accept: image/*, */*</code></p></div>

    <p>signifierait que tout type commen�ant par "image/" est 
    acceptable, comme serait acceptable tout autre type. Certains 
    navigateurs envoient sans arr�t des jokers en plus des types 
    qu'ils peuvent effectivement g�rer. Par exemple&nbsp;:</p>

<div class="example"><p><code>
  Accept: text/html, text/plain, image/gif, image/jpeg, */*
</code></p></div>
    <p>Le but de ces informations est d'indiquer que les types 
    explicitement cit�s sont les pr�f�r�s mais que le 
    navigateur accepte �galement d'autres repr�sentations. 
    En utilisant les facteurs de qualit�, voici ce que devrait 
    envoyer le navigateur&nbsp;:</p>
<div class="example"><p><code>
  Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01
</code></p></div>
    <p>Les types explicitement cit�s ne pr�sentent pas de facteur 
    de qualit�, ils re�oivent donc la valeur par d�faut de 1.0 
    (la plus haute valeur possible). Les jokers sont affect�s 
    d'une pr�f�rence tr�s basse de 0.01, si bien que les autres 
    types ne seront utilis�s que si aucune des variantes ne 
    correspond � un des types explicitement pr�f�r�s.</p>

    <p>Si le champ d'en-t�te <code>Accept:</code> <em>ne</em> 
    contient <em>aucun</em> facteur de qualit�, Apache modifie 
    le facteur de qualit� de "*/*" (s'il est pr�sent) en 0.01 
    afin d'�muler le comportement souhait�. Apache positionne 
    �galement le facteur de qualit� des jokers qui se pr�sentent 
    sous la forme "type/*" en 0.02 (afin que ces derniers soient 
    pr�f�r�s � "*/*"). Si un seul ou plusieurs types de m�dia de 
    l'en-t�te <code>Accept:</code> pr�sente un facteur de qualit�, 
    ces modifications <em>ne</em> sont <em>pas</em> effectu�es, 
    afin que les requ�tes des navigateurs qui envoient des 
    informations correctes fonctionnent comme pr�vu.</p>


<h3><a name="exceptions" id="exceptions">Exceptions aux N�gociations sur la Langue</a></h3>

    <p>� partir d'Apache 2.0, certaines exceptions ont �t� ajout�es 
    � l'algorithme de n�gociation afin de retomber �l�gamment sur 
    nos pattes dans les cas o� la n�gociation sur la langue 
    n'aboutit pas.</p>
    
    <p>Si un client demande une page du serveur, sans que ce dernier 
    ne puisse d�terminer une page correspondant au champ 
    <code>Accept-language</code> envoy� par le navigateur, le serveur 
    doit renvoyer une r�ponse parmi "Pas de Variante Acceptable" 
    et "Choix Multiples" au client. Afin d'�viter ces messages 
    d'erreur, il est possible de configurer Apache pour qu'il ignore 
    le champ <code>Accept-language</code> dans ces cas et qu'il 
    fournisse au client un document qui ne correspond pas 
    explicitement � sa requ�te. La directive 
    <code class="directive"><a href="./mod/mod_negotiation.html#forcelanguagepriority">ForceLanguagePriority</a></code> 
    peut �tre utilis�e pour passer outre � ces deux messages d'erreur 
    et modifier la r�ponse du serveur au moyen de la directive 
    <code class="directive"><a href="./mod/mod_negotiation.html#languagepriority">LanguagePriority</a></code>.</p>

    <p>Le serveur va �galement essayer de modifier la sous-classe 
    de langue si aucune correspondance n'est trouv�e. Par exemple, 
    dans le cas o� un client demande des documents avec le langage 
    <code>en-GB</code> pour "British English", le protocole HTTP/1.1 
    n'autorise pas le serveur � r�pondre par un document qui serait 
    marqu� par <code>en</code>. (Notez que pr�senter 
    <code>en-GB</code> dans l'en-t�te <code>Accept-language</code> 
    est loin d'�tre pertinent, il semble tr�s peu probable que le 
    lecteur comprenne l'anglais "British" et ne comprenne pas 
    l'anglais "tout court". Il se trouve malheureusement que 
    beaucoup de navigateurs pr�sentent ce comportement.) Bref, 
    si aucune autre langue ne correspond et que le serveur 
    s'appr�terait normalement � envoyer une r�ponse d'erreur 
    "No Acceptable Variants", ou � utiliser la m�thode 
    <code class="directive"><a href="./mod/mod_negociation.html#languagepriority">LanguagePriority</a></code> 
    pr�sent�e ci-avant, le serveur va ignorer la sous-classe de 
    langue <code>GB</code> et consid�rer que la requ�te 
    <code>en-GB</code> correspond bien au document <code>en</code>. 
    Implicitement, Apache ajoute la langue parente (<code>en</code>) 
    � la liste des langues consid�r�es comme acceptables par le 
    navigateur, avec un facteur de qualit� tr�s faible. Notez 
    cependant que si le client demande "en-GB; qs=0.9, fr; qs=0.8", 
    et que le serveur dispose de documents marqu�s comme "en" et 
    "fr", alors le document en fran�ais sera renvoy� par le serveur. 
    Ce comportement est n�cessaire, afin de garder la compatibilit� 
    avec HTTP/1.1 et fonctionner avec les navigateurs correctement 
    configur�s.</p>
    
    <p>Pour supporter les techniques avanc�es de d�tection de
    pr�f�rence de langues de l'utilisateur (telles que les 
    Cookies, ou les chemins d'URL sp�ciaux), Apache reconna�t 
    depuis la version 2.0.47 la <a href="env.html">variable 
    d'environnement</a> <code>prefer-language</code>. Si cette 
    variable existe, et qu'elle pr�cise une langue valide, 
    <code class="module"><a href="./mod/mod_negociation.html">mod_negociation</a></code> cherchera une variante qui 
    y corresponde. S'il n'en trouve pas, le processus de 
    n�gociation normal se d�roulera.</p>

    <div class="example"><h3>Exemple</h3><p><code>
      SetEnvIf Cookie "language=en" prefer-language=en<br />
      SetEnvIf Cookie "language=fr" prefer-language=fr
    </code></p></div>

</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="extensions" id="extensions">Extensions vers la N�gociation de Contenu
Transparente</a></h2>

<p>Apache compl�te le protocole de n�gociation de contenu (RFC 2295) 
comme d�crit ici. Un nouvel �l�ment <code>{encoding ..}</code> est 
utilis� dans la liste des variantes pour nommer celles qui ne sont 
disponibles que sous un encodage sp�cifique. L'impl�mentation de 
l'algorithme RVSA/1.0 (RFC 2296) est �tendue afin d'int�grer les 
variantes encod�es dans la liste, et de les proposer comme 
candidates quand leur encodage est acceptable au vu de l'en-t�te 
<code>Accept-Encoding</code>. L'impl�mentation RVSA/1.0 ne tronque 
pas les facteurs de qualit� � 5 d�cimales avant de choisir la 
meilleure des variantes.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="naming" id="naming">� propos des liens hypertextes et des conventions de nommage</a></h2>

    <p>Dans le cas o� la n�gociation de langues est utilis�e, il est 
    possible de choisir diverses conventions de nommage, car les 
    fichiers peuvent pr�senter plus d'une extension, et l'ordre des 
    extensions n'est normalement pas significatif (voir la 
    documentation <a href="mod/mod_mime.html#multipleext">mod_mime</a> 
    pour plus de d�tails).</p>

    <p>Habituellement, un fichier a une extension pour son type MIME 
    (par exemple, <code>html</code>), parfois une extension pour son 
    encodage (par exemple, <code>gz</code>), et bien s�r une extension 
    de langue (par exemple, <code>en</code>) pour distinguer les 
    diverses variantes.</p>

    <p>Exemples&nbsp;:</p>

    <ul>
      <li>foo.en.html</li>

      <li>foo.html.en</li>

      <li>foo.en.html.gz</li>
    </ul>

    <p>Voici d'autres exemples de noms de fichiers ainsi que des liens
    hypertextes valides et invalides&nbsp;:</p>

    <table class="bordered">
      
      <tr>
        <th>Nom de 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>Le tableau ci-dessus montre qu'il est toujours possible de 
    sp�cifier le lien sans aucune extension dans un lien hypertexte. 
    (par exemple, <code>foo</code>). L'avantage en est qu'il est 
    ainsi possible de ne pas montrer le type d'un document, et de 
    le modifier ult�rieurement, par exemple le passer de <code>html</code> 
    � <code>shtml</code> ou <code>cgi</code> sans avoir besoin de 
    modifier aucun lien.</p>
    
    <p>Pour continuer � utiliser les types MIME dans les liens 
    (par exemple, <code>foo.html</code>), l'extension correspondant 
    � la langue (ainsi que l'extension d'encodage, si elle existe) 
    doit �tre du cot� droit de l'extension du type MIME (par exemple, 
    <code>foo.html.en</code>).</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="caching" id="caching">� propos des Caches</a></h2>

    <p>Quand un cache garde en m�moire une repr�sentation, il l'associe 
    � l'URL de la requ�te. Quand la m�me URL vient � �tre redemand�e, 
    le cache peut utiliser la repr�sentation gard�e en m�moire, plut�t 
    que de refaire une requ�te au serveur. Cependant, si la ressource 
    est n�gociable cot� serveur, le r�sultat pourrait en �tre que la 
    r�ponse � la premi�re requ�te mise en cache serait renvoy�e de 
    fa�on erron�e. Pour pr�venir ce probl�me, Apache marque toutes 
    les r�ponses issues d'une n�gociation comme "non-cachables" par 
    les clients HTTP/1.0. Apache supporte les sp�cifications du 
    protocole HTTP/1.1 en ce qui concerne la mise en cache des 
    r�ponses n�goci�es.</p>

    <p>Les requ�tes venant d'un client conforme au protocole HTTP/1.0 
    (qu'il s'agisse d'un navigateur ou d'un serveur cache) peuvent 
    �tre rendues "cachables" si la directive <code class="directive"><a href="./mod/mod_negociation.html#cachenegotiateddocs">CacheNegotiatedDocs</a></code> est 
    utilis�e. Cette directive peut �tre sp�cifi�e aussi bien dans 
    la configuration principale du serveur que dans un serveur 
    virtuel, et ne n�cessite pas d'argument. Elle n'a aucun impact 
    sur les requ�tes des clients fonctionnant en HTTP/1.1.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="more" id="more">Plus d'Information</a></h2>

    <p>Pour plus d'informations au sujet de la n�gociation de contenu, voir
    <a href="http://ppewww.ph.gla.ac.uk/~flavell/www/lang-neg.html">Language
    Negotiation Notes</a> de Alan J. Flavell. Notez que ce 
    document ne sera peut-�tre pas mis � jour en fonction des 
    changements intervenus dans Apache 2.0.</p>
</div></div>
<div class="bottomlang">
<p><span>Langues Disponibles: </span><a href="./en/content-negotiation.html" hreflang="en" rel="alternate" title="English">&nbsp;en&nbsp;</a> |
<a href="./fr/content-negotiation.html" title="Fran�ais">&nbsp;fr&nbsp;</a> |
<a href="./ja/content-negotiation.html" hreflang="ja" rel="alternate" title="Japanese">&nbsp;ja&nbsp;</a> |
<a href="./ko/content-negotiation.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a> |
<a href="./tr/content-negotiation.html" hreflang="tr" rel="alternate" title="T�rk�e">&nbsp;tr&nbsp;</a></p>
</div><div id="footer">
<p class="apache">Copyright 2009 The Apache Software Foundation.<br />Autoris� sous <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
<p class="menu"><a href="./mod/">Modules</a> | <a href="./mod/directives.html">Directives</a> | <a href="./faq/">FAQ</a> | <a href="./glossary.html">Glossaire</a> | <a href="./sitemap.html">Plan du site</a></p></div>
</body></html>