diff --git a/docs/manual/bind.html.es b/docs/manual/bind.html.es index 93c2ad056a4..bf9a3d2da5c 100644 --- a/docs/manual/bind.html.es +++ b/docs/manual/bind.html.es @@ -20,6 +20,7 @@

Idiomas disponibles: en | es | + fr | ja | ko

@@ -175,6 +176,7 @@

Idiomas disponibles: en | es | + fr | ja | ko

diff --git a/docs/manual/bind.html.fr b/docs/manual/bind.html.fr new file mode 100644 index 00000000000..ec0936f6f75 --- /dev/null +++ b/docs/manual/bind.html.fr @@ -0,0 +1,192 @@ + + + +Liaison - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.0

Liaison

Langues Disponibles: en | + es | + fr | + ja | + ko

+ +

Configuration des adresses et ports sur lesquels Apache écoute.

Informations générales
Précisions au sujet d'IPv6
Faire fonctionner tout ceci avec les Serveurs Virtuels

Voir aussi

Informations générales

Modules Apparentés	Directives Apparentées
`core` `mpm_common`	`<VirtualHost>` `Listen`

+ + + + + +

Au moment de son démarrage, Apache se lie à un port et à une + adresse sur la machine et se met en attente de requêtes entrantes. + Par défaut, toutes les adresses de la machine se retrouvent + à l'écoute. Dans tous les cas, Apache accepte d'écouter sur un + ou plusieurs ports spécifiques, ou sur une seule ou plusieurs + adresses, ou encore une combinaison des deux. + Il est fréquent d'utiliser ces possibilités avec les fonctionnalités + de Serveurs Virtuels, qui permettent de faire répondre Apache de + manière différente en fonction de l'adresse IP, du nom ou du port.

+ +

Le serveur utilise la directive + Listen + pour n'accepter que des requêtes provenant de ports spécifiques ou + d'une combinaison adresse IP + port passés en argument. + Dans le cas où seul un port est spécifié avec la directive + Listen, + le serveur se met à l'écoute sur le port spécifié, sur toutes + les interfaces et adresses de la machine. Si une adresse IP est + précisée en plus du port, le serveur n'écoute que sur l'adresse + et le port spécifiés. Il est possible de configurer plusieurs + directives Listen, + afin qu'Apache écoute sur plusieurs adresses + et ports. Dans ce cas, le serveur répondra aux requêtes faites + sur tous les adresses et ports énumérés.

+ + +

Par exemple, pour que le serveur accepte les connexions à la fois sur + les ports 80 et 8000, spécifiez :

+ +

+ Listen 80 + Listen 8000 +

+ +

Pour qu'Apache accepte les connexions sur deux combinaisons + adresses + ports, spécifiez :

+ +

+ Listen 192.170.2.1:80 + Listen 192.170.2.5:8000 +

+ +

Les adresses IPv6 sont acceptées, pourvu qu'elles soient entourées + entre crochets de la façon suivante :

+ +

+ Listen [fe80::a00:20ff:fea7:ccea]:80 +

Précisions au sujet d'IPv6

+ + +

De plus en plus de plates-formes implémentent IPv6, et APR + supporte IPv6 sur la plupart d'entre elles, si bien qu'Apache + peut utiliser des sockets IPv6 et répondre aux requêtes envoyées + en IPv6.

+ +

Une complication possible pour les administrateurs Apache est de + savoir si un socket IPv6 est capable de gérer les connexions IPv4 + aussi bien qu'IPv6. Gérer les connexions IPv4 sur une socket IPv6 + suppose l'utilisation d'adresses IPv6 mappées en IPv4, ce qui est + le cas sur la plupart des plates-formes, mais pas sur FreeBSD, NetBSD + et OpenBSD, en raison des politiques systèmes de ces plates-formes. + Même sur des systèmes où cette fonctionnalité n'est pas activée par + défaut, un paramètre de compilation pour configure + permet de changer ce comportement pour Apache.

+ +

Pour qu'Apache puisse gérer à la fois les connexions IPv4 et IPv6 + avec un minimum de sockets, il faut permettre l'utilisation des adresses + IPv6 mappées en IPv4, ce qui est faisable en spécifiant l'option + de compilation --enable-v4-mapped et en utilisant la + directive générique Listen + comme suit :

+ +

+ Listen 80 +

+ +

Si --enable-v4-mapped a été spécifié à la compilation, + les directives Listen de la configuration par défaut sont de la forme + ci-dessus. --enable-v4-mapped est l'option de compilation + par défaut sur toutes les plates-formes, sauf pour FreeBSD, NetBSD, et + OpenBSD, donc il est probable que votre Apache ait été compilé avec + cette option.

+ +

Pour qu'Apache ne gère que les connexions IPv4, en ignorant l'éventuel + support IPv6 de la plate-forme ou d'APR, une adresse IPv4 peut être + donnée dans toutes les directives + Listen, comme dans les + exemples suivants :

+ +

+ Listen 0.0.0.0:80 + Listen 192.170.2.1:80 +

+ +

Pour qu'Apache gère les connexions IPv4 et IPv6 sur des sockets + différents (i.e., pour ne pas accepter les adresses IPv6 mappées + en IPv4), spécifiez l'option de compilation + --disable-v4-mapped et utilisez des directives + Listen spécifiques telles que :

+ +

+ Listen [::]:80 + Listen 0.0.0.0:80 +

+ +

Si le paramètre --disable-v4-mapped a été défini + au moment de la compilation, les directives Listen de la + configuration par défaut sont de la forme ci-dessus. + --disable-v4-mapped est l'option de + compilation par défaut sous FreeBSD, NetBSD, et OpenBSD.

+ +

Faire fonctionner tout ceci avec les Serveurs Virtuels

+ + +

La directive Listen + n'implémente aucun Serveur Virtuel. Elle sert simplement à + indiquer au serveur principal sur quels adresses et ports écouter. + Dans le cas où aucune section + <VirtualHost> + n'est utilisée, le serveur répondra de la même manière pour toutes + les requêtes qu'il recevra. + Des sections + <VirtualHost> + peuvent être utilisées pour qu'Apache réagisse différemment selon que la + requête est destinée à telle adresse ou à tel port. Avant d'implémenter + un Serveur Virtuel au moyen de la directive VirtualHost, la directive + Listen doit être configurée pour que le serveur écoute sur l'adresse + ou le port utilisé. Ensuite, une section + <VirtualHost> + devrait être utilisée pour qu'Apache réagisse différemment selon + l'adresse ou le port. + À noter que si un Serveur Virtuel + <VirtualHost> + est configuré sur une adresse et un port sur lesquels le serveur + n'est pas à l'écoute, le Serveur Virtuel ne sera pas accessible.

Langues Disponibles: en | + es | + fr | + ja | + ko

+ \ No newline at end of file diff --git a/docs/manual/bind.html.ja.euc-jp b/docs/manual/bind.html.ja.euc-jp index ecacce9bf78..e32bfaec5a0 100644 --- a/docs/manual/bind.html.ja.euc-jp +++ b/docs/manual/bind.html.ja.euc-jp @@ -20,6 +20,7 @@

Available Languages: en | es | + fr | ja | ko

@@ -181,6 +182,7 @@

Available Languages: en | es | + fr | ja | ko

diff --git a/docs/manual/bind.html.ko.euc-kr b/docs/manual/bind.html.ko.euc-kr index fe1cddb2c06..4a3adf15134 100644 --- a/docs/manual/bind.html.ko.euc-kr +++ b/docs/manual/bind.html.ko.euc-kr @@ -20,6 +20,7 @@

°¡´ÉÇÑ ¾ð¾î: en | es | + fr | ja | ko

@@ -151,6 +152,7 @@

°¡´ÉÇÑ ¾ð¾î: en | es | + fr | ja | ko

diff --git a/docs/manual/bind.xml.meta b/docs/manual/bind.xml.meta index 91ef1f679b7..3fc99a6e4ed 100644 --- a/docs/manual/bind.xml.meta +++ b/docs/manual/bind.xml.meta @@ -8,6 +8,7 @@ en es + fr ja ko diff --git a/docs/manual/configuring.html b/docs/manual/configuring.html index 3ec3186dbc5..34ebcac1929 100644 --- a/docs/manual/configuring.html +++ b/docs/manual/configuring.html @@ -6,6 +6,10 @@ URI: configuring.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 +URI: configuring.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 + URI: configuring.html.ja.euc-jp Content-Language: ja Content-type: text/html; charset=EUC-JP diff --git a/docs/manual/configuring.html.de b/docs/manual/configuring.html.de index 67739389c4e..97ae197836b 100644 --- a/docs/manual/configuring.html.de +++ b/docs/manual/configuring.html.de @@ -20,6 +20,7 @@

Verfügbare Sprachen: de | en | + fr | ja | ko

@@ -175,6 +176,7 @@

Verfügbare Sprachen: de | en | + fr | ja | ko

diff --git a/docs/manual/configuring.html.en b/docs/manual/configuring.html.en index e3a109b0438..41753f111da 100644 --- a/docs/manual/configuring.html.en +++ b/docs/manual/configuring.html.en @@ -20,6 +20,7 @@

Available Languages: de | en | + fr | ja | ko

@@ -159,6 +160,7 @@ HTTP server.

Available Languages: de | en | + fr | ja | ko

diff --git a/docs/manual/configuring.html.fr b/docs/manual/configuring.html.fr new file mode 100644 index 00000000000..9ed0611385e --- /dev/null +++ b/docs/manual/configuring.html.fr @@ -0,0 +1,181 @@ + + + +Fichiers de Configuration - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.0

Fichiers de Configuration

Langues Disponibles: de | + en | + fr | + ja | + ko

+ +

Ce document présente les fichiers utilisés pour la configuration +du serveur HTTP Apache.

Fichiers de Configuration principaux
Syntaxe des fichiers de configuration
Modules
Directives Possibles
Fichiers .htaccess

Fichiers de Configuration principaux

Modules Apparentés	Directives Apparentées
`mod_mime`	`<IfDefine>` `Include` `TypesConfig`

+ + + +

Apache se configure en positionnant des directives dans des fichiers de + configurations, au format texte. Le fichier de configuration principal + est habituellement nommé httpd.conf. + L'emplacement de ce fichier est défini lors de la compilation + mais il est possible de le modifier en ligne de commande au lancement + d'Apache au moyen de l'option -f. + De plus, il est possible d'ajouter d'autres fichiers de configuration au + moyen de la directive Include, + qui accepte des jokers, rendant possible la lecture de multiples + fichiers de configuration. Cette directive peut être incluse dans + n'importe quel fichier de configuration. Les changements apportés + aux fichiers de configuration principale ne seront pris en compte + qu'au démarrage d'Apache ou à son redémarrage.

+ +

Le serveur lit également un fichier contenant les types de documents + mime ; le nom de ce fichier est défini au moyen de la directive + TypesConfig, et son nom + par défaut est mime.types.

Syntaxe des fichiers de configuration

+ + +

Les fichiers de configuration d'Apache contiennent une directive par + ligne. Il est possible d'utiliser le caractère antislash "\" à la fin + d'une ligne pour signaler que celle-ci se continue sur la ligne suivante. + Dans ce cas l'antislash doit impérativement être le tout dernier + caractère de la ligne et ne doit pas être suivi d'espaces.

+ +

Les directives placées dans les fichiers de configuration + ne sont pas sensibles à la casse, mais leurs arguments le sont. + Les lignes commençant par le caractère "#" sont considérées comme + des commentaires, et sont donc ignorées. Il n'est + pas possible d'ajouter un commentaire en fin de + ligne, après une directive. Les lignes vides, ainsi que les + espaces précédant les directives, sont ignorés, ce qui vous + permet d'indenter le fichier pour de simplifier sa lecture.

+ +

Vous pouvez tester vos fichiers de configuration sans + avoir à démarrer le serveur en utilisant la commande + apachectl configtest ou en appelant Apache + avec l'option -t.

Modules

Modules Apparentés	Directives Apparentées
`mod_so`	`<IfModule>` `LoadModule`

+ + + + +

Apache est un serveur modulaire, ce qui signifie que le + noyau du serveur ne dispose que des fonctions des plus basiques. + Toutes les fonctions étendues sont possibles grâce à des modules, qui peuvent être chargés par Apache. + Par défaut, un certain + nombre de modules est fourni et compilé avec le serveur. + Dans le cas où le serveur a été compilé avec le + support dynamique des modules, il est possible de compiler + des modules à part et de les charger au moyen de la directive + LoadModule. Dans le cas + contraire, il faudra recompiler tout Apache pour lui ajouter ou + lui enlever des modules. Des directives peuvent être incluses de + façon conditionnelle selon la présence d'un module particulier en + les positionnant dans un bloc <IfModule>.

+ +

L'option -l, à passer en ligne de commande, provoque + l'affichage des modules qui sont compilés dans Apache.

Directives Possibles

Modules Apparentés	Directives Apparentées
	`<Directory>` `<DirectoryMatch>` `<Files>` `<FilesMatch>` `<Location>` `<LocationMatch>` `<VirtualHost>`

+ + + + +

Les directives positionnées dans les fichiers de configuration principaux + s'appliquent au serveur dans son ensemble. Pour spécifier des directives + spécifiques à une partie du serveur, il est possible de les positionner à + l'intérieur d'une des sections <Directory>, <DirectoryMatch>, <Files>, <FilesMatch>, <Location>, ou <LocationMatch>. + Chacune de ces sections limite la validité des directives qu'elle + contient à la partie du système de fichier ou de l'URL qu'elle + contient. Ces sections peuvent également se contenir les unes les autres, + ce qui permet une configuration très fine.

+ +

Il est possible d'utiliser un seul serveur Apache pour servir plusieurs + sites web, ce qu'on appelle des Serveurs Virtuels. + Les différentes directives peuvent être positionnées à l'intérieur de + sections <VirtualHost>, + afin qu'elles régulent le fonctionnement d'un site (dit virtuel) + particulier.

+ +

La plupart des directives peuvent être positionnées dans toutes les + sections présentées ci-dessus, sauf dans certains cas. Par exemple, + les directives qui contrôlent la création du processus Apache ne + peuvent être placées que dans le contexte du serveur principal. Les + sections possibles pour chaque directive sont décrites au niveau du Contexte de celle-ci. + Des informations plus complètes au sujet du fonctionnement des sections + Directory, Location et Files + sont disponibles ailleurs.

Fichiers .htaccess

Modules Apparentés	Directives Apparentées
	`AccessFileName` `AllowOverride`

+ + + + +

Apache permet de délocaliser la gestion de la configuration, au + moyen de fichiers spéciaux, placés directement dans l'arborescence Web. + Ces fichiers spéciaux portent le plus souvent le nom .htaccess, + mais il est bien sûr possible de changer ce nom au moyen de la directive + AccessFileName. + Les directives positionnées dans un fichier .htaccess + s'appliquent au répertoire le contenant ainsi qu'à tous ses + sous-répertoires. La syntaxe à employer dans un fichier + .htaccess est identique à la syntaxe des fichiers de + configuration principaux. De plus, les fichiers .htaccess + étant lus au moment de chaque requête les concernant, toute + modification de ces fichiers prend effet immédiatement sans qu'il soit + nécessaire de redémarrer le serveur.

+ +

Pour savoir si une directive peut être placée dans un fichier + .htaccess, il suffit de vérifier son Contexte. Il est possible à + l'administrateur du serveur de spécifier quelles directives sont + autorisées ou non dans les fichiers .htaccess, au moyen + de la directive AllowOverride, + positionnée dans les fichiers de configuration principaux.

+ +

Des informations plus complètes concernant les fichiers + .htaccess sont disponible dans le + tutoriel .htaccess.

+ +

Langues Disponibles: de | + en | + fr | + ja | + ko

+ \ No newline at end of file diff --git a/docs/manual/configuring.html.ja.euc-jp b/docs/manual/configuring.html.ja.euc-jp index 3a62ff5dd82..d5496d1f475 100644 --- a/docs/manual/configuring.html.ja.euc-jp +++ b/docs/manual/configuring.html.ja.euc-jp @@ -20,6 +20,7 @@

Available Languages: de | en | + fr | ja | ko

@@ -161,6 +162,7 @@

Available Languages: de | en | + fr | ja | ko

diff --git a/docs/manual/configuring.html.ko.euc-kr b/docs/manual/configuring.html.ko.euc-kr index 4eb6c53f23f..ddca799c5f4 100644 --- a/docs/manual/configuring.html.ko.euc-kr +++ b/docs/manual/configuring.html.ko.euc-kr @@ -20,6 +20,7 @@

°¡´ÉÇÑ ¾ð¾î: de | en | + fr | ja | ko

@@ -142,6 +143,7 @@

°¡´ÉÇÑ ¾ð¾î: de | en | + fr | ja | ko

diff --git a/docs/manual/configuring.xml.meta b/docs/manual/configuring.xml.meta index 201286fae56..619bd975104 100644 --- a/docs/manual/configuring.xml.meta +++ b/docs/manual/configuring.xml.meta @@ -8,6 +8,7 @@ de en + fr ja ko diff --git a/docs/manual/content-negotiation.html b/docs/manual/content-negotiation.html index 3fbf5ee048d..02319b8db62 100644 --- a/docs/manual/content-negotiation.html +++ b/docs/manual/content-negotiation.html @@ -2,6 +2,10 @@ URI: content-negotiation.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 +URI: content-negotiation.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 + URI: content-negotiation.html.ja.euc-jp Content-Language: ja Content-type: text/html; charset=EUC-JP diff --git a/docs/manual/content-negotiation.html.en b/docs/manual/content-negotiation.html.en index 6e182a05e8b..fc84d20afd4 100644 --- a/docs/manual/content-negotiation.html.en +++ b/docs/manual/content-negotiation.html.en @@ -19,6 +19,7 @@ Apache > HTTP Server > Documentation > Version 2.0

Content Negotiation

Available Languages: en | + fr | ja | ko

@@ -663,6 +664,7 @@ factors to 5 decimal places before choosing the best variant.

Available Languages: en | + fr | ja | ko

diff --git a/docs/manual/content-negotiation.html.fr b/docs/manual/content-negotiation.html.fr new file mode 100644 index 00000000000..64816f4b126 --- /dev/null +++ b/docs/manual/content-negotiation.html.fr @@ -0,0 +1,711 @@ + + + +Négociation de Contenus - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.0

Négociation de Contenus

Langues Disponibles: en | + fr | + ja | + ko

+ + +

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.

+ +

C'est le module mod_negotiation qui fournit + la négociation de contenus ; ce module est inclus dans Apache + par défaut.

À propos de la Négociation de Contenus
Négociations avec Apache
Méthodes de Négociations
Tricher sur les Facteurs de Qualité
Extensions vers la Négociation de Contenu +Transparente
À propos des liens hypertextes et des conventions de nommage
À propos des Caches
Plus d'Information

À propos de la Négociation de Contenus

+ +

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

+ +

Accept-Language: fr

+ +

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.

+ +

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) :

+ +

+ Accept-Language: fr; q=1.0, en; q=0.5 + 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 +

+ +

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 + Accept, Accept-Language, + Accept-Charset et Accept-Encoding + 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.

+ +

On appelle ressource 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 + représentations 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 + négociable et chacune de ses représentations + possibles est appelée une variante. + Les différentes possibilités de choisir les variantes d'une ressource + négociable sont appelées dimensions de la + négociation.

Négociations avec Apache

+ +

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 :

+ +

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

+ +

Utilisation d'une Table de Types (Type Map)

+ +

Une table de types est un document qui est associé avec le + gestionnaire type-map (ou, dans les plus anciennes + versions d'Apache, le type mime application/x-type-map). + Notez que pour implémenter cette méthode, un 'handler' doit être + défini dans la configuration pour associer une extension de fichier à + type-map ; ce qui est généralement obtenu au moyen de

+ +

AddHandler type-map .var

+ +

dans le fichier de configuration du serveur.

+ +

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 ; 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 foo.var, puisque + le fichier décrit une ressource appelée foo.

+ +

+ URI: foo + + URI: foo.en.html + Content-type: text/html + Content-language: en + + URI: foo.fr.de.html + Content-type: text/html;charset=iso-8859-2 + Content-language: fr, de +

+ +

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 : "qs", comme dans le cas de + cette image (disponible en JPEG, GIF ou ASCII-art) :

+ +

+ URI: foo + + URI: foo.jpeg + Content-type: image/jpeg; qs=0.8 + + URI: foo.gif + Content-type: image/gif; qs=0.5 + + URI: foo.txt + Content-type: text/plain; qs=0.01 +

+ +

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.

+ +

La liste complète des en-têtes utilisables est disponible + dans la documentation de + mod_negotation.

+ + +

Multiviews

+ +

L'option MultiViews est à spécifier par répertoire, + ce qui signifie qu'elle peut être utilisée au moyen d'une directive + Options dans une section + <Directory>, + <Location> ou + <Files> + du fichier httpd.conf, ou dans les fichiers + .htaccess (à condition que l'option AllowOverride soit paramétrée pour cela). + Notez que Options All n'active pas l'option + MultiViews ; cette dernière doit être positionnée + explicitement.

+ +

Voici comment fonctionne MultiViews : supposons qu'un + serveur reçoive une requête pour /some/dir/foo, que l'option + MultiViews soit activée pour /some/dir, + et que le fichier /some/dir/foo n'existe + pas ; 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.

+ +

L'option MultiViews sert aussi lors du choix d'un + index, lorsque la directive DirectoryIndex est précisée. + Par exemple, si la configuration contient

DirectoryIndex index

le serveur devra choisir entre les fichiers index.html et + index.html3, dans le cas où ces deux fichiers existent. Si + aucun de ces fichiers n'existe, mais qu'un fichier index.cgi + est présent, ce dernier sera exécuté par le serveur.

+ +

Si à la lecture du répertoire, un fichier est trouvé + dont l'extension n'est pas reconnue par mod_mime + 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 MultiViewsMatch. + Cette directive précise en effet quels gestionnaires, filtres, et + autres types d'extensions peuvent contribuer à la négociation + MultiViews.

+ +

Méthodes de Négociations

+ +

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 ; cependant pour + le lecteur intéressé la suite de ce document s'attache à décrire + ce fonctionnement.

+ +

Il existe deux méthodes de négociations :

+ +

La négociation menée par le serveur, selon + l'algorithme d'Apache, 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.
La négociation transparente de contenu + 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.

+ +

Dimensions d'une Négociation

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Dimension	Notes
Type de Média	Le navigateur présente ses préférences au moyen du + champ `Accept` 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").
Langues	Le navigateur présente ses préférences au moyen du champ + `Accept-Language` 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.
Encodage	Le navigateur présente ses préférences au moyen du champ + `Accept-Encoding` de l'en-tête. À chaque élément + peut être associé un facteur de qualité.
Jeu de caractères	Le navigateur présente ses préférences au moyen du champ + `Accept-Charset` 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.

+ + +

Algorithme de Négociation d'Apache

+ +

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 :

+ +

En premier lieu, pour chaque dimension de la négociation, + vérifier le champ d'en-tête Accept* approprié et + attribuer un facteur de qualité à chacune des variantes. Si + l'en-tête Accept* d'une dimension indique que cette + variante n'est pas acceptable, éliminer cette variante. S'il + ne reste aucune variante, aller à l'étape 4.
+ 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. + +
1. Multiplier le facteur de qualité de l'en-tête + Accept 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.
2. Choisir les variantes qui présentent le plus grand + facteur de qualité de langue.
3. Choisir les variantes dont la langue correspond le + mieux, soit à l'ordre de préférence des langues dans + l'en-tête Accept-Language (s'il existe), + soit à l'ordre des langues de la directive + LanguagePriority (si elle existe).
4. 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).
5. Choisir les variantes dont le jeu de caractères est le + meilleur, par rapport à l'en-tête Accept-Charset. + 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 test/* et qui ne sont + pas explicitement associées à un jeu de caractère donné + sont supposées encodées en ISO-8859-1.
6. Choisir les variantes qui ont un jeu de caractères + défini et qui n'est pas ISO-8859-1. + S'il n'existe pas de telles variantes, alors les + choisir toutes.
7. 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.
8. Choisir les variantes présentant la plus petite taille.
9. 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.
+
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 Vary 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.
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 : + "Aucune représentation acceptable") dans un document HTML + présentant les diverses variantes possibles. L'en-tête HTTP + Vary est également renseigné pour présenter les + dimensions de la négociation.

+ +

Tricher sur les Facteurs de Qualité

+ +

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 Accept 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é.

+ +

Types de Médias et Jokers

+ +

L'en-tête de requête Accept: 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 :

+ +

Accept: image/*, */*

+ +

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 :

+ +

+ Accept: text/html, text/plain, image/gif, image/jpeg, */* +

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 :

+ Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01 +

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.

+ +

Si le champ d'en-tête Accept: ne + contient aucun 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 Accept: présente un facteur de qualité, + ces modifications ne sont pas effectuées, + afin que les requêtes des navigateurs qui envoient des + informations correctes fonctionnent comme prévu.

+ + +

Exceptions aux Négociations sur la Langue

+ +

À 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.

+ +

Si un client demande une page du serveur, sans que ce dernier + ne puisse déterminer une page correspondant au champ + Accept-language 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 Accept-language dans ces cas et qu'il + fournisse au client un document qui ne correspond pas + explicitement à sa requête. La directive + ForceLanguagePriority + peut être utilisée pour passer outre à ces deux messages d'erreur + et modifier la réponse du serveur au moyen de la directive + LanguagePriority.

+ +

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 + en-GB pour "British English", le protocole HTTP/1.1 + n'autorise pas le serveur à répondre par un document qui serait + marqué par en. (Notez que présenter + en-GB dans l'en-tête Accept-language + 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 + LanguagePriority + présentée ci-avant, le serveur va ignorer la sous-classe de + langue GB et considérer que la requête + en-GB correspond bien au document en. + Implicitement, Apache ajoute la langue parente (en) + à 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.

+ +

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 variable + d'environnement prefer-language. Si cette + variable existe, et qu'elle précise une langue valide, + mod_negociation cherchera une variante qui + y corresponde. S'il n'en trouve pas, le processus de + négociation normal se déroulera.

+ +

Exemple

+ SetEnvIf Cookie "language=en" prefer-language=en + SetEnvIf Cookie "language=fr" prefer-language=fr +

+ +

Extensions vers la Négociation de Contenu +Transparente

+ +

Apache complète le protocole de négociation de contenu (RFC 2295) +comme décrit ici. Un nouvel élément {encoding ..} 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 +Accept-Encoding. L'implémentation RVSA/1.0 ne tronque +pas les facteurs de qualité à 5 décimales avant de choisir la +meilleure des variantes.

À propos des liens hypertextes et des conventions de nommage

+ +

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 mod_mime + pour plus de détails).

+ +

Habituellement, un fichier a une extension pour son type MIME + (par exemple, html), parfois une extension pour son + encodage (par exemple, gz), et bien sûr une extension + de langue (par exemple, en) pour distinguer les + diverses variantes.

+ +

Exemples :

+ +

foo.en.html
foo.html.en
foo.en.html.gz

+ +

Voici d'autres exemples de noms de fichiers ainsi que des liens + hypertextes valides et invalides :

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Nom de Fichier	Lien valide	Lien invalide
foo.html.en	foo + foo.html	-
foo.en.html	foo	foo.html
foo.html.en.gz	foo + foo.html	foo.gz + foo.html.gz
foo.en.html.gz	foo	foo.html + foo.html.gz + foo.gz
foo.gz.html.en	foo + foo.gz + foo.gz.html	foo.html
foo.html.gz.en	foo + foo.html + foo.html.gz	foo.gz

+ +

Le tableau ci-dessus montre qu'il est toujours possible de + spécifier le lien sans aucune extension dans un lien hypertexte. + (par exemple, foo). 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 html + à shtml ou cgi sans avoir besoin de + modifier aucun lien.

+ +

Pour continuer à utiliser les types MIME dans les liens + (par exemple, foo.html), 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, + foo.html.en).

À propos des Caches

+ +

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.

+ +

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 CacheNegotiatedDocs 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.

Plus d'Information

+ +

Pour plus d'informations au sujet de la négociation de contenu, voir + Language + Negotiation Notes de Alan J. Flavell. Notez que ce + document ne sera peut-être pas mis à jour en fonction des + changements intervenus dans Apache 2.0.

Langues Disponibles: en | + fr | + ja | + ko

+ \ No newline at end of file diff --git a/docs/manual/content-negotiation.html.ja.euc-jp b/docs/manual/content-negotiation.html.ja.euc-jp index 698d436f00a..7b2d162eb03 100644 --- a/docs/manual/content-negotiation.html.ja.euc-jp +++ b/docs/manual/content-negotiation.html.ja.euc-jp @@ -19,6 +19,7 @@ Apache > HTTP ¥µ¡¼¥Ð > ¥É¥¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó > ¥Ð¡¼¥¸¥ç¥ó 2.0

¥³¥ó¥Æ¥ó¥È¥Í¥´¥·¥¨¡¼¥·¥ç¥ó

Available Languages: en | + fr | ja | ko

@@ -711,6 +712,7 @@ RVSA/1.0

Available Languages: en | + fr | ja | ko

³»¿ëÇù»ó (Content Negotiation)

°¡´ÉÇÑ ¾ð¾î: en | + fr | ja | ko

@@ -594,6 +595,7 @@ content-encoding

°¡´ÉÇÑ ¾ð¾î: en | + fr | ja | ko

diff --git a/docs/manual/content-negotiation.xml.meta b/docs/manual/content-negotiation.xml.meta index 98539b1d019..030550e0afb 100644 --- a/docs/manual/content-negotiation.xml.meta +++ b/docs/manual/content-negotiation.xml.meta @@ -7,6 +7,7 @@ en + fr ja ko diff --git a/docs/manual/custom-error.html b/docs/manual/custom-error.html index 3ee08771909..1e57e6c59b9 100644 --- a/docs/manual/custom-error.html +++ b/docs/manual/custom-error.html @@ -6,6 +6,10 @@ URI: custom-error.html.es Content-Language: es Content-type: text/html; charset=ISO-8859-1 +URI: custom-error.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 + URI: custom-error.html.ja.euc-jp Content-Language: ja Content-type: text/html; charset=EUC-JP diff --git a/docs/manual/custom-error.html.en b/docs/manual/custom-error.html.en index 157266e0184..04156b1cc78 100644 --- a/docs/manual/custom-error.html.en +++ b/docs/manual/custom-error.html.en @@ -20,6 +20,7 @@

Available Languages: en | es | + fr | ja | ko

@@ -196,6 +197,7 @@

Available Languages: en | es | + fr | ja | ko

diff --git a/docs/manual/custom-error.html.es b/docs/manual/custom-error.html.es index c18f6921451..ae462e71e3c 100644 --- a/docs/manual/custom-error.html.es +++ b/docs/manual/custom-error.html.es @@ -20,6 +20,7 @@

Idiomas disponibles: en | es | + fr | ja | ko

@@ -211,6 +212,7 @@

Idiomas disponibles: en | es | + fr | ja | ko

diff --git a/docs/manual/custom-error.html.fr b/docs/manual/custom-error.html.fr new file mode 100644 index 00000000000..9c116a5567a --- /dev/null +++ b/docs/manual/custom-error.html.fr @@ -0,0 +1,213 @@ + + + +Personnalisation des Messages d'Erreurs - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.0

Personnalisation des Messages d'Erreurs

Langues Disponibles: en | + es | + fr | + ja | + ko

+ +

Il est possible à un administrateur Apache de configurer les réponses + d'Apache dans les cas où des erreurs ou problèmes se présentent.

+ +

Des réponses paramétrables peuvent être définies pour être activées au + cas où le serveur détecterait une erreur ou un problème.

+ +

Quand un script plante et génère une réponse "500 Server Error", sa + réponse peut être remplacée par un message plus convivial, ou par une + redirection vers une autre URL (locale, ou sur un autre serveur).

Fonctionnement
Configuration
Messages d'Erreurs Personnalisés et Redirections

Fonctionnement

+ + +

Fonctionnement antérieur

+ + +

NCSA httpd 1.3 renvoyait un message d'erreur insipide qui ne + présentait le plus souvent aucun sens ni à l'utilisateur, ni + dans les journaux d'enregistrement sur des symptômes causant + le plantage.

+ + +

Fonctionnement des versions plus récentes

+ + +

Le serveur peut être paramétré pour :

+ +

Afficher un autre message que celui codé dans NCSA, ou bien
procéder à une redirection sur une URL locale, ou bien
procéder à une redirection vers un autre serveur.

+ +

La redirection vers une autre URL peut être utile, mais seulement + si des informations peuvent être envoyées pour expliquer/enregistrer + l'erreur ou le problème plus clairement.

+ +

Pour y parvenir, Apache définit de nouvelles variables + d'environnement CGI :

+ +

+ REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/x-xbitmap, + image/jpeg + REDIRECT_HTTP_USER_AGENT=Mozilla/1.1b2 (X11; I; HP-UX A.09.05 + 9000/712) + REDIRECT_PATH=.:/bin:/usr/local/bin:/etc + REDIRECT_QUERY_STRING= + REDIRECT_REMOTE_ADDR=121.345.78.123 + REDIRECT_REMOTE_HOST=ooh.ahhh.com + REDIRECT_SERVER_NAME=crash.bang.edu + REDIRECT_SERVER_PORT=80 + REDIRECT_SERVER_SOFTWARE=Apache/0.8.15 + REDIRECT_URL=/cgi-bin/buggy.pl +

+ +

Notez que le préfixe REDIRECT_ est présent pour toutes + ces variables d'environnement.

+ +

Au minimum, REDIRECT_URL et + REDIRECT_QUERY_STRING seront passées à la nouvelle + URL (en supposant qu'il s'agisse d'un script CGI ou d'un + include CGI). Les autres variables ne sont définies que si + elles existaient avant l'apparition du problème ou de l'erreur. + Aucune de ces variables ne sera + définie si votre directive ErrorDocument + entraîne une redirection vers un serveur externe ; + tout ce qui commence par http: est considéré comme + une redirection externe, y compris si cela pointe vers le + serveur local.

+ +

Configuration

+ + +

Il est possible d'utiliser la directive + ErrorDocument dans les fichiers + .htaccess si AllowOverride est + paramétrée pour le permettre.

+ +

Voici quelques exemples :

+ +

+ ErrorDocument 500 /cgi-bin/crash-recover + ErrorDocument 500 "Sorry, our script crashed. Oh dear" + ErrorDocument 500 http://xxx/ + ErrorDocument 404 /Lame_excuses/not_found.html + ErrorDocument 401 /Subscription/how_to_subscribe.html +

+ +

La syntaxe à utiliser est :

+ +

+ ErrorDocument <code-à-3-chiffres> <action> +

+ +

où l'action peut désigner :

+ +

Un message à afficher. Le message doit être précédé par + des guillemets ("). Tout ce qui suit ces guillemets est affiché. + Notez que le préfixe (") n'est pas affiché.
Une URL vers un serveur externe, vers lequel la redirection + sera effectuée.
Une URL locale vers laquelle la redirection sera effectuée.

Messages d'Erreurs Personnalisés et Redirections

+ + +

Le fonctionnement d'Apache vis-à-vis des redirections a été + modifié afin que les nouvelles variables d'environnement soient + disponibles pour un script ou un server-include.

+ +

Fonctionnement antérieur

+ + +

Les variables CGI standard étaient passées au script sur + lequel pointe la redirection. Aucune indication sur la + provenance de la redirection n'était fournie.

+ + +

Fonctionnement pour les nouvelles versions

+ + +

Une série de nouvelles variables d'environnement est + initialisée pour être passée au script sur lequel pointe + la redirection. Chacune de ces variables est munie du préfixe + REDIRECT_. Les variables d'environnement + REDIRECT_ sont créées à partir des variables + d'environnement "normales", telles qu'existant avant la + redirection, mais simplement renommées au moyen du préfixe + REDIRECT_ ; ainsi par exemple HTTP_USER_AGENT + devient REDIRECT_HTTP_USER_AGENT. En plus de ces + nouvelles variables, Apache définit REDIRECT_URL + et REDIRECT_status pour aider le script à + comprendre d'où il a été appelé. L'URL d'origine et l'URL + redirigée sont toutes deux ajoutées dans le journal "access".

+ +

Si ErrorDocument précise une redirection + locale vers un script CGI, ce script devrait inclure un + champ "Status:" dans son en-tête de transmission + afin d'assurer que le client reçoive bien le code d'erreur et + puisse comprendre ce qui l'a causé. Par exemple, un script + Perl ErrorDocument pourrait inclure quelque chose comme :

+ +

+ ... + print "Content-type: text/html\n"; + printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"}; + ... +

+ +

Un script dédié à la gestion d'une erreur donnée, + telle que 404 Not Found, peut bien sûr + utiliser le code spécifique d'erreur et le texte associé.

+ +

Notez que le script doit envoyer l'en-tête + Status: appropriée (comme par exemple + 302 Found), si la réponse contient un en-tête + Location: (pour générer la redirection coté client). + Sans cet en-tête Status:, Location: n'aura + pas d'effet.

+ +

Langues Disponibles: en | + es | + fr | + ja | + ko

+ \ No newline at end of file diff --git a/docs/manual/custom-error.html.ja.euc-jp b/docs/manual/custom-error.html.ja.euc-jp index 689da1b9c5f..8be7a2ea120 100644 --- a/docs/manual/custom-error.html.ja.euc-jp +++ b/docs/manual/custom-error.html.ja.euc-jp @@ -20,6 +20,7 @@

Available Languages: en | es | + fr | ja | ko

@@ -189,6 +190,7 @@

Available Languages: en | es | + fr | ja | ko