Modules Apparentés	Directives Apparentées
`mod_cache` `mod_mem_cache` `mod_disk_cache` `mod_file_cache`	`CacheEnable` `CacheDisable` `MMapStatic` `CacheFile` `CacheFile` `UseCanonicalName` `CacheNegotiatedDocs`

Modules Apparentés	Directives Apparentées
`mod_file_cache` `mod_mem_cache`	`CacheFile` `CacheEnable` `CacheDisable`

Modules Apparentés	Directives Apparentées
`mod_mem_cache` `mod_file_cache`	`CacheEnable` `CacheDisable` `MMapStatic`

Modules Apparentés	Directives Apparentées
`mod_disk_cache`	`CacheEnable` `CacheDisable`

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

@@ -176,6 +177,7 @@

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

diff --git a/docs/manual/configuring.html.en b/docs/manual/configuring.html.en index 4ab83ed5f0d..01b621d8157 100644 --- a/docs/manual/configuring.html.en +++ b/docs/manual/configuring.html.en @@ -20,6 +20,7 @@

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

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

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

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

+Apache > Serveur HTTP > Documentation > Version 2.3

Fichiers de configuration

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

+ +

Ce document décrit les fichiers utilisés pour configurer +le Serveur HTTP Apache.

Fichiers de configuration principaux
Syntaxe des fichiers de configuration
Modules
Portée des directives
Fichiers .htaccess

Fichiers de configuration principaux

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

+ + + +

La configuration d'Apache est effectuée en plaçant des directives dans des fichiers de + configuration au format texte. Le fichier de configuration principal se nomme + en général + httpd.conf. La localisation de ce fichier est définie + à la compilation, mais peut être redéfinie à l'aide de l'option + de ligne de commande -f. En outre, d'autres fichiers de + configuration peuvent être ajoutés à l'aide de la directive + Include, et des caractères de + remplacement + peuvent être utilisés pour inclure de nombreux fichiers de configuration. + Des directives de tous types peuvent être placées dans chacun de ces fichiers + de configuration. Les modifications dans les fichiers de configuration + principaux ne sont prises en compte par Apache que lorsque le serveur + est démarré ou redémarré.

+ +

Le serveur lit aussi un fichier contenant les types de document mime; + ce fichier est défini par la directive TypesConfig, + et se nomme mime.types par défaut.

Syntaxe des fichiers de configuration

+ + +

Les fichiers de configuration d'Apache contiennent une directive + par ligne. + On peut utiliser l'anti-slash "\" comme dernier caractère d'une ligne + pour indiquer que la directive continue à la ligne suivante. + Il ne doit y avoir aucun caractère ni espace entre l'anti-slash et + la fin de la ligne.

+ +

Les directives dans les fichiers de configuration ne sont pas + sensibles à la casse, mais leurs arguments le sont souvent. Les lignes + qui débutent par le caractère "#" sont interprétées comme des + commentaires, et sont ignorées. Les commentaires ne doivent + pas être inclus dans une ligne après une directive + de configuration. Les lignes vides et les espaces précédant une directive + sont ignorés; vous pouvez par conséquent indenter les directives + afin d'améliorer la lisibilité.

+ +

Vous pouvez vérifier l'absence d'erreurs de syntaxe dans vos fichiers + de configuration sans démarrer le serveur à l'aide de la commande + apachectl configtest ou de l'option de ligne de commande + -t.

Modules

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

+ + + + +

Apache est un serveur modulaire. Ceci implique que seules les + fonctionnalités les plus courantes sont incluses dans le serveur de base. + Les fonctionnalités étendues sont fournies à l'aide de modules qui peuvent être chargés dans Apache. + Par défaut, un jeu de modules de base est inclus dans le + serveur à la compilation. Si le serveur est compilé de façon à utiliser + les modules chargés dynamiquement, + alors les modules peuvent être compilés séparément et chargés à + n'importe quel moment à l'aide de la directive + LoadModule. + Dans le cas contraire, Apache doit être recompilé pour ajouter ou + supprimer des modules. + Les directives de configuration peuvent être incluses de manière + conditionnelle selon la présence ou l'absence d'un module particulier + en les plaçant dans un bloc <IfModule>.

+ +

Pour voir quels modules ont été compilés avec le serveur, + vous pouvez utiliser l'option de ligne de commande -l.

Portée des directives

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

+ + + + +

Les directives placées dans les fichiers de configuration principaux + s'appliquent au serveur dans son ensemble. Si vous souhaitez modifier la + configuration d'une partie du serveur seulement, vous pouvez limiter la + portée de vos directives en les plaçant dans une section + <Directory>, <DirectoryMatch>, <Files>, <FilesMatch>, <Location>, ou <LocationMatch>. + Ces sections limitent le champ d'application des directives qu'elles + contiennent à des URls ou des portions du système de fichiers particulières. + Elles peuvent aussi être imbriquées, ce qui permet + une configuration très fine.

+ +

Apache peut servir simultanément de nombreux sites web au travers des + Hôtes Virtuels. La portée des directives peut ainsi + être limitée en les plaçant dans des sections + <VirtualHost>, + afin qu'elles ne s'appliquent qu'aux requêtes + pour un site web particulier.

+ +

Bien que la plupart des directives puissent être placées dans + chacune de ces sections, certaines d'entre elles n'ont aucun sens + dans certains contextes. + Par exemple, les directives qui contrôlent la création des processus + n'ont de sens que dans le contexte du serveur principal. Pour déterminer + quelles directives peuvent être placées dans quelles sections, consultez + le Contexte de la + directive. Pour plus d'informations, nous fournissons des détails dans + Comment fonctionnent les sections Directory, + Location et Files.

Fichiers .htaccess

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

+ + + + +

Apache permet la gestion décentralisée de la configuration + via des fichiers spéciaux placés dans l'arborescence du site web. + Ces fichiers spéciaux se nomment en général .htaccess, + mais tout autre nom peut être spécifié à l'aide de la directive + AccessFileName. + Les directives placées dans les fichiers .htaccess + s'appliquent au répertoire dans lequel vous avez placé le fichier, + ainsi qu'à tous ses sous-répertoires. + La syntaxe des fichiers .htaccess est la même que celle + des fichiers de configuration principaux. Comme les fichiers + .htaccess sont lus à chaque requête, les modifications de + ces fichiers prennent effet immédiatement.

+ +

Pour déterminer quelles directives peuvent être placées + dans les fichiers .htaccess, consultez le + Contexte de la + directive. L'administrateur du serveur peut contrôler quelles + directives peuvent être placées dans les fichiers + .htaccess en définissant la directive + AllowOverride + dans les fichiers de configuration principaux.

+ +

Pour plus d'informations sur les fichiers .htaccess, + se référer au tutoriel .htaccess.

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

+ \ No newline at end of file diff --git a/docs/manual/configuring.html.ja.utf8 b/docs/manual/configuring.html.ja.utf8 index 8863a87d899..08b7b178d23 100644 --- a/docs/manual/configuring.html.ja.utf8 +++ b/docs/manual/configuring.html.ja.utf8 @@ -21,6 +21,7 @@

è¨èª: de | en | + fr | ja | ko | tr

@@ -165,6 +166,7 @@

è¨èª: de | en | + fr | ja | ko | tr

diff --git a/docs/manual/configuring.html.ko.euc-kr b/docs/manual/configuring.html.ko.euc-kr index 73168df45ce..810230d8e53 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 | tr

@@ -143,6 +144,7 @@

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

diff --git a/docs/manual/configuring.html.tr.utf8 b/docs/manual/configuring.html.tr.utf8 index eca26cbba2b..11e85a859fe 100644 --- a/docs/manual/configuring.html.tr.utf8 +++ b/docs/manual/configuring.html.tr.utf8 @@ -20,6 +20,7 @@

Mevcut Diller: de | en | + fr | ja | ko | tr

@@ -90,6 +91,7 @@

Mevcut Diller: de | en | + fr | ja | ko | tr

diff --git a/docs/manual/configuring.xml.meta b/docs/manual/configuring.xml.meta index 7d5488ca49f..cc22438e3d2 100644 --- a/docs/manual/configuring.xml.meta +++ b/docs/manual/configuring.xml.meta @@ -9,6 +9,7 @@ de en + fr ja ko tr diff --git a/docs/manual/dso.html b/docs/manual/dso.html index 6cc9403fe4f..dc0861821c8 100644 --- a/docs/manual/dso.html +++ b/docs/manual/dso.html @@ -4,6 +4,10 @@ URI: dso.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 +URI: dso.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 + URI: dso.html.ja.utf8 Content-Language: ja Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/dso.html.en b/docs/manual/dso.html.en index b9901c89262..58c7a80abbb 100644 --- a/docs/manual/dso.html.en +++ b/docs/manual/dso.html.en @@ -19,6 +19,7 @@ Apache > HTTP Server > Documentation > Version 2.3

Dynamic Shared Object (DSO) Support

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

@@ -308,6 +309,7 @@ $ apxs -i -a -n foo mod_foo.la

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

diff --git a/docs/manual/dso.html.fr b/docs/manual/dso.html.fr new file mode 100644 index 00000000000..86fc15e9009 --- /dev/null +++ b/docs/manual/dso.html.fr @@ -0,0 +1,332 @@ + + + +Support des objets dynamiques partagés (DSO) - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.3

Support des objets dynamiques partagés (DSO)

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

+ +

La conception modulaire du serveur HTTP Apache permet à l'administrateur + de choisir les fonctionnalités à inclure dans le serveur en sélectionnant + un certain nombre de modules. Les modules peuvent être soit intégrés + statiquement dans le binaire httpd lors de la + compilation du serveur, soit compilés en tant qu'objets + dynamiques partagés (DSOs) qui existeront indépendamment du binaire + principal httpd. Les modules DSO peuvent être compilés + au moment de la construction du serveur, ou bien compilés séparément, + à l'aide de l'utilitaire des extensions d'Apache (apxs), + et associés au serveur ultérieurement.

+ +

Ce document décrit l'utilisation des modules DSO ainsi que les dessous + de leur fonctionnement.

Implémentation
Mode d'emploi succinct
Les dessous du fonctionnement des DSO
Avantages et inconvénients

Implémentation

Modules Apparentés	Directives Apparentées
`mod_so`	`LoadModule`

+ + + +

Le support DSO pour le chargement de modules individuels d'Apache est + assuré par un module nommé mod_so qui doit être compilé + statiquement dans le coeur d'Apache. Il s'agit du seul module avec le + module core à ne pas pouvoir être compilé en tant que + module DSO lui-même. Pratiquement tous les autres modules d'Apache + distribués peuvent être compilés en tant que modules DSO en sélectionnant + pour chacun d'entre eux le mode de construction DSO à l'aide de l'option + --enable-module=shared du script + configure, comme décrit dans la + Documentation de l'installation. Une fois + compilé en tant que module DSO, un module peut être chargé en mémoire au + démarrage ou redémarrage du serveur à l'aide de la commande + LoadModule du module + mod_so, placée + dans votre fichier httpd.conf.

+ +

Un nouvel utilitaire a été introduit afin de simplifier la création de + fichiers DSO pour les modules d'Apache + (particulièrement pour les modules tiers) ; il s'agit du programme nommé + apxs (APache + eXtenSion). On peut l'utiliser pour construire des modules de type + DSO en dehors de l'arborescence des sources d'Apache. L'idée est + simple : à l'installation d'Apache, la procédure make install + du script configure installe les fichiers d'en-têtes + d'Apache et positionne, pour la plateforme de compilation, les drapeaux du compilateur et de + l'éditeur de liens à l'intérieur du programme + apxs, qui sera utilisé pour la construction de fichiers DSO. + Il est ainsi possible d'utiliser le programme apxs + pour compiler ses sources de modules Apache sans avoir besoin de + l'arborescence des sources de la distribution d'Apache, et sans avoir à + régler les drapeaux du compilateur et de l'éditeur de liens pour le support DSO.

Mode d'emploi succinct

+ +

Afin que vous puissiez vous faire une idée des fonctionnalités DSO + d'Apache 2.x, en voici un résumé court et concis :

+ +

+ Construire et installer un module Apache faisant partie de la + distribution, par exemple mod_foo.c, + en tant que module DSO mod_foo.so : + +
+$ ./configure --prefix=/chemin/vers/répertoire-installation +--enable-foo=shared +$ make install +
+
+ Construire et installer un module Apache tiers, par exemple + mod_foo.c, en tant que module DSO mod_foo.so : + +
+$ ./configure --add-module=type_de_module: +/chemin/vers/module_tiers/mod_foo.c \ + + --enable-foo=shared + +$ make install +
+
+ Configurer Apache pour pouvoir installer ultérieurement des + modules partagés : + +
+$ ./configure --enable-so +$ make install +
+
+ Construire et installer un module Apache tiers, par exemple + mod_foo.c, en tant que module DSO + mod_foo.so en dehors de l'arborescence des sources + d'Apache à l'aide du programme apxs : + +
+$ cd /chemin/vers/module_tiers +$ apxs -c mod_foo.c +$ apxs -i -a -n foo mod_foo.la +
+

+ +

Dans tous les cas, une fois le module partagé compilé, vous devez + ajouter une directive LoadModule + dans le fichier httpd.conf pour qu'Apache active le module.

Les dessous du fonctionnement des DSO

+ +

Les clônes modernes d'UNIX proposent un astucieux mécanisme + communément appelé édition de liens et chargement dynamiques d' + Objets Dynamiques Partagés (DSO), qui permet de construire un + morceau de programme dans un format spécial pour le rendre chargeable + à l'exécution dans l'espace d'adressage d'un programme exécutable.

+ +

Ce chargement peut s'effectuer de deux manières : automatiquement par + un programme système appelé ld.so quand un programme + exécutable est démarré, ou manuellement à partir du programme en cours + d'exécution via sa propre interface système vers le chargeur Unix à l'aide + des appels système dlopen()/dlsym().

+ +

Dans la première méthode, les DSO sont en général appelés + bibliothèques partagées ou encore bibliothèques DSO, et + possèdent des noms du style + libfoo.so ou libfoo.so.1.2. Ils résident dans un + répertoire système (en général /usr/lib) + et le lien avec le programme exécutable est établi à la compilation en + ajoutant -lfoo à la commande de l'éditeur de liens. Les + références à la bibliothèque sont ainsi codées en dur dans le fichier du + programme exécutable de façon à ce qu'au démarrage du programme, le + chargeur Unix soit capable de localiser libfoo.so dans + /usr/lib, dans des chemins codés en dur à l'aide d'options de + l'éditeur de liens comme -R ou dans des chemins définis par la + variable d'environnement + LD_LIBRARY_PATH. Le chargeur peut dès lors résoudre tous les symboles + (jusque là non encore résolus) du DSO dans le programme exécutable.

+ +

Les symboles du programme exécutable ne sont en général pas + référencés par le DSO (car c'est une bibliothèque de code à usage général + et réutilisable), + et ainsi aucune résolution supplémentaire n'est nécessaire. De son côté, + le programme exécutable ne doit accomplir aucune action particulière + pour utiliser les + symboles du DSO car toutes les résolutions sont effectuées par le chargeur + Unix. En fait, le code permettant d'invoquer + ld.so fait partie du code de démarrage pour l'exécution qui + est lié dans tout programme exécutable non statiquement lié. + L'avantage du chargement dynamique du code d'une bibliothèque partagée est + évident : le code de la bibliothèque ne doit être stocké qu'une seule fois + dans une bibliothèque système telle que libc.so, ce qui permet + d'économiser de l'espace disque pour les autres programmes.

+ +

Dans la seconde méthode, les DSO sont en général appelés objets + partagés ou fichiers DSO, et peuvent être nommés avec + l'extension de son choix (bien que le nom conseillé soit du style + foo.so). Ces fichiers résident en général dans un répertoire + spécifique à un programme, et aucun lien n'est automatiquement établi avec + le programme exécutable dans lequel ils sont utilisés. + Le programme exécutable charge manuellement le DSO à l'exécution dans son + espace d'adressage à l'aide de l'appel système dlopen(). + A ce moment, aucune résolution de symboles du DSO n'est effectuée pour le + programme exécutable. Par contre le chargeur Unix + résoud automatiquement tout symbole du DSO (non encore résolu) + faisant partie de l'ensemble de symboles exporté par le programme + exécutable et ses bibliothèques DSO déjà chargées (et en particulier tous + les symboles de la bibliothèque à tout faire libc.so). + De cette façon, le DSO prend connaissance de l'ensemble de symboles du + programme exécutable comme s'il avait été lié statiquement avec lui + auparavant.

+ +

Finalement, pour tirer profit de l'API des DSO, le programme exécutable + doit résoudre certains symboles du DSO à l'aide de l'appel système + dlsym() pour une utilisation ultérieure dans les tables de + distribution, etc... En d'autres termes, le programme exécutable doit + résoudre manuellement tous les symboles dont il a besoin pour pouvoir les + utiliser. + Avantage d'un tel mécanisme : les modules optionnels du programme n'ont pas + besoin d'être chargés (et ne gaspillent donc pas de ressources mémoire) + tant qu'il ne sont pas nécessaires au programme en question. Si nécessaire, + ces modules peuvent être chargés dynamiquement afin d'étendre les + fonctionnalités de base du programme.

+ +

Bien que ce mécanisme DSO paraisse évident, il comporte au moins une + étape difficile : la résolution des symboles depuis le programme exécutable + pour le DSO lorsqu'on utilise un DSO pour étendre les fonctionnalités d'un + programme (la seconde méthode). Pourquoi ? Parce que la "résolution + inverse" des symboles DSO à partir du jeu de symboles du programme + exécutable dépend de la conception de la bibliothèque (la bibliothèque n'a + aucune information sur le programme qui l'utilise) et n'est ni standardisée + ni disponible sur toutes les plateformes. En pratique, les symboles globaux + du programme exécutable ne sont en général pas réexportés et donc + indisponibles pour l'utilisation dans un DSO. Trouver une méthode pour + forcer l'éditeur de liens à exporter tous les symboles globaux est le + principal problème que l'on doit résoudre lorsqu'on utilise un DSO pour + étendre les fonctionnalités d'un programme au moment de son exécution.

+ +

L'approche des bibliothèques partagées est la plus courante, parce que + c'est dans cette optique que le mécanisme DSO a été conçu ; c'est cette + approche qui est ainsi + utilisée par pratiquement tous les types de bibliothèques que fournit le + système d'exploitation. Par contre, les objets partagés sont relativement + peu utilisés pour étendre les fonctionnalités d'un programme.

+ +

En 1998, seule une poignée de logiciels distribués + utilisaient le mécanisme DSO pour réellement étendre leurs fonctionnalités + au moment de l'exécution : Perl 5 (via son mécanisme XS et le module + DynaLoader), le serveur Netscape, etc... A partir de la + version 1.3, Apache rejoignit ce groupe, car Apache + présentait déjà un concept modulaire pour étendre ses fonctionnalités, et + utilisait en interne une approche basée sur une liste de distribution pour + relier des modules externes avec les fonctionnalités de base d'Apache. + Ainsi, Apache était vraiment prédestiné à l'utilisation des DSO pour + charger ses modules au moment de l'exécution.

Avantages et inconvénients

+ +

Les fonctionnalités ci-dessus basées sur les DSO présentent les + avantages suivants :

+ +

Le paquetage du serveur est plus flexible à l'exécution car le + processus serveur effectif peut être assemblé à l'exécution via la + directive LoadModule du fichier de + configuration httpd.conf plutôt que par des options du script + configure à la compilation. Par exemple, + on peut ainsi exécuter différentes instances du serveur + (standard et version SSL, version minimale et version étoffée + [mod_perl, PHP], etc...) à partir d'une seule installation + d'Apache.
Le paquetage du serveur peut être facilement étendu avec des modules + tiers, même après l'installation. Ceci présente en tout cas un gros + avantage pour les mainteneurs de paquetages destinés aux distributions, + car ils peuvent créer un paquetage Apache de base, et des paquetages + additionnels contenant des extensions telles que PHP, mod_perl, mod_fastcgi, + etc...
Une facilité de prototypage des modules Apache car la paire + DSO/apxs vous permet d'une part de travailler en + dehors de l'arborescence des sources d'Apache, et d'autre part de n'avoir + besoin que de la commande apxs -i + suivie d'un apachectl restart pour introduire une nouvelle + version de votre module fraîchement développé dans le serveur Apache + en cours d'exécution.

+ +

Inconvénients des DSO :

+ +

Le mécanisme DSO n'est pas disponible sur toutes les plates-formes + car tous les systèmes d'exploitation ne supportent pas le chargement + dynamique de code dans l'espace d'adressage d'un programme.
Le serveur est environ 20 % plus lent au démarrage + à cause des résolutions de symboles supplémentaires que le chargeur + Unix doit effectuer.
Le serveur est environ 5 % plus lent à l'exécution + sur certaines plates-formes, car le code indépendant de la position (PIC) + nécessite parfois des manipulations compliquées en assembleur pour + l'adressage relatif qui ne sont pas toujours aussi rapides que celles + que permet l'adressage absolu.
Comme les modules DSO ne peuvent pas être liés avec d'autres + bibliothèques basées sur DSO (ld -lfoo) sur toutes les + plates-formes + (par exemple, les plates-formes basées sur a.out ne fournissent en + général pas cette fonctionnalité alors que les plates-formes basées sur + ELF le font), vous ne pouvez pas utiliser le mécanisme DSO pour tous les + types de modules. Ou en d'autres termes, les modules compilés comme + fichiers DSO sont contraints de n'utiliser que les symboles du coeur + d'Apache, de la bibliothèque C + (libc) et toutes autres bibliothèques statiques ou + dynamiques utilisées par le coeur d'Apache, ou d'archives statiques + (libfoo.a) contenant du code indépendant de la + position (PIC). + Il y a deux solutions pour utiliser un autre type de code : soit le + coeur d'Apache contient déjà lui-même une référence au code, soit vous + chargez le code vous-même via dlopen().

+ +

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

+ \ No newline at end of file diff --git a/docs/manual/dso.html.ja.utf8 b/docs/manual/dso.html.ja.utf8 index 0f643f2929b..2e4f47b1db3 100644 --- a/docs/manual/dso.html.ja.utf8 +++ b/docs/manual/dso.html.ja.utf8 @@ -20,6 +20,7 @@ 2.3

åçå±æãªãã¸ã§ã¯ã (DSO) ãµãã¼ã

è¨èª: en | + fr | ja | ko | tr

@@ -290,6 +291,7 @@ $ apxs -i -a -n foo mod_foo.la

è¨èª: en | + fr | ja | ko | tr

diff --git a/docs/manual/dso.html.ko.euc-kr b/docs/manual/dso.html.ko.euc-kr index bbe00fa1cc0..31e5a567b96 100644 --- a/docs/manual/dso.html.ko.euc-kr +++ b/docs/manual/dso.html.ko.euc-kr @@ -19,6 +19,7 @@ Apache > HTTP Server > Documentation > Version 2.3

µ¿Àû°øÀ¯°´Ã¼ (DSO) Áö¿ø

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

@@ -269,6 +270,7 @@ $ apxs -i -a -n foo mod_foo.la

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

diff --git a/docs/manual/dso.html.tr.utf8 b/docs/manual/dso.html.tr.utf8 index 1bcc8184825..49a9e058541 100644 --- a/docs/manual/dso.html.tr.utf8 +++ b/docs/manual/dso.html.tr.utf8 @@ -19,6 +19,7 @@ Apache > HTTP Sunucusu > Belgeleme > SÃ¼rÃ¼m 2.3

Devingen PaylaÅÄ±mlÄ± Nesne DesteÄi

Mevcut Diller: en | + fr | ja | ko | tr

@@ -299,6 +300,7 @@ $ apxs -i -a -n filanca mod_filanca.la

Mevcut Diller: en | + fr | ja | ko | tr

diff --git a/docs/manual/dso.xml.meta b/docs/manual/dso.xml.meta index deb573106bf..dd4ab4b4dbb 100644 --- a/docs/manual/dso.xml.meta +++ b/docs/manual/dso.xml.meta @@ -8,6 +8,7 @@ en + fr ja ko tr diff --git a/docs/manual/glossary.html b/docs/manual/glossary.html index 0d713ccfa9f..1703ce12324 100644 --- a/docs/manual/glossary.html +++ b/docs/manual/glossary.html @@ -12,6 +12,10 @@ URI: glossary.html.es Content-Language: es Content-type: text/html; charset=ISO-8859-1 +URI: glossary.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 + URI: glossary.html.ja.utf8 Content-Language: ja Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/glossary.html.de b/docs/manual/glossary.html.de index d4969cb45b7..f3808dc7815 100644 --- a/docs/manual/glossary.html.de +++ b/docs/manual/glossary.html.de @@ -21,6 +21,7 @@

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

@@ -546,6 +547,7 @@

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

diff --git a/docs/manual/glossary.html.en b/docs/manual/glossary.html.en index b8e64c2283a..0e7642081a2 100644 --- a/docs/manual/glossary.html.en +++ b/docs/manual/glossary.html.en @@ -21,6 +21,7 @@

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

@@ -449,6 +450,7 @@

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

diff --git a/docs/manual/glossary.html.es b/docs/manual/glossary.html.es index 8f791e4ef87..df910b0f0b8 100644 --- a/docs/manual/glossary.html.es +++ b/docs/manual/glossary.html.es @@ -21,6 +21,7 @@

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

@@ -390,6 +391,7 @@ SSL/TLS.
Consulte: Encriptado SSL/TLS

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

diff --git a/docs/manual/glossary.html.fr b/docs/manual/glossary.html.fr new file mode 100644 index 00000000000..8fe966f24ba --- /dev/null +++ b/docs/manual/glossary.html.fr @@ -0,0 +1,554 @@ + + + +Glossaire - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.3

Glossaire

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

+ +

Ce glossaire définit la terminologie courante relative à Apache en + particulier, et aux serveurs web en général. Vous trouverez plus + d'informations sur chaque concept dans les liens fournis.

Définitions

+ +

Algorithme: Une formule sans ambiguité ou un jeu de règles destinées à + résoudre un problème en un nombre fini d'étapes. Les algorithmes de + chiffrement sont en général appelés + Ciphers. +
Algorithme de chiffrement + (Cipher): Un algorithme ou un système de chiffrement des données. + Quelques exemples : DES, IDEA, RC4, etc.
+ Voir : chiffrement SSL/TLS +
Archive Tar (Tarball): Un paquetage de fichiers rassemblés dans une archive + à l'aide de l'utilitaire tar. + Les distributions d'Apache sont stockées dans des Archives Tar compressées + ou en utilisant pkzip. +
Authentification: L'identification formelle d'une entité du réseau comme un serveur, un + client, ou un utilisateur.
+ Voir : Authentification, Autorisation, et + contrôle d'accès +
Autorité de Certification + (Certification Authority) + (CA): Un tiers de confiance habilité à signer des certificats pour des entités + du réseau qu'il a authentifiées selon des critères basés sur la sécurité. + Les autres entités du réseau peuvent alors utiliser la signature pour + vérifier qu'une CA a authentifié le porteur du certificat.
+ Voir : chiffrement SSL/TLS +
Certificat (Certificate): Un ensemble de données servant à authentifier des entités du + réseau comme un serveur ou un client. Un certificat contient des ensembles + d'informations X509 à propos de son propriétaire (appelé sujet/subject) + et de l'Autorité de Certification + (Certification Authority) ou CA signataire (appelée + le fournisseur/issuer), ainsi que la + clé publique (public + key) du propriétaire et la + signature de la CA. Les entités du réseau vérifient ces signatures + en utilisant les certificats des Autorités de Certification.
+ Voir : chiffrement SSL/TLS +
Chiffrement à Clé Publique + (Public Key Cryptography): L'étude et l'application des systèmes de chiffrement asymétriques, + qui utilisent une clé pour le chiffrement et une autre pour le + déchiffrement. Les deux clés correspondantes constituent une paire de clés. + Appelé aussi chiffrement asymétrique. +
+ Voir : chiffrement SSL/TLS +
Clé Privée (Private Key): La clé secrète dans un système de + chiffrement à clé publique, + utilisée pour déchiffrer les messages entrants et signer + les messages sortants.
+ Voir : chiffrement SSL/TLS +
Clé Publique (Public Key): La clé accessible au public dans un système de Chiffrement à clé publique, + utilisée pour chiffrer les messages destinés uniquement à son + propriétaire et déchiffrer les signatures + faites par son propriétaire.
+ Voir : chiffrement SSL/TLS +
CONNECT: Une méthode HTTP pour encapsuler + des données brutes dans HTTP. Elle peut aussi être utilisée pour encapsuler + d'autres protocoles, comme le protocole SSL. +
Contexte (Context): Une portion des + fichiers de configuration dans laquelle certains types de + directives sont autorisés.
+ Voir : Termes utilisés + pour décrire les directives d'Apache +
Contrôle d'accès + (Access Control): La restriction d'accès à des zones du réseau. Habituellement + dans un contexte Apache, + la restriction d'accès à certaines URLs.
+ Voir : Authentification, Autorisation et + Contrôle d'accès +
+ Couche des Points de connexion Sécurisés + (Secure Sockets Layer) + (SSL): Un protocole créé par Netscape Communications Corporation pour + l'authentification et le chiffrement généraux des communications dans les + réseaux TCP/IP. L'utilisation la plus connue est HTTPS, autrement dit + le Protocole de Transfert Hypertexte (HTTP) au dessus de SSL.
+ Voir : chiffrement SSL/TLS +
+ Cryptographie Symétrique (Symmetric Cryptography): L'étude et l'application des Algorithmes de chiffrement qui + utilisent une clé secrète unique pour les opérations de chiffrement et de + déchiffrement.
+ Voir : chiffrement SSL/TLS +
+ Dégradé pour l'exportation + (Export-Crippled): Diminué en terme de puissance cryptographique (et de sécurité) + afin de respecter les Règles de l'Administration des Exportations + des Etats-Unis (Export Administration Regulations ou EAR). + Les logiciels de cryptographie dégradés pour l'exportation sont limités + à une clé de petite taille, et produisent un + Texte crypté qui peut en général être décrypté + par force brute.
+ Voir : chiffrement SSL/TLS +
Demande de signature de certificat + (Certificate Signing Request) + (CSR): La soumission d'un certificat + non signé à une Autorité de + certification, qui le signe avec la Clé privée de leur + Certificat de CA. Une fois le CSR signé, il devient un vrai + certificat.
+ Voir : chiffrement SSL/TLS +
Directive: Une commande de configuration qui contrôle un ou plusieurs aspects du + comportement d'Apache. Les directives sont placées dans le Fichier de configuration
+ Voir : Index des directives +
Directive de configuration + (Configuration Directive): Voir : Directive
En-tête (Header): La partie de la requête et de la réponse + HTTP qui est envoyée avant le contenu + proprement dit, et contient des méta-informations décrivant le contenu. +
Expression Rationnelle + (Regular Expression) + (Regex): Une méthode pour décrire un modèle sous forme de texte - par exemple, + "tous les mots qui commencent par la lettre A" ou "tous les numéros de + téléphone à 10 chiffres" ou encore "Toutes les phrases contenant 2 virgules, + et aucun Q majuscule". Les expressions rationnelles sont très utiles dans + Apache car elles vous permettent d'appliquer certains attributs à des + ensembles de fichiers ou ressources avec une grande flexibilité + - par exemple, tous les fichiers .gif et .jpg situés dans tout répertoire + nommé "images", pourraient être enregistrés comme + "/images/.*(jpg|gif)$". Apache utilise les Expressions + Rationnelles Compatibles avec Perl fournies par la librairie PCRE. +
+ Fichier de configuration + (Configuration File): Un fichier texte contenant des + Directives + qui contrôlent la configuration d'Apache.
+ Voir : Fichiers de configuration +
Filtre (Filter): Un traitement appliqué aux données envoyées ou reçues par le serveur. + Les filtres en entrée traitent les données envoyées au serveur par le + client, alors que les filtres en sortie traitent les documents sur le + serveur avant qu'ils soient envoyés au client. + Par exemple, le filtre en sortie + INCLUDES + traite les documents pour les + Server Side Includes (Inclusions côté Serveur) + .
+ Voir : Filtres +
Gestionnaire (Handler): Une représentation interne à Apache de l'action à entreprendre + quand un fichier est appelé. En général, les fichiers ont des gestionnaires + implicites, basés sur le type de fichier. Normalement, tous les + fichiers sont directement servis par le serveur, mais certains + types de fichiers sont "gérés" séparément. Par exemple, le gestionnaire + cgi-script désigne les fichiers qui doivent être traités + comme CGIs.
+ Voir : Utilisation des gestionnaires d'Apache +
Hachage (Hash): Un algorithme mathématique à sens unique, irréversible, générant une + chaîne de longueur fixe à partir d'une autre chaîne de longueur quelconque. + Des chaînes différentes en entrée vont normalement produire des chaînes + différentes en sortie (selon la fonction de hachage). +
Hébergement Virtuel + (Virtual Hosting): Servir des sites web multiples en utilisant une seule instance d'Apache. + Les Hôtes virtuels basés sur IP différencient les sites web en se + basant sur leur adresse IP, alors que les + Hôtes virtuels basés sur le nom utilisent uniquement le nom d'hôte + et peuvent en conséquence héberger de nombreux sites avec la même + adresse IP.
+ Voir la Documentation des Hôtes Virtuels d'Apache +
.htaccess: Un fichier de configuration + placé à un certain niveau de l'arborescence du site web, et appliquant des + directives de configuration au + répertoire dans lequel il est placé, ainsi qu'à tous ses sous-répertoires. + En dépit de son nom, ce fichier peut contenir pratiquement tout type de + directive, et pas seulement des directives de contrôle d'accès.
+ Voir : Fichiers de configuration +
httpd.conf: Le fichier de configuration + principal d'Apache. Sa localisation par défaut est + /usr/local/apache2/conf/httpd.conf, mais ceci peut être + changé en utilisant des options de compilation ou d'exécution.
+ Voir : Fichiers de configuration +
HTTPS: Le Protocole de Transfert Hypertexte (Sécurisé), le mécanisme de + communication cryptée standard sur le World Wide Web. + Il s'agit en fait de HTTP au dessus de + SSL.
+ Voir : chiffrement SSL/TLS +
Identificateur de Ressource Uniformisé + (Uniform Resource Identifier) + (URI): Une chaîne de caractères compacte servant à identifier une ressource + abstraite ou physique. Elle est formellement définie par la RFC 2396. Les URIs + utilisées sur le world-wide web sont souvent appelées URLs. +
+ Inclusions Côté Serveur + (Server Side Includes) (SSI) +: Une technique permettant d'englober des directives de traitement dans + des fichiers HTML.
+ Voir : Introduction aux Inclusions Côté Serveur +
+Interface commune avec les programmes externes +(Common Gateway Interface) + (CGI): La définition standard d'une interface entre un serveur web et un + programme externe pour permettre à ce dernier de traiter des requêtes. + L'interface a été initialement définie par NCSA mais il + existe aussi le projet + RFC project.
+ Voir : Contenu dynamique avec CGI +
Bibliothèques pour la portabilité d'Apache + (Apache Portable Runtime) (APR): Un jeu de bibliothèques qui fournit la plupart des interfaces de base + entre le serveur et le système d'exploitation. APR est développé + parallèlement au serveur HTTP Apache comme projet indépendant.
+ Voir : Apache Portable Runtime + Project +
+Localisation de Ressource Uniformisée +(Uniform Resource Locator) + (URL): Le nom/adresse d'une ressource sur l'Internet. Il s'agit du terme + informel commun pour ce qui est formellement défini comme + Identificateur de Ressource Uniformisé. + Les URLs sont généralement construites selon un schéma, comme + http ou + https, un nom d'hôte, et un chemin. Une URL pour cette page + pourrait être + http://httpd.apache.org/docs/trunk/glossary.html. +
Mandataire (Proxy): Un serveur intermédiaire qui se situe entre le client et le + serveur d'origine. + Il prend en compte les requêtes des clients, les transmet au serveur + d'origine, puis renvoie la réponse du serveur d'origine au client. + Si plusieurs clients demandent le même contenu, le mandataire peut l'extraire + de son cache, plutôt que le demander au serveur d'origine + à chaque fois, ce qui réduit le temps de réponse.
+ Voir : mod_proxy +
Mandataire inverse + (Reverse Proxy): Un serveur mandataire qui est vu du client + comme un serveur d'origine. Ceci peut s'avérer utile pour + dissimuler le serveur d'origine réel au client pour des raisons de sécurité, + ou pour répartir la charge. +
Méthode (Method): Dans le contexte HTTP, une action à + effectuer sur une ressource spécifiée dans la ligne de requête + par le client. Parmi les méthodes disponibles dans HTTP, on trouve + GET, POST, + et PUT. +
Module: Une partie indépendante d'un programme. De nombreuses fonctionnalités + d'Apache sont fournies par des modules que vous pouvez choisir d'inclure + ou d'exclure. Les modules qui sont compilés dans le binaire + httpd sont appelés modules statiques, alors + que les modules qui existent séparément et peuvent être chargés + optionnellement à l'exécution sont appelés + modules dynamiques ou DSOs. + Les modules qui sont inclus par défaut sont appelés + modules de base. De nombreux modules disponibles pour Apache + ne se trouvent pas dans l'archive + du Serveur HTTP Apache . Il sont appelés + modules tiers.
+ Voir : Index des modules +
Mot de Passe (Pass Phrase): Le mot ou la phrase qui protège les fichiers de clés privées. + Il empêche les utilisateurs non autorisés de les déchiffrer. En général, + il s'agit simplement de la clé secrète de chiffrement/déchiffrement + utilisée pour les Algorithmes de chiffrement.
+ Voir : chiffrement SSL/TLS +
Nom de domaine entièrement qualifié + (Fully-Qualified Domain-Name) + (FQDN): Le nom unique d'une entité du réseau, comprenant un nom d'hôte et un + nom de domaine qui peuvent être résolus en une adresse IP. Par exemple, + www est un nom d'hôte, example.com est un nom + de domaine, et www.example.com est un nom de domaine + entièrement qualifié. +
+ Nombre Magique des Modules + (Module Magic Number) + (MMN): Le Nombre Magique des Modules est une constante définie dans le code + source d'Apache et associée à la compatibilité binaire des modules. + Sa valeur est modifiée quand des structures internes d'Apache, des appels + de fonctions et d'autres parties significatives de l'API sont modifiées + de telle façon que la compatibilité binaire ne peut plus être garantie. + En cas de changement de MMN, tous les modules tiers doivent être au + moins recompilés, et parfois même légèrement modifiés afin de pouvoir + fonctionner avec la nouvelle version d'Apache. +
+ Objet Dynamique Partagé (Dynamic Shared Object) + (DSO): Modules compilés en dehors du binaire + Apache httpd et qui peuvent être + chargés à la demande.
+ Voir : Support des objets dynamiques partagés +
OpenSSL: L'ensemble d'outils Open Source pour SSL/TLS
+ Voir http://www.openssl.org/# +
+ Outil de gestion des extensions Apache + (APache eXtension Tool) + (apxs): Un script Perl qui aide à la compilation des sources de module sous forme d'Objets Dynamiques Partagés + (Dynamic Shared Objects ou + DSOs) et facilite leur installation + dans le serveur Web Apache.
+ Voir : Page de manuel : apxs +
Plein Texte (Plaintext): Le texte non chiffré.
Protocole de Transfert Hypertexte + (HyperText Transfer Protocol) + (HTTP): Le protocole de transmission standard utilisé sur le World Wide Web. + Apache implémente la version 1.1 du protocole, référencée comme HTTP/1.1 et + définie par la + RFC 2616. +
Résumé de message + (Message Digest): Un hachage du message, qui peut être utilisé pour vérifier + que son contenu n'a pas été altéré durant le transfert.
+ Voir : chiffrement SSL/TLS +
+ Sécurité de la couche Transport + (Transport Layer Security) + (TLS): Le protocole successeur de SSL, créé par l'Internet Engineering Task + Force (IETF) pour l'authentification et le chiffrement généraux des + communications dans les réseaux TCP/IP. TLS version 1 est pratiquement + identique à SSL version 3.
+ Voir : chiffrement SSL/TLS +
Session: Les informations sur le contexte d'une communication en général.
Signature numérique + (Digital Signature): Un bloc de texte crypté qui valide un certificat ou un autre fichier. + Une Autorité de certification + crée une signature en générant une empreinte de la Clé publique + fournie avec le Certificat; la CA chiffre ensuite l'empreinte + avec sa propre Clé privée. Seule la clé publique de la CA + peut décrypter la signature, ce qui permet de vérifier que la CA a bien + authentifié l'entité du réseau qui possède le + Certificat.
+ Voir : chiffrement SSL/TLS +
SSLeay: La bibliothèque originelle d'implémentation de SSL/TLS développée par + Eric A. Young +
Texte crypté +(Ciphertext): Le résultat du passage d'un document + Plaintext (Plein texte) par un + Cipher.
+ Voir : chiffrement SSL/TLS +
Type MIME (MIME-type): Une méthode pour décrire le type de document transmis. Son nom + vient du fait que son format est issu des Multipurpose + Internet Mail Extensions (Extensions Multi-usages de la + Messagerie par Internet) . Il comprend un type majeur et un type + mineur, séparés par un slash (barre oblique). On trouve + entre autres types text/html, + image/gif, et application/octet-stream. Dans + HTTP, le type MIME est transmis dans l' + en-tête Content-Type.
+ Voir : mod_mime +
+ Variable d'environnement + (Environment Variable) (env-variable): Ce sont des variables nommées gérées par le shell du système + d'exploitation, et servant au stockage d'informations et à la + communication entre les programmes. Apache possède aussi des variables + internes considérées comme variables d'environnement, mais stockées dans + des structures internes à Apache, et non dans l'environnement + du shell.
+ Voir : Les variables d'environnement dans Apache +
X.509: Une norme de certificat d'authentification recommandée par l'International + Telecommunication Union (ITU-T) et utilisée pour + l'authentification SSL/TLS.
Voir : chiffrement SSL/TLS +

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

+ \ No newline at end of file diff --git a/docs/manual/glossary.html.ja.utf8 b/docs/manual/glossary.html.ja.utf8 index 1e1bdc2bf2f..8517002cb46 100644 --- a/docs/manual/glossary.html.ja.utf8 +++ b/docs/manual/glossary.html.ja.utf8 @@ -22,6 +22,7 @@

è¨èª: de | en | es | + fr | ja | ko | tr

@@ -442,6 +443,7 @@

è¨èª: de | en | es | + fr | ja | ko | tr

diff --git a/docs/manual/glossary.html.ko.euc-kr b/docs/manual/glossary.html.ko.euc-kr index f09f7391968..c6d786041ba 100644 --- a/docs/manual/glossary.html.ko.euc-kr +++ b/docs/manual/glossary.html.ko.euc-kr @@ -21,6 +21,7 @@

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

@@ -359,6 +360,7 @@ ITU-T)

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

diff --git a/docs/manual/glossary.html.tr.utf8 b/docs/manual/glossary.html.tr.utf8 index 8bf88fe2594..2f7039ebb4f 100644 --- a/docs/manual/glossary.html.tr.utf8 +++ b/docs/manual/glossary.html.tr.utf8 @@ -21,6 +21,7 @@

Mevcut Diller: de | en | es | + fr | ja | ko | tr

@@ -462,6 +463,7 @@

Mevcut Diller: de | en | es | + fr | ja | ko | tr

diff --git a/docs/manual/glossary.xml.meta b/docs/manual/glossary.xml.meta index f6c982679c3..c2d9b2f7d9a 100644 --- a/docs/manual/glossary.xml.meta +++ b/docs/manual/glossary.xml.meta @@ -10,6 +10,7 @@ de en es + fr ja ko tr diff --git a/docs/manual/logs.html b/docs/manual/logs.html index 9824ca02d65..48e9a0da743 100644 --- a/docs/manual/logs.html +++ b/docs/manual/logs.html @@ -4,6 +4,10 @@ URI: logs.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 +URI: logs.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 + URI: logs.html.ja.utf8 Content-Language: ja Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/logs.html.en b/docs/manual/logs.html.en index bfe6a57ce5e..72febaed18c 100644 --- a/docs/manual/logs.html.en +++ b/docs/manual/logs.html.en @@ -19,6 +19,7 @@ Apache > HTTP Server > Documentation > Version 2.3

Log Files

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

@@ -595,6 +596,7 @@

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

diff --git a/docs/manual/logs.html.fr b/docs/manual/logs.html.fr new file mode 100644 index 00000000000..e952785ae25 --- /dev/null +++ b/docs/manual/logs.html.fr @@ -0,0 +1,642 @@ + + + +Fichiers journaux - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.3

Fichiers journaux

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

+ +

Pour véritablement gérer un serveur web, + il est nécessaire de disposer d'un + retour d'informations à propos de l'activité et des performances du + serveur, ainsi que de tout problème qui pourrait survenir. Le serveur HTTP + Apache propose des fonctionnalités de journalisation souples et très + complètes. Ce document décrit comment configurer ces fonctionnalités de + journalisation et interpréter le contenu des journaux.

Avertissement à propos de la sécurité
Journal des erreurs
Journal des accès
Rotation des journaux
Journaux redirigés
Hôtes virtuels
Autres fichiers journaux

Avertissement à propos de la sécurité

+ + +

Tout utilisateur qui a les droits en écriture sur le répertoire dans + lequel Apache écrit ses journaux pourra quasi + certainement avoir accès à l'uid sous lequel le serveur est démarré, en + l'occurrence habituellement root. N'accordez PAS aux utilisateurs + l'accès en écriture au répertoire dans lequel les journaux sont stockés + sans savoir exactement quelles en seraient les conséquences ; voir le + document conseils sur la sécurité + pour plus de détails.

+ +

En outre, les journaux peuvent contenir des informations fournies + directement par un client, sans caractères d'échappement. Des clients mal + intentionnés peuvent donc insérer des caractères de contrôle dans les + journaux, et il convient par conséquent d'être très prudent lors de la + manipulation des journaux bruts.

Journal des erreurs

Modules Apparentés	Directives Apparentées
	`ErrorLog` `LogLevel`

+ + + + +

Le journal des erreurs du serveur, dont le nom et la localisation sont + définis par la directive ErrorLog, + est le journal le plus important. C'est dans celui-ci + que le démon Apache httpd va envoyer les informations de diagnostic et + enregistrer toutes les erreurs qui surviennent lors du traitement des + requêtes. Lorsqu'un problème survient au démarrage du serveur ou pendant + son fonctionnement, la première chose à faire est de regarder dans ce + journal, car il vous renseignera souvent sur le problème rencontré et + la manière d'y remédier.

+ +

Le journal des erreurs est habituellement enregistré dans un fichier + (en général error_log sur les systèmes de type Unix et + error.log sur Windows et OS/2). Sur les systèmes de type Unix, + le serveur peut aussi enregistrer ses erreurs dans + syslog ou les + rediriger vers un programme par l'intermédiaire d'un + tube de communication (pipe).

+ +

Le format du journal des erreurs est descriptif et de forme + relativement libre. Certaines informations apparaissent cependant dans la + plupart des entrées du journal. Voici un message typique + à titre d'exemple :

+ +

+ [Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1] + client denied by server configuration: + /export/home/live/ap/htdocs/test +

+ +

Le premier champ de l'entrée du journal est la date et l'heure du + message. Le second champ indique la sévérité de l'erreur rapportée. La + directive LogLevel permet de + restreindre le type des erreurs qui doivent être enregistrées + dans le journal des erreurs en définissant leur niveau de sévérité. Le + troisième champ contient l'adresse IP du client qui a généré l'erreur. + Vient ensuite le message proprement dit, qui indique dans ce cas que le + serveur a été configuré pour interdire l'accès au client. Le serveur + indique le chemin système du document requis (et non + son chemin web).

+ +

Une grande variété de messages différents peuvent apparaître dans le + journal des erreurs. La plupart d'entre eux sont similaires à l'exemple + ci-dessus. Le journal des erreurs peut aussi contenir des informations de + débogage en provenance de scripts CGI. Toute information qu'un script CGI + écrit sur la sortie d'erreurs standard stderr sera recopiée + telle quelle dans le journal des erreurs.

+ +

Il n'est pas possible de personnaliser le journal des erreurs en ajoutant ou en + supprimant des informations. Cependant, les entrées du journal des erreurs + qui concernent certaines requêtes possèdent des entrées correspondantes + dans le journal des accès. Ainsi, l'entrée de + l'exemple ci-dessus correspond à une entrée du journal des accès avec un + code de statut 403. Etant donné qu'il est possible de personnaliser le + journal des accès, vous pouvez obtenir d'avantage d'informations sur les + circonstances d'une erreur en consultant ce journal.

+ +

Pendant la phase de test, il est souvent utile de visualiser en continu + le journal des erreurs afin de détecter tout problème éventuel. Sur les + systèmes de type Unix, ceci s'effectue à l'aide de la commande :

+ +

+ tail -f error_log +

Journal des accès

Modules Apparentés	Directives Apparentées
`mod_log_config` `mod_setenvif`	`CustomLog` `LogFormat` `SetEnvIf`

+ + + + +

Le journal des accès au serveur + enregistre toutes les requêtes que traite + ce dernier. La localisation et le contenu du journal des accès sont définis + par la directive CustomLog. + La directive LogFormat + permet de simplifier la sélection du contenu du journal. Cette section + décrit comment configurer le serveur pour l'enregistrement des informations + dans le journal des accès.

+ +

Bien évidemment, le stockage d'informations dans le journal des accès + n'est que le point de départ de la gestion de la journalisation. L'étape + suivante consiste à analyser ces informations de façon à pouvoir en + extraire des statistiques utiles. L'analyse de journaux en général est en + dehors du sujet de ce document et ne fait pas vraiment partie intégrante + du travail du serveur web lui-même. Pour plus d'informations à propos de ce + sujet et des applications dédiées à l'analyse de journaux, vous pouvez vous + référer à Open Directory ou + Yahoo.

+ +

Différentes versions du démon Apache httpd utilisaient d'autres modules + et directives pour contrôler la journalisation des accès, à l'instar de + mod_log_referer, mod_log_agent, et de la directive + TransferLog. La directive + CustomLog rassemble + désormais les fonctionnalités de toutes les anciennes directives.

+ +

Le format du journal des accès est hautement configurable. Il est + défini à l'aide d'une chaîne de format qui ressemble sensiblement à la + chaîne de format de style langage C de printf(1). Vous trouverez quelques + exemples dans les sections suivantes. Pour une liste exhaustive de ce que + peut contenir une chaîne de format, vous pouvez vous référer au chapitre + chaînes de format de la + documentation du module mod_log_config.

+ +

Format habituel du journal

+ + +

Voici une configuration typique pour le journal des accès :

+ +

+ LogFormat "%h %l %u %t \"%r\" %>s %b" common + CustomLog logs/access_log common +

+ +

Ici est définie l'identité common qui est + ensuite associée à une chaîne de format de journalisation particulière. + La chaîne de format est constituée de directives débutant par le + caractère %, chacune d'entre elles indiquant au serveur d'enregistrer + un élément particulier d'information. Des caractères littéraux peuvent + aussi être insérés dans la chaîne de format ; il seront copiés tels + quels dans le flux de sortie destiné à la journalisation. + Les guillemets (") doivent être échappées en les faisant + précéder d'un anti-slash (\) afin qu'elles ne soient pas + interprétées comme la fin de la chaîne de format. La chaîne de format + peut aussi contenir les caractères de contrôle spéciaux + "\n" et "\t" pour insérer respectivement + un passage à la ligne et une tabulation.

+ +

La directive CustomLog + définit un nouveau fichier journal en l'associant à l'identité + précédemment définie. Le chemin du nom de fichier associé au journal + des accès est relatif au chemin défini par la directive + ServerRoot, sauf s'il + débute par un slash.

+ +

La configuration ci-dessus va enregistrer les entrées de + journalisation selon un format connu sous le nom de + Common Log Format (CLF) pour "Format de journalisation standard". + Ce format standard peut être produit par de nombreux serveurs web + différents et lu par de nombreux programmes d'analyse de journaux. + Les entrées de fichier journal générées selon le format CLF + ressemblent à ceci :

+ +

+ 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET + /apache_pb.gif HTTP/1.0" 200 2326 +

+ +

Chaque partie de cette entrée de journal est décrite + dans ce qui suit.

+ +

127.0.0.1 (%h): Il s'agit de l'adresse IP du client (l'hôte distant) qui a envoyé + la requête au serveur. Si la directive + HostnameLookups est positionnée à + On, le serveur va essayer de déterminer le nom de l'hôte + et de l'enregistrer à la place de l'adresse IP. Cette configuration + n'est cependant pas recommandée car elle peut ralentir le serveur de + manière significative. Il est par conséquent préférable d'utiliser un + processeur d'analyse de journaux a posteriori + tel que logresolve + pour déterminer les noms d'hôte. L'adresse IP indiquée ici n'est pas + nécessairement l'adresse IP de la machine devant laquelle se trouve + l'utilisateur. Si un serveur mandataire s'intercale entre le serveur + et l'utilisateur, l'adresse indiquée sera celle du mandataire et non + celle de la machine à l'origine de la requête.
- (%l): Le "trait d'union" indique que la portion d'information + correspondante n'est pas disponible. Dans le cas présent, l'information + non disponible est l'identité (RFC 1413) du client telle que déterminée + par identd sur la machine cliente. Cette information est + très peu fiable et ne devrait jamais être utilisée, sauf dans le cas + de réseaux internes étroitement contrôlés. Le démon httpd ne cherchera + d'ailleurs à obtenir cette information que si la directive + IdentityCheck est positionnée + à On.
frank (%u): Il s'agit de l'identifiant utilisateur de la personne qui a + demandé le document, issu d'une authentification HTTP. + Ce même identifiant est en général fourni aux scripts CGI par + l'intermédiaire de la valeur de la variable d'environnement + REMOTE_USER. Si le statut de la requête (voir plus loin) + est 401, cette identifiant n'est pas fiable car l'utilisateur n'est + pas encore authentifié. Si le document n'est pas protégé par + mot de passe, cette partie d'information sera représentée par + "-", comme la partie précédente.
[10/Oct/2000:13:55:36 -0700] + (%t): + L'heure à laquelle la requête a été reçue. + Le format est le suivant : + +
+ [jour/mois/année:heure:minutes:secondes zone] + jour = 2*chiffre + mois = 3*lettre + année = 4*chiffre + heure = 2*chiffre + minutes = 2*chiffre + secondes = 2*chiffre + zone = (`+' | `-') 4*chiffre +
Il est possible de modifier le format d'affichage de l'heure + en spécifiant %{format}t dans la chaîne de format du + journal, où format est une chaîne de format de même + forme que celle de la fonction strftime(3) de la + bibliothèque C standard. +
"GET /apache_pb.gif HTTP/1.0" + (\"%r\"): La ligne de la requête du client est placée entre guillemets. + Elle contient de nombreuses informations utiles. Tout d'abord, la + méthode utilisée par le client est GET. Ensuite, le + client a demandé la ressource /apache_pb.gif, et enfin, + le client a utilisé le protocole HTTP/1.0. Il est aussi + possible d'enregistrer séparément une ou plusieurs parties de la + requête. Par exemple, la chaîne de format "%m %U %q %H" + va enregistrer la méthode, le chemin, la chaîne de la requête et le + protocole, ce qui donnera le même résultat que + "%r".
200 (%>s): C'est le code de statut que le serveur retourne au client. Cette + information est très importante car elle indique si la requête a fait + l'objet d'une réponse positive (codes commençant par 2), une + redirection (codes commençant par 3), une erreur due au client (codes + commençant par 4), ou une erreur due au serveur (codes commençant + par 5). Vous trouverez la liste complète des codes de statut possibles + dans la specification HTTP (RFC2616 section 10).
2326 (%b): La dernière partie indique la taille de l'objet retourné au client, + en-têtes non compris. Si aucun contenu n'a été retourné au client, cette + partie contiendra "-". Pour indiquer l'absence de contenu + par "0", utilisez %B au lieu de + %b.

+ + +

Combined Log Format (Format de journalisation combiné)

+ + +

Une autre chaîne de format couramment utilisée est le + "Combined Log Format" (Format de journalisation combiné). Il s'utilise + comme suit :

+ +

+ LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" + \"%{User-agent}i\"" combined + CustomLog log/access_log combined +

+ +

Ce format est identique au Common Log Format, avec deux champs + supplémentaires. Chacun de ces deux champs utilise la directive + commençant par le caractère "%" %{header}i, + où header peut être n'importe quel en-tête de requête HTTP. + Avec ce format, le journal des accès se présentera comme suit :

+ +

+ 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET + /apache_pb.gif HTTP/1.0" 200 2326 + "http://www.example.com/start.html" "Mozilla/4.08 [en] + (Win98; I ;Nav)" +

+ +

Les champs supplémentaires sont :

+ +

"http://www.example.com/start.html" + (\"%{Referer}i\"): L'en-tête "Referer" (sic) de la requête HTTP. Il indique le site + depuis lequel le client prétend avoir lancé sa requête. (Ce doit être + la page qui contient un lien vers /apache_pb.gif ou + inclut ce dernier fichier).
"Mozilla/4.08 [en] (Win98; I ;Nav)" + (\"%{User-agent}i\"): L'en-tête User-Agent de la requête HTTP. C'est une information + d'identification que le navigateur du client envoie à propos + de lui-même.

+ + +

Journaux d'accès multiples

+ + +

Plusieurs journaux d'accès peuvent être créés en spécifiant tout + simplement plusieurs directives + CustomLog dans le + fichier de configuration. Par exemple, les directives suivantes vont + créer trois journaux d'accès. Le premier contiendra les informations + de base CLF, le second les informations du Referer, et le troisième + les informations sur le navigateur. Les deux dernières directives + CustomLog montrent + comment simuler les effets des directives ReferLog et + AgentLog.

+ +

+ LogFormat "%h %l %u %t \"%r\" %>s %b" common + CustomLog logs/access_log common + CustomLog logs/referer_log "%{Referer}i -> %U" + CustomLog logs/agent_log "%{User-agent}i" +

+ +

Cet exemple montre aussi qu'il n'est pas obligatoire d'associer + une chaîne de format à un alias au moyen de la directive + LogFormat. Elle peut + être définie directement dans la ligne de la directive + CustomLog.

+ + +

Journalisation conditionnelle

+ + +

Il est parfois souhaitable d'exclure certaines entrées des journaux + d'accès en fonction des caractéristiques de la requête du client. On + peut aisément accomplir ceci à l'aide des + variables d'environnement. Tout d'abord, une + variable d'environnement doit être définie pour indiquer que la + requête remplit certaines conditions. Pour ceci, on utilise en général + la directive SetEnvIf, + puis la clause env= de la directive + CustomLog pour inclure + ou exclure les requêtes pour lesquelles + la variable d'environnement est définie. + Quelques exemples :

+ +

+ # Marque les requêtes en provenance de l'interface loop-back + SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog + # Marque les requêtes pour le fichier robots.txt + SetEnvIf Request_URI "^/robots\.txt$" dontlog + # Journalise toutes les autres requêtes + CustomLog logs/access_log common env=!dontlog +

+ +

Autre exemple, imaginons l'enregistrement des requêtes en provenance + d'utilisateurs de langue anglaise dans un journal, et celles des autres + utilisateurs dans un autre journal.

+ +

+ SetEnvIf Accept-Language "en" english + CustomLog logs/english_log common env=english + CustomLog logs/non_english_log common env=!english +

+ +

Bien que nous venions de montrer que la journalisation conditionnelle + est souple et très puissante, cette méthode de contrôle du contenu des + journaux n'est pas la seule. Les fichiers journaux sont plus utiles + quand ils contiennent un enregistrement complet de l'activité du serveur, + et il est souvent plus aisé de simplement traiter à posteriori les fichiers + journaux pour supprimer les requêtes que vous ne voulez pas y voir + apparaître.

+ +

Rotation des journaux

+ + +

Même dans le cas d'un serveur modérément sollicité, la quantité + d'informations stockées dans les fichiers journaux est très importante. + Le fichier journal des accès grossit en général d'1 Mo ou plus toutes + les 10000 requêtes. Il est par conséquent nécessaire d'effectuer + périodiquement la rotation des journaux en déplaçant ou supprimant les + fichiers correspondants. On ne peut pas le faire pendant que le serveur + est en cours d'exécution, car Apache va continuer à écrire dans l'ancien + fichier journal aussi longtemps qu'il le maintiendra ouvert. + C'est pourquoi le serveur doit être + redémarré après le déplacement ou la + suppression des fichiers journaux de façon à ce qu'il en ouvre + de nouveaux.

+ +

Avec un redémarrage graceful, on peut faire en sorte que le + serveur ouvre de nouveaux fichiers journaux sans perdre de connexions + existantes ou en cours avec les clients. Cependant, pour que ceci soit + possible, le serveur doit continuer à écrire dans les anciens fichiers + journaux pendant qu'il termine le traitement des requêtes en cours. + Il est donc nécessaire d'attendre un certain temps après le rédémarrage + avant d'effectuer tout traitement sur les fichiers journaux. Voici un + scénario typique dans lequel on effectue une simple rotation des + journaux en compressant les anciens fichiers correspondants afin + de gagner de l'espace disque :

+ +

+ mv access_log access_log.old + mv error_log error_log.old + apachectl graceful + sleep 600 + gzip access_log.old error_log.old +

+ +

La section suivante présente une autre méthode de rotation des journaux + qui consiste à utiliser les + journaux redirigés.

Journaux redirigés

+ + +

Nous avons vu que le démon httpd écrivait les informations de + journalisation des erreurs et des accès dans un fichier journal ; + il peut aussi + rediriger ces informations vers un autre processus par l'intermédiaire d'un + tube de communication (pipe). Cette fonctionnalité améliore + considérablement la souplesse de la journalisation, sans ajouter de code + au serveur principal. Pour rediriger les informations de journalisation + vers un tube de communication, remplacez simplement le nom de fichier + journal par + le caractère pipe "|", suivi du nom de l'exécutable qui va + recueillir les entrées de journal sur son entrée standard. Apache va + lancer le processus de redirection des journaux au moment du démarrage du + serveur, et le relancera s'il cesse de fonctionner + pendant l'exécution du serveur. + (Nous dénommons cette technique "journalisation + redirigée fiable" grâce à cette dernière fonctionnalité.)

+ +

Les processus de journalisation redirigée sont lancés par le processus + httpd parent, et héritent de l'UID de ce dernier. Cela signifie que les + programmes de journalisation dirigée s'exécutent généralement en tant que + root. Il est donc très important que ces programmes soient simples et + sécurisés.

+ +

Un des grands avantages de la journalisation redirigée est la possibilité + d'effectuer la rotation des journaux sans avoir à redémarrer le serveur. Pour + accomplir cette tâche, le serveur HTTP Apache fournit un programme simple + appelé rotatelogs. Par exemple, pour une rotation des + journaux toutes les 24 heures, ajoutez ces lignes :

+ +

+ CustomLog "|/usr/local/apache/bin/rotatelogs + /var/log/access_log 86400" common +

+ +

Notez que l'ensemble de la commande qui sera appelée par le tube de + communication a été placée entre guillemets. Bien que cet exemple + concerne le journal des accès, la même technique peut être utilisée + pour le journal des erreurs.

+ +

Il existe un autre programme de rotation des journaux similaire mais + beaucoup plus souple : il s'agit de "cronolog", non fourni par Apache, + mais disponible ici.

+ +

Comme la journalisation conditionnelle, la journalisation redirigée est + un outil très puissant, mais si elle existe, il est préférable d'utiliser + une solution plus simple comme le traitement à posteriori hors ligne.

Hôtes virtuels

+ + +

Lorsqu'un serveur possède plusieurs hôtes virtuels, il existe de nombreuses solutions pour gérer + les fichiers journaux. Par exemple, on peut utiliser les journaux comme + s'il s'agissait d'un serveur avec un seul hôte. Il suffit pour cela de + placer les directives de journalisation en dehors des sections + <VirtualHost> au niveau + du serveur principal, ce qui a pour effet de journaliser toutes les + requêtes dans le même journal des accès et des erreurs. Cette technique + est cependant inappropriée pour recueillir des statistiques sur chaque + hôte virtuel individuellement.

+ +

Si des directives CustomLog ou + ErrorLog sont placées dans une section + <VirtualHost>, toutes les + requêtes ou erreurs pour cet hôte virtuel ne seront enregistrées que dans + le fichier spécifié. Tout hôte virtuel qui ne possède pas de directives de + journalisation verra ses requêtes enregistrées dans le journal du serveur + principal. Cette technique est appropriée pour un petit nombre d'hôtes + virtuels, mais si ce nombre est important, elle peut devenir compliquée à + gérer. En outre, des problèmes de nombre de descripteurs + de fichiers insuffisant peuvent rapidement apparaître.

+ +

Il existe un très bon compromis pour le journal des accès. En intégrant + les informations à propos de l'hôte virtuel à la chaîne de format du + journal, il est possible de journaliser tous les hôtes dans le même + journal, puis de séparer ultérieurement le journal en plusieurs journaux + individuels. Considérons par exemple les directives suivantes :

+ +

+ LogFormat "%v %l %u %t \"%r\" %>s %b" + comonvhost + CustomLog logs/access_log comonvhost +

+ +

Le champ %v sert à enregistrer le nom de l'hôte virtuel qui + traite la requête. Un programme tel que split-logfile peut ensuite être utilisé + pour générer "à froid" autant de journaux que d'hôtes virtuels.

Autres fichiers journaux

Modules Apparentés	Directives Apparentées
`mod_logio` `mod_log_forensic` `mod_cgi` `mod_rewrite`	`LogFormat` `ForensicLog` `PidFile` `RewriteLog` `RewriteLogLevel` `ScriptLog` `ScriptLogBuffer` `ScriptLogLength`

+ + + + +

Enregistrement du nombre réel d'octets envoyés et reçus

+ + +

Le module mod_logio fournit deux champs + LogFormat supplémentaires + (%I et %O) qui permettent d'enregistrer le nombre réel d'octets reçus et + envoyés sur le réseau.

+ + +

Journalisation de style investigation judiciaire (forensic logging)

+ + +

Le module mod_log_forensic permet la journalisation + à des fins d'investigation judiciaire des requêtes des clients. La + journalisation est effectuée avant et après le traitement de la requête, + qui fait donc l'objet de deux entrées dans le journal. Le générateur de + journaux d'investigation est très strict et ne permet aucune + personnalisation. C'est un inestimable outil de débogage et de sécurité.

+ + +

Fichier PID

+ + +

Au démarrage, le démon httpd Apache enregistre l'identifiant du + processus httpd parent dans le fichier logs/httpd.pid. + Le nom de ce fichier peut être modifié à l'aide de la directive + PidFile. Cet identifiant + permet à l'administrateur de redémarrer et arrêter le démon en + envoyant des signaux au processus parent ; sous Windows, vous devez + utiliser l'option de ligne de commande -k. Pour plus de détails, + consulter la page Arrêt et redémarrage.

+ + +

Journal des scripts

+ + +

Afin de faciliter le débogage, la directive + ScriptLog vous permet + d'enregistrer les entrées et sorties des scripts CGI. Elle ne doit être + utilisée que pendant la phase de test, et en aucun cas sur un + serveur en production. Vous trouverez plus d'informations dans la + documentation du module mod_cgi.

+ + +

Journal de réécriture

+ + +

Lorsqu'on utilise les fonctionnalités puissantes et complexes du + module mod_rewrite, il est presque + toujours nécessaire d'utiliser la directive + RewriteLog afin de + faciliter le débogage. Ce fichier journal fournit une analyse détaillée + de la transformation des requêtes par le moteur de réécriture. Le niveau + de détail est contrôlé par la directive + RewriteLogLevel.

+ +

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

+ \ No newline at end of file diff --git a/docs/manual/logs.html.ja.utf8 b/docs/manual/logs.html.ja.utf8 index a0af01fc56f..52ab99a8952 100644 --- a/docs/manual/logs.html.ja.utf8 +++ b/docs/manual/logs.html.ja.utf8 @@ -20,6 +20,7 @@ 2.3

ãã°ãã¡ã¤ã«

è¨èª: en | + fr | ja | ko | tr

@@ -565,6 +566,7 @@

è¨èª: en | + fr | ja | ko | tr

diff --git a/docs/manual/logs.html.ko.euc-kr b/docs/manual/logs.html.ko.euc-kr index 163d5e63bd1..5443b92f10a 100644 --- a/docs/manual/logs.html.ko.euc-kr +++ b/docs/manual/logs.html.ko.euc-kr @@ -19,6 +19,7 @@ Apache > HTTP Server > Documentation > Version 2.3

·Î±×ÆÄÀÏ

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

@@ -514,6 +515,7 @@

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

diff --git a/docs/manual/logs.html.tr.utf8 b/docs/manual/logs.html.tr.utf8 index 81521d00d30..4275772868b 100644 --- a/docs/manual/logs.html.tr.utf8 +++ b/docs/manual/logs.html.tr.utf8 @@ -19,6 +19,7 @@ Apache > HTTP Sunucusu > Belgeleme > SÃ¼rÃ¼m 2.3

GÃ¼nlÃ¼k DosyalarÄ±

Mevcut Diller: en | + fr | ja | ko | tr

@@ -565,6 +566,7 @@

Mevcut Diller: en | + fr | ja | ko | tr

diff --git a/docs/manual/logs.xml.meta b/docs/manual/logs.xml.meta index 1f03c4a2836..71c35f16e75 100644 --- a/docs/manual/logs.xml.meta +++ b/docs/manual/logs.xml.meta @@ -8,6 +8,7 @@ en + fr ja ko tr diff --git a/docs/manual/mod/directives.html.ja.utf8 b/docs/manual/mod/directives.html.ja.utf8 index 1f2f547adbd..a06c103d215 100644 --- a/docs/manual/mod/directives.html.ja.utf8 +++ b/docs/manual/mod/directives.html.ja.utf8 @@ -415,6 +415,7 @@

diff --git a/docs/manual/mod/mod_include.html.ja.utf8 b/docs/manual/mod/mod_include.html.ja.utf8 index 65ef5657e6a..8e2136ad04d 100644 --- a/docs/manual/mod/mod_include.html.ja.utf8 +++ b/docs/manual/mod/mod_include.html.ja.utf8 @@ -25,8 +25,6 @@

è¨èª: en | ja

@@ -42,6 +40,7 @@

ãã£ã¬ã¯ãã£ã

SSIAccessEnable
SSIEndTag
SSIErrorMsg
SSIStartTag

attribute

value

è¦ç´ (è¨³æ³¨: element) ãä»¥ä¸ã®è¡¨ã«ç¤ºãã¾ãã

è¦ç´ (è¨³æ³¨: element) ãä»¥ä¸ã®è¡¨ã«ç¤ºãã¾ãã

èª¬æ:	ãµã¼ãããã¼ã¹ãã html ããã¥ã¡ã³ã (Server Side Includes)
ã¹ãã¼ã¿ã¹:	Base
ã¢ã¸ã¥ã¼ã«èå¥å:	include_module

@@ -252,7 +251,7 @@

+ HTML ã®ã¢ã³ã«ã¼ (è¨³æ³¨: ãªã³ã¯) ã«å¤æããã¾ãã

exec cgi ãããã include virtual @@ -318,8 +317,9 @@ æ¿å¥ãã¾ããæ¿å¥ããããã¡ã¤ã«ã¯ã¢ã¯ã»ã¹å¶å¾¡ã®ç®¡çä¸ã«ããã¾ãã è§£æãã¦ãããã¡ã¤ã«ã®åå¨ãããã£ã¬ã¯ããªã« Option IncludesNOEXEC - ãè¨å®ããã¦ããå ´åãtext MIME ã¿ã¤ã (text/plain, - text/html ç) ã®ããã¥ã¡ã³ãã®ã¿ã¤ã³ã¯ã«ã¼ããè¡ãªããã¾ãã + ãè¨å®ããã¦ããå ´åãtext MIME ã¿ã¤ã + (text/plain, text/html ç) + ã®ããã¥ã¡ã³ãã®ã¿ã¤ã³ã¯ã«ã¼ããè¡ãªããã¾ãã ãã®ä»ã®å ´åã¯ãã¯ã¨ãªã¼æååãå«ããã³ãã³ãã§æå®ããã å®å¨ãª URL ãä½¿ã£ã¦æ®éã« CGI ã¹ã¯ãªãããå¼ã³åºããã¾ãã

@@ -358,6 +358,15 @@

HTML ããã¥ã¡ã³ãã« CGI ããã°ã©ã ã®åºåãå«ããæ¹æ³ã¨ãã¦ã¯ã include virtual ã®æ¹ã exec cgi ããã å¥½ã¾ããæ¹æ³ã§ãã

+ +

+ @@ -499,6 +508,27 @@

string

string ãç©ºã§ãªãå ´åã«çã§ã

-A string

(è¨³æ³¨: httpd ã®)è¨å®ãæ¤æ»ãã¦ã + æååã§æå®ãã URL ã«ã¢ã¯ã»ã¹ã§ããå ´å true ã§ã + ããã§ãªããã° false ã«ãªãã¾ãã + SSIAccessEnable ãæå¹ã®ã¨ãã«ã®ã¿ + ãã®æ¤æ»ã¯è¡ããã¾ãã + æ¿èªããã¦ããªãã¦ã¼ã¶ããã¯é ãã¦ãããã URL ã«ã¤ãã¦ã®æå ±ã + ãã¨ãã° URL ã¸ã®ãªã³ã¯ãªã©ãããå ´åã«ãä¾¿å©ã§ãã + æ¤æ»ã§ã¯ URL ã¸ã¢ã¯ã»ã¹ã§ãããã®æ¨©éã®ã¿ãè¡ãããURL + ãåå¨ãããã©ããã«ã¤ãã¦ã¯æ¤æ»ãããªããã¨ã«æ³¨æãã¦ãã ããã

+ +

Example

+  + + Click <a href="/private">here</a> to access private + information. + +  +

string1 = string2

       string1 == string2

       string1 != string2

@@ -602,6 +632,40 @@ ãããã©ã®ããã«ã¯ã©ã¤ã¢ã³ãã«éãããåºåã¾ã§è©ä¾¡ããããã æ¿å¥ãã¾ãã

+ +

æ£è¦è¡¨ç¾åã§ã® / ã®ã¨ã¹ã±ã¼ã

+ +

SSIAccessEnable ãã£ã¬ã¯ãã£ã

è¦ç´	èª¬æ

+ + + + + + +

èª¬æ:	æ¡ä»¶åå²ããã¼ã®å¶å¾¡ã§ -A ãã©ã°ãä½¿ããããã«ãã
æ§æ:	`SSIAccessEnable on\|off`
ããã©ã«ã:	`SSIAccessEnable off`
ã³ã³ããã¹ã:	ãã£ã¬ã¯ããª, .htaccess
ã¹ãã¼ã¿ã¹:	Base
ã¢ã¸ã¥ã¼ã«:	mod_include

SSIAccessEnable ãã£ã¬ã¯ãã£ããä½¿ã£ã¦ã + æ¡ä»¶åå²ããã¼ã®å¶å¾¡ã§ -A æ¤æ»ãä½¿ããããã«ãã¾ãã + SSIAccessEnable ã¯æ¬¡ã®å¤ãå¼æ°ã«ã¨ãã¾ã:

+ +

off:  ã§ã¯æååãæ£è¦è¡¨ç¾ã¨ãã¦ + è§£éããã-A ã¯ç¹å¥ãªæå³ã¯æã¡ã¾ããã
on:  ã§ã¯ãè¨å®ä¸ URL /foo + ã«ã¢ã¯ã»ã¹ã§ããªãå ´å false ã§ãã¢ã¯ã»ã¹ã§ããå ´åã¯ true

+ +

SSIEndTag ãã£ã¬ã¯ãã£ã

@@ -752,7 +816,7 @@ directive]" ã¢ã¸ã¥ã¼ã«:mod_include

diff --git a/docs/manual/mod/mod_include.xml.meta b/docs/manual/mod/mod_include.xml.meta index f85a6efa0b8..207bee2b3d3 100644 --- a/docs/manual/mod/mod_include.xml.meta +++ b/docs/manual/mod/mod_include.xml.meta @@ -8,6 +8,6 @@ en - ja + ja diff --git a/docs/manual/mod/quickreference.html.ja.utf8 b/docs/manual/mod/quickreference.html.ja.utf8 index 287f8e546c4..309ab585a83 100644 --- a/docs/manual/mod/quickreference.html.ja.utf8 +++ b/docs/manual/mod/quickreference.html.ja.utf8 @@ -665,108 +665,109 @@ CGI ã¹ã¯ãªããã«æå® SetHandler handler-name|NonesvdhCããããããã¡ã¤ã«ããã³ãã©ã§å¦çãããããã«ãã SetInputFilter filter[;filter...]svdhCã¯ã©ã¤ã¢ã³ãã®ãªã¯ã¨ã¹ãã POST ã®å¥åãå¦çãããã£ã«ã¿ãè¨å®ãã SetOutputFilter filter[;filter...]svdhCãµã¼ãã®å¿çãå¦çãããã£ã«ã¿ãè¨å®ãã -SSIEndTag tag "-->" svBinclude è¦ç´ ãçµäºãããæåå -SSIErrorMsg message "[an error occurred +svdhBSSI ã®ã¨ã©ã¼ããã£ãã¨ãã«è¡¨ç¤ºãããã¨ã©ã¼ã¡ãã»ã¼ã¸ -SSIStartTag tag "" svBinclude è¦ç´ ãçµäºãããæåå +SSIErrorMsg message "[an error occurred +svdhBSSI ã®ã¨ã©ã¼ããã£ãã¨ãã«è¡¨ç¤ºãããã¨ã©ã¼ã¡ãã»ã¼ã¸ +SSIStartTag tag "<!--#" svBinclude è¦ç´ ãéå§ããæåå +SSITimeFormat formatstring "%A, %d-%b-%Y %H:%M +svdhBæ¥ä»ããç¾ãæååã®æ¸å¼ãè¨å®ãã +SSIUndefinedEcho string "(none)" svdhBæªå®ç¾©ã®å¤æ°ã echo ãããã¨ãã«è¡¨ç¤ºãããæåå +SSLCACertificateFile file-pathsvEFile of concatenated PEM-encoded CA Certificates for Client Auth -SSLCACertificatePath directory-pathsvEDirectory of PEM-encoded CA Certificates for +SSLCACertificatePath directory-pathsvEDirectory of PEM-encoded CA Certificates for Client Auth -SSLCADNRequestFile file-pathsvEFile of concatenated PEM-encoded CA Certificates +SSLCADNRequestFile file-pathsvEFile of concatenated PEM-encoded CA Certificates for defining acceptable CA names -SSLCADNRequestPath directory-pathsvEDirectory of PEM-encoded CA Certificates for +SSLCADNRequestPath directory-pathsvEDirectory of PEM-encoded CA Certificates for defining acceptable CA names -SSLCARevocationFile file-pathsvEFile of concatenated PEM-encoded CA CRLs for +SSLCARevocationFile file-pathsvEFile of concatenated PEM-encoded CA CRLs for Client Auth -SSLCARevocationPath directory-pathsvEDirectory of PEM-encoded CA CRLs for +SSLCARevocationPath directory-pathsvEDirectory of PEM-encoded CA CRLs for Client Auth -SSLCertificateChainFile file-pathsvEFile of PEM-encoded Server CA Certificates -SSLCertificateFile file-pathsvEServer PEM-encoded X.509 Certificate file -SSLCertificateKeyFile file-pathsvEServer PEM-encoded Private Key file -SSLCipherSuite cipher-spec ALL:!ADH:RC4+RSA:+H +svdhECipher Suite available for negotiation in SSL +SSLCertificateChainFile file-pathsvEFile of PEM-encoded Server CA Certificates +SSLCertificateFile file-pathsvEServer PEM-encoded X.509 Certificate file +SSLCertificateKeyFile file-pathsvEServer PEM-encoded Private Key file +SSLCipherSuite cipher-spec ALL:!ADH:RC4+RSA:+H +svdhECipher Suite available for negotiation in SSL handshake -SSLCryptoDevice engine builtin sEEnable use of a cryptographic hardware accelerator -SSLEngine on|off|optional off svESSL Engine Operation Switch -SSLHonorCiperOrder flagsvEOption to prefer the server's cipher preference order -SSLMutex type none sESemaphore for internal mutual exclusion of +SSLCryptoDevice engine builtin sEEnable use of a cryptographic hardware accelerator +SSLEngine on|off|optional off svESSL Engine Operation Switch +SSLHonorCiperOrder flagsvEOption to prefer the server's cipher preference order +SSLMutex type none sESemaphore for internal mutual exclusion of operations -SSLOCSDefaultResponder urisvESet the default responder URI for OCSP validation -SSLOCSPEnable flagsvEEnable OCSP validation of the client certificate chain -SSLOCSPOverrideResponder flagsvEForce use of the default responder URI for OCSP validation -SSLOptions [+|-]option ...svdhEConfigure various SSL engine run-time options -SSLPassPhraseDialog type builtin sEType of pass phrase dialog for encrypted private +SSLOCSDefaultResponder urisvESet the default responder URI for OCSP validation +SSLOCSPEnable flagsvEEnable OCSP validation of the client certificate chain +SSLOCSPOverrideResponder flagsvEForce use of the default responder URI for OCSP validation +SSLOptions [+|-]option ...svdhEConfigure various SSL engine run-time options +SSLPassPhraseDialog type builtin sEType of pass phrase dialog for encrypted private keys -SSLProtocol [+|-]protocol ... all svEConfigure usable SSL protocol versions -SSLProxyCACertificateFile file-pathsvEFile of concatenated PEM-encoded CA Certificates +SSLProtocol [+|-]protocol ... all svEConfigure usable SSL protocol versions +SSLProxyCACertificateFile file-pathsvEFile of concatenated PEM-encoded CA Certificates for Remote Server Auth -SSLProxyCACertificatePath directory-pathsvEDirectory of PEM-encoded CA Certificates for +SSLProxyCACertificatePath directory-pathsvEDirectory of PEM-encoded CA Certificates for Remote Server Auth -SSLProxyCARevocationFile file-pathsvEFile of concatenated PEM-encoded CA CRLs for +SSLProxyCARevocationFile file-pathsvEFile of concatenated PEM-encoded CA CRLs for Remote Server Auth -SSLProxyCARevocationPath directory-pathsvEDirectory of PEM-encoded CA CRLs for +SSLProxyCARevocationPath directory-pathsvEDirectory of PEM-encoded CA CRLs for Remote Server Auth -SSLProxyCipherSuite cipher-spec ALL:!ADH:RC4+RSA:+H +svdhECipher Suite available for negotiation in SSL +SSLProxyCipherSuite cipher-spec ALL:!ADH:RC4+RSA:+H +svdhECipher Suite available for negotiation in SSL proxy handshake -SSLProxyEngine on|off off svESSL Proxy Engine Operation Switch -SSLProxyMachineCertificateFile filenamesEFile of concatenated PEM-encoded client certificates and keys to be used by the proxy -SSLProxyMachineCertificatePath directorysEDirectory of PEM-encoded client certificates and keys to be used by the proxy -SSLProxyProtocol [+|-]protocol ... all svEConfigure usable SSL protocol flavors for proxy usage -SSLProxyVerify level none svdhEType of remote server Certificate verification -SSLProxyVerifyDepth number 1 svdhEMaximum depth of CA Certificates in Remote Server +SSLProxyEngine on|off off svESSL Proxy Engine Operation Switch +SSLProxyMachineCertificateFile filenamesEFile of concatenated PEM-encoded client certificates and keys to be used by the proxy +SSLProxyMachineCertificatePath directorysEDirectory of PEM-encoded client certificates and keys to be used by the proxy +SSLProxyProtocol [+|-]protocol ... all svEConfigure usable SSL protocol flavors for proxy usage +SSLProxyVerify level none svdhEType of remote server Certificate verification +SSLProxyVerifyDepth number 1 svdhEMaximum depth of CA Certificates in Remote Server Certificate verification -SSLRandomSeed context source -[bytes]sEPseudo Random Number Generator (PRNG) seeding +SSLRandomSeed context source +[bytes]sEPseudo Random Number Generator (PRNG) seeding source -SSLRequire expressiondhEAllow access only when an arbitrarily complex +SSLRequire expressiondhEAllow access only when an arbitrarily complex boolean expression is true -SSLRequireSSLdhEDeny access when SSL is not used for the +SSLRequireSSLdhEDeny access when SSL is not used for the HTTP request -SSLSessionCache type none sEType of the global/inter-process SSL Session +SSLSessionCache type none sEType of the global/inter-process SSL Session Cache -SSLSessionCacheTimeout seconds 300 svENumber of seconds before an SSL session expires +SSLSessionCacheTimeout seconds 300 svENumber of seconds before an SSL session expires in the Session Cache -SSLUserName varnamesdhEVariable name to determine user name -SSLVerifyClient level none svdhEType of Client Certificate verification -SSLVerifyDepth number 1 svdhEMaximum depth of CA Certificates in Client +SSLUserName varnamesdhEVariable name to determine user name +SSLVerifyClient level none svdhEType of Client Certificate verification +SSLVerifyDepth number 1 svdhEMaximum depth of CA Certificates in Client Certificate verification -StartServers numbersMèµ·åæã«çæãããåãµã¼ãããã»ã¹ã®æ° -StartThreads numbersMèµ·åæã«çæãããã¹ã¬ããã®æ° -Substitute s/pattern/substitution/[infq]dhXPattern to filter the response content -SuexecUserGroup User GroupsvECGI ããã°ã©ã ã®ã¦ã¼ã¶ãã¼ããã·ã§ã³ãã°ã«ã¼ããã¼ããã·ã§ã³ -ThreadLimit numbersMè¨å®å¯è½ãªåããã»ã¹æ¯ã®ã¹ã¬ããæ°ã®ä¸éã +StartServers numbersMèµ·åæã«çæãããåãµã¼ãããã»ã¹ã®æ° +StartThreads numbersMèµ·åæã«çæãããã¹ã¬ããã®æ° +Substitute s/pattern/substitution/[infq]dhXPattern to filter the response content +SuexecUserGroup User GroupsvECGI ããã°ã©ã ã®ã¦ã¼ã¶ãã¼ããã·ã§ã³ãã°ã«ã¼ããã¼ããã·ã§ã³ +ThreadLimit numbersMè¨å®å¯è½ãªåããã»ã¹æ¯ã®ã¹ã¬ããæ°ã®ä¸éã è¨å®ãã¾ã -ThreadsPerChild numbersMåããã»ã¹ããããã«çæãããã¹ã¬ããæ° -ThreadStackSize sizesMã¯ã©ã¤ã¢ã³ãã®ã³ãã¯ã·ã§ã³ãåãæã¤ã¹ã¬ãããä½¿ç¨ãã +ThreadsPerChild numbersMåããã»ã¹ããããã«çæãããã¹ã¬ããæ° +ThreadStackSize sizesMã¯ã©ã¤ã¢ã³ãã®ã³ãã¯ã·ã§ã³ãåãæã¤ã¹ã¬ãããä½¿ç¨ãã ã¹ã¿ãã¯ã®ãã¤ãæ° -TimeOut seconds 300 svCåã¤ãã³ãã«ã¤ãã¦ããªã¯ã¨ã¹ããå¤±æãããã¾ã§ã«ãµã¼ãã +TimeOut seconds 300 svCåã¤ãã³ãã«ã¤ãã¦ããªã¯ã¨ã¹ããå¤±æãããã¾ã§ã«ãµã¼ãã å¾ã¤æéãè¨å® -TraceEnable [on|off|extended] on sCTRACE ã¡ã½ããã®ãªã¯ã¨ã¹ãã«å¯¾ããå¿çæ¹æ³ãæ±ºãã +TraceEnable [on|off|extended] on sCTRACE ã¡ã½ããã®ãªã¯ã¨ã¹ãã«å¯¾ããå¿çæ¹æ³ãæ±ºãã -TransferLog file|pipesvBãã°ãã¡ã¤ã«ã®ä½ç½®ãæå® -TypesConfig file-path conf/mime.types sBmime.types ãã¡ã¤ã«ã®ä½ç½® -UnsetEnv env-variable [env-variable] -...svdhBç°å¢ããå¤æ°ãåãé¤ã -UseCanonicalName On|Off|Dns Off svdCãµã¼ããèªåèªèº«ã®ååã¨ãã¼ããæ±ºå®ããæ¹æ³ãè¨å®ãã -UseCanonicalPhysicalPort On|Off Off svdCèªåèªèº«ã®ååã¨ãã¼ãçªå·ãè§£æ±ºããæ¹æ³ãè¨å®ãã +TransferLog file|pipesvBãã°ãã¡ã¤ã«ã®ä½ç½®ãæå® +TypesConfig file-path conf/mime.types sBmime.types ãã¡ã¤ã«ã®ä½ç½® +UnsetEnv env-variable [env-variable] +...svdhBç°å¢ããå¤æ°ãåãé¤ã +UseCanonicalName On|Off|Dns Off svdCãµã¼ããèªåèªèº«ã®ååã¨ãã¼ããæ±ºå®ããæ¹æ³ãè¨å®ãã +UseCanonicalPhysicalPort On|Off Off svdCèªåèªèº«ã®ååã¨ãã¼ãçªå·ãè§£æ±ºããæ¹æ³ãè¨å®ãã -User unix-userid #-1 sMãªã¯ã¨ã¹ãã«å¿çããéã«ç¨ããã¦ã¼ã¶ ID -UserDir directory-filename [directory-filename] ...svBã¦ã¼ã¶å°ç¨ãã£ã¬ã¯ããªã®ä½ç½® -VirtualDocumentRoot interpolated-directory|none none svEDynamically configure the location of the document root +User unix-userid #-1 sMãªã¯ã¨ã¹ãã«å¿çããéã«ç¨ããã¦ã¼ã¶ ID +UserDir directory-filename [directory-filename] ...svBã¦ã¼ã¶å°ç¨ãã£ã¬ã¯ããªã®ä½ç½® +VirtualDocumentRoot interpolated-directory|none none svEDynamically configure the location of the document root for a given virtual host -VirtualDocumentRootIP interpolated-directory|none none svEDynamically configure the location of the document root +VirtualDocumentRootIP interpolated-directory|none none svEDynamically configure the location of the document root for a given virtual host -<VirtualHost +<VirtualHost addr[:port] [addr[:port]] - ...> ... </VirtualHost>sCç¹å®ã®ãã¹ãåã IP ã¢ãã¬ã¹ã®ã¿ã«é©ç¨ããããã£ã¬ã¯ãã£ãã + ...> ... </VirtualHost>sCç¹å®ã®ãã¹ãåã IP ã¢ãã¬ã¹ã®ã¿ã«é©ç¨ããããã£ã¬ã¯ãã£ãã å²ã -VirtualScriptAlias interpolated-directory|none none svEDynamically configure the location of the CGI directory for +VirtualScriptAlias interpolated-directory|none none svEDynamically configure the location of the CGI directory for a given virtual host -VirtualScriptAliasIP interpolated-directory|none none svEDynamically configure the location of the cgi directory for +VirtualScriptAliasIP interpolated-directory|none none svEDynamically configure the location of the cgi directory for a given virtual host -Win32DisableAcceptExsMãããã¯ã¼ã¯æ¥ç¶ã®åãä»ãã« accept() ãAcceptEx ã®ä»£ããã«ä½¿ã -XBitHack on|off|full off svdhBå®è¡ããããè¨å®ããããã¡ã¤ã«ã® SSI ãã£ã¬ã¯ãã£ãã +Win32DisableAcceptExsMãããã¯ã¼ã¯æ¥ç¶ã®åãä»ãã« accept() ãAcceptEx ã®ä»£ããã«ä½¿ã +XBitHack on|off|full off svdhBå®è¡ããããè¨å®ããããã¡ã¤ã«ã® SSI ãã£ã¬ã¯ãã£ãã è§£æãã

diff --git a/docs/manual/new_features_2_4.html b/docs/manual/new_features_2_4.html index b86f7c57575..7d4eca0a84c 100644 --- a/docs/manual/new_features_2_4.html +++ b/docs/manual/new_features_2_4.html @@ -3,3 +3,7 @@ URI: new_features_2_4.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 + +URI: new_features_2_4.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 diff --git a/docs/manual/new_features_2_4.html.en b/docs/manual/new_features_2_4.html.en index 22453497461..fcb681fa66c 100644 --- a/docs/manual/new_features_2_4.html.en +++ b/docs/manual/new_features_2_4.html.en @@ -18,7 +18,8 @@

Apache > HTTP Server > Documentation > Version 2.3

Overview of new features in Apache 2.4

Available Languages: en

Available Languages: en | + fr

This document describes some of the major changes between the @@ -71,7 +72,8 @@

Available Languages: en

Available Languages: en | + fr

diff --git a/docs/manual/new_features_2_4.html.fr b/docs/manual/new_features_2_4.html.fr new file mode 100644 index 00000000000..5f5a5717a8e --- /dev/null +++ b/docs/manual/new_features_2_4.html.fr @@ -0,0 +1,81 @@ + + + +Vue d'ensemble des nouvelles fonctionnalités d'Apache 2.4 - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.3

Vue d'ensemble des nouvelles fonctionnalités d'Apache 2.4

Langues Disponibles: en | + fr

+ +

Ce document décrit certaines modifications majeures entre les versions + 2.2 et 2.4 du serveur HTTP Apache. Pour les nouvelles fonctionnalités + ajoutées depuis la version 2.0, se référer au document + nouvelles fonctionnalités + de la version 2.2.

Améliorations du noyau
Améliorations des modules
Améliorations des programmes
Modifications pour le développeur de modules

Améliorations du noyau

+ + +

Améliorations des modules

+ + +

Améliorations des programmes

+ + +

Modifications pour le développeur de modules

+ +

Ajout de code pour la vérification de la configuration: Une nouvelle fonction, check_config, a été ajoutée et + s'exécute entre les fonctions pre_config et + open_logs. Elle s'exécute aussi avant la fonction + test_config si l'option -t est passée au + démon httpd. La fonction check_config + permet aux modules de vérifier l'interdépendance des valeurs des + directives de configuration et d'ajuster ces valeurs, alors que les + messages du serveur peuvent encore être affichés sur la console. + L'utilisateur est ainsi averti des erreurs de configuration avant que la + fonction du noyau open_logs ne redirige les sorties de la + console vers le journal des erreurs.
Ajout d'un analyseur syntaxique d'expressions: Nous disposons à présent d'un analyseur générique d'expressions, dont l'API + est décrite dans ap_expr.h. Il s'agit d'une adaptation de + l'analyseur qu'on trouvait auparavant dans mod_include.

Langues Disponibles: en | + fr

+ \ No newline at end of file diff --git a/docs/manual/new_features_2_4.xml.meta b/docs/manual/new_features_2_4.xml.meta index 3ea077a81ef..c40e1ec7816 100644 --- a/docs/manual/new_features_2_4.xml.meta +++ b/docs/manual/new_features_2_4.xml.meta @@ -8,5 +8,6 @@ en + fr diff --git a/docs/manual/sections.html b/docs/manual/sections.html index d1cce6cac09..f4f8cf04106 100644 --- a/docs/manual/sections.html +++ b/docs/manual/sections.html @@ -4,6 +4,10 @@ URI: sections.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 +URI: sections.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 + URI: sections.html.ja.utf8 Content-Language: ja Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/sections.html.en b/docs/manual/sections.html.en index 8ad7e8b0e78..faaadc379a9 100644 --- a/docs/manual/sections.html.en +++ b/docs/manual/sections.html.en @@ -19,6 +19,7 @@ Apache > HTTP Server > Documentation > Version 2.3

Configuration Sections

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

@@ -470,6 +471,7 @@ Deny from badguy.example.com

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

diff --git a/docs/manual/sections.html.fr b/docs/manual/sections.html.fr new file mode 100644 index 00000000000..b118c6963fd --- /dev/null +++ b/docs/manual/sections.html.fr @@ -0,0 +1,530 @@ + + + +Sections de configuration - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.3

Sections de configuration

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

Les directives des fichiers de configuration peuvent s'appliquer +au serveur dans son ensemble, ou seulement à des répertoires, fichiers, hôtes, +ou URLs particuliers. Ce document décrit comment utiliser les conteneurs de +sections de configuration ou les fichiers .htaccess pour +modifier la portée des directives de configuration.

Types de conteneurs de sections de +configuration
Système de fichiers et +arborescence du site web
Hôtes virtuels
Mandataire
Quelles sont les directives autorisées ?
Comment les sections sont combinées entre elles

Types de conteneurs de sections de +configuration

+ +

Modules Apparentés	Directives Apparentées
`core` `mod_version` `mod_proxy`	`<Directory>` `<DirectoryMatch>` `<Files>` `<FilesMatch>` `<IfDefine>` `<IfModule>` `<IfVersion>` `<Location>` `<LocationMatch>` `<Proxy>` `<ProxyMatch>` `<VirtualHost>`

+ +

Il existe deux grands types de conteneurs. La plupart des conteneurs sont +évalués pour chaque requête. Les directives qu'ils contiennent s'appliquent +seulement aux requêtes qui sont concernées par le conteneur. En revanche, +les conteneurs +<IfDefine>, <IfModule>, et +<IfVersion> sont +évalués seulement au démarrage et au redémarrage du serveur. +Si leurs conditions sont vérifiées au démarrage, les directives qu'ils contiennent +s'appliqueront à toutes les requêtes. Si leurs conditions ne sont pas vérifiées, les +directives qu'ils contiennent seront ignorées.

+ +

Le conteneur <IfDefine> +contient des directives qui ne seront appliquées que si un paramètre +approprié a été défini dans la ligne de commande de httpd. +Par exemple, +avec la configuration suivante, toutes les requêtes seront redirigées vers +un autre site si le serveur est démarré en utilisant la ligne de commande : +httpd -DClosedForNow:

+ +

+<IfDefine ClosedForNow> +Redirect / http://otherserver.example.com/ +</IfDefine> +

+ +

Le conteneur <IfModule> +est similaire; les directives qu'il contient ne s'appliqueront que si +un module particulier est disponible au niveau du serveur. +Le module doit être soit compilé statiquement dans le serveur, soit +dynamiquement et dans ce cas, la ligne LoadModule correspondante doit apparaître +plus haut dans le fichier de configuration. Ce conteneur ne doit être +utilisé que dans le cas où votre fichier de configuration doit fonctionner +indépendamment de la présence ou de l'absence de certains modules. +Il ne doit pas contenir de directives que vous souhaitez voir s'appliquer +systématiquement, car vous pouvez perdre ainsi de précieux messages d'erreur +à propos de modules manquants.

+ +

Dans l'exemple suivant, la directive MimeMagicFiles ne s'appliquera que si le +module mod_mime_magic est disponible.

+ +

+<IfModule mod_mime_magic.c> +MimeMagicFile conf/magic +</IfModule> +

+ +

Le conteneur +<IfVersion> +est similaire aux conteneurs <IfDefine> et <IfModule>; les directives qu'il contient ne +s'appliqueront que si une version particulière du serveur s'exécute. Ce +conteneur a été conçu pour une utilisation dans les suites de tests +et les grands réseaux qui doivent prendre en compte différentes versions +et configurations de httpd.

+ +

+ <IfVersion >= 2.1> + + # les directives situées ici ne s'appliquent que si la version + # est supérieure ou égale à 2.1.0. + + </IfVersion> +

+ +

<IfDefine>, +<IfModule>, et +<IfVersion> +peuvent inverser leur test conditionnel en le faisant précéder d'un "!". +De plus, ces sections peuvent être imbriquées afin de définir des restrictions +plus complexes.

Système de fichiers et +arborescence du site web

+ +

Les conteneurs de sections de configuration les plus couramment utilisés +sont ceux qui modifient la configuration de points particuliers du système de +fichiers ou de l'arborescence du site web. Tout d'abord, il est important de +comprendre la différence entre les deux. Le système de fichiers est une vue +de vos disques tels qu'ils sont perçus par votre système d'exploitation. +Par exemple, avec une installation par défaut, +Apache est situé dans /usr/local/apache2 pour le système de +fichiers UNIX, ou "c:/Program Files/Apache Group/Apache2" pour +le système de fichiers Windows. (Notez que des slashes directs doivent +toujours être utilisés comme séparateur de chemin dans Apache, même sous +Windows.) Quant à +l'arborescence du site web, il s'agit d'une vue de votre site +tel que présenté par le +serveur web et perçue par le client. Ainsi le chemin /dir/ dans +l'arborescence du site web correspond au chemin +/usr/local/apache2/htdocs/dir/ dans le système de fichiers pour +une installation d'Apache par défaut sous UNIX. +En outre, l'arborescence du site web n'a pas besoin de correspondre en permanence au +système de fichiers, car les pages web peuvent être générées dynamiquement +à partir de bases de données ou d'autres emplacements.

+ +

Conteneurs de système de fichiers

+ +

Les conteneurs <Directory> +et <Files>, +ainsi que leurs équivalents acceptant les +expressions rationnelles, +appliquent des directives à certaines parties du système de fichiers. +Les directives contenues dans une section <Directory> s'appliquent au répertoire +précisé, ainsi qu'à tous ses sous-répertoires. +Le même effet peut être obtenu en utilisant les fichiers .htaccess. Par exemple, avec la +configuration suivante, l'indexation sera activée pour le répertoire +/var/web/dir1 et tous ses sous-répertoires.

+ +

+<Directory /var/web/dir1> +Options +Indexes +</Directory> +

+ +

Les directives contenues dans une section <Files> s'appliquent à tout fichier +avec le nom spécifié, quel que soit le répertoire dans lequel il se trouve. +Ainsi par exemple, les directives de configuration suivantes, si elles sont +placées dans la section principale du fichier de configuration, vont interdire +l'accès à tout fichier nommé private.html quel que soit +l'endroit où il se trouve.

+ +

+<Files private.html> +Order allow,deny +Deny from all +</Files> +

+ +

Pour faire référence à des fichiers qui se trouvent en des points +particuliers du système de fichiers, les sections +<Files> et +<Directory> +peuvent être combinées. Par exemple, la configuration suivante va interdire +l'accès à /var/web/dir1/private.html, +/var/web/dir1/subdir2/private.html, +/var/web/dir1/subdir3/private.html, ainsi que toute instance de +private.html qui se trouve dans l'arborescence +/var/web/dir1/.

+ +

+<Directory /var/web/dir1> +<Files private.html> +Order allow,deny +Deny from all +</Files> +</Directory> +

+ + +

Conteneurs de l'arborescence du site web

+ +

le conteneur <Location> +et son équivalent acceptant les +expressions rationnelles, modifient quant à eux la +configuration de parties de l'arborescence du site web. Par exemple, la +configuration suivante interdit l'accès à toute URL dont la partie chemin +commence par /private. +En particulier, l'interdiction s'appliquera aux requêtes pour : +http://yoursite.example.com/private, +http://yoursite.example.com/private123, et +http://yoursite.example.com/private/dir/file.html ainsi qu'à +toute requête commençant par la chaîne de caractères /private.

+ +

+<Location /private> +Order Allow,Deny +Deny from all +</Location> +

+ +

Le conteneur <Location> +n'a pas besoin de faire référence à un élément du système de fichiers. +Par exemple, l'exemple suivant montre comment faire référence à une URL +particulière vers un gestionnaire interne d'Apache fourni par le module +mod_status. +Il n'est pas nécessaire de trouver un fichier nommé server-status +dans le système de fichiers.

+ +

+<Location /server-status> +SetHandler server-status +</Location> +

+ + +

Caractères de remplacement +et expressions rationnelles

+ +

Les conteneurs +<Directory>, +<Files>, et +<Location> +peuvent utiliser des caractères de remplacement de style shell comme dans +la fonction fnmatch de la bibliothèque C standard. +Le caractère "*" +correspond à toute séquence de caractères, "?" à un caractère seul, +et "[seq]" à tout caractère contenu dans seq. +Le caractère "/" +ne peut pas faire l'objet d'un remplacement; +il doit être spécifié explicitement.

+ +

Si une définition des critères de correspondance +encore plus souple est nécessaire, chaque conteneur +possède son équivalent acceptant les expressions rationnelles : <DirectoryMatch>, <FilesMatch>, et <LocationMatch> acceptent les +expressions rationnelles compatibles Perl +pour définir les critères de correspondance. Mais voyez plus loin la section +à propos de la combinaison des sections de configuration +pour comprendre comment l'utilisation de +conteneurs avec des expressions rationnelles va modifier la manière +dont les directives sont appliquées.

+ +

Un conteneur qui modifie la configuration de tous les +répertoires utilisateurs à l'aide de caractères de remplacement +mais sans utiliser +les expressions rationnelles pourrait ressembler à ceci :

+ +

+<Directory /home/*/public_html> +Options Indexes +</Directory> +

+ +

Avec les conteneurs utilisant les expressions rationnelles, +on peut interdire l'accès à de nombreux types de fichiers d'images +simultanément :

+<FilesMatch \.(?i:gif|jpe?g|png)$> +Order allow,deny +Deny from all +</FilesMatch> +

+ + + +

Que faut-il utiliser et quand ?

+ +

Choisir entre des conteneurs de système de fichiers et des conteneurs +d'arborescence du site web est vraiment très simple. +Pour appliquer des directives à des objets qui résident dans le système de +fichiers, utilisez toujours un conteneur <Directory> ou <Files>. Pour appliquer des directives à des objets +qui ne résident pas dans le système de fichiers (comme une page web générée +par une base de données), utilisez un conteneur <Location>.

+ +

Il ne faut jamais utiliser un conteneur <Location> pour restreindre l'accès à des +objets du système de fichiers, car plusieurs localisations de +l'arborescence du site web (URLs) peuvent correspondre à la même localisation +du système de fichier, ce qui peut permettre de contourner vos restrictions. +Par exemple, imaginez la configuration suivante :

+ +

+<Location /dir/> +Order allow,deny +Deny from all +</Location> +

+ +

Elle fonctionne correctement si la requête appelle +http://yoursite.example.com/dir/. Mais que va-t-il se passer si +votre système de fichiers est insensible à la casse ? +Votre restriction va pouvoir être tout simplement contournée en envoyant une +requête sur +http://yoursite.example.com/DIR/. Le conteneur <Directory>, quant à lui, s'appliquera +à tout contenu servi à partir de cette localisation, +sans tenir compte de la manière dont il est appelé. +(Les liens du système de fichiers constituent une exception. +Le même répertoire peut être placé dans plusieurs parties du système de +fichiers en utilisant des liens symboliques. Le conteneur +<Directory> va suivre le +lien symbolique sans modifier le nom du chemin. Par conséquent, pour plus de +sécurité, les liens symboliques doivent être désactivés à l'aide de la +directive +Options appropriée.)

+ +

Si vous pensez que vous n'êtes pas concerné par ce problème +parceque vous utilisez un système de fichiers sensible à la casse, +gardez à l'esprit qu'il y a de nombreuses autres manières pour faire +correspondre plusieurs localisations de l'arborescence du site web à la même +localisation du système de fichiers. C'est pourquoi vous devez autant que +possible toujours utiliser les conteneurs de système de fichiers. +Il y a cependant une exception à cette règle. Placer des restrictions de +configuration dans un conteneur <Location +/> est tout à fait sans rique car ce conteneur va s'appliquer à +toutes les requêtes sans tenir compte de l'URL spécifique.

+ + +

Hôtes virtuels

+ +

Le conteneur <VirtualHost> +contient des directives qui s'appliquent à des hôtes spécifiques. +Ceci s'avère utile pour servir des hôtes multiples à partir de la même machine, +chacun d'entre eux possédant une configuration différente. Pour de plus amples +informations, +voir la Documentation sur les hôtes virtuels.

Mandataire

+ +

Les conteneurs +<Proxy> +et <ProxyMatch> +appliquent les directives de configuration qu'ils contiennent uniquement aux +sites qui correspondent à l'URL spécifiée et auxquels on a +accédé via le serveur mandataire du module mod_proxy. +Par exemple, la configuration suivante +va interdire l'utilisation du serveur proxy pour accéder au site +cnn.com.

+ +

+<Proxy http://cnn.com/*> +Order allow,deny +Deny from all +</Proxy> +

Quelles sont les directives autorisées ?

+ +

Pour déterminer quelles sont les directives autorisées pour tel type de +section de configuration, vérifiez le Contexte de la directive. +Tout ce qui est autorisé dans les sections +<Directory> +l'est aussi d'un point de vue syntaxique dans les sections +<DirectoryMatch>, +<Files>, +<FilesMatch>, +<Location>, +<LocationMatch>, +<Proxy>, +et <ProxyMatch>. +Il y a cependant quelques exceptions :

+ +

La directive AllowOverride +ne fonctionne que dans les sections +<Directory>.
Les Options FollowSymLinks et +SymLinksIfOwnerMatch ne fonctionnent que dans les sections +<Directory> ou les fichiers +.htaccess.
La directive Options ne peut pas être +utilisée dans les sections +<Files> +et <FilesMatch>.

Comment les sections sont combinées entre elles

+ +

Les sections de configuration sont appliquées dans un ordre très particulier. +Il est important de savoir comment cet ordre est défini car il peut avoir +des effets importants sur la manière dont les directives de configuration +sont interprétées.

+ +

L'ordre dans lequel les sections sont combinées est :

+ +

Les sections <Directory> (à l'exception des + expressions rationnelles) + et les fichiers .htaccess sont appliqués simultanément (avec + la possibilité pour .htaccess, s'il y est autorisé, de + prévaloir sur + <Directory>)
Les sections + <DirectoryMatch> + (et <Directory ~>)
Les sections <Files> et <FilesMatch> sont appliquées + simultanément
Les sections + <Location> + et <LocationMatch> sont appliquées + simultanément

+ +

Mises à part les sections <Directory>, chaque groupe est traité selon + l'ordre dans lequel il apparaît dans les fichiers de configuration. + Les sections <Directory> (groupe 1 ci-dessus) + sont traitées dans l'ordre du répertoire le plus court vers le plus long. + Par exemple, <Directory /var/web/dir> sera + traité avant <Directory + /var/web/dir/subdir>. Si plusieurs sections <Directory> s'appliquent au même + répertoire, elles sont traitées selon l'ordre dans lequel elles + apparaissent dans le fichier de configuration. + Les sections de configuration incluses via la directive Include sont traitées comme si elles se + trouvaient réellement dans le fichier qui les inclut à la position de la + directive + Include.

+ +

Les sections situées à l'intérieur de sections <VirtualHost> + sont appliquées après les sections correspondantes situées en + dehors de la définition de l'hôte virtuel, ce qui permet à l'hôte virtuel + de prévaloir sur la configuration du serveur principal.

+ +

Quand la requête est servie par le module mod_proxy, + le conteneur <Proxy> + prend la place du conteneur <Directory> dans l'ordre de traitement.

+ +

Les sections situées plus loin dans le fichier de configuration prévalent + sur celles qui les précèdent.

+ +

Note technique

+ Une séquence + <Location>/<LocationMatch> + est réellement traitée juste avant la phase de traduction du nom + (où Aliases et DocumentRoots + sont utilisés pour faire correspondre les URLs aux noms de fichiers). + Les effets de cette séquence disparaissent totalement lorsque + la traduction est terminée. +

+ +

Quelques exemples

+ +

Voici un exemple imaginaire qui montre l'ordre de combinaison des sections. +En supposant qu'elles s'appliquent toutes à la requête, les directives de +cet exemple seront appliquées dans l'ordre suivant : A > B > C > D > +E.

+ +

+<Location /> +E +</Location> + +<Files f.html> +D +</Files> + +<VirtualHost *> +<Directory /a/b> +B +</Directory> +</VirtualHost> + +<DirectoryMatch "^.*b$"> +C +</DirectoryMatch> + +<Directory /a/b> +A +</Directory> + +

+ +

Pour un exemple plus concret, considérez ce qui suit. Sans tenir compte +de toute restriction d'accès placée dans les sections <Directory>, la section <Location> sera +évaluée en dernier et permettra un accès au serveur sans aucune restriction. +En d'autres termes, l'ordre de la combinaison des sections est important, +soyez donc prudent !

+ +

+<Location /> +Order deny,allow +Allow from all +</Location> + :if expand("%") == ""|browse confirm w|else|confirm w|endif + +# Arrghs! Cette section <Directory> n'aura aucun effet +<Directory /> +Order allow,deny +Allow from all +Deny from badguy.example.com +</Directory> +

+ + + +

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

+ \ No newline at end of file diff --git a/docs/manual/sections.html.ja.utf8 b/docs/manual/sections.html.ja.utf8 index 97d3bfe8405..c2a84edf37a 100644 --- a/docs/manual/sections.html.ja.utf8 +++ b/docs/manual/sections.html.ja.utf8 @@ -20,6 +20,7 @@ 2.3

ã»ã¯ã·ã§ã³ã®è¨å®

è¨èª: en | + fr | ja | ko | tr

@@ -483,6 +484,7 @@ Deny from badguy.example.com

è¨èª: en | + fr | ja | ko | tr

diff --git a/docs/manual/sections.html.ko.euc-kr b/docs/manual/sections.html.ko.euc-kr index 3b0d0966465..0439822051b 100644 --- a/docs/manual/sections.html.ko.euc-kr +++ b/docs/manual/sections.html.ko.euc-kr @@ -19,6 +19,7 @@ Apache > HTTP Server > Documentation > Version 2.3

¼½¼Ç ¼³Á¤

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

@@ -415,6 +416,7 @@ Deny from badguy.example.com

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

diff --git a/docs/manual/sections.html.tr.utf8 b/docs/manual/sections.html.tr.utf8 index c790168d350..3bbab662b05 100644 --- a/docs/manual/sections.html.tr.utf8 +++ b/docs/manual/sections.html.tr.utf8 @@ -19,6 +19,7 @@ Apache > HTTP Sunucusu > Belgeleme > SÃ¼rÃ¼m 2.3

YapÄ±landÄ±rma BÃ¶lÃ¼mleri

Mevcut Diller: en | + fr | ja | ko | tr

@@ -494,6 +495,7 @@ BaÅka bir deyiÅle, katÄ±ÅtÄ±rma sÄ±rasÄ± Ã¶nemlidir, bu nedenle dikkatli olma

Mevcut Diller: en | + fr | ja | ko | tr

diff --git a/docs/manual/sections.xml.meta b/docs/manual/sections.xml.meta index e54ddb54846..676e86d8f4a 100644 --- a/docs/manual/sections.xml.meta +++ b/docs/manual/sections.xml.meta @@ -8,6 +8,7 @@ en + fr ja ko tr diff --git a/docs/manual/server-wide.html b/docs/manual/server-wide.html index bc7d087ae3a..66b9be57855 100644 --- a/docs/manual/server-wide.html +++ b/docs/manual/server-wide.html @@ -4,6 +4,10 @@ URI: server-wide.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 +URI: server-wide.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 + URI: server-wide.html.ja.utf8 Content-Language: ja Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/server-wide.html.en b/docs/manual/server-wide.html.en index ecbca34da9b..0ed84a4ae58 100644 --- a/docs/manual/server-wide.html.en +++ b/docs/manual/server-wide.html.en @@ -19,6 +19,7 @@ Apache > HTTP Server > Documentation > Version 2.3

Server-Wide Configuration

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

@@ -93,6 +94,7 @@ the basic operations of the server.

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

diff --git a/docs/manual/server-wide.html.fr b/docs/manual/server-wide.html.fr new file mode 100644 index 00000000000..ada59ba6ef5 --- /dev/null +++ b/docs/manual/server-wide.html.fr @@ -0,0 +1,106 @@ + + + +Configuration à l'échelle du serveur - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.3

Configuration à l'échelle du serveur

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

+ +

Ce document explique le fonctionnement de certaines directives du serveur +de base qui sont utilisées pour configurer les opérations élémentaires du +serveur.

Identification du serveur
Localisation des fichiers
Limitation de l'utilisation des ressources

Identification du serveur

Modules Apparentés	Directives Apparentées
	`ServerName` `ServerAdmin` `ServerSignature` `ServerTokens` `UseCanonicalName` `UseCanonicalPhysicalPort`

+ + + + +

Les directives ServerAdmin et + ServerTokens contrôlent la nature des + informations à propos du serveur qui seront affichées dans les documents + générés par le serveur comme les messages d'erreur. La directive + ServerTokens définit la valeur du + champ d'en-tête de la réponse du serveur HTTP.

+ +

Le serveur utilise les directives + ServerName, + UseCanonicalName et + UseCanonicalPhysicalPort pour + déterminer la manière de construire des URLs vers ses propres ressources. + Par exemple, quand un client émet une requête vers un répertoire, mais + n'ajoute pas le slash final au nom du répertoire, Apache doit rediriger le + client vers le nom complet incluant le slash final afin que le client + puisse résoudre correctement les références relatives présentes dans + le document.

Localisation des fichiers

Modules Apparentés	Directives Apparentées
	`CoreDumpDirectory` `DocumentRoot` `ErrorLog` `LockFile` `PidFile` `ScoreBoardFile` `ServerRoot`

+ + + + +

Ces directives contrôlent la localisation des différents fichiers + nécessaires au bon fonctionnement d'Apache. Quand le chemin utilisé ne + commence pas par un slash (/), la localisation des fichiers est relative + à la valeur de la directive + ServerRoot. Soyez prudent avec la + localisation de fichiers dans des répertoires où les utilisateurs non root + ont les droits en écriture. Voir la documention sur les + Conseils à propos + de la sécurité pour plus de détails.

Limitation de l'utilisation des ressources

Modules Apparentés	Directives Apparentées
	`LimitRequestBody` `LimitRequestFields` `LimitRequestFieldsize` `LimitRequestLine` `RLimitCPU` `RLimitMEM` `RLimitNPROC` `ThreadStackSize`

+ + + + +

Les directives LimitRequest* permettent de + limiter la quantité de ressources consommées par Apache pour le traitement + des requêtes des clients. Cette limitation permet de minimiser les effets + de certains types d'attaques par déni de service.

+ +

Les directives RLimit* permettent de limiter la + quantité de ressources utilisable par les processus initiés (forked) par + les processus enfants Apache. Elles permettent en particulier de contrôler + les ressources utilisées par les scripts CGI et les commandes exec des + "Inclusions côté serveur" (Server Side Includes ou SSI).

+ +

La directive ThreadStackSize + permet sur certaines plates-formes de contrôler la taille de la pile.

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

+ \ No newline at end of file diff --git a/docs/manual/server-wide.html.ja.utf8 b/docs/manual/server-wide.html.ja.utf8 index a6e83e24d69..9ef4ee86e6d 100644 --- a/docs/manual/server-wide.html.ja.utf8 +++ b/docs/manual/server-wide.html.ja.utf8 @@ -20,6 +20,7 @@ 2.3

ãµã¼ãå¨ä½ã®è¨å®

è¨èª: en | + fr | ja | ko | tr

@@ -94,6 +95,7 @@

è¨èª: en | + fr | ja | ko | tr

diff --git a/docs/manual/server-wide.html.ko.euc-kr b/docs/manual/server-wide.html.ko.euc-kr index a536b72c62d..22d245203dd 100644 --- a/docs/manual/server-wide.html.ko.euc-kr +++ b/docs/manual/server-wide.html.ko.euc-kr @@ -19,6 +19,7 @@ Apache > HTTP Server > Documentation > Version 2.3

¼¹ö Àü¿ª ¼³Á¤

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

@@ -88,6 +89,7 @@

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

diff --git a/docs/manual/server-wide.html.tr.utf8 b/docs/manual/server-wide.html.tr.utf8 index 69f648ed805..60d7d68e1f0 100644 --- a/docs/manual/server-wide.html.tr.utf8 +++ b/docs/manual/server-wide.html.tr.utf8 @@ -19,6 +19,7 @@ Apache > HTTP Sunucusu > Belgeleme > SÃ¼rÃ¼m 2.3

Sunucu Genelinde YapÄ±landÄ±rma

Mevcut Diller: en | + fr | ja | ko | tr

@@ -90,6 +91,7 @@ iÅlemlerini yapÄ±landÄ±rmakta kullanÄ±lan yÃ¶nergelerden bazÄ±larÄ± aÃ§Ä±klanm

Mevcut Diller: en | + fr | ja | ko | tr

diff --git a/docs/manual/server-wide.xml.meta b/docs/manual/server-wide.xml.meta index b983f5a782c..5d4092f762b 100644 --- a/docs/manual/server-wide.xml.meta +++ b/docs/manual/server-wide.xml.meta @@ -8,6 +8,7 @@ en + fr ja ko tr diff --git a/docs/manual/suexec.html b/docs/manual/suexec.html index 9c833c98bf2..c4cc65bdbe2 100644 --- a/docs/manual/suexec.html +++ b/docs/manual/suexec.html @@ -4,6 +4,10 @@ URI: suexec.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 +URI: suexec.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 + URI: suexec.html.ja.utf8 Content-Language: ja Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/suexec.html.en b/docs/manual/suexec.html.en index a60d3a512a1..d59bc09927a 100644 --- a/docs/manual/suexec.html.en +++ b/docs/manual/suexec.html.en @@ -19,6 +19,7 @@ Apache > HTTP Server > Documentation > Version 2.3

suEXEC Support

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

@@ -608,6 +609,7 @@

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

diff --git a/docs/manual/suexec.html.fr b/docs/manual/suexec.html.fr new file mode 100644 index 00000000000..fc6cd951bbe --- /dev/null +++ b/docs/manual/suexec.html.fr @@ -0,0 +1,662 @@ + + + +Support suEXEC - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.3

Support suEXEC

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

+ +

La fonctionnalité suEXEC permet + l'exécution des programmes CGI et + SSI sous un utilisateur autre que celui sous + lequel s'exécute le serveur web qui appelle ces programmes. + Normalement, lorsqu'un programme CGI ou SSI est lancé, il + s'exécute sous le même utilisateur que celui du serveur web qui + l'appelle.

+ +

Utilisée de manière appropriée, cette fonctionnalité peut + réduire considérablement les risques de sécurité encourus + lorsqu'on autorise les utilisateurs à développer et faire + s'exécuter des programmes CGI ou SSI de leur cru. Cependant, mal + configuré, suEXEC peut causer de nombreux problèmes et même créer + de nouvelles failles dans la sécurité de votre ordinateur. Si + vous n'êtes pas familier avec la gestion des programmes + setuid root et les risques de sécurité qu'ils comportent, + nous vous recommandons vivement de ne pas tenter + d'utiliser suEXEC.

Avant de commencer
Modèle de sécurité de suEXEC
Configurer et installer suEXEC
Activation et désactivation +de suEXEC
Utilisation de suEXEC
Débogage de suEXEC
Avis à la population ! + Avertissements et exemples

Avant de commencer

+ +

Avant de foncer tête baissée dans la lecture de ce document, + vous devez tenir compte des hypothèses faites par le Groupe + Apache et dans ce document.

+ +

Premièrement, vous devez utiliser un système d'exploitation + UNIX ou dérivé, capable d'effectuer des opérations + setuid et setgid. Tous les + exemples de commande sont donnés en conséquence. D'autres + plates-formes, même si elles supportent suEXEC, peuvent + avoir une configuration différente.

+ +

Deuxièmement, vous devez être familier avec les concepts de base + relatifs à la sécurité de votre ordinateur et son administration. + Ceci implique la compréhension des opérations + setuid/setgid et des différents effets qu'elles + peuvent produire sur votre système et son niveau de sécurité.

+ +

Troisièmement, vous devez utiliser une version + non modifiée du code de suEXEC. L'ensemble du + code de suEXEC a été scruté et testé avec soin par les développeurs + et de nombreux bêta testeurs. Toutes les précautions ont été prises + pour s'assurer d'une base sûre de code non seulement simple, mais + aussi solide. La modification de ce code peut causer des problèmes + inattendus et de nouveaux risques de sécurité. Il est + vivement recommandé de ne pas modifier le code de + suEXEC, à moins que vous ne soyez un programmeur spécialiste des + particularités liées à la sécurité, et souhaitez partager votre + travail avec le Groupe Apache afin de pouvoir en discuter.

+ +

Quatrièmement et dernièrement, le Groupe Apache a décidé de ne + PAS inclure suEXEC dans l'installation par défaut + d'Apache. Pour pouvoir mettre en oeuvre suEXEC, l'administrateur + doit porter la plus grande attention aux détails. Après avoir bien + réfléchi aux différents points de la configuration de suEXEC, + l'administrateur peut l'installer selon les méthodes classiques. + Les valeurs des paramètres de configuration doivent être + déterminées et spécifiées avec soin par l'administrateur, afin de + maintenir la sécurité du système de manière appropriée lors de + l'utilisation de la fonctionnalité suEXEC. C'est par le biais de + ce processus minutieux que le Groupe Apache espère réserver + l'installation de suEXEC aux administrateurs prudents et + suffisamment déterminés à vouloir l'utiliser.

+ +

Vous êtes encore avec nous ? Oui ? Bien. + Alors nous pouvons continuer !

Modèle de sécurité de suEXEC

+ +

Avant d'installer et configurer suEXEC, nous allons tout d'abord + décrire le modèle de sécurité que vous êtes sur le point + d'implémenter. Vous devriez ainsi mieux comprendre ce qui se passe + vraiment à l'intérieur de suEXEC et quelles précautions ont été + prises pour préserver la sécurité de votre système.

+ +

suEXEC est basé sur un programme "conteneur" + (wrapper) setuid qui est appelé par le serveur web Apache principal. + Ce conteneur est appelé quand une requête HTTP concerne + un programme CGI ou SSI que l'administrateur + a décidé de faire s'exécuter + sous un utilisateur autre que celui du serveur principal. + Lorsqu'il reçoit une telle requête, Apache fournit au conteneur + suEXEC le nom du programme, ainsi que les identifiants utilisateur + et groupe sous lesquels le programme doit s'exécuter.

+ +

Le conteneur effectue ensuite les vérifications suivantes afin + de déterminer la réussite ou l'échec du processus -- si une seule + de ces conditions n'est pas vérifiée, le programme journalise + l'erreur et se termine en retournant un code d'erreur, sinon il + continue :

+ +

+ L'utilisateur qui exécute le conteneur est-il un + utilisateur valide de ce système ? + +
+ Ceci permet de s'assurer que l'utilisateur qui exécute le + conteneur est vraiment un utilisateur appartenant au système. +
+
+ Le conteneur a-t-il été appelé avec un nombre + d'arguments correct ? + +
+ Le conteneur ne s'exécutera que si on lui fournit un nombre + d'arguments correct. Le serveur web apache sait quel est le + bon format des arguments. Si le conteneur ne reçoit pas un + nombre d'arguments correct, soit il a été modifié, + soit quelque chose ne va pas dans la portion suEXEC de + votre binaire Apache. +
+
+ Cet utilisateur valide est-il autorisé à exécuter le + conteneur ? + +
+ Cet utilisateur est-il celui autorisé à exécuter le + conteneur ? Un seul utilisateur (celui d'Apache) est + autorisé à exécuter ce programme. +
+
+ Le chemin du programme CGI ou SSI cible est-il + non sûr ? + +
+ Le chemin du programme CGI ou SSI cible débute-t-il par un + '/' ou contient-il une référence arrière '..' ? Ceci est + interdit ; le programme CGI ou SSI cible doit se trouver dans + la hiérarchie de la racine des documents de suEXEC (voir + --with-suexec-docroot=DIR ci-dessous). +
+
+ Le nom utilisateur cible est-il valide ? + +
+ L'utilisateur cible existe-t-il ? +
+
+ Le nom du groupe cible est-il valide ? + +
+ Le groupe cible existe-t-il ? +
+
+ L'utilisateur cible n'est-il PAS + superutilisateur ? + + +
+ Actuellement, suEXEc ne permet pas à + root d'exécuter des programmes CGI/SSI. +
+
+ Le numéro de l'identifiant de l'utilisateur cible + est-il SUPERIEUR au numéro d'identifiant + minimum ? + +
+ Le numéro d'identifiant utilisateur minimum est défini à + l'exécution du script configure. Ceci vous permet de définir + le numéro d'identifiant utilisateur le plus bas qui sera + autorisé à éxécuter des programmes CGI/SSI. En particulier, + cela permet d'écarter les comptes système. +
+
+ Le groupe cible n'est-il PAS le groupe + superutilisateur ? + +
+ Actuellement, suEXEC ne permet pas au groupe + root d'exécuter des programmes CGI/SSI. +
+
+ Le numéro d'identifiant du groupe cible est-il + SUPERIEUR au numéro d'identifiant minimum ? + +
+ Le numéro d'identifiant de groupe minimum est spécifié lors + de l'exécution du script configure. Ceci vous permet de + définir l'identifiant de groupe le plus bas possible qui sera + autorisé à exécuter des programmes CGI/SSI, et est + particulièrement utile pour écarter les groupes "système". +
+
+ Le conteneur peut-il obtenir avec succès l'identité + des utilisateur et groupe cibles ? + +
+ C'est ici que le programme obtient l'identité des utilisateur + et groupe cibles via des appels à setuid et setgid. De même, + la liste des accès groupe est initialisée avec tous les + groupes auxquels l'utilisateur cible appartient. +
+
+ Peut-on se positionner dans le répertoire dans dequel + sont situés les programmes CGI/SSI ? + +
+ S'il n'existe pas, il ne peut pas contenir de fichier. Et si + l'on ne peut pas s'y positionner, il n'existe probablement + pas. +
+
+ Le répertoire est-il dans l'espace web + d'Apache ? + +
+ Si la requête concerne une portion de la racine du serveur, + le répertoire demandé est-il dans la hiérarchie de la racine + des documents de suEXEC ? Si la requête concerne un + UserDir, le répertoire demandé est-il dans + la hiérarchie du répertoire défini comme le répertoire + utilisateur de suEXEC (voir les + options de configuration de suEXEC) ? +
+
+ L'écriture dans le répertoire est-elle interdite pour + un utilisateur autre que le propriétaire + +
+ Le répertoire ne doit pas être ouvert aux autres + utilisateurs ; seul l'utilisateur propriétaire doit pouvoir + modifier le contenu du répertoire. +
+
+ Le programme CGI/SSI cible existe-t-il ? + +
+ S'il n'existe pas, il ne peut pas être exécuté. +
+
+ Les utilisateurs autres que le propriétaire n'ont-ils + PAS de droits en écriture sur le programme + CGI/SSI ? + +
+ Les utilisateurs autres que le propriétaire ne doivent pas + pouvoir modifier le programme CGI/SSI. +
+
+ Le programme CGI/SSI n'est-il PAS setuid ou + setgid ? + +
+ Les programmes cibles ne doivent pas pouvoir modifier à + nouveau les identifiants utilisateur/groupe. +
+
+ Le couple utilisateur/groupe cible est-il le même que + celui du programme ? + +
+ L'utilisateur est-il le propriétaire du fichier ? +
+
+ Peut-on nettoyer avec succès l'environnement des + processus afin de garantir la sûreté des opérations ? + +
+ suExec nettoie l'environnement des processus en établissant + un chemin d'exécution sûr (défini lors de la configuration), + et en ne passant que les variables dont les noms font partie + de la liste de l'environnement sûr (créée de même lors de la + configuration). +
+
+ Le conteneur peut-il avec succès se substituer au + programme CGI/SSI cible et s'exécuter ? + +
+ C'est là où l'exécution de suEXEC s'arrête et où commence + celle du programme CGI/ssi cible. +
+

+ +

Ce sont les opérations standards effectuées par le modèle de + sécurité du conteneur suEXEC. Il peut paraître strict et est + susceptible d'imposer de nouvelles limitations et orientations + dans la conception des programmes CGI/SSI, mais il a été développé + avec le plus grand soin, étape par étape, en se focalisant sur + la sécurité.

+ +

Pour plus d'informations sur la mesure dans laquelle ce modèle + de sécurité peut limiter vos possibilités au regard de la + configuration du serveur, ainsi que les risques de sécurité qui + peuvent être évités grâce à une configuration appropriée de suEXEC, + se référer à la section "Avis à la population !" de ce document.

Configurer et installer suEXEC

+ +

C'est ici que nous entrons dans le vif du sujet.

+ +

Options de configuration de suEXEC
+

+ +

--enable-suexec: Cette option active la fonctionnalité suEXEC qui n'est + jamais installée ou activée par défaut. Au moins une option + --with-suexec-xxxxx doit accompagner l'option + --enable-suexec pour qu'APACI (l'utilitaire de + configuration de la compilation d'Apache) accepte votre demande + d'utilisation de la fonctionnalité suEXEC.
--with-suexec-bin=PATH: Le chemin du binaire suexec doit être codé en + dur dans le serveur pour des raisons de sécurité. Cette option + vous permet de modifier le chemin par défaut. + Par exemple + --with-suexec-bin=/usr/sbin/suexec
--with-suexec-caller=UID: L'utilisateur sous + lequel Apache s'exécute habituellement. C'est le seul utilisateur + autorisé à utiliser suexec.
--with-suexec-userdir=DIR: Cette option définit le sous-répertoire de la hiérarchie des + répertoires utilisateurs dans lequel l'utilisation + de suEXEC sera autorisée. Tous les exécutables situés dans ce + répertoire seront exécutables par suEXEC sous l'utilisateur + cible ; ces programmes doivent donc être sûrs. Si vous utilisez + une directive UserDir + "simple" (c'est à dire ne contenant pas de + "*"), l'option --with-suexec-userdir + devra contenir la même valeur. SuEXEC ne fonctionnera pas + correctement si la directive UserDir contient une valeur + différente du répertoire home de l'utilisateur tel qu'il est + défini dans le fichier passwd. la valeur par défaut + est "public_html".
+ Si vous avez plusieurs hôtes virtuels avec une directive + UserDir différente + pour chacun d'entre eux, vous devrez faire en sorte que chaque + UserDir possède un répertoire parent commun ; donnez alors à + l'option --with-suexec-userdir le nom + de ce répertoire commun. Si tout ceci n'est pas défini + correctement, les requêtes CGI "~userdir" ne fonctionneront + pas !
--with-suexec-docroot=DIR: Cette option fonctionne comme la directive DocumentRoot pour + Apache. Il s'agit de la seule hiérarchie (en dehors des directives + UserDir) dans laquelle la fonctionnalité suEXEC + pourra être utilisée. La valeur par défaut est la valeur de + --datadir accompagnée du suffixe + "/htdocs" ; + Par exemple, si vous exécutez configure avec + "--datadir=/home/apache", la valeur + "/home/apache/htdocs" sera utilisée par défaut comme + racine des documents pour le conteneur suEXEC.
--with-suexec-uidmin=UID: Cette option définit l'identifiant utilisateur le plus bas + avec lequel un utilisateur pourra être la cible de + suEXEC. 500 ou 100 sont des valeurs courantes sur la plupart des + systèmes. la valeur par défaut est 100.
--with-suexec-gidmin=GID: Cette option définit l'identifiant de groupe le plus bas + avec lequel un utilisateur pourra être la cible de + suEXEC. 100 est une valeur courante sur la plupart des + systèmes et est par conséquent la valeur par défaut.
--with-suexec-logfile=FILE: Cette option permet de définir le fichier dans lequel + toutes les transactions et erreurs de suEXEC seront journalisées + (à des fins d'analyse ou de débogage). Par défaut, le fichier + journal se nomme "suexec_log" et se trouve dans votre + répertoire standard des fichiers journaux défini par + --logfiledir
--with-suexec-safepath=PATH: Cette option permet de définir une variable d'environnement + PATH sûre à passer aux exécutables CGI. La valeur par défaut + est "/usr/local/bin:/usr/bin:/bin".

+ +

Compilation et installation du conteneur suEXEC

+ + +

Si vous avez activé la fonctionnalité suEXEC à l'aide de + l'option --enable-suexec, le binaire + suexec sera automatiquement construit (en même temps + qu'Apache) lorsque vous exécuterez la commande + make.

+ +

Lorsque tous les composants auront été construits, vous pourrez + exécuter la commande make install afin de les + installer. Le binaire suexec sera installé dans le + répertoire défini à l'aide de l'option --sbindir. La + localisation par défaut est "/usr/local/apache2/bin/suexec".

Veuillez noter que vous aurez besoin des + privilèges root pour passer l'étape de + l'installation. Pour que le conteneur puisse changer + l'identifiant utilisateur, il doit avoir comme propriétaire + root, et les droits du fichier doivent + inclure le bit d'exécution setuserid.

+ + +

>Mise en place de permissions pour + paranoïaque

+ +

Bien que le conteneur suEXEC vérifie que l'utilisateur qui + l'appelle correspond bien à l'utilisateur spécifié à l'aide de + l'option --with-suexec-caller du programme + configure, il subsiste toujours le risque qu'un + appel système ou une bibliothèque fasse appel à suEXEC avant que + cette vérification ne soit exploitable sur votre système. Pour + tenir compte de ceci, et parce que c'est en général la meilleure + pratique, vous devez utiliser les permissions du système de + fichiers afin de vous assurer que seul le groupe sous lequel + s'exécute Apache puisse faire appel à suEXEC.

+ +

Si, par exemple, votre serveur web est configuré pour + s'exécuter en tant que :

+ +

+ User www + Group webgroup +

+ +

et suexec se trouve à + "/usr/local/apache2/bin/suexec", vous devez exécuter les + commandes

+ +

+ chgrp webgroup /usr/local/apache2/bin/suexec + chmod 4750 /usr/local/apache2/bin/suexec +

+ +

Ceci permet de s'assurer que seul le groupe sous lequel Apache + s'exécute (ici webgroup) puisse faire appel au conteneur + suEXEC.

+ +

Activation et désactivation +de suEXEC

+ +

Au démarrage, Apache vérifie la présence du fichier + suexec dans le répertoire défini par + l'option --sbindir du script configure (le + répertoire par défaut est "/usr/local/apache/sbin/suexec"). Si + Apache trouve un conteneur suEXEC correctement configuré, il + enregistrera le message suivant dans le journal des erreurs :

+ +

+ [notice] suEXEC mechanism enabled (wrapper: /path/to/suexec) +

+ +

Si ce message n'est pas généré au démarrage du serveur, ce + dernier ne trouve probablement pas le programme conteneur à + l'endroit où il est sensé être, ou l'exécutable suexec n'est pas + installé en setuid root.

+ +

Si le serveur Apache est déjà en cours d'exécution, et si + vous activez le mécanisme suEXEC pour la première fois, vous + devez arrêter et redémarrer Apache. Un redémarrage + à l'aide d'un simple signal HUP ou USR1 suffira.

Pour désactiver suEXEC, vous devez supprimer le fichier + suexec, puis arrêter et redémarrer + Apache.

Utilisation de suEXEC

+ +

Les requêtes pour des programmes CGI ne feront appel au + conteneur suEXEC que si elles concernent un hôte virtuel + contenant une directive SuexecUserGroup, ou si elles sont + traitées par mod_userdir.

+ +

Hôtes virtuels :
Une des méthodes + d'utilisation du conteneur suEXEC consiste à insérer une + directive SuexecUserGroup dans une section + VirtualHost. En définissant + des valeurs différentes de celles du serveur principal, toutes les + requêtes pour des ressources CGI seront exécutées sous + les User et Group définis pour cette section + <VirtualHost>. Si cette + directive est absente de la section <VirtualHost>, l'utilisateur du + serveur principal sera pris par défaut

+ +

Répertoires des utilisateurs :
Avec + cette méthode, les + requêtes traitées par mod_userdir appelleront le + conteneur suEXEC pour exécuter le programme CGI sous l'identifiant + utilisateur du répertoire utilisateur concerné. Seuls prérequis + pour pouvoir accéder à cette fonctionnalité : l'exécution des CGI + doit être activée pour l'utilisateur concerné, et le script doit + passer avec succès le test des vérifications de + sécurité décrit plus haut. Voir aussi l' + option de compilation + --with-suexec-userdir.

Débogage de suEXEC

+ +

Le conteneur suEXEC va écrire ses informations de journalisation + dans le fichier défini par l'option de compilation + --with-suexec-logfile comme indiqué plus haut. Si vous + pensez avoir configuré et installé correctement le conteneur, + consultez ce journal, ainsi que le journal des erreurs du serveur + afin de déterminer l'endroit où vous avez fait fausse route.

+ +

Avis à la population ! + Avertissements et exemples

+ +

NOTE ! Cette section est peut-être incomplète. + Pour en consulter la dernière révision, voir la version de la Documentation en ligne du Groupe Apache.

+ +

Quelques points importants du conteneur peuvent + imposer des contraintes du point de vue de la configuration du + serveur. Veuillez en prendre connaissance avant de soumettre un + rapport de bogue à propos de suEXEC.

+ +

Points importants de suEXEC
+ Limitations concernant la hiérarchie. + +
+ Pour des raisons de sécurité et d'efficacité, toutes les + requêtes suEXEC ne doivent concerner que des ressources + situées dans la racine des documents définie pour les + requêtes concernant un hôte virtuel, ou des ressources + situées dans la racine des documents définies pour les + requêtes concernant un répertoire utilisateur. Par exemple, + si vous avez configuré quatre hôtes virtuels, vous devrez + définir la structure des racines de documents de vos hôtes + virtuels en dehors d'une hiérarchie de documents principale + d'Apache, afin de tirer parti de suEXEC dans le contexte des + hôtes virtuels (Exemple à venir). +
+
+ La variable d'environnement PATH de suEXEC + +
+ Modifier cette variable peut s'avérer dangereux. Assurez-vous + que tout chemin que vous ajoutez à cette variable est un + répertoire de confiance. Vous n'avez + probablement pas l'intention d'ouvrir votre serveur de façon + à ce que l'on puisse y exécuter un cheval de Troie. +
+
+ Modification de suEXEC + +
+ Encore une fois, ceci peut vous causer de + graves ennuis si vous vous y essayez sans + savoir ce que vous faites. Evitez de vous y risquer dans la + mesure du possible. +
+

+ +

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

+ \ No newline at end of file diff --git a/docs/manual/suexec.html.ja.utf8 b/docs/manual/suexec.html.ja.utf8 index 1d77952c365..8b8e7b5b46d 100644 --- a/docs/manual/suexec.html.ja.utf8 +++ b/docs/manual/suexec.html.ja.utf8 @@ -20,6 +20,7 @@ 2.3

suEXEC ãµãã¼ã

è¨èª: en | + fr | ja | ko | tr

@@ -605,6 +606,7 @@

è¨èª: en | + fr | ja | ko | tr

diff --git a/docs/manual/suexec.html.ko.euc-kr b/docs/manual/suexec.html.ko.euc-kr index 6bda88a8946..7bd357d016d 100644 --- a/docs/manual/suexec.html.ko.euc-kr +++ b/docs/manual/suexec.html.ko.euc-kr @@ -19,6 +19,7 @@ Apache > HTTP Server > Documentation > Version 2.3

suEXEC Áö¿ø

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

@@ -527,6 +528,7 @@

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

diff --git a/docs/manual/suexec.html.tr.utf8 b/docs/manual/suexec.html.tr.utf8 index 0b1775fa376..5c1aabbb883 100644 --- a/docs/manual/suexec.html.tr.utf8 +++ b/docs/manual/suexec.html.tr.utf8 @@ -19,6 +19,7 @@ Apache > HTTP Sunucusu > Belgeleme > SÃ¼rÃ¼m 2.3

SuEXEC DesteÄi

Mevcut Diller: en | + fr | ja | ko | tr

@@ -547,6 +548,7 @@

Mevcut Diller: en | + fr | ja | ko | tr

diff --git a/docs/manual/suexec.xml.meta b/docs/manual/suexec.xml.meta index bd36bfcacc5..93d068f2a94 100644 --- a/docs/manual/suexec.xml.meta +++ b/docs/manual/suexec.xml.meta @@ -8,6 +8,7 @@ en + fr ja ko tr diff --git a/docs/manual/upgrading.html b/docs/manual/upgrading.html index e3bfb3141fc..b7c1cb61b54 100644 --- a/docs/manual/upgrading.html +++ b/docs/manual/upgrading.html @@ -3,3 +3,7 @@ URI: upgrading.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 + +URI: upgrading.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 diff --git a/docs/manual/upgrading.html.en b/docs/manual/upgrading.html.en index 69faad12c2a..1d3506c9644 100644 --- a/docs/manual/upgrading.html.en +++ b/docs/manual/upgrading.html.en @@ -18,7 +18,8 @@

Apache > HTTP Server > Documentation > Version 2.3

Upgrading to 2.4 from 2.2

Available Languages: en

Available Languages: en | + fr

In order to assist folks upgrading, we maintain a document @@ -62,7 +63,8 @@

Available Languages: en

Available Languages: en | + fr

diff --git a/docs/manual/upgrading.html.fr b/docs/manual/upgrading.html.fr new file mode 100644 index 00000000000..69afaf140cd --- /dev/null +++ b/docs/manual/upgrading.html.fr @@ -0,0 +1,76 @@ + + + +Mise à jour vers 2.4 depuis 2.2 - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.3

Mise à jour vers 2.4 depuis 2.2

Langues Disponibles: en | + fr

+ +

Afin d'assister les utilisateurs lors de leurs opérations de mise à + jour, nous maintenons un document + qui comporte des informations critiques à l'attention des personnes qui + utilisent déjà Apache. Ces informations ne sont que de brèves notes, et vous + devriez trouver plus d'informations dans le document Nouvelles fonctionnalités, ou dans + le fichier src/CHANGES.

+ +

Ce document ne décrit que les modifications intervenues entre les versions + 2.2 et 2.4. Si vous effectuez une mise à jour depuis la version 2.0, vous + devez aussi consulter le + document de mise + à jour de 2.0 vers 2.2.

+ +

Modifications de la configuration au moment de la compilation
Modifications de la configuration à l'exécution
Changements divers
Modules tiers

Voir aussi

Vue d'ensemble des nouvelles +fonctionnalités de Apache 2.4

Modifications de la configuration au moment de la compilation

+ + + +

Modifications de la configuration à l'exécution

+ + + +

Changements divers

+ + +

Modules tiers

+ + + + +

Langues Disponibles: en | + fr

+ \ No newline at end of file diff --git a/docs/manual/upgrading.xml.meta b/docs/manual/upgrading.xml.meta index c29c957dab9..047fb80e5ad 100644 --- a/docs/manual/upgrading.xml.meta +++ b/docs/manual/upgrading.xml.meta @@ -8,5 +8,6 @@ en + fr diff --git a/docs/manual/urlmapping.html b/docs/manual/urlmapping.html index d5b6507f0e7..e42d122cc87 100644 --- a/docs/manual/urlmapping.html +++ b/docs/manual/urlmapping.html @@ -4,6 +4,10 @@ URI: urlmapping.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 +URI: urlmapping.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 + URI: urlmapping.html.ja.utf8 Content-Language: ja Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/urlmapping.html.en b/docs/manual/urlmapping.html.en index 470478c61ff..3a64d95a146 100644 --- a/docs/manual/urlmapping.html.en +++ b/docs/manual/urlmapping.html.en @@ -19,6 +19,7 @@ Apache > HTTP Server > Documentation > Version 2.3

Mapping URLs to Filesystem Locations

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

@@ -289,6 +290,7 @@ is available to rewrite links in HTML and XHTML.

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

diff --git a/docs/manual/urlmapping.html.fr b/docs/manual/urlmapping.html.fr new file mode 100644 index 00000000000..d3d4ad27c42 --- /dev/null +++ b/docs/manual/urlmapping.html.fr @@ -0,0 +1,313 @@ + + + + Mise en correspondance des URLs avec le système de fichiers - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.3

Mise en correspondance des URLs avec le système de fichiers

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

+ +

Ce document explique comment Apache utilise l'URL contenue dans une + requête pour déterminer le noeud du système de fichier à partir duquel le + fichier devra être servi.

Modules et directives concernés
Racine des documents (DocumentRoot)
Fichiers situés en dehors de +l'arborescence DocumentRoot
Répertoires des utilisateurs
Redirection d'URL
Mandataire inverse (Reverse Proxy)
Moteur de réécriture
Fichier non trouvé (File Not Found)

Modules et directives concernés

+ +

Modules Apparentés	Directives Apparentées
`mod_alias` `mod_proxy` `mod_rewrite` `mod_userdir` `mod_speling` `mod_vhost_alias`	`Alias` `AliasMatch` `CheckSpelling` `DocumentRoot` `ErrorDocument` `Options` `ProxyPass` `ProxyPassReverse` `ProxyPassReverseCookieDomain` `ProxyPassReverseCookiePath` `Redirect` `RedirectMatch` `RewriteCond` `RewriteMatch` `ScriptAlias` `ScriptAliasMatch` `UserDir`

Racine des documents (DocumentRoot)

+ +

La méthode par défaut d'Apache pour déterminer quel fichier servir pour + une requête donnée, consiste à extraire le chemin du fichier de la requête + (la partie de l'URL qui suit le nom d'hôte et le port), puis de l'ajouter + à la fin de la valeur de la directive + DocumentRoot définie dans vos fichiers + de configuration. + Ainsi, les fichiers et répertoires + situés en dessous de DocumentRoot + constituent l'arborescence de base des documents qui seront visibles + depuis le web.

+ +

Par exemple, si la directive + DocumentRoot contient + /var/www/html, une requête pour + http://www.example.com/fish/guppies.html retournera le + fichier /var/www/html/fish/guppies.html au client.

+ +

Apache supporte aussi les Hôtes virtuels, + ce qui lui permet de traiter des requêtes pour plusieurs hôtes. + Dans ce cas, un DocumentRoot + différent peut être défini pour chaque hôte virtuel; + les directives fournies par le module + mod_vhost_alias peuvent aussi être utilisées afin de + déterminer dynamiquement le noeud approprié du système de fichiers + à partir duquel servir un contenu en fonction de l'adresse IP + ou du nom d'hôte.

+ +

La directive DocumentRoot est + définie dans le fichier de configuration de votre serveur principal + (httpd.conf), mais peut aussi être redéfinie pour chaque + Hôte virtuel supplémentaire que vous avez créé.

Fichiers situés en dehors de +l'arborescence DocumentRoot

+ +

Il existe de nombreuses circonstances pour lesquelles il est nécessaire + d'autoriser l'accès web à des portions du système de fichiers qui ne se + trouvent pas dans l'arborescence DocumentRoot. Apache propose de nombreuses + solutions pour réaliser cela. Sur les systèmes Unix, les liens + symboliques permettent de rattacher d'autres portions du système de + fichiers au DocumentRoot. Pour des raisons de sécurité, + Apache ne suivra les liens symboliques que si les Options pour le répertoire concerné contiennent + FollowSymLinks ou SymLinksIfOwnerMatch.

+ +

Une autre méthode consiste à utiliser la directive Alias pour rattacher toute portion + du système de fichiers à l'arborescence du site web. Par exemple, avec

+ +

Alias /docs /var/web

+ +

l'URL http://www.example.com/docs/dir/file.html + correspondra au fichier /var/web/dir/file.html. La + directive + ScriptAlias + fonctionne de la même manière, excepté que tout contenu localisé dans le + chemin cible sera traité comme un script CGI.

+ +

Pour les situations qui nécessitent plus de flexibilité, vous disposez + des directives AliasMatch + et ScriptAliasMatch + qui permettent des substitutions et comparaisons puissantes basées + sur les expressions rationnelles. + Par exemple,

+ +

ScriptAliasMatch ^/~([a-zA-Z0-9]+)/cgi-bin/(.+) + /home/$1/cgi-bin/$2

+ +

fera correspondre une requête du style + http://example.com/~user/cgi-bin/script.cgi au chemin + /home/user/cgi-bin/script.cgi, et traitera le fichier résultant + comme un script CGI.

Répertoires des utilisateurs

+ +

Sur les systèmes Unix, on peut traditionnellement faire référence + au répertoire personnel d'un utilisateur particulier à l'aide de + l'expression ~user/. + Le module mod_userdir + étend cette idée au web en autorisant l'accès aux fichiers situés dans les + répertoires home des utilisateurs à l'aide d'URLs + comme dans ce qui suit :

+ +

http://www.example.com/~user/file.html

+ +

Pour des raisons de sécurité, il est déconseillé de permettre un accès + direct à un répertoire home d'utilisateur depuis le web. A cet effet, la + directive UserDir + spécifie un répertoire où sont situés les fichiers accessibles depuis le web + dans le répertoire home de l'utilisateur. + Avec la configuration par défaut + Userdir public_html, l'URL ci-dessus correspondra à un fichier + dont le chemin sera du style + /home/user/public_html/file.html où + /home/user/ est le répertoire home de l'utilisateur tel qu'il + est défini dans /etc/passwd.

+ +

La directive Userdir met à votre disposition de nombreuses + formes différentes pour les systèmes où /etc/passwd ne + spécifie pas la localisation du répertoire home.

+ +

Certains jugent le symbole "~" (dont le code sur le web est souvent + %7e) inapproprié et préfèrent utiliser une chaîne de + caractères différente pour représenter les répertoires utilisateurs. + mod_userdir ne supporte pas cette fonctionnalité. Cependant, si les + répertoires home des utilisateurs sont structurés de manière rationnelle, + il est possible d'utiliser la directive + AliasMatch + pour obtenir l'effet désiré. Par exemple, pour faire correspondre + http://www.example.com/upages/user/file.html à + /home/user/public_html/file.html, utilisez la directive + AliasMatch suivante :

+ +

AliasMatch ^/upages/([a-zA-Z0-9]+)/?(.*) + /home/$1/public_html/$2

Redirection d'URL

+ +

Les directives de configuration décrites dans les sections précédentes + demandent à Apache d'extraire un contenu depuis un emplacement spécifique + du système de fichiers + et de la retourner au client. Il est cependant parfois + souhaitable d'informer le + client que le contenu demandé est localisé à une URL différente, et de + demander au client d'élaborer une nouvelle requête avec la nouvelle URL. + Ce processus se nomme redirection et est implémenté par la + directive Redirect. + Par exemple, si le contenu du répertoire /foo/ sous + DocumentRoot est déplacé vers le + nouveau répertoire /bar/, vous pouvez demander aux clients + de le requérir à sa nouvelle localisation comme suit :

+ +

Redirect permanent /foo/ http://www.example.com/bar/

+ +

Ceci aura pour effet de rediriger tout chemin d'URL commençant par + /foo/ vers le même chemin d'URL sur le serveur + www.example.com en remplaçant /foo/ par + /bar/. Vous pouvez rediriger les clients non seulement sur le + serveur d'origine, mais aussi vers n'importe quel autre serveur.

+ +

Apache propose aussi la directive RedirectMatch pour traiter les problèmes + de réécriture d'une plus grande complexité. Par exemple, afin de rediriger + les requêtes pour la page d'accueil du site vers un site différent, mais + laisser toutes les autres requêtes inchangées, utilisez la + configuration suivante :

+ +

RedirectMatch permanent ^/$ + http://www.example.com/startpage.html

+ +

De même, pour rediriger temporairement toutes les pages d'un site + vers une page particulière d'un autre site, utilisez ce qui suit :

+ +

RedirectMatch temp .* + http://othersite.example.com/startpage.html

Mandataire inverse (Reverse Proxy)

+ +

Apache vous permet aussi de rapatrier des documents distants +dans l'espace des URL du serveur local. +Cette technique est appelée mandataire inverse ou reverse +proxying car le serveur web agit comme un serveur mandataire en +rapatriant les documents depuis un serveur distant puis les renvoyant +au client. Ceci diffère d'un service de proxy usuel car, pour le client, +les documents semblent appartenir au serveur mandataire inverse.

+ +

Dans l'exemple suivant, quand les clients demandent des documents situés +dans le répertoire +/foo/, le serveur rapatrie ces documents depuis le répertoire +/bar/ sur internal.example.com +et les renvoie au client comme s'ils appartenaient au serveur local.

+ +

+ProxyPass /foo/ http://internal.example.com/bar/ +ProxyPassReverse /foo/ http://internal.example.com/bar/ +ProxyPassReverseCookieDomain internal.example.com public.example.com +ProxyPassReverseCookiePath /foo/ /bar/ +

+ +

La directive ProxyPass configure +le serveur pour rapatrier les documents appropriés, alors que la directive +ProxyPassReverse +réécrit les redirections provenant de +internal.example.com de telle manière qu'elles ciblent le +répertoire approprié sur le serveur local. De manière similaire, les directives +ProxyPassReverseCookieDomain +et ProxyPassReverseCookiePath +réécrivent les cookies élaborés par le serveur d'arrière-plan.

Il est important de noter cependant, que les liens situés dans les documents +ne seront pas réécrits. Ainsi, tout lien absolu sur +internal.example.com fera décrocher le client +du serveur mandataire et effectuer sa requête directement sur +internal.example.com. Un module tiers +mod_proxy_html +permet de réécrire les liens dans les documents HTML et XHTML.

Moteur de réécriture

+ +

Le moteur de réécriture mod_rewrite peut s'avérer + utile lorsqu'une substitution plus puissante est nécessaire. + Les directives fournies par ce module utilisent des caractéristiques de la + requête comme le type de navigateur ou l'adresse IP source afin de décider + depuis où servir le contenu. En outre, mod_rewrite peut utiliser des + fichiers ou programmes de bases de données externes pour déterminer comment + traiter une requête. Le moteur de réécriture peut effectuer les trois types + de mise en correspondance discutés plus haut : + redirections internes (aliases), redirections externes, et services mandataires. + De nombreux exemples pratiques utilisant mod_rewrite sont discutés dans le + Guide de réécriture des URLs.

Fichier non trouvé (File Not Found)

+ +

Inévitablement, apparaîtront des URLs qui ne correspondront à aucun + fichier du système de fichiers. + Ceci peut arriver pour de nombreuses raisons. + Il peut s'agir du déplacement de documents d'une + localisation vers une autre. Dans ce cas, le mieux est d'utiliser la + redirection d'URL pour informer les clients de la + nouvelle localisation de la ressource. De cette façon, vous êtes sur que + les anciens signets et liens continueront de fonctionner, même si la + ressource est déplacée.

+ +

Une autre cause fréquente d'erreurs "File Not Found" est l'erreur de + frappe accidentelle dans les URLs, soit directement dans le navigateur, + soit dans les liens HTML. Apache propose le module + mod_speling (sic) pour tenter de résoudre ce problème. + Lorsque ce module est activé, il intercepte les erreurs + "File Not Found" et recherche une ressource possédant un nom de fichier + similaire. Si un tel fichier est trouvé, mod_speling va envoyer une + redirection HTTP au client pour lui communiquer l'URL correcte. + Si plusieurs fichiers proches sont trouvés, une liste des alternatives + possibles sera présentée au client.

+ +

mod_speling possède une fonctionnalité particulièrement utile : + il compare les noms de fichiers sans tenir compte de la casse. + Ceci peut aider les systèmes où les utilisateurs ne connaissent pas la + sensibilité des URLs à la casse et bien sûr les systèmes de fichiers unix. + Mais l'utilisation de mod_speling pour toute autre chose que la correction + occasionnelle d'URLs peut augmenter la charge du serveur, car chaque + requête "incorrecte" entraîne une redirection d'URL et une nouvelle requête + de la part du client.

+ +

Si toutes les tentatives pour localiser le contenu échouent, Apache + retourne une page d'erreur avec le code de statut HTTP 404 + (file not found). L'apparence de cette page est contrôlée à l'aide de la + directive ErrorDocument + et peut être personnalisée de manière très flexible comme discuté dans le + document + Réponses personnalisées aux erreurs.

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

+ \ No newline at end of file diff --git a/docs/manual/urlmapping.html.ja.utf8 b/docs/manual/urlmapping.html.ja.utf8 index 7409624df9a..32bebf2e58f 100644 --- a/docs/manual/urlmapping.html.ja.utf8 +++ b/docs/manual/urlmapping.html.ja.utf8 @@ -20,6 +20,7 @@ 2.3

URL ãããã¡ã¤ã«ã·ã¹ãã ä¸ã®ä½ç½®ã¸ã®ããã

è¨èª: en | + fr | ja | ko | tr

@@ -280,6 +281,7 @@ ProxyPassReverseCookiePath /foo/ /bar/

è¨èª: en | + fr | ja | ko | tr

diff --git a/docs/manual/urlmapping.html.ko.euc-kr b/docs/manual/urlmapping.html.ko.euc-kr index 61101b4d0c5..bef4ec12aca 100644 --- a/docs/manual/urlmapping.html.ko.euc-kr +++ b/docs/manual/urlmapping.html.ko.euc-kr @@ -19,6 +19,7 @@ Apache > HTTP Server > Documentation > Version 2.3

URLÀ» ÆÄÀÏ½Ã½ºÅÛ À§Ä¡·Î ´ëÀÀÇÏ±â

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

@@ -240,6 +241,7 @@ ProxyPassReverse /foo/ http://internal.example.com/bar/

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

diff --git a/docs/manual/urlmapping.html.tr.utf8 b/docs/manual/urlmapping.html.tr.utf8 index 7ac488f0197..0304ff70c89 100644 --- a/docs/manual/urlmapping.html.tr.utf8 +++ b/docs/manual/urlmapping.html.tr.utf8 @@ -19,6 +19,7 @@ Apache > HTTP Sunucusu > Belgeleme > SÃ¼rÃ¼m 2.3

URLâlerin Dosya Sistemi ile EÅleÅtirilmesi

Mevcut Diller: en | + fr | ja | ko | tr

@@ -275,6 +276,7 @@

Mevcut Diller: en | + fr | ja | ko | tr

diff --git a/docs/manual/urlmapping.xml.meta b/docs/manual/urlmapping.xml.meta index c2cdad8c33f..88f0e34da4f 100644 --- a/docs/manual/urlmapping.xml.meta +++ b/docs/manual/urlmapping.xml.meta @@ -8,6 +8,7 @@ en + fr ja ko tr

Caching Guide

Guide de la mise en cache

Amélioration du taux de présence dans le cache

Périodes d'expiration

Guide succinct des requêtes conditionnelles

Que peut-on mettre en cache ?

Qu'est ce qui ne doit pas être mis en cache ?

Contenu variable et/ou négocié

Autorisation et contrôle d'accès

Piratages locaux

Empoisonnement du cache (Cache Poisoning)

Directive CacheFile

Directive CacheEnable

Mise en cache par l'intermédiaire du système d'exploitation

Mise en cache à l'aide de la directive MMapStatic

Mise en cache à l'aide du module mod_mem_cache

Comprendre le stockage dans le cache

Maintenance du cache sur disque

Ãnbellek KullanÄ±m KÄ±lavuzu

Fichiers de configuration

Dynamic Shared Object (DSO) Support

Support des objets dynamiques partagés (DSO)

åçå ±æãªãã¸ã§ã¯ã (DSO) ãµãã¼ã

µ¿Àû°øÀ¯°´Ã¼ (DSO) Áö¿ø

Devingen PaylaÅÄ±mlÄ± Nesne DesteÄi

Glossaire

Log Files

Fichiers journaux

Enregistrement du nombre réel d'octets envoyés et reçus

Journalisation de style investigation judiciaire (forensic logging)

ã­ã°ãã¡ã¤ã«

·Î±×ÆÄÀÏ

GÃ¼nlÃ¼k DosyalarÄ±

ãã£ã¬ã¯ãã£ã

Example

æ­£è¦è¡¨ç¾å ã§ã® / ã®ã¨ã¹ã±ã¼ã

Overview of new features in Apache 2.4

Vue d'ensemble des nouvelles fonctionnalités d'Apache 2.4

Configuration Sections

Sections de configuration

Note technique

ã»ã¯ã·ã§ã³ã®è¨­å®

¼½¼Ç ¼³Á¤

YapÄ±landÄ±rma BÃ¶lÃ¼mleri

Server-Wide Configuration

Configuration à l'échelle du serveur

ãµã¼ãå ¨ä½ã®è¨­å®

¼­¹ö Àü¿ª ¼³Á¤

Sunucu Genelinde YapÄ±landÄ±rma

suEXEC Support

Support suEXEC

Compilation et installation du conteneur suEXEC

>Mise en place de permissions pour + paranoïaque

suEXEC ãµãã¼ã

suEXEC Áö¿ø

SuEXEC DesteÄi

Upgrading to 2.4 from 2.2

Mise à jour vers 2.4 depuis 2.2

Voir aussi

Mapping URLs to Filesystem Locations

Mise en correspondance des URLs avec le système de fichiers

URL ãããã¡ã¤ã«ã·ã¹ãã ä¸ã®ä½ç½®ã¸ã®ããã

URLÀ» ÆÄÀÏ½Ã½ºÅÛ À§Ä¡·Î ´ëÀÀÇÏ±â

URLâlerin Dosya Sistemi ile EÅleÅtirilmesi

Ãnbellek KullanÄ±m KÄ±lavuzu

åçå±æãªãã¸ã§ã¯ã (DSO) ãµãã¼ã

Devingen PaylaÅÄ±mlÄ± Nesne DesteÄi

ãã°ãã¡ã¤ã«

ãã£ã¬ã¯ãã£ã

æ£è¦è¡¨ç¾åã§ã® / ã®ã¨ã¹ã±ã¼ã

ã»ã¯ã·ã§ã³ã®è¨å®

ãµã¼ãå¨ä½ã®è¨å®

¼¹ö Àü¿ª ¼³Á¤

suEXEC ãµãã¼ã

SuEXEC DesteÄi

URL ãããã¡ã¤ã«ã·ã¹ãã ä¸ã®ä½ç½®ã¸ã®ããã

URLâlerin Dosya Sistemi ile EÅleÅtirilmesi