From: Lucien Gentis 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. La négociation de contenu est assurée par le module
- Apache HTTPD prend en charge 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. La négociation de contenu est assurée par le module
+ 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
+ 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
+ ce choix automatiquement. Cela 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.
+ 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 :
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 +
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.
-À 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 :
+à 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 :
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 +
httpd prend en charge 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 à renvoyer pour la ressource
+ demandée. Il prend entièrement en charge les en-têtes de requête
Accept
, Accept-Language
,
Accept-Charset
et Accept-Encoding
.
- 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.
Une ressource est une entité conceptuelle identifiée - par une URI (RFC 2396). Un serveur HTTP comme le serveur HTTP Apache - propose l'accès à des - représentations 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 - négociable et chacune de ses représentations se nomme - variante. Les différences entre les - variantes disponibles d'une ressource négociable constituent les - dimensions de la négociation.
+ httpd prend aussi en charge 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 prend pas en charge la négociation de fonctionnalité (feature negotiation) + telle qu'elle est définie dans ces RFCs. + +Une ressource est une entité conceptuelle identifiée + par un URI (RFC 2396). Un serveur HTTP comme le serveur HTTP Apache + propose l'accès à des + représentations 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. à 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 + négociable et chacune de ses représentations se nomme + variante. Les différences entre les + variantes disponibles d'une ressource négociable constituent les + dimensions de la négociation.
-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 :
+Pour négocier une ressource, on doit fournir au serveur des + informations à propos de chacune des variantes. Il y a deux manières + d'y parvenir :
*.var
) qui nomme explicitement les fichiers
contenant les variantes, ouUne liste de correspondances de types est un document associé au
- gestionnaire type-map
(ou, dans un souci de compatibilité
+
Une liste de correspondances de types est un document associé au
+ gestionnaire type-map
(ou, dans un souci de compatibilité
ascendante avec des configurations de httpd plus anciennes, le
application/x-type-map
). Notez que pour utiliser cette
- fonctionnalité, vous devez, dans le fichier de configuration, définir un
- gestionnaire qui associe un suffixe de fichier à une type-map
;
+ fonctionnalité, vous devez, dans le fichier de configuration, définir un
+ gestionnaire qui associe un suffixe de fichier à une type-map
,
ce qui se fait simplement en ajoutant
dans le fichier de configuration du serveur.
-Les fichiers de correspondances de types doivent posséder le même nom que - la ressource qu'ils décrivent, avec pour extension +
Les fichiers de correspondances de types doivent posséder le même nom que
+ la ressource qu'ils décrivent, avec pour extension
.var
. Dans l'exemple ci-dessous, la ressource a pour
nom foo
, et le fichier de correspondances se nomme donc
foo.var
.
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 +
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 + correspondances de types est fourni ci-dessous.
-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 +
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 + relatifs pour tout fichier situé sur le même serveur que le fichier de correspondances.
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 + 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) :
@@ -189,19 +189,19 @@ Content-type: text/plain; qs=0.01Les 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.
- -La liste complète des en-têtes reconnus est disponible dans la +
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.
+ +La liste complète des en-têtes reconnus est disponible dans la documentation sur les correspondances de types du module mod_negotiation.
@@ -209,88 +209,88 @@MultiViews
est une option qui s'applique à un répertoire,
- ce qui signifie qu'elle peut être activée à l'aide d'une directive
-
MultiViews
est une option qui s'applique à un répertoire,
+ ce qui signifie qu'elle peut être activée à l'aide d'une directive
+ httpd.conf
, ou (si .htaccess
. Notez que Options All
- n'active pas MultiViews
; vous devez activer cette option en
+ n'active pas MultiViews
; vous devez activer cette option en
la nommant explicitement.
L'effet de MultiViews
est le suivant : si le serveur reçoit
- une requête pour /tel/répertoire/foo
, si
- MultiViews
est activée pour
- /tel/répertoire
, et si
- /tel/répertoire/foo
n'existe pas, 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
+
L'effet de MultiViews
est le suivant : si le serveur reçoit
+ une requête pour /tel/répertoire/foo
, si
+ MultiViews
est activée pour
+ /tel/répertoire
et si
+ /tel/répertoire/foo
n'existe pas, 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.
MultiViews
peut aussi s'appliquer à la recherche du fichier
- nommé par la directive MultiViews
peut aussi s'appliquer à la recherche du fichier
+ nommé par la directive
le serveur va choisir entre index.html
- et index.html3
si les deux fichiers sont présents. Si aucun
- n'est présent, mais index.cgi
existe,
- le serveur l'exécutera.
index.html3
si les deux fichiers sont présents. Si aucun
+ n'est présent, alors quâindex.cgi
existe,
+ le serveur l'exécutera.
Si, parcequ'elle n'est pas reconnue par mod_mime
,
- 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
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).
+Une fois obtenue la liste des variantes pour une ressource donnée, + httpd dispose de deux méthodes pour choisir la meilleure variante à + renvoyer, s'il y a lieu, soit à partir d'un fichier de + correspondances de types, soit en se basant sur les noms de fichier 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).
-Il existe deux méthodes de négociation :
+Il existe deux méthodes de négociation :
Type de média | +Type de média | -Le navigateur affiche ses préférences à l'aide du champ d'en-tête
- Accept . 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"). |
+ Le navigateur affiche ses préférences à l'aide du champ d'en-tête
+ Accept . 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 »). |
Langage | -Le navigateur affiche ses préférences à l'aide du champ d'en-tête
- Accept-Language . Chaque langue peut se voir associé un facteur de
- qualité. Les variantes peuvent être associées avec zéro, un ou
+ | Le navigateur affiche ses préférences à l'aide du champ d'en-tête
+ Accept-Language . Chaque langue peut se voir associé un facteur de
+ qualité. Les variantes peuvent être associées avec zéro, un ou
plusieurs langages. |
|
Encoding | +Encodage | -Le navigateur affiche ses préférences à l'aide du champ d'en-tête
- Accept-Encoding . Chaque encodage peut se voir associé un facteur de
- qualité. |
+ Le navigateur affiche ses préférences à l'aide du champ d'en-tête
+ Accept-Encoding . Chaque encodage peut se voir associé un facteur de
+ qualité. |
Charset | +Jeu de caractères | -Le navigateur affiche ses préférences à l'aide du champ d'en-tête
- Accept-Charset . 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. |
+ Le navigateur affiche ses préférences à l'aide du champ d'en-tête
+ Accept-Charset . 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. |
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 +
httpd peut utiliser l'algorithme suivant pour choisir la « meilleure » + variante (s'il y en a une) à renvoyer au navigateur. Cet algorithme n'est pas configurable. Il fonctionne comme suit :
Accept
par le facteur de qualité "qs" pour le type de
- média de ces variantes, et choisir la variante qui possède la valeur
+ Accept
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.Accept-Language
(s'il existe), ou de la directive
LanguagePriority
(si elle existe).Accept-Charset
. Le jeu de
- caractères ISO-8859-1 est acceptable sauf s'il est explicitement
- exclus. Les variantes avec un type de média text/*
- mais non explicitement associées avec un jeu de caractères
- particulier sont supposées être en ISO-8859-1.Accept-Charset
. Le jeu de
+ caractères ISO-8859-1 est acceptable sauf s'il est explicitement
+ exclus. Les variantes avec un type de média text/*
+ mais non explicitement associées avec un jeu de caractères
+ particulier sont supposées être en ISO-8859-1.Vary
de la réponse est renseigné de façon à
- indiquer les dimensions de la négociation (les navigateurs et les caches
+ Vary
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é.Vary
de façon à indiquer les dimensions de la variante.Vary
de façon à indiquer les dimensions de la variante.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. +
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, cela afin dâ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 Accept
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.
Accept
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.
-L'en-tête de requête Accept:
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 :
L'en-tête de requête Accept:
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 :
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. +
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 :
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 +
Cela 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 :
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é.
- -Si l'en-tête Accept:
ne contient pas 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 Accept:
contient un facteur de
- qualité, ces valeurs spéciales ne seront pas appliquées, de façon
- à ce que les requêtes de navigateurs qui envoient les informations
- explicites à prendre en compte fonctionnent comme souhaité.
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 + renvoyés + que s'il n'existe pas de variante correspondant à un type explicitement + listé.
+ +Si l'en-tête Accept:
ne contient pas de
+ facteur de qualité, httpd positionne la valeur de qualité de
+ « */* », si présent, à 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 Accept:
contient un facteur de
+ qualité, ces valeurs spéciales ne seront pas appliquées, de façon
+ à ce que les requêtes de navigateurs qui envoient les informations
+ explicites à prendre en compte fonctionnent comme souhaité.
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.
+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.
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
- Accept-language
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 Accept-language
et fournisse
- tout de même un document, même s'il ne correspond pas exactement à la
+ parvient pas à trouver une page dont la langue correspond à l'en-tête
+ Accept-language
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 que,
+ dans ces cas, il ignore l'en-tête Accept-language
et fournisse
+ tout de même un document, même s'il ne correspond pas exactement à la
demande explicite du client. La directive
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 en-GB
, 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 en
.
- (Notez qu'inclure en-GB
et non en
dans l'en-tête
+
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 en-GB
, 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 en
+ (notez qu'inclure en-GB
et non en
dans l'en-tête
Accept-Language
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 en-GB
à des documents en en
. 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
+ la spécification du sous-ensemble de langage et associera la demande en
+ en-GB
à des documents en en
. Implicitement,
+ httpd ajoute le langage parent à la liste de langages 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 si le serveur dispose de
+ documents estampillés « en » et « fr », c'est le document « fr » qui sera
+ renvoyé, tout cela dans un souci de compatibilité avec la spécification
HTTP/1.1 et afin de fonctionner efficacement avec les clients
- correctement configurés.
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
Pour prendre en charge 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 prefer-language
- depuis la version 2.0.47 de httpd. Si elle est définie et contient un
- symbole de langage approprié,
httpd étend le protocole de négociation de contenu transparente (RFC
-2295) comme suit. Un nouvel élément {encodage ..}
est utilisé dans
+
httpd étend le protocole de négociation de contenu transparente (RFC
+2295) comme suit. Un nouvel élément {encodage ..}
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
-Accept-Encoding
. L'implémentation RVSA/1.0 n'arrondit pas les
-facteurs de qualité calculés à 5 décimales avant d'avoir choisi la meilleure
+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
+Accept-Encoding
. 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.
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 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 mod_mime - pour plus de détails).
+ pour plus de détails). -Un fichier type possède une extension liée au type MIME +
Un fichier type possède une extension liée au type MIME
(par exemple, html
), mais parfois aussi une
- extension liée à l'encodage (par exemple, gz
),
- et bien sûr une extension liée au langage
+ extension liée à l'encodage (par exemple, gz
),
+ et bien sûr une extension liée au langage
(par exemple, en
) quand plusieurs variantes de
langage sont disponibles pour ce fichier.
Ci-dessous d'autres exemples de noms de fichiers avec des liens - hypertextes valides et invalides :
+ hypertextes valables et non valables :