--- /dev/null
+<?xml version="1.0" encoding="ISO-8859-1" ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+<!-- English Revision : 587444 -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<manualpage metafile="dso.xml.meta">
+
+ <title>Support des objets dynamiques partagés (DSO)</title>
+
+ <summary>
+ <p>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 <program>httpd</program> lors de la
+ compilation du serveur, soit compilés en tant qu'objets
+ dynamiques partagés (DSOs) qui existeront indépendamment du binaire
+ principal <program>httpd</program>. 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 (<program>apxs</program>),
+ et associés au serveur ultérieurement.</p>
+
+ <p>Ce document décrit l'utilisation des modules DSO ainsi que les dessous
+ de leur fonctionnement.</p>
+ </summary>
+
+
+<section id="implementation"><title>Implémentation</title>
+
+<related>
+<modulelist>
+<module>mod_so</module>
+</modulelist>
+<directivelist>
+<directive module="mod_so">LoadModule</directive>
+</directivelist>
+</related>
+
+ <p>Le support DSO pour le chargement de modules individuels d'Apache est
+ assuré par un module nommé <module>mod_so</module> qui doit être compilé
+ statiquement dans le coeur d'Apache. Il s'agit du seul module avec le
+ module <module>core</module> à 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
+ <code>--enable-<em>module</em>=shared</code> du script
+ <program>configure</program>, comme décrit dans la
+ <a href="install.html">Documentation de l'installation</a>. 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
+ <directive module="mod_so">LoadModule</directive> du module
+ <module>mod_so</module>, placée
+ dans votre fichier <code>httpd.conf</code>.</p>
+
+ <p>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é
+ <program>apxs</program> (<dfn>APache
+ eXtenSion</dfn>). On peut l'utiliser pour construire des modules de type
+ DSO <em>en dehors</em> de l'arborescence des sources d'Apache. L'idée est
+ simple : à l'installation d'Apache, la procédure <code>make install</code>
+ du script <program>configure</program> 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
+ <program>apxs</program>, qui sera utilisé pour la construction de fichiers DSO.
+ Il est ainsi possible d'utiliser le programme <program>apxs</program>
+ 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.</p>
+</section>
+
+<section id="usage"><title>Mode d'emploi succinct</title>
+
+ <p>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 :</p>
+
+ <ol>
+ <li>
+ Construire et installer un module Apache <em>faisant partie de la
+ distribution</em>, par exemple <code>mod_foo.c</code>,
+ en tant que module DSO <code>mod_foo.so</code> :
+
+<example>
+$ ./configure --prefix=/chemin/vers/répertoire-installation
+--enable-foo=shared<br />
+$ make install
+</example>
+ </li>
+
+ <li>
+ Construire et installer un module Apache <em>tiers</em>, par exemple
+ <code>mod_foo.c</code>, en tant que module DSO <code>mod_foo.so</code> :
+
+<example>
+$ ./configure --add-module=<var>type_de_module</var>:
+/chemin/vers/module_tiers/mod_foo.c \<br />
+<indent>
+ --enable-foo=shared<br />
+</indent>
+$ make install
+</example>
+ </li>
+
+ <li>
+ Configurer Apache pour <em>pouvoir installer ultérieurement</em> des
+ modules partagés :
+
+<example>
+$ ./configure --enable-so<br />
+$ make install
+</example>
+ </li>
+
+ <li>
+ Construire et installer un module Apache <em>tiers</em>, par exemple
+ <code>mod_foo.c</code>, en tant que module DSO
+ <code>mod_foo.so</code> <em>en dehors</em> de l'arborescence des sources
+ d'Apache à l'aide du programme <program>apxs</program> :
+
+<example>
+$ cd /chemin/vers/module_tiers<br />
+$ apxs -c mod_foo.c<br />
+$ apxs -i -a -n foo mod_foo.la
+</example>
+ </li>
+ </ol>
+
+ <p>Dans tous les cas, une fois le module partagé compilé, vous devez
+ ajouter une directive <directive module="mod_so">LoadModule</directive>
+ dans le fichier <code>httpd.conf</code> pour qu'Apache active le module.</p>
+</section>
+
+<section id="background"><title>Les dessous du fonctionnement des DSO</title>
+
+ <p>Les clônes modernes d'UNIX proposent un astucieux mécanisme
+ communément appelé édition de liens et chargement dynamiques d'
+ <em>Objets Dynamiques Partagés</em> (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.</p>
+
+ <p>Ce chargement peut s'effectuer de deux manières : automatiquement par
+ un programme système appelé <code>ld.so</code> 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 <code>dlopen()/dlsym()</code>.</p>
+
+ <p>Dans la première méthode, les DSO sont en général appelés
+ <em>bibliothèques partagées</em> ou encore <em>bibliothèques DSO</em>, et
+ possèdent des noms du style
+ <code>libfoo.so</code> ou <code>libfoo.so.1.2</code>. Ils résident dans un
+ répertoire système (en général <code>/usr/lib</code>)
+ et le lien avec le programme exécutable est établi à la compilation en
+ ajoutant <code>-lfoo</code> à 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 <code>libfoo.so</code> dans
+ <code>/usr/lib</code>, dans des chemins codés en dur à l'aide d'options de
+ l'éditeur de liens comme <code>-R</code> ou dans des chemins définis par la
+ variable d'environnement
+ <code>LD_LIBRARY_PATH</code>. Le chargeur peut dès lors résoudre tous les symboles
+ (jusque là non encore résolus) du DSO dans le programme exécutable.</p>
+
+ <p>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
+ <code>ld.so</code> 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 <code>libc.so</code>, ce qui permet
+ d'économiser de l'espace disque pour les autres programmes.</p>
+
+ <p>Dans la seconde méthode, les DSO sont en général appelés <em>objets
+ partagés</em> ou <em>fichiers DSO</em>, et peuvent être nommés avec
+ l'extension de son choix (bien que le nom conseillé soit du style
+ <code>foo.so</code>). 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 <code>dlopen()</code>.
+ 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 <code>libc.so</code>).
+ 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.</p>
+
+ <p>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
+ <code>dlsym()</code> pour une utilisation ultérieure dans les tables de
+ distribution, <em>etc...</em> 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.</p>
+
+ <p>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.</p>
+
+ <p>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.</p>
+
+ <p>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, <em>etc...</em> 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.</p>
+</section>
+
+<section id="advantages"><title>Avantages et inconvénients</title>
+
+ <p>Les fonctionnalités ci-dessus basées sur les DSO présentent les
+ avantages suivants :</p>
+
+ <ul>
+ <li>Le paquetage du serveur est plus flexible à l'exécution car le
+ processus serveur effectif peut être assemblé à l'exécution via la
+ directive <directive module="mod_so">LoadModule</directive> du fichier de
+ configuration <code>httpd.conf</code> plutôt que par des options du script
+ <program>configure</program> à 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], <em>etc...</em>) à partir d'une seule installation
+ d'Apache.</li>
+
+ <li>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,
+ <em>etc...</em></li>
+
+ <li>Une facilité de prototypage des modules Apache car la paire
+ DSO/<program>apxs</program> 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 <code>apxs -i</code>
+ suivie d'un <code>apachectl restart</code> pour introduire une nouvelle
+ version de votre module fraîchement développé dans le serveur Apache
+ en cours d'exécution.</li>
+ </ul>
+
+ <p>Inconvénients des DSO :</p>
+
+ <ul>
+ <li>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.</li>
+
+ <li>Le serveur est environ 20 % plus lent au démarrage
+ à cause des résolutions de symboles supplémentaires que le chargeur
+ Unix doit effectuer.</li>
+
+ <li>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.</li>
+
+ <li>Comme les modules DSO ne peuvent pas être liés avec d'autres
+ bibliothèques basées sur DSO (<code>ld -lfoo</code>) 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
+ (<code>libc</code>) et toutes autres bibliothèques statiques ou
+ dynamiques utilisées par le coeur d'Apache, ou d'archives statiques
+ (<code>libfoo.a</code>) 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 <code>dlopen()</code>.</li>
+ </ul>
+
+</section>
+
+</manualpage>
--- /dev/null
+<?xml version="1.0" encoding="ISO-8859-1" ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+<!--English Revision : 664361 -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<manualpage metafile="glossary.xml.meta">
+
+ <title>Glossaire</title>
+
+ <summary>
+ <p>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.</p>
+ </summary>
+
+<section id="definitions"><title>Définitions</title>
+
+<dt><a name="algorithm" id="algorithm">Algorithme</a></dt>
+
+ <dd>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
+ <dfn>Ciphers</dfn>.
+ </dd>
+
+ <dt><a name="cipher" id="cipher">Algorithme de chiffrement
+ (Cipher)</a></dt>
+ <dd>Un algorithme ou un système de chiffrement des données.
+ Quelques exemples : DES, IDEA, RC4, etc.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+ <dt><a name="tarball" id="tarball">Archive Tar (Tarball)</a></dt>
+ <dd>Un paquetage de fichiers rassemblés dans une archive
+ à l'aide de l'utilitaire <code>tar</code>.
+ Les distributions d'Apache sont stockées dans des Archives Tar compressées
+ ou en utilisant pkzip.
+ </dd>
+
+ <dt><a name="authentication" id="authentication">Authentification </a></dt>
+ <dd>L'identification formelle d'une entité du réseau comme un serveur, un
+ client, ou un utilisateur.<br />
+ Voir : <a href="howto/auth.html">Authentification, Autorisation, et
+ contrôle d'accès</a>
+ </dd>
+
+ <dt><a name="certificationauthority"
+ id="certificationauthority">Autorité de Certification
+ (Certification Authority)</a>
+ <a name="ca" id="ca">(CA)</a></dt>
+ <dd>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.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+
+<dt><a name="certificate" id="certificate">Certificat (Certificate)</a></dt>
+ <dd>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'<glossary
+ ref="certificationauthority">Autorité de Certification
+ (Certification Authority) ou CA</glossary> signataire (appelée
+ le fournisseur/issuer), ainsi que la
+ <glossary ref="publickey">clé publique (public
+ key)</glossary> 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.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+ <dt><a name="publickeycryptography"
+ id="publickeycryptography">Chiffrement à Clé Publique
+ (Public Key Cryptography)</a></dt>
+ <dd>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.
+ <br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+ <dt><a name="privatekey" id="privatekey">Clé Privée (Private Key)</a></dt>
+ <dd>La clé secrète dans un système de
+ <glossary ref="publickeycryptography">chiffrement à clé publique</glossary>,
+ utilisée pour déchiffrer les messages entrants et signer
+ les messages sortants.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+<dt><a name="publickey" id="publickey">Clé Publique (Public Key)</a></dt>
+ <dd>La clé accessible au public dans un système de <glossary
+ ref="publickeycryptography">Chiffrement à clé publique</glossary>,
+ utilisée pour chiffrer les messages destinés uniquement à son
+ propriétaire et déchiffrer les signatures
+ faites par son propriétaire.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+<dt><a name="connect" id="connect">CONNECT</a></dt>
+ <dd>Une <glossary ref="method">méthode</glossary> HTTP pour encapsuler
+ des données brutes dans HTTP. Elle peut aussi être utilisée pour encapsuler
+ d'autres protocoles, comme le protocole SSL.
+ </dd>
+
+ <dt><a name="context" id="context">Contexte (Context)</a></dt>
+ <dd>Une portion des <glossary ref="configurationfile">
+ fichiers de configuration</glossary> dans laquelle certains types de
+ <glossary ref="directive">directives</glossary> sont autorisés.<br />
+ Voir : <a href="mod/directive-dict.html#Context">Termes utilisés
+ pour décrire les directives d'Apache</a>
+ </dd>
+
+<dl>
+ <dt><a name="accesscontrol" id="accesscontrol">Contrôle d'accès
+ (Access Control)</a></dt>
+ <dd>La restriction d'accès à des zones du réseau. Habituellement
+ dans un contexte Apache,
+ la restriction d'accès à certaines <em>URLs</em>.<br />
+ Voir : <a
+ href="howto/auth.html">Authentification, Autorisation et
+ Contrôle d'accès</a>
+ </dd>
+
+ <dt><a name="securesocketslayer" id="securesocketslayer">
+ Couche des Points de connexion Sécurisés
+ (Secure Sockets Layer)
+ </a> <a name="ssl" id="ssl">(SSL)</a></dt>
+ <dd>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 <em>HTTPS</em>, autrement dit
+ le Protocole de Transfert Hypertexte (HTTP) au dessus de SSL.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+ <dt><a name="symmetriccryptophraphy" id="symmetriccryptophraphy">
+ Cryptographie Symétrique (Symmetric Cryptography)</a></dt>
+ <dd>L'étude et l'application des <em>Algorithmes de chiffrement</em> qui
+ utilisent une clé secrète unique pour les opérations de chiffrement et de
+ déchiffrement.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+
+ <dt><a name="export-crippled" id="export-crippled">
+ Dégradé pour l'exportation
+ (Export-Crippled)</a></dt>
+ <dd>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
+ <em>Texte crypté</em> qui peut en général être décrypté
+ par force brute.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+
+ <dt><a name="certificatsigningrequest"
+ id="certificatsigningrequest">Demande de signature de certificat
+ (Certificate Signing Request)</a>
+ <a name="csr" id="csr">(CSR)</a></dt>
+ <dd>La soumission d'un <glossary ref="certificate">certificat</glossary>
+ non signé à une <glossary ref="certificationauthority">Autorité de
+ certification</glossary>, qui le signe avec la <glossary
+ ref="privatekey">Clé privée</glossary> de leur
+ <em>Certificat</em> de CA. Une fois le CSR signé, il devient un vrai
+ certificat.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+ <dt><a name="directive" id="directive">Directive</a></dt>
+ <dd>Une commande de configuration qui contrôle un ou plusieurs aspects du
+ comportement d'Apache. Les directives sont placées dans le <glossary
+ ref="configurationfile">Fichier de configuration</glossary><br />
+ Voir : <a href="mod/directives.html">Index des directives</a>
+ </dd>
+
+<dt><a name="configurationdirective"
+ id="configurationdirective">Directive de configuration
+ (Configuration Directive)</a></dt>
+ <dd>Voir : <glossary ref="directive">Directive</glossary></dd>
+
+ <dt><a name="header" id="header">En-tête (Header)</a></dt>
+ <dd>La partie de la requête et de la réponse
+ <glossary ref="http">HTTP</glossary> qui est envoyée avant le contenu
+ proprement dit, et contient des méta-informations décrivant le contenu.
+ </dd>
+
+ <dt><a name="regularexpresion" id="regularexpresion">Expression Rationnelle
+ (Regular Expression)</a>
+ <a name="regex" id="regex">(Regex)</a></dt>
+ <dd>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
+ "<code>/images/.*(jpg|gif)$</code>". Apache utilise les Expressions
+ Rationnelles Compatibles avec Perl fournies par la librairie <a
+ href="http://www.pcre.org/">PCRE</a>.
+ </dd>
+
+ <dt><a name="configurationfile" id="configurationfile">
+ Fichier de configuration
+ (Configuration File)</a></dt>
+ <dd>Un fichier texte contenant des
+ <glossary ref="directive">Directives</glossary>
+ qui contrôlent la configuration d'Apache.<br />
+ Voir : <a href="configuring.html">Fichiers de configuration</a>
+ </dd>
+
+ <dt><a name="filter" id="filter">Filtre (Filter)</a></dt>
+ <dd>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
+ <code>INCLUDES</code>
+ traite les documents pour les
+ <glossary ref="ssi">Server Side Includes (Inclusions côté Serveur)
+ </glossary>.<br />
+ Voir : <a href="filter.html">Filtres</a>
+ </dd>
+
+<dt><a name="handler" id="handler">Gestionnaire (Handler)</a></dt>
+ <dd>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
+ <code>cgi-script</code> désigne les fichiers qui doivent être traités
+ comme <glossary ref="cgi">CGIs</glossary>.<br />
+ Voir : <a href="handler.html">Utilisation des gestionnaires d'Apache</a>
+ </dd>
+
+ <dt><a name="hash" id="hash">Hachage (Hash)</a></dt>
+ <dd>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).
+ </dd>
+
+ <dt><a name="virtualhosting" id="virtualhosting">Hébergement Virtuel
+ (Virtual Hosting)</a></dt>
+ <dd>Servir des sites web multiples en utilisant une seule instance d'Apache.
+ Les <em>Hôtes virtuels basés sur IP</em> différencient les sites web en se
+ basant sur leur adresse IP, alors que les
+ <em>Hôtes virtuels basés sur le nom</em> utilisent uniquement le nom d'hôte
+ et peuvent en conséquence héberger de nombreux sites avec la même
+ adresse IP.<br />
+ Voir la <a href="vhosts/">Documentation des Hôtes Virtuels d'Apache</a>
+ </dd>
+
+
+ <dt><a name="htaccess" id="htaccess">.htaccess</a></dt>
+ <dd>Un <glossary ref="configurationfile">fichier de configuration</glossary>
+ placé à un certain niveau de l'arborescence du site web, et appliquant des
+ <glossary ref="directive">directives</glossary> 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.<br />
+ Voir : <a href="configuring.html">Fichiers de configuration</a>
+ </dd>
+
+<dt><a name="httpd.conf" id="httpd.conf">httpd.conf</a></dt>
+ <dd>Le <glossary ref="configurationfile">fichier de configuration
+ </glossary> principal d'Apache. Sa localisation par défaut est
+ <code>/usr/local/apache2/conf/httpd.conf</code>, mais ceci peut être
+ changé en utilisant des options de compilation ou d'exécution.<br />
+ Voir : <a href="configuring.html">Fichiers de configuration</a>
+ </dd>
+
+ <dt><a name="https" id="https">HTTPS</a></dt>
+ <dd>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
+ <glossary ref="ssl">SSL</glossary>.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+ <dt><a name="uniformresourceidentifier"
+ id="uniformresourceidentifier">Identificateur de Ressource Uniformisé
+ (Uniform Resource Identifier)</a>
+ <a name="URI" id="URI">(URI)</a></dt>
+ <dd>Une chaîne de caractères compacte servant à identifier une ressource
+ abstraite ou physique. Elle est formellement définie par la <a
+ href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396</a>. Les URIs
+ utilisées sur le world-wide web sont souvent appelées <glossary
+ ref="url">URLs</glossary>.
+ </dd>
+
+ <dt><a name="serversideincludes" id="serversideincludes">
+ Inclusions Côté Serveur
+ (Server Side Includes)</a> <a name="ssi" id="ssi">(SSI)
+ </a></dt>
+ <dd>Une technique permettant d'englober des directives de traitement dans
+ des fichiers HTML.<br />
+ Voir : <a href="howto/ssi.html">Introduction aux Inclusions Côté Serveur</a>
+ </dd>
+
+<dt><a name="commongatewayinterface" id="commongatewayinterface">
+Interface commune avec les programmes externes
+(Common Gateway Interface)</a>
+ <a name="cgi" id="cgi">(CGI)</a></dt>
+ <dd>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 <a
+ href="http://hoohoo.ncsa.uiuc.edu/cgi/overview.html">NCSA</a> mais il
+ existe aussi le projet
+ <a href="http://cgi-spec.golux.com/">RFC project</a>.<br />
+ Voir : <a href="howto/cgi.html">Contenu dynamique avec CGI</a>
+ </dd>
+
+
+ <dt><a name="apacheportableruntime"
+ id="apacheportableruntime">Bibliothèques pour la portabilité d'Apache
+ (Apache Portable Runtime)</a> <a
+ name="apr" id="apr">(APR)</a></dt>
+ <dd>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.<br />
+ Voir : <a href="http://apr.apache.org/">Apache Portable Runtime
+ Project</a>
+ </dd>
+<dt><a name="uniformresourcelocator" id="uniformresourcelocator">
+Localisation de Ressource Uniformisée
+(Uniform Resource Locator)
+ </a> <a name="url" id="url">(URL)</a></dt>
+ <dd>Le nom/adresse d'une ressource sur l'Internet. Il s'agit du terme
+ informel commun pour ce qui est formellement défini comme <glossary
+ ref="uniformresourceidentifier">
+ Identificateur de Ressource Uniformisé</glossary>.
+ Les URLs sont généralement construites selon un schéma, comme
+ <code>http</code> ou
+ <code>https</code>, un nom d'hôte, et un chemin. Une URL pour cette page
+ pourrait être
+ <code>http://httpd.apache.org/docs/&httpd.docs;/glossary.html</code>.
+ </dd>
+
+
+ <dt><a name="proxy" id="proxy">Mandataire (Proxy)</a></dt>
+ <dd>Un serveur intermédiaire qui se situe entre le client et le
+ <em>serveur d'origine</em>.
+ 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.<br />
+ Voir : <a href="mod/mod_proxy.html">mod_proxy</a>
+ </dd>
+
+ <dt><a name="reverseproxy" id="reverseproxy">Mandataire inverse
+ (Reverse Proxy)</a></dt>
+ <dd>Un serveur <glossary ref="proxy">mandataire</glossary> qui est vu du client
+ comme un <em>serveur d'origine</em>. 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.
+ </dd>
+
+ <dt><a name="method" id="method">Méthode (Method)</a></dt>
+ <dd>Dans le contexte <glossary ref="http">HTTP</glossary>, 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
+ <code>GET</code>, <code>POST</code>,
+ et <code>PUT</code>.
+ </dd>
+
+ <dt><a name="module" id="module">Module</a></dt>
+ <dd>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
+ <program>httpd</program> sont appelés <dfn>modules statiques</dfn>, alors
+ que les modules qui existent séparément et peuvent être chargés
+ optionnellement à l'exécution sont appelés
+ <dfn>modules dynamiques</dfn> ou <glossary ref="dso">DSOs</glossary>.
+ Les modules qui sont inclus par défaut sont appelés
+ <dfn>modules de base</dfn>. De nombreux modules disponibles pour Apache
+ ne se trouvent pas dans l'<glossary ref="tarball">archive</glossary>
+ du Serveur HTTP Apache . Il sont appelés
+ <dfn>modules tiers</dfn>.<br />
+ Voir : <a href="mod/">Index des modules</a>
+ </dd>
+
+<dt><a name="passphrase" id="passphrase">Mot de Passe (Pass Phrase)</a></dt>
+ <dd>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 <glossary
+ ref="cipher">Algorithmes de chiffrement</glossary>.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+ <dt><a name="fully-qualifieddomain-name"
+ id="fully-qualifieddomain-name">Nom de domaine entièrement qualifié
+ (Fully-Qualified Domain-Name)</a>
+ <a name="fqdn" id="fqdn">(FQDN)</a></dt>
+ <dd>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,
+ <code>www</code> est un nom d'hôte, <code>example.com</code> est un nom
+ de domaine, et <code>www.example.com</code> est un nom de domaine
+ entièrement qualifié.
+ </dd>
+
+ <dt><a name="modulemagicnumber" id="modulemagicnumber">
+ Nombre Magique des Modules
+ (Module Magic Number)</a>
+ (<a name="mmn" id="mmn">MMN</a>)</dt>
+ <dd>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.
+ </dd>
+
+ <dt><a name="dynamicsharedobject" id="dynamicsharedobject">
+ Objet Dynamique Partagé (Dynamic Shared Object)
+ </a> <a name="dso" id="dso">(DSO)</a></dt>
+ <dd><glossary ref="module">Modules</glossary> compilés en dehors du binaire
+ Apache <program>httpd</program> et qui peuvent être
+ chargés à la demande.<br />
+ Voir : <a href="dso.html">Support des objets dynamiques partagés</a>
+ </dd>
+
+<dt><a name="openssl" id="openssl">OpenSSL</a></dt>
+ <dd>L'ensemble d'outils Open Source pour SSL/TLS<br />
+ Voir <a href="http://www.openssl.org/">http://www.openssl.org/</a>#
+ </dd>
+
+<dt><a name="apacheextensiontool" id="apacheextensiontool">
+ Outil de gestion des extensions Apache
+ (APache eXtension Tool)</a>
+ <a name="apxs" id="apxs">(apxs)</a></dt>
+ <dd>Un script Perl qui aide à la compilation des sources de <glossary
+ ref="module">module</glossary> sous forme d'Objets Dynamiques Partagés
+ (Dynamic Shared Objects ou
+ <glossary ref="dso">DSO</glossary>s) et facilite leur installation
+ dans le serveur Web Apache.<br />
+ Voir : Page de manuel : <program>apxs</program>
+ </dd>
+
+<dt><a name="plaintext" id="plaintext">Plein Texte (Plaintext)</a></dt>
+ <dd>Le texte non chiffré.</dd>
+
+
+
+ <dt><a name="hypertexttransferprotocol"
+ id="hypertexttransferprotocol">Protocole de Transfert Hypertexte
+ (HyperText Transfer Protocol)</a>
+ <a name="http" id="hhtp">(HTTP)</a></dt>
+ <dd>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
+ <a href="http://ietf.org/rfc/rfc2616.txt">RFC 2616</a>.
+ </dd>
+
+ <dt><a name="messagedigest" id="messagedigest">Résumé de message
+ (Message Digest)</a></dt>
+ <dd>Un hachage du message, qui peut être utilisé pour vérifier
+ que son contenu n'a pas été altéré durant le transfert.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+ <dt><a name="transportlayersecurity" id="transportlayersecurity">
+ Sécurité de la couche Transport
+ (Transport Layer Security)
+ </a> <a name="tls" id="tls">(TLS)</a></dt>
+ <dd>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.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+ <dt><a name="session" id="session">Session</a></dt>
+ <dd>Les informations sur le contexte d'une communication en général.</dd>
+
+ <dt><a name="digitalsignature" id="digitalsignature">Signature numérique
+ (Digital Signature)</a></dt>
+ <dd>Un bloc de texte crypté qui valide un certificat ou un autre fichier.
+ Une <glossary ref="certificationauthority">Autorité de certification</glossary>
+ crée une signature en générant une empreinte de la <em>Clé publique</em>
+ fournie avec le <em>Certificat</em>; la CA chiffre ensuite l'empreinte
+ avec sa propre <em>Clé privée</em>. 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
+ <em>Certificat</em>.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+<dt><a name="ssleay" id="ssleay">SSLeay</a></dt>
+ <dd>La bibliothèque originelle d'implémentation de SSL/TLS développée par
+ Eric A. Young
+ </dd>
+
+<dt><a name="ciphertext" id="ciphertext">Texte crypté
+(Ciphertext)</a></dt>
+ <dd>Le résultat du passage d'un document
+ <glossary ref="plaintext">Plaintext</glossary> (Plein texte) par un
+ <glossary ref="cipher">Cipher</glossary>.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+ <dt><a name="mime-type" id="mime-type">Type MIME (MIME-type)</a></dt>
+ <dd>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 <code>text/html</code>,
+ <code>image/gif</code>, et <code>application/octet-stream</code>. Dans
+ HTTP, le type MIME est transmis dans l'
+ <glossary ref="header">en-tête</glossary> <code>Content-Type</code>.<br />
+ Voir : <a href="mod/mod_mime.html">mod_mime</a>
+ </dd>
+
+
+ <dt><a name="environmentvariable" id="environmentvariable">
+ Variable d'environnement
+ (Environment Variable)</a> <a name="env-variable"
+ id="env-variable">(env-variable)</a></dt>
+ <dd>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.<br />
+ Voir : <a href="env.html">Les variables d'environnement dans Apache</a>
+ </dd>
+
+ <dt><a name="x.509" id="x.509">X.509</a></dt>
+ <dd>Une norme de certificat d'authentification recommandée par l'International
+ Telecommunication Union (ITU-T) et utilisée pour
+ l'authentification SSL/TLS.<br
+ /> Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+</dl>
+</section>
+</manualpage>
+
+
--- /dev/null
+<?xml version="1.0" encoding="ISO-8859-1" ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+<!-- English Revision: 659902 -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<manualpage metafile="logs.xml.meta">
+
+ <title>Fichiers journaux</title>
+
+ <summary>
+ <p>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.</p>
+ </summary>
+
+ <section id="security">
+ <title>Avertissement à propos de la sécurité</title>
+
+ <p>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 <em>PAS</em> 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 <a href="misc/security_tips.html">conseils sur la sécurité</a>
+ pour plus de détails.</p>
+
+ <p>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.</p>
+ </section>
+
+ <section id="errorlog">
+ <title>Journal des erreurs</title>
+
+ <related>
+ <directivelist>
+ <directive module="core">ErrorLog</directive>
+ <directive module="core">LogLevel</directive>
+ </directivelist>
+ </related>
+
+ <p>Le journal des erreurs du serveur, dont le nom et la localisation sont
+ définis par la directive <directive module="core">ErrorLog</directive>,
+ 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.</p>
+
+ <p>Le journal des erreurs est habituellement enregistré dans un fichier
+ (en général <code>error_log</code> sur les systèmes de type Unix et
+ <code>error.log</code> sur Windows et OS/2). Sur les systèmes de type Unix,
+ le serveur peut aussi enregistrer ses erreurs dans
+ <code>syslog</code> ou les
+ <a href="#piped">rediriger vers un programme</a> par l'intermédiaire d'un
+ tube de communication (pipe).</p>
+
+ <p>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 : </p>
+
+ <example>
+ [Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1]
+ client denied by server configuration:
+ /export/home/live/ap/htdocs/test
+ </example>
+
+ <p>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 <directive module="core">LogLevel</directive> 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).</p>
+
+ <p>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 <code>stderr</code> sera recopiée
+ telle quelle dans le journal des erreurs.</p>
+
+ <p>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 <a href="#accesslog">journal des accès</a>. 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.</p>
+
+ <p>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 :</p>
+
+ <example>
+ tail -f error_log
+ </example>
+ </section>
+
+ <section id="accesslog">
+ <title>Journal des accès</title>
+
+ <related>
+ <modulelist>
+ <module>mod_log_config</module>
+ <module>mod_setenvif</module>
+ </modulelist>
+ <directivelist>
+ <directive module="mod_log_config">CustomLog</directive>
+ <directive module="mod_log_config">LogFormat</directive>
+ <directive module="mod_setenvif">SetEnvIf</directive>
+ </directivelist>
+ </related>
+
+ <p>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 <directive module="mod_log_config">CustomLog</directive>.
+ La directive <directive module="mod_log_config">LogFormat</directive>
+ 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.</p>
+
+ <p>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 à <a href="http://dmoz.org/Computers/Software/Internet/
+ Site_Management/Log_analysis/">Open Directory</a> ou
+ <a href="http://dir.yahoo.com/Computers_and_Internet/Software/
+ Internet/World_Wide_Web/Servers/Log_Analysis_Tools/">Yahoo</a>.</p>
+
+ <p>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
+ <code>TransferLog</code>. La directive
+ <directive module="mod_log_config">CustomLog</directive> rassemble
+ désormais les fonctionnalités de toutes les anciennes directives.</p>
+
+ <p>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
+ <a href="mod/mod_log_config.html#formats">chaînes de format</a> de la
+ documentation du module <module>mod_log_config</module>.</p>
+
+ <section id="common">
+ <title>Format habituel du journal</title>
+
+ <p>Voici une configuration typique pour le journal des accès :</p>
+
+ <example>
+ LogFormat "%h %l %u %t \"%r\" %>s %b" common<br />
+ CustomLog logs/access_log common
+ </example>
+
+ <p>Ici est définie l'<em>identité</em> <code>common</code> 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 (<code>"</code>) doivent être échappées en les faisant
+ précéder d'un anti-slash (<code>\</code>) 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
+ "<code>\n</code>" et "<code>\t</code>" pour insérer respectivement
+ un passage à la ligne et une tabulation.</p>
+
+ <p>La directive <directive module="mod_log_config">CustomLog</directive>
+ 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
+ <directive module="core">ServerRoot</directive>, sauf s'il
+ débute par un slash.</p>
+
+ <p>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 :</p>
+
+ <example>
+ 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
+ /apache_pb.gif HTTP/1.0" 200 2326
+ </example>
+
+ <p>Chaque partie de cette entrée de journal est décrite
+ dans ce qui suit.</p>
+
+ <dl>
+ <dt><code>127.0.0.1</code> (<code>%h</code>)</dt>
+
+ <dd>Il s'agit de l'adresse IP du client (l'hôte distant) qui a envoyé
+ la requête au serveur. Si la directive
+ <directive module="core">HostnameLookups</directive> est positionnée à
+ <code>On</code>, 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 <program>logresolve</program>
+ 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.</dd>
+
+ <dt><code>-</code> (<code>%l</code>)</dt>
+
+ <dd>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 <code>identd</code> 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
+ <directive module="core">IdentityCheck</directive> est positionnée
+ à <code>On</code>.</dd>
+
+ <dt><code>frank</code> (<code>%u</code>)</dt>
+
+ <dd>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
+ <code>REMOTE_USER</code>. 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
+ "<code>-</code>", comme la partie précédente.</dd>
+
+ <dt><code>[10/Oct/2000:13:55:36 -0700]</code>
+ (<code>%t</code>)</dt>
+
+ <dd>
+ L'heure à laquelle la requête a été reçue.
+ Le format est le suivant :
+
+ <p class="indent">
+ <code>[jour/mois/année:heure:minutes:secondes zone]<br />
+ jour = 2*chiffre<br />
+ mois = 3*lettre<br />
+ année = 4*chiffre<br />
+ heure = 2*chiffre<br />
+ minutes = 2*chiffre<br />
+ secondes = 2*chiffre<br />
+ zone = (`+' | `-') 4*chiffre</code>
+ </p>Il est possible de modifier le format d'affichage de l'heure
+ en spécifiant <code>%{format}t</code> dans la chaîne de format du
+ journal, où <code>format</code> est une chaîne de format de même
+ forme que celle de la fonction <code>strftime(3)</code> de la
+ bibliothèque C standard.
+ </dd>
+
+ <dt><code>"GET /apache_pb.gif HTTP/1.0"</code>
+ (<code>\"%r\"</code>)</dt>
+
+ <dd>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 <code>GET</code>. Ensuite, le
+ client a demandé la ressource <code>/apache_pb.gif</code>, et enfin,
+ le client a utilisé le protocole <code>HTTP/1.0</code>. Il est aussi
+ possible d'enregistrer séparément une ou plusieurs parties de la
+ requête. Par exemple, la chaîne de format "<code>%m %U %q %H</code>"
+ 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
+ "<code>%r</code>".</dd>
+
+ <dt><code>200</code> (<code>%>s</code>)</dt>
+
+ <dd>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 <a href="http://www.w3.org/Protocols/rfc2616/
+ rfc2616.txt">specification HTTP</a> (RFC2616 section 10).</dd>
+
+ <dt><code>2326</code> (<code>%b</code>)</dt>
+
+ <dd>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 "<code>-</code>". Pour indiquer l'absence de contenu
+ par "<code>0</code>", utilisez <code>%B</code> au lieu de
+ <code>%b</code>.</dd>
+ </dl>
+ </section>
+
+ <section id="combined">
+ <title>Combined Log Format (Format de journalisation combiné)</title>
+
+ <p>Une autre chaîne de format couramment utilisée est le
+ "Combined Log Format" (Format de journalisation combiné). Il s'utilise
+ comme suit :</p>
+
+ <example>
+ LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
+ \"%{User-agent}i\"" combined<br />
+ CustomLog log/access_log combined
+ </example>
+
+ <p>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 "%" <code>%{<em>header</em>}i</code>,
+ où <em>header</em> 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 :</p>
+
+ <example>
+ 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)"
+ </example>
+
+ <p>Les champs supplémentaires sont :</p>
+
+ <dl>
+ <dt><code>"http://www.example.com/start.html"</code>
+ (<code>\"%{Referer}i\"</code>)</dt>
+
+ <dd>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 <code>/apache_pb.gif</code> ou
+ inclut ce dernier fichier).</dd>
+
+ <dt><code>"Mozilla/4.08 [en] (Win98; I ;Nav)"</code>
+ (<code>\"%{User-agent}i\"</code>)</dt>
+
+ <dd>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.</dd>
+ </dl>
+ </section>
+
+ <section id="multiple">
+ <title>Journaux d'accès multiples</title>
+
+ <p>Plusieurs journaux d'accès peuvent être créés en spécifiant tout
+ simplement plusieurs directives
+ <directive module="mod_log_config">CustomLog</directive> 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
+ <directive module="mod_log_config">CustomLog</directive> montrent
+ comment simuler les effets des directives <code>ReferLog</code> et
+ <code>AgentLog</code>.</p>
+
+ <example>
+ LogFormat "%h %l %u %t \"%r\" %>s %b" common<br />
+ CustomLog logs/access_log common<br />
+ CustomLog logs/referer_log "%{Referer}i -> %U"<br />
+ CustomLog logs/agent_log "%{User-agent}i"
+ </example>
+
+ <p>Cet exemple montre aussi qu'il n'est pas obligatoire d'associer
+ une chaîne de format à un alias au moyen de la directive
+ <directive module="mod_log_config">LogFormat</directive>. Elle peut
+ être définie directement dans la ligne de la directive
+ <directive module="mod_log_config">CustomLog</directive>.</p>
+ </section>
+
+ <section id="conditional">
+ <title>Journalisation conditionnelle</title>
+
+ <p>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
+ <a href="env.html">variables d'environnement</a>. 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 <directive module="mod_setenvif">SetEnvIf</directive>,
+ puis la clause <code>env=</code> de la directive
+ <directive module="mod_log_config">CustomLog</directive> pour inclure
+ ou exclure les requêtes pour lesquelles
+ la variable d'environnement est définie.
+ Quelques exemples :</p>
+
+ <example>
+ # Marque les requêtes en provenance de l'interface loop-back<br />
+ SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog<br />
+ # Marque les requêtes pour le fichier robots.txt<br />
+ SetEnvIf Request_URI "^/robots\.txt$" dontlog<br />
+ # Journalise toutes les autres requêtes<br />
+ CustomLog logs/access_log common env=!dontlog
+ </example>
+
+ <p>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.</p>
+
+ <example>
+ SetEnvIf Accept-Language "en" english<br />
+ CustomLog logs/english_log common env=english<br />
+ CustomLog logs/non_english_log common env=!english
+ </example>
+
+ <p>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.</p>
+ </section>
+ </section>
+
+ <section id="rotation">
+ <title>Rotation des journaux</title>
+
+ <p>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
+ <a href="stopping.html">redémarré</a> après le déplacement ou la
+ suppression des fichiers journaux de façon à ce qu'il en ouvre
+ de nouveaux.</p>
+
+ <p>Avec un redémarrage <em>graceful</em>, 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 :</p>
+
+ <example>
+ mv access_log access_log.old<br />
+ mv error_log error_log.old<br />
+ apachectl graceful<br />
+ sleep 600<br />
+ gzip access_log.old error_log.old
+ </example>
+
+ <p>La section suivante présente une autre méthode de rotation des journaux
+ qui consiste à utiliser les
+ <a href="#piped">journaux redirigés</a>.</p>
+ </section>
+
+ <section id="piped">
+ <title>Journaux redirigés</title>
+
+ <p>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 "<code>|</code>", 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é.)</p>
+
+ <p>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.</p>
+
+ <p>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é <program>rotatelogs</program>. Par exemple, pour une rotation des
+ journaux toutes les 24 heures, ajoutez ces lignes :</p>
+
+ <example>
+ CustomLog "|/usr/local/apache/bin/rotatelogs
+ /var/log/access_log 86400" common
+ </example>
+
+ <p>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.</p>
+
+ <p>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 <a href="http://www.cronolog.org/">ici</a>.</p>
+
+ <p>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.</p>
+ </section>
+
+ <section id="virtualhost">
+ <title>Hôtes virtuels</title>
+
+ <p>Lorsqu'un serveur possède plusieurs <a href
+ ="vhosts/">hôtes virtuels</a>, 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
+ <directive module="core" type="section">VirtualHost</directive> 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.</p>
+
+ <p>Si des directives <directive module=
+ "mod_log_config">CustomLog</directive> ou
+ <directive module="core">ErrorLog</directive> sont placées dans une section
+ <directive module="core" type="section">VirtualHost</directive>, 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 <a
+ href="vhosts/fd-limits.html">nombre de descripteurs
+ de fichiers insuffisant</a> peuvent rapidement apparaître.</p>
+
+ <p>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 :</p>
+
+ <example>
+ LogFormat "%v %l %u %t \"%r\" %>s %b"
+ comonvhost<br />
+ CustomLog logs/access_log comonvhost
+ </example>
+
+ <p>Le champ <code>%v</code> sert à enregistrer le nom de l'hôte virtuel qui
+ traite la requête. Un programme tel que <a
+ href="programs/other.html">split-logfile</a> peut ensuite être utilisé
+ pour générer "à froid" autant de journaux que d'hôtes virtuels.</p>
+ </section>
+
+ <section id="other">
+ <title>Autres fichiers journaux</title>
+
+ <related>
+ <modulelist>
+ <module>mod_logio</module>
+ <module>mod_log_forensic</module>
+ <module>mod_cgi</module>
+ <module>mod_rewrite</module>
+ </modulelist>
+ <directivelist>
+ <directive module="mod_log_config">LogFormat</directive>
+ <directive module="mod_log_forensic">ForensicLog</directive>
+ <directive module="mpm_common">PidFile</directive>
+ <directive module="mod_rewrite">RewriteLog</directive>
+ <directive module="mod_rewrite">RewriteLogLevel</directive>
+ <directive module="mod_cgi">ScriptLog</directive>
+ <directive module="mod_cgi">ScriptLogBuffer</directive>
+ <directive module="mod_cgi">ScriptLogLength</directive>
+ </directivelist>
+ </related>
+
+ <section>
+ <title>Enregistrement du nombre réel d'octets envoyés et reçus</title>
+
+ <p>Le module <module>mod_logio</module> fournit deux champs
+ <directive module="mod_log_config">LogFormat</directive> supplémentaires
+ (%I et %O) qui permettent d'enregistrer le nombre réel d'octets reçus et
+ envoyés sur le réseau.</p>
+ </section>
+
+ <section>
+ <title>Journalisation de style investigation judiciaire (forensic logging)</title>
+
+ <p>Le module <module>mod_log_forensic</module> 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é.</p>
+ </section>
+
+ <section id="pidfile">
+ <title>Fichier PID</title>
+
+ <p>Au démarrage, le démon httpd Apache enregistre l'identifiant du
+ processus httpd parent dans le fichier <code>logs/httpd.pid</code>.
+ Le nom de ce fichier peut être modifié à l'aide de la directive
+ <directive module="mpm_common">PidFile</directive>. 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 <a href="stopping.html">Arrêt et redémarrage</a>.</p>
+ </section>
+
+ <section id="scriptlog">
+ <title>Journal des scripts</title>
+
+ <p>Afin de faciliter le débogage, la directive
+ <directive module="mod_cgi">ScriptLog</directive> 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 <a href="mod/mod_cgi.html">mod_cgi</a>.</p>
+ </section>
+
+ <section id="rewritelog">
+ <title>Journal de réécriture</title>
+
+ <p>Lorsqu'on utilise les fonctionnalités puissantes et complexes du
+ module <a href="mod/mod_rewrite.html">mod_rewrite</a>, il est presque
+ toujours nécessaire d'utiliser la directive
+ <directive module="mod_rewrite">RewriteLog</directive> 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
+ <directive module="mod_rewrite">RewriteLogLevel</directive>.</p>
+ </section>
+ </section>
+</manualpage>
+
+
+
+
--- /dev/null
+<?xml version="1.0" encoding="ISO-8859-1" ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+<!-- English Revision : 642717 -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<manualpage metafile="new_features_2_4.xml.meta">
+
+<title>Vue d'ensemble des nouvelles fonctionnalités d'Apache 2.4</title>
+
+<summary>
+ <p>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
+ <a href="new_features_2_2.html">nouvelles fonctionnalités
+ de la version 2.2</a>.</p>
+</summary>
+
+ <section id="core">
+ <title>Améliorations du noyau</title>
+ <!-- <dl>
+ </dl> -->
+ </section>
+
+ <section id="module">
+ <title>Améliorations des modules</title>
+ <!-- <dl>
+ </dl> -->
+ </section>
+
+ <section id="programs">
+ <title>Améliorations des programmes</title>
+ <!-- <dl>
+ </dl> -->
+ </section>
+
+ <section id="developer">
+ <title>Modifications pour le développeur de modules</title>
+ <dl>
+ <dt>Ajout de code pour la vérification de la configuration</dt>
+
+ <dd>Une nouvelle fonction, <code>check_config</code>, a été ajoutée et
+ s'exécute entre les fonctions <code>pre_config</code> et
+ <code>open_logs</code>. Elle s'exécute aussi avant la fonction
+ <code>test_config</code> si l'option <code>-t</code> est passée au
+ démon <program>httpd</program>. La fonction <code>check_config</code>
+ 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 <code>open_logs</code> ne redirige les sorties de la
+ console vers le journal des erreurs.</dd>
+ <dt>Ajout d'un analyseur syntaxique d'expressions</dt>
+ <dd>Nous disposons à présent d'un analyseur générique d'expressions, dont l'API
+ est décrite dans <var>ap_expr.h</var>. Il s'agit d'une adaptation de
+ l'analyseur qu'on trouvait auparavant dans <module>mod_include</module>.</dd>
+ </dl>
+ </section>
+</manualpage>
--- /dev/null
+<?xml version="1.0" encoding="ISO-8859-1" ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+<!-- English Revision: 420990 -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<manualpage metafile="sections.xml.meta">
+
+<title>Sections de configuration</title>
+
+<summary> <p>Les directives des <a
+href="configuring.html">fichiers de configuration</a> 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 <code>.htaccess</code> pour
+modifier la portée des directives de configuration.</p>
+</summary>
+
+<section id="types"><title>Types de conteneurs de sections de
+configuration</title>
+
+<related>
+<modulelist>
+<module>core</module>
+<module>mod_version</module>
+<module>mod_proxy</module>
+</modulelist>
+<directivelist>
+<directive type="section" module="core">Directory</directive>
+<directive type="section" module="core">DirectoryMatch</directive>
+<directive type="section" module="core">Files</directive>
+<directive type="section" module="core">FilesMatch</directive>
+<directive type="section" module="core">IfDefine</directive>
+<directive type="section" module="core">IfModule</directive>
+<directive type="section" module="mod_version">IfVersion</directive>
+<directive type="section" module="core">Location</directive>
+<directive type="section" module="core">LocationMatch</directive>
+<directive type="section" module="mod_proxy">Proxy</directive>
+<directive type="section" module="mod_proxy">ProxyMatch</directive>
+<directive type="section" module="core">VirtualHost</directive>
+</directivelist>
+</related>
+
+<p>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
+<directive type="section" module="core">IfDefine</directive>, <directive
+type="section" module="core">IfModule</directive>, et
+<directive type="section" module="mod_version">IfVersion</directive> 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.</p>
+
+<p>Le conteneur <directive type="section" module="core">IfDefine</directive>
+contient des directives qui ne seront appliquées que si un paramètre
+approprié a été défini dans la ligne de commande de <program>httpd</program>.
+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 :
+<code>httpd -DClosedForNow</code>:</p>
+
+<example>
+<IfDefine ClosedForNow><br />
+Redirect / http://otherserver.example.com/<br />
+</IfDefine>
+</example>
+
+<p>Le conteneur <directive type="section" module="core">IfModule</directive>
+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 <directive
+module="mod_so">LoadModule</directive> 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.</p>
+
+<p>Dans l'exemple suivant, la directive <directive
+module="mod_mime_magic">MimeMagicFiles</directive> ne s'appliquera que si le
+module <module>mod_mime_magic</module> est disponible.</p>
+
+<example>
+<IfModule mod_mime_magic.c><br />
+MimeMagicFile conf/magic<br />
+</IfModule>
+</example>
+
+<p>Le conteneur
+<directive type="section" module="mod_version">IfVersion</directive>
+est similaire aux conteneurs <directive type="section"
+module="core">IfDefine</directive> et <directive type="section"
+module="core">IfModule</directive>; 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.</p>
+
+<example>
+ <IfVersion >= 2.1><br />
+ <indent>
+ # les directives situées ici ne s'appliquent que si la version <br />
+ # est supérieure ou égale à 2.1.0.<br />
+ </indent>
+ </IfVersion>
+</example>
+
+<p><directive type="section" module="core">IfDefine</directive>,
+<directive type="section" module="core">IfModule</directive>, et
+<directive type="section" module="mod_version">IfVersion</directive>
+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.</p>
+</section>
+
+<section id="file-and-web"><title>Système de fichiers et
+arborescence du site web</title>
+
+<p>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 <code>/usr/local/apache2</code> pour le système de
+fichiers UNIX, ou <code>"c:/Program Files/Apache Group/Apache2"</code> 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 <code>/dir/</code> dans
+l'arborescence du site web correspond au chemin
+<code>/usr/local/apache2/htdocs/dir/</code> 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.</p>
+
+<section id="filesystem"><title>Conteneurs de système de fichiers</title>
+
+<p>Les conteneurs <directive type="section" module="core">Directory</directive>
+et <directive type="section" module="core">Files</directive>,
+ainsi que leurs équivalents acceptant les
+<glossary ref="regex">expressions rationnelles</glossary>,
+appliquent des directives à certaines parties du système de fichiers.
+Les directives contenues dans une section <directive
+type="section" module="core">Directory</directive> s'appliquent au répertoire
+précisé, ainsi qu'à tous ses sous-répertoires.
+Le même effet peut être obtenu en utilisant les <a
+href="howto/htaccess.html">fichiers .htaccess</a>. Par exemple, avec la
+configuration suivante, l'indexation sera activée pour le répertoire
+<code>/var/web/dir1</code> et tous ses sous-répertoires.</p>
+
+<example>
+<Directory /var/web/dir1><br />
+Options +Indexes<br />
+</Directory>
+</example>
+
+<p>Les directives contenues dans une section <directive type="section"
+module="core">Files</directive> 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é <code>private.html</code> quel que soit
+l'endroit où il se trouve.</p>
+
+<example>
+<Files private.html><br />
+Order allow,deny<br />
+Deny from all<br />
+</Files>
+</example>
+
+<p>Pour faire référence à des fichiers qui se trouvent en des points
+particuliers du système de fichiers, les sections
+<directive type="section" module="core">Files</directive> et
+<directive type="section" module="core">Directory</directive>
+peuvent être combinées. Par exemple, la configuration suivante va interdire
+l'accès à <code>/var/web/dir1/private.html</code>,
+<code>/var/web/dir1/subdir2/private.html</code>,
+<code>/var/web/dir1/subdir3/private.html</code>, ainsi que toute instance de
+<code>private.html</code> qui se trouve dans l'arborescence
+<code>/var/web/dir1/</code>.</p>
+
+<example>
+<Directory /var/web/dir1><br />
+<Files private.html><br />
+Order allow,deny<br />
+Deny from all<br />
+</Files><br />
+</Directory>
+</example>
+</section>
+
+<section id="webspace"><title>Conteneurs de l'arborescence du site web</title>
+
+<p>le conteneur <directive type="section" module="core">Location</directive>
+et son équivalent acceptant les
+<glossary ref="regex">expressions rationnelles</glossary>, 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 :
+<code>http://yoursite.example.com/private</code>,
+<code>http://yoursite.example.com/private123</code>, et
+<code>http://yoursite.example.com/private/dir/file.html</code> ainsi qu'à
+toute requête commençant par la chaîne de caractères <code>/private</code>.</p>
+
+<example>
+<Location /private><br />
+Order Allow,Deny<br />
+Deny from all<br />
+</Location>
+</example>
+
+<p>Le conteneur <directive type="section" module="core">Location</directive>
+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
+<module>mod_status</module>.
+Il n'est pas nécessaire de trouver un fichier nommé <code>server-status</code>
+dans le système de fichiers.</p>
+
+<example>
+<Location /server-status><br />
+SetHandler server-status<br />
+</Location>
+</example>
+</section>
+
+<section id="wildcards"><title>Caractères de remplacement
+et expressions rationnelles</title>
+
+<p>Les conteneurs
+<directive type="section" module="core">Directory</directive>,
+<directive type="section" module="core">Files</directive>, et
+<directive type="section" module="core">Location</directive>
+peuvent utiliser des caractères de remplacement de style shell comme dans
+la fonction <code>fnmatch</code> de la bibliothèque C standard.
+Le caractère "*"
+correspond à toute séquence de caractères, "?" à un caractère seul,
+et "[<em>seq</em>]" à tout caractère contenu dans <em>seq</em>.
+Le caractère "/"
+ne peut pas faire l'objet d'un remplacement;
+il doit être spécifié explicitement.</p>
+
+<p>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 : <directive
+type="section" module="core">DirectoryMatch</directive>, <directive
+type="section" module="core">FilesMatch</directive>, et <directive
+type="section" module="core">LocationMatch</directive> acceptent les
+<glossary ref="regex">expressions rationnelles</glossary> 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.</p>
+
+<p>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 :</p>
+
+<example>
+<Directory /home/*/public_html><br />
+Options Indexes<br />
+</Directory>
+</example>
+
+<p>Avec les conteneurs utilisant les expressions rationnelles,
+on peut interdire l'accès à de nombreux types de fichiers d'images
+simultanément :</p>
+<example>
+<FilesMatch \.(?i:gif|jpe?g|png)$><br />
+Order allow,deny<br />
+Deny from all<br />
+</FilesMatch>
+</example>
+
+</section>
+
+<section id="whichwhen"><title>Que faut-il utiliser et quand ?</title>
+
+<p>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 <directive type="section"
+module="core">Directory</directive> ou <directive type="section"
+module="core">Files</directive>. 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 <directive type="section"
+module="core">Location</directive>.</p>
+
+<p>Il ne faut jamais utiliser un conteneur <directive type="section"
+module="core">Location</directive> 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 :</p>
+
+<example>
+<Location /dir/><br />
+Order allow,deny<br />
+Deny from all<br />
+</Location>
+</example>
+
+<p>Elle fonctionne correctement si la requête appelle
+<code>http://yoursite.example.com/dir/</code>. 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
+<code>http://yoursite.example.com/DIR/</code>. Le conteneur <directive
+type="section" module="core">Directory</directive>, 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
+<directive type="section" module="core">Directory</directive> 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
+<directive module="core">Options</directive> appropriée.)</p>
+
+<p>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 <code><Location
+/></code> est tout à fait sans rique car ce conteneur va s'appliquer à
+toutes les requêtes sans tenir compte de l'URL spécifique.</p>
+</section>
+
+</section>
+
+<section id="virtualhost"><title>Hôtes virtuels</title>
+
+<p>Le conteneur <directive type="section" module="core">VirtualHost</directive>
+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 <a href="vhosts/">Documentation sur les hôtes virtuels</a>.</p>
+</section>
+
+<section id="proxy"><title>Mandataire</title>
+
+<p>Les conteneurs
+<directive type="section" module="mod_proxy">Proxy</directive>
+et <directive type="section" module="mod_proxy">ProxyMatch</directive>
+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 <module>mod_proxy</module>.
+Par exemple, la configuration suivante
+va interdire l'utilisation du serveur proxy pour accéder au site
+<code>cnn.com</code>.</p>
+
+<example>
+<Proxy http://cnn.com/*><br />
+Order allow,deny<br />
+Deny from all<br />
+</Proxy>
+</example>
+</section>
+
+<section id="whatwhere"><title>Quelles sont les directives autorisées ?</title>
+
+<p>Pour déterminer quelles sont les directives autorisées pour tel type de
+section de configuration, vérifiez le <a
+href="mod/directive-dict.html#Context">Contexte</a> de la directive.
+Tout ce qui est autorisé dans les sections
+<directive type="section" module="core">Directory</directive>
+l'est aussi d'un point de vue syntaxique dans les sections
+<directive type="section" module="core">DirectoryMatch</directive>,
+<directive type="section" module="core">Files</directive>,
+<directive type="section" module="core">FilesMatch</directive>,
+<directive type="section" module="core">Location</directive>,
+<directive type="section" module="core">LocationMatch</directive>,
+<directive type="section" module="mod_proxy">Proxy</directive>,
+et <directive type="section" module="mod_proxy">ProxyMatch</directive>.
+Il y a cependant quelques exceptions :</p>
+
+<ul>
+<li>La directive <directive module="core">AllowOverride</directive>
+ne fonctionne que dans les sections
+<directive type="section" module="core">Directory</directive>.</li>
+
+<li>Les <directive
+module="core">Options</directive> <code>FollowSymLinks</code> et
+<code>SymLinksIfOwnerMatch</code> ne fonctionnent que dans les sections
+<directive type="section" module="core">Directory</directive> ou les fichiers
+<code>.htaccess</code>.</li>
+
+<li>La directive <directive module="core">Options</directive> ne peut pas être
+utilisée dans les sections
+<directive type="section" module="core">Files</directive>
+et <directive type="section" module="core">FilesMatch</directive>.</li>
+</ul>
+</section>
+
+<section id="mergin"><title>Comment les sections sont combinées entre elles</title>
+
+<p>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.</p>
+
+ <p>L'ordre dans lequel les sections sont combinées est :</p>
+
+ <ol>
+ <li> Les sections <directive type="section"
+ module="core">Directory</directive> (à l'exception des
+ expressions rationnelles)
+ et les fichiers <code>.htaccess</code> sont appliqués simultanément (avec
+ la possibilité pour <code>.htaccess</code>, s'il y est autorisé, de
+ prévaloir sur
+ <directive type="section" module="core">Directory</directive>)</li>
+
+ <li>Les sections
+ <directive type="section" module="core">DirectoryMatch</directive>
+ (et <code><Directory ~></code>)</li>
+
+ <li>Les sections <directive type="section"
+ module="core">Files</directive> et <directive
+ type="section" module="core">FilesMatch</directive> sont appliquées
+ simultanément</li>
+
+ <li>Les sections
+ <directive type="section" module="core">Location</directive>
+ et <directive type="section"
+ module="core">LocationMatch</directive> sont appliquées
+ simultanément</li>
+ </ol>
+
+ <p>Mises à part les sections <directive type="section"
+ module="core">Directory</directive>, chaque groupe est traité selon
+ l'ordre dans lequel il apparaît dans les fichiers de configuration.
+ Les sections <directive
+ type="section" module="core">Directory</directive> (groupe 1 ci-dessus)
+ sont traitées dans l'ordre du répertoire le plus court vers le plus long.
+ Par exemple, <code><Directory /var/web/dir></code> sera
+ traité avant <code><Directory
+ /var/web/dir/subdir></code>. Si plusieurs sections <directive
+ type="section" module="core">Directory</directive> 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 <directive
+ module="core">Include</directive> sont traitées comme si elles se
+ trouvaient réellement dans le fichier qui les inclut à la position de la
+ directive
+ <directive module="core">Include</directive>.</p>
+
+ <p>Les sections situées à l'intérieur de sections <directive type="section"
+ module="core">VirtualHost</directive>
+ sont appliquées <em>après</em> 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.</p>
+
+ <p>Quand la requête est servie par le module <module>mod_proxy</module>,
+ le conteneur <directive module="mod_proxy" type="section">Proxy</directive>
+ prend la place du conteneur <directive module="core"
+ type="section">Directory</directive> dans l'ordre de traitement.</p>
+
+ <p>Les sections situées plus loin dans le fichier de configuration prévalent
+ sur celles qui les précèdent.</p>
+
+<note><title>Note technique</title>
+ Une séquence
+ <code><Location></code>/<code><LocationMatch></code>
+ est réellement traitée juste avant la phase de traduction du nom
+ (où <code>Aliases</code> et <code>DocumentRoots</code>
+ 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.
+</note>
+
+<section id="merge-examples"><title>Quelques exemples</title>
+
+<p>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.</p>
+
+<example>
+<Location /><br />
+E<br />
+</Location><br />
+<br />
+<Files f.html><br />
+D<br />
+</Files><br />
+<br />
+<VirtualHost *><br />
+<Directory /a/b><br />
+B<br />
+</Directory><br />
+</VirtualHost><br />
+<br />
+<DirectoryMatch "^.*b$"><br />
+C<br />
+</DirectoryMatch><br />
+<br />
+<Directory /a/b><br />
+A<br />
+</Directory><br />
+<br />
+</example>
+
+<p>Pour un exemple plus concret, considérez ce qui suit. Sans tenir compte
+de toute restriction d'accès placée dans les sections <directive module="core"
+type="section">Directory</directive>, la section <directive
+module="core" type="section">Location</directive> 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 !</p>
+
+<example>
+<Location /><br />
+Order deny,allow<br />
+Allow from all<br />
+</Location><br />
+<br />:if expand("%") == ""|browse confirm w|else|confirm w|endif
+
+# Arrghs! Cette section <Directory> n'aura aucun effet<br />
+<Directory /><br />
+Order allow,deny<br />
+Allow from all<br />
+Deny from badguy.example.com<br />
+</Directory>
+</example>
+
+</section>
+
+</section>
+</manualpage>
--- /dev/null
+<?xml version="1.0" encoding="ISO-8859-1" ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+<!-- English Revision: 420990 -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<manualpage metafile="server-wide.xml.meta">
+
+ <title>Configuration à l'échelle du serveur</title>
+
+<summary>
+<p>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.</p>
+</summary>
+
+ <section id="identification">
+ <title>Identification du serveur</title>
+
+ <related>
+ <directivelist>
+ <directive module="core">ServerName</directive>
+ <directive module="core">ServerAdmin</directive>
+ <directive module="core">ServerSignature</directive>
+ <directive module="core">ServerTokens</directive>
+ <directive module="core">UseCanonicalName</directive>
+ <directive module="core">UseCanonicalPhysicalPort</directive>
+ </directivelist>
+ </related>
+
+ <p>Les directives <directive module="core">ServerAdmin</directive> et
+ <directive module="core">ServerTokens</directive> 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
+ <directive module="core">ServerTokens</directive> définit la valeur du
+ champ d'en-tête de la réponse du serveur HTTP.</p>
+
+ <p>Le serveur utilise les directives
+ <directive module="core">ServerName</directive>,
+ <directive module="core">UseCanonicalName</directive> et
+ <directive module="core">UseCanonicalPhysicalPort</directive> 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.</p>
+ </section>
+
+ <section id="locations">
+ <title>Localisation des fichiers</title>
+
+ <related>
+ <directivelist>
+ <directive module="mpm_common">CoreDumpDirectory</directive>
+ <directive module="core">DocumentRoot</directive>
+ <directive module="core">ErrorLog</directive>
+ <directive module="mpm_common">LockFile</directive>
+ <directive module="mpm_common">PidFile</directive>
+ <directive module="mpm_common">ScoreBoardFile</directive>
+ <directive module="core">ServerRoot</directive>
+ </directivelist>
+ </related>
+
+ <p>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
+ <directive module="core">ServerRoot</directive>. 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
+ <a href="misc/security_tips.html#serverroot">Conseils à propos
+ de la sécurité</a> pour plus de détails.</p>
+ </section>
+
+ <section id="resource">
+ <title>Limitation de l'utilisation des ressources</title>
+
+ <related>
+ <directivelist>
+ <directive module="core">LimitRequestBody</directive>
+ <directive module="core">LimitRequestFields</directive>
+ <directive module="core">LimitRequestFieldsize</directive>
+ <directive module="core">LimitRequestLine</directive>
+ <directive module="core">RLimitCPU</directive>
+ <directive module="core">RLimitMEM</directive>
+ <directive module="core">RLimitNPROC</directive>
+ <directive module="mpm_common">ThreadStackSize</directive>
+ </directivelist>
+ </related>
+
+ <p>Les directives <directive>LimitRequest</directive>* 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.</p>
+
+ <p>Les directives <directive>RLimit</directive>* 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).</p>
+
+ <p>La directive <directive module="mpm_common">ThreadStackSize</directive>
+ permet sur certaines plates-formes de contrôler la taille de la pile.</p>
+ </section>
+</manualpage>
--- /dev/null
+<?xml version="1.0" encoding="ISO-8859-1" ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+<!-- English Revision: 698389 -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<manualpage metafile="suexec.xml.meta">
+
+ <title>Support suEXEC</title>
+
+ <summary>
+ <p>La fonctionnalité <strong>suEXEC</strong> permet
+ l'exécution des programmes <strong>CGI</strong> et
+ <strong>SSI</strong> 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.</p>
+
+ <p>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
+ <em>setuid root</em> et les risques de sécurité qu'ils comportent,
+ nous vous recommandons vivement de ne pas tenter
+ d'utiliser suEXEC.</p>
+ </summary>
+
+<section id="before"><title>Avant de commencer</title>
+
+ <p>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.</p>
+
+ <p>Premièrement, vous devez utiliser un système d'exploitation
+ UNIX ou dérivé, capable d'effectuer des opérations
+ <strong>setuid</strong> et <strong>setgid</strong>. 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.</p>
+
+ <p>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
+ <strong>setuid/setgid</strong> et des différents effets qu'elles
+ peuvent produire sur votre système et son niveau de sécurité.</p>
+
+ <p>Troisièmement, vous devez utiliser une version
+ <strong>non modifiée</strong> 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
+ <strong>vivement</strong> 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.</p>
+
+ <p>Quatrièmement et dernièrement, le Groupe Apache a décidé de ne
+ <strong>PAS</strong> 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.</p>
+
+ <p>Vous êtes encore avec nous ? Oui ? Bien.
+ Alors nous pouvons continuer !</p>
+</section>
+
+<section id="model"><title>Modèle de sécurité de suEXEC</title>
+
+ <p>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.</p>
+
+ <p><strong>suEXEC</strong> 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.</p>
+
+ <p>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 :</p>
+
+ <ol>
+ <li>
+ <strong>L'utilisateur qui exécute le conteneur est-il un
+ utilisateur valide de ce système ?</strong>
+
+ <p class="indent">
+ Ceci permet de s'assurer que l'utilisateur qui exécute le
+ conteneur est vraiment un utilisateur appartenant au système.
+ </p>
+ </li>
+
+ <li>
+ <strong>Le conteneur a-t-il été appelé avec un nombre
+ d'arguments correct ?</strong>
+
+ <p class="indent">
+ 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.
+ </p>
+ </li>
+
+ <li>
+ <strong>Cet utilisateur valide est-il autorisé à exécuter le
+ conteneur ?</strong>
+
+ <p class="indent">
+ Cet utilisateur est-il celui autorisé à exécuter le
+ conteneur ? Un seul utilisateur (celui d'Apache) est
+ autorisé à exécuter ce programme.
+ </p>
+ </li>
+
+ <li>
+ <strong>Le chemin du programme CGI ou SSI cible est-il
+ non sûr ?</strong>
+
+ <p class="indent">
+ 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
+ <code>--with-suexec-docroot=<em>DIR</em></code> ci-dessous).
+ </p>
+ </li>
+
+ <li>
+ <strong>Le nom utilisateur cible est-il valide ?</strong>
+
+ <p class="indent">
+ L'utilisateur cible existe-t-il ?
+ </p>
+ </li>
+
+ <li>
+ <strong>Le nom du groupe cible est-il valide ?</strong>
+
+ <p class="indent">
+ Le groupe cible existe-t-il ?
+ </p>
+ </li>
+
+ <li>
+ <strong>L'utilisateur cible n'est-il <em>PAS</em>
+ superutilisateur ?</strong>
+
+
+ <p class="indent">
+ Actuellement, suEXEc ne permet pas à
+ <code><em>root</em></code> d'exécuter des programmes CGI/SSI.
+ </p>
+ </li>
+
+ <li>
+ <strong>Le numéro de l'identifiant de l'utilisateur cible
+ est-il <em>SUPERIEUR</em> au numéro d'identifiant
+ minimum ?</strong>
+
+ <p class="indent">
+ 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.
+ </p>
+ </li>
+
+ <li>
+ <strong>Le groupe cible n'est-il <em>PAS</em> le groupe
+ superutilisateur ?</strong>
+
+ <p class="indent">
+ Actuellement, suEXEC ne permet pas au groupe
+ <code><em>root</em></code> d'exécuter des programmes CGI/SSI.
+ </p>
+ </li>
+
+ <li>
+ <strong> Le numéro d'identifiant du groupe cible est-il
+ <em>SUPERIEUR</em> au numéro d'identifiant minimum ?</strong>
+
+ <p class="indent">
+ 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".
+ </p>
+ </li>
+
+ <li>
+ <strong>Le conteneur peut-il obtenir avec succès l'identité
+ des utilisateur et groupe cibles ?</strong>
+
+ <p class="indent">
+ 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.
+ </p>
+ </li>
+
+ <li>
+ <strong>Peut-on se positionner dans le répertoire dans dequel
+ sont situés les programmes CGI/SSI ?</strong>
+
+ <p class="indent">
+ 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.
+ </p>
+ </li>
+
+ <li>
+ <strong>Le répertoire est-il dans l'espace web
+ d'Apache ?</strong>
+
+ <p class="indent">
+ 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
+ <directive module="mod_userdir"
+ >UserDir</directive>, le répertoire demandé est-il dans
+ la hiérarchie du répertoire défini comme le répertoire
+ utilisateur de suEXEC (voir les
+ <a href="#install">options de configuration de suEXEC</a>) ?
+ </p>
+ </li>
+
+ <li>
+ <strong>L'écriture dans le répertoire est-elle interdite pour
+ un utilisateur autre que le propriétaire </strong>
+
+ <p class="indent">
+ Le répertoire ne doit pas être ouvert aux autres
+ utilisateurs ; seul l'utilisateur propriétaire doit pouvoir
+ modifier le contenu du répertoire.
+ </p>
+ </li>
+
+ <li>
+ <strong>Le programme CGI/SSI cible existe-t-il ?</strong>
+
+ <p class="indent">
+ S'il n'existe pas, il ne peut pas être exécuté.
+ </p>
+ </li>
+
+ <li>
+ <strong>Les utilisateurs autres que le propriétaire n'ont-ils
+ <em>PAS</em> de droits en écriture sur le programme
+ CGI/SSI ?</strong>
+
+ <p class="indent">
+ Les utilisateurs autres que le propriétaire ne doivent pas
+ pouvoir modifier le programme CGI/SSI.
+ </p>
+ </li>
+
+ <li>
+ <strong>Le programme CGI/SSI n'est-il <em>PAS</em> setuid ou
+ setgid ?</strong>
+
+ <p class="indent">
+ Les programmes cibles ne doivent pas pouvoir modifier à
+ nouveau les identifiants utilisateur/groupe.
+ </p>
+ </li>
+
+ <li>
+ <strong>Le couple utilisateur/groupe cible est-il le même que
+ celui du programme ?</strong>
+
+ <p class="indent">
+ L'utilisateur est-il le propriétaire du fichier ?
+ </p>
+ </li>
+
+ <li>
+ <strong>Peut-on nettoyer avec succès l'environnement des
+ processus afin de garantir la sûreté des opérations ?</strong>
+
+ <p class="indent">
+ 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).
+ </p>
+ </li>
+
+ <li>
+ <strong>Le conteneur peut-il avec succès se substituer au
+ programme CGI/SSI cible et s'exécuter ?</strong>
+
+ <p class="indent">
+ C'est là où l'exécution de suEXEC s'arrête et où commence
+ celle du programme CGI/ssi cible.
+ </p>
+ </li>
+ </ol>
+
+ <p>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é.</p>
+
+ <p>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 <a
+ href="#jabberwock">"Avis à la population !"</a> de ce document.</p>
+</section>
+
+<section id="install"><title>Configurer et installer suEXEC</title>
+
+ <p>C'est ici que nous entrons dans le vif du sujet.</p>
+
+ <p><strong>Options de configuration de suEXEC</strong><br />
+ </p>
+
+ <dl>
+ <dt><code>--enable-suexec</code></dt>
+
+ <dd>Cette option active la fonctionnalité suEXEC qui n'est
+ jamais installée ou activée par défaut. Au moins une option
+ <code>--with-suexec-xxxxx</code> doit accompagner l'option
+ <code>--enable-suexec</code> pour qu'APACI (l'utilitaire de
+ configuration de la compilation d'Apache) accepte votre demande
+ d'utilisation de la fonctionnalité suEXEC.</dd>
+
+ <dt><code>--with-suexec-bin=<em>PATH</em></code></dt>
+
+ <dd>Le chemin du binaire <code>suexec</code> 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.
+ <em>Par exemple</em>
+ <code>--with-suexec-bin=/usr/sbin/suexec</code></dd>
+
+ <dt><code>--with-suexec-caller=<em>UID</em></code></dt>
+
+ <dd>L'<a href="mod/mpm_common.html#user">utilisateur</a> sous
+ lequel Apache s'exécute habituellement. C'est le seul utilisateur
+ autorisé à utiliser suexec.</dd>
+
+ <dt><code>--with-suexec-userdir=<em>DIR</em></code></dt>
+
+ <dd>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 <directive module="mod_userdir">UserDir</directive>
+ "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 <directive
+ module="mod_userdir">UserDir</directive> contient une valeur
+ différente du répertoire home de l'utilisateur tel qu'il est
+ défini dans le fichier <code>passwd</code>. la valeur par défaut
+ est "<code>public_html</code>".<br />
+ Si vous avez plusieurs hôtes virtuels avec une directive
+ <directive module="mod_userdir">UserDir</directive> 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. <strong>Si tout ceci n'est pas défini
+ correctement, les requêtes CGI "~userdir" ne fonctionneront
+ pas !</strong></dd>
+
+ <dt><code>--with-suexec-docroot=<em>DIR</em></code></dt>
+
+ <dd>Cette option fonctionne comme la directive DocumentRoot pour
+ Apache. Il s'agit de la seule hiérarchie (en dehors des directives
+ <directive module="mod_userdir"
+ >UserDir</directive>) dans laquelle la fonctionnalité suEXEC
+ pourra être utilisée. La valeur par défaut est la valeur de
+ <code>--datadir</code> accompagnée du suffixe
+ "<code>/htdocs</code>" ;
+ <em>Par exemple</em>, si vous exécutez configure avec
+ "<code>--datadir=/home/apache</code>", la valeur
+ "<code>/home/apache/htdocs</code>" sera utilisée par défaut comme
+ racine des documents pour le conteneur suEXEC.</dd>
+
+ <dt><code>--with-suexec-uidmin=<em>UID</em></code></dt>
+
+ <dd>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.</dd>
+
+ <dt><code>--with-suexec-gidmin=<em>GID</em></code></dt>
+
+ <dd>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.</dd>
+
+ <dt><code>--with-suexec-logfile=<em>FILE</em></code></dt>
+
+ <dd>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 "<code>suexec_log</code>" et se trouve dans votre
+ répertoire standard des fichiers journaux défini par
+ <code>--logfiledir</code></dd>
+
+ <dt><code>--with-suexec-safepath=<em>PATH</em></code></dt>
+
+ <dd>Cette option permet de définir une variable d'environnement
+ PATH sûre à passer aux exécutables CGI. La valeur par défaut
+ est "<code>/usr/local/bin:/usr/bin:/bin</code>".</dd>
+ </dl>
+
+ <section>
+ <title>Compilation et installation du conteneur suEXEC</title>
+
+ <p>Si vous avez activé la fonctionnalité suEXEC à l'aide de
+ l'option <code>--enable-suexec</code>, le binaire
+ <code>suexec</code> sera automatiquement construit (en même temps
+ qu'Apache) lorsque vous exécuterez la commande
+ <code>make</code>.</p>
+
+ <p>Lorsque tous les composants auront été construits, vous pourrez
+ exécuter la commande <code>make install</code> afin de les
+ installer. Le binaire <code>suexec</code> sera installé dans le
+ répertoire défini à l'aide de l'option <code>--sbindir</code>. La
+ localisation par défaut est "/usr/local/apache2/bin/suexec".</p>
+ <p>Veuillez noter que vous aurez besoin des
+ <strong><em>privilèges root</em></strong> pour passer l'étape de
+ l'installation. Pour que le conteneur puisse changer
+ l'identifiant utilisateur, il doit avoir comme propriétaire
+ <code><em>root</em></code>, et les droits du fichier doivent
+ inclure le bit d'exécution setuserid.</p>
+ </section>
+
+ <section>
+ <title>>Mise en place de permissions pour
+ paranoïaque</title>
+ <p>Bien que le conteneur suEXEC vérifie que l'utilisateur qui
+ l'appelle correspond bien à l'utilisateur spécifié à l'aide de
+ l'option <code>--with-suexec-caller</code> du programme
+ <program>configure</program>, 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.</p>
+
+ <p>Si, par exemple, votre serveur web est configuré pour
+ s'exécuter en tant que :</p>
+
+<example>
+ User www<br />
+ Group webgroup<br />
+</example>
+
+ <p>et <program>suexec</program> se trouve à
+ "/usr/local/apache2/bin/suexec", vous devez exécuter les
+ commandes</p>
+
+<example>
+ chgrp webgroup /usr/local/apache2/bin/suexec<br />
+ chmod 4750 /usr/local/apache2/bin/suexec<br />
+</example>
+
+ <p>Ceci permet de s'assurer que seul le groupe sous lequel Apache
+ s'exécute (ici webgroup) puisse faire appel au conteneur
+ suEXEC.</p>
+ </section>
+</section>
+
+<section id="enable"><title>Activation et désactivation
+de suEXEC</title>
+
+ <p>Au démarrage, Apache vérifie la présence du fichier
+ <program>suexec</program> dans le répertoire défini par
+ l'option <code>--sbindir</code> 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 :</p>
+
+<example>
+ [notice] suEXEC mechanism enabled (wrapper: <var>/path/to/suexec</var>)
+</example>
+
+ <p>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 <em>setuid root</em>.</p>
+
+ <p>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. </p>
+ <p>Pour désactiver suEXEC, vous devez supprimer le fichier
+ <program>suexec</program>, puis arrêter et redémarrer
+ Apache.</p>
+</section>
+
+<section id="usage"><title>Utilisation de suEXEC</title>
+
+ <p>Les requêtes pour des programmes CGI ne feront appel au
+ conteneur suEXEC que si elles concernent un hôte virtuel
+ contenant une directive <directive
+ module="mod_suexec">SuexecUserGroup</directive>, ou si elles sont
+ traitées par <module>mod_userdir</module>.</p>
+
+ <p><strong>Hôtes virtuels :</strong><br /> Une des méthodes
+ d'utilisation du conteneur suEXEC consiste à insérer une
+ directive <directive
+ module="mod_suexec">SuexecUserGroup</directive> dans une section
+ <directive module="core">VirtualHost</directive>. 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 <em>User</em> et <em>Group</em> définis pour cette section
+ <directive
+ module="core" type="section">VirtualHost</directive>. Si cette
+ directive est absente de la section <directive module="core"
+ type="section">VirtualHost</directive>, l'utilisateur du
+ serveur principal sera pris par défaut</p>
+
+ <p><strong>Répertoires des utilisateurs :</strong><br /> Avec
+ cette méthode, les
+ requêtes traitées par <module>mod_userdir</module> 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 <a href="#model">vérifications de
+ sécurité</a> décrit plus haut. Voir aussi l'
+ <a href="#install">option de compilation</a>
+ <code>--with-suexec-userdir</code>.</p> </section>
+
+<section id="debug"><title>Débogage de suEXEC</title>
+
+ <p>Le conteneur suEXEC va écrire ses informations de journalisation
+ dans le fichier défini par l'option de compilation
+ <code>--with-suexec-logfile</code> 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.</p>
+
+</section>
+
+<section id="jabberwock"><title>Avis à la population !
+ Avertissements et exemples</title>
+
+ <p><strong>NOTE !</strong> Cette section est peut-être incomplète.
+ Pour en consulter la dernière révision, voir la version de la <a
+ href="http://httpd.apache.org/docs/&httpd.docs;/suexec.html"
+ >Documentation en ligne</a> du Groupe Apache.</p>
+
+ <p>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.</p>
+
+ <ul>
+ <li><strong>Points importants de suEXEC</strong></li>
+
+ <li>
+ Limitations concernant la hiérarchie.
+
+ <p class="indent">
+ 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).
+ </p>
+ </li>
+
+ <li>
+ La variable d'environnement PATH de suEXEC
+
+ <p class="indent">
+ Modifier cette variable peut s'avérer dangereux. Assurez-vous
+ que tout chemin que vous ajoutez à cette variable est un
+ répertoire <strong>de confiance</strong>. 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.
+ </p>
+ </li>
+
+ <li>
+ Modification de suEXEC
+
+ <p class="indent">
+ Encore une fois, ceci peut vous causer de
+ <strong>graves ennuis</strong> si vous vous y essayez sans
+ savoir ce que vous faites. Evitez de vous y risquer dans la
+ mesure du possible.
+ </p>
+ </li>
+ </ul>
+
+</section>
+
+</manualpage>
--- /dev/null
+<?xml version="1.0" encoding="ISO-8859-1" ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+<!-- English Revision: 420990 -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<manualpage metafile="upgrading.xml.meta">
+
+<title>Mise à jour vers 2.4 depuis 2.2</title>
+
+<summary>
+ <p>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 <a
+ href="new_features_2_4.html">Nouvelles fonctionnalités</a>, ou dans
+ le fichier <code>src/CHANGES</code>.</p>
+
+ <p>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
+ <a href="http://httpd.apache.org/docs/2.2/upgrading.html">document de mise
+ à jour de 2.0 vers 2.2.</a></p>
+
+</summary>
+<seealso><a href="new_features_2_4.html">Vue d'ensemble des nouvelles
+fonctionnalités de Apache 2.4</a></seealso>
+
+ <section id="compile-time">
+ <title>Modifications de la configuration au moment de la compilation</title>
+ <!-- <ul>
+ </ul> -->
+
+ </section>
+
+ <section id="run-time">
+ <title>Modifications de la configuration à l'exécution</title>
+
+ <!-- <ul>
+ </ul> -->
+ </ul>
+ </section>
+
+ <section id="misc">
+ <title>Changements divers</title>
+
+ </section>
+
+ <section id="third-party">
+ <title>Modules tiers</title>
+
+
+
+ </section>
+</manualpage>
--- /dev/null
+<?xml version="1.0" encoding="ISO-8859-1" ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+<!-- English Revision: 567425 -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<manualpage metafile="urlmapping.xml.meta">
+
+ <title> Mise en correspondance des URLs avec le système de fichiers</title>
+
+ <summary>
+ <p>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.</p>
+ </summary>
+
+<section id="related"><title>Modules et directives concernés</title>
+
+<related>
+<modulelist>
+<module>mod_alias</module>
+<module>mod_proxy</module>
+<module>mod_rewrite</module>
+<module>mod_userdir</module>
+<module>mod_speling</module>
+<module>mod_vhost_alias</module>
+</modulelist>
+<directivelist>
+<directive module="mod_alias">Alias</directive>
+<directive module="mod_alias">AliasMatch</directive>
+<directive module="mod_speling">CheckSpelling</directive>
+<directive module="core">DocumentRoot</directive>
+<directive module="core">ErrorDocument</directive>
+<directive module="core">Options</directive>
+<directive module="mod_proxy">ProxyPass</directive>
+<directive module="mod_proxy">ProxyPassReverse</directive>
+<directive module="mod_proxy">ProxyPassReverseCookieDomain</directive>
+<directive module="mod_proxy">ProxyPassReverseCookiePath</directive>
+<directive module="mod_alias">Redirect</directive>
+<directive module="mod_alias">RedirectMatch</directive>
+<directive module="mod_rewrite">RewriteCond</directive>
+<directive module="mod_rewrite">RewriteMatch</directive>
+<directive module="mod_alias">ScriptAlias</directive>
+<directive module="mod_alias">ScriptAliasMatch</directive>
+<directive module="mod_userdir">UserDir</directive>
+</directivelist>
+</related>
+</section>
+
+<section id="documentroot"><title>Racine des documents (DocumentRoot)</title>
+
+ <p>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
+ <directive module="core">DocumentRoot</directive> définie dans vos fichiers
+ de configuration.
+ Ainsi, les fichiers et répertoires
+ situés en dessous de <directive module="core">DocumentRoot</directive>
+ constituent l'arborescence de base des documents qui seront visibles
+ depuis le web.</p>
+
+ <p>Par exemple, si la directive
+ <directive module="core">DocumentRoot</directive> contient
+ <code>/var/www/html</code>, une requête pour
+ <code>http://www.example.com/fish/guppies.html</code> retournera le
+ fichier <code>/var/www/html/fish/guppies.html</code> au client.</p>
+
+ <p>Apache supporte aussi les <a href="vhosts/">Hôtes virtuels</a>,
+ ce qui lui permet de traiter des requêtes pour plusieurs hôtes.
+ Dans ce cas, un <directive module="core">DocumentRoot</directive>
+ différent peut être défini pour chaque hôte virtuel;
+ les directives fournies par le module
+ <module>mod_vhost_alias</module> 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.</p>
+
+ <p>La directive <directive module="core">DocumentRoot</directive> est
+ définie dans le fichier de configuration de votre serveur principal
+ (<code>httpd.conf</code>), mais peut aussi être redéfinie pour chaque
+ <a href="vhosts/">Hôte virtuel</a> supplémentaire que vous avez créé.</p>
+</section>
+
+<section id="outside"><title>Fichiers situés en dehors de
+l'arborescence DocumentRoot</title>
+
+ <p>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 <directive
+ module="core">DocumentRoot</directive>. 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 <directive
+ module="core">DocumentRoot</directive>. Pour des raisons de sécurité,
+ Apache ne suivra les liens symboliques que si les <directive
+ module="core">Options</directive> pour le répertoire concerné contiennent
+ <code>FollowSymLinks</code> ou <code>SymLinksIfOwnerMatch</code>.</p>
+
+ <p>Une autre méthode consiste à utiliser la directive <directive
+ module="mod_alias">Alias</directive> pour rattacher toute portion
+ du système de fichiers à l'arborescence du site web. Par exemple, avec</p>
+
+<example>Alias /docs /var/web</example>
+
+ <p>l'URL <code>http://www.example.com/docs/dir/file.html</code>
+ correspondra au fichier <code>/var/web/dir/file.html</code>. La
+ directive
+ <directive module="mod_alias">ScriptAlias</directive>
+ fonctionne de la même manière, excepté que tout contenu localisé dans le
+ chemin cible sera traité comme un script <glossary ref="cgi"
+ >CGI</glossary>.</p>
+
+ <p>Pour les situations qui nécessitent plus de flexibilité, vous disposez
+ des directives <directive module="mod_alias">AliasMatch</directive>
+ et <directive module="mod_alias">ScriptAliasMatch</directive>
+ qui permettent des substitutions et comparaisons puissantes basées
+ sur les <glossary ref="regex">expressions rationnelles</glossary>.
+ Par exemple,</p>
+
+<example>ScriptAliasMatch ^/~([a-zA-Z0-9]+)/cgi-bin/(.+)
+ /home/$1/cgi-bin/$2</example>
+
+ <p>fera correspondre une requête du style
+ <code>http://example.com/~user/cgi-bin/script.cgi</code> au chemin
+ <code>/home/user/cgi-bin/script.cgi</code>, et traitera le fichier résultant
+ comme un script CGI.</p>
+</section>
+
+<section id="user"><title>Répertoires des utilisateurs</title>
+
+ <p>Sur les systèmes Unix, on peut traditionnellement faire référence
+ au répertoire personnel d'un <em>utilisateur</em> particulier à l'aide de
+ l'expression <code>~user/</code>.
+ Le module <module>mod_userdir</module>
+ é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 :</p>
+
+<example>http://www.example.com/~user/file.html</example>
+
+ <p>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 <directive module="mod_userdir">UserDir</directive>
+ 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
+ <code>Userdir public_html</code>, l'URL ci-dessus correspondra à un fichier
+ dont le chemin sera du style
+ <code>/home/user/public_html/file.html</code> où
+ <code>/home/user/</code> est le répertoire home de l'utilisateur tel qu'il
+ est défini dans <code>/etc/passwd</code>.</p>
+
+ <p>La directive <code>Userdir</code> met à votre disposition de nombreuses
+ formes différentes pour les systèmes où <code>/etc/passwd</code> ne
+ spécifie pas la localisation du répertoire home.</p>
+
+ <p>Certains jugent le symbole "~" (dont le code sur le web est souvent
+ <code>%7e</code>) 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
+ <directive module="mod_alias">AliasMatch</directive>
+ pour obtenir l'effet désiré. Par exemple, pour faire correspondre
+ <code>http://www.example.com/upages/user/file.html</code> à
+ <code>/home/user/public_html/file.html</code>, utilisez la directive
+ <code>AliasMatch</code> suivante :</p>
+
+<example>AliasMatch ^/upages/([a-zA-Z0-9]+)/?(.*)
+ /home/$1/public_html/$2</example>
+</section>
+
+<section id="redirect"><title>Redirection d'URL</title>
+
+ <p>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 <em>redirection</em> et est implémenté par la
+ directive <directive module="mod_alias">Redirect</directive>.
+ Par exemple, si le contenu du répertoire <code>/foo/</code> sous
+ <directive module="core">DocumentRoot</directive> est déplacé vers le
+ nouveau répertoire <code>/bar/</code>, vous pouvez demander aux clients
+ de le requérir à sa nouvelle localisation comme suit :</p>
+
+<example>Redirect permanent /foo/ http://www.example.com/bar/</example>
+
+ <p>Ceci aura pour effet de rediriger tout chemin d'URL commençant par
+ <code>/foo/</code> vers le même chemin d'URL sur le serveur
+ <code>www.example.com</code> en remplaçant <code>/foo/</code> par
+ <code>/bar/</code>. Vous pouvez rediriger les clients non seulement sur le
+ serveur d'origine, mais aussi vers n'importe quel autre serveur.</p>
+
+ <p>Apache propose aussi la directive <directive
+ module="mod_alias">RedirectMatch</directive> 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 :</p>
+
+<example>RedirectMatch permanent ^/$
+ http://www.example.com/startpage.html</example>
+
+ <p>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 :</p>
+
+<example>RedirectMatch temp .*
+ http://othersite.example.com/startpage.html</example>
+</section>
+
+<section id="proxy"><title>Mandataire inverse (Reverse Proxy)</title>
+
+<p>Apache vous permet aussi de rapatrier des documents distants
+dans l'espace des URL du serveur local.
+Cette technique est appelée <em>mandataire inverse ou reverse
+proxying</em> 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.</p>
+
+<p>Dans l'exemple suivant, quand les clients demandent des documents situés
+dans le répertoire
+<code>/foo/</code>, le serveur rapatrie ces documents depuis le répertoire
+<code>/bar/</code> sur <code>internal.example.com</code>
+et les renvoie au client comme s'ils appartenaient au serveur local.</p>
+
+<example>
+ProxyPass /foo/ http://internal.example.com/bar/<br />
+ProxyPassReverse /foo/ http://internal.example.com/bar/
+ProxyPassReverseCookieDomain internal.example.com public.example.com
+ProxyPassReverseCookiePath /foo/ /bar/
+</example>
+
+<p>La directive <directive module="mod_proxy">ProxyPass</directive> configure
+le serveur pour rapatrier les documents appropriés, alors que la directive
+<directive module="mod_proxy">ProxyPassReverse</directive>
+réécrit les redirections provenant de
+<code>internal.example.com</code> de telle manière qu'elles ciblent le
+répertoire approprié sur le serveur local. De manière similaire, les directives
+<directive module="mod_proxy">ProxyPassReverseCookieDomain</directive>
+et <directive module="mod_proxy">ProxyPassReverseCookiePath</directive>
+réécrivent les cookies élaborés par le serveur d'arrière-plan.</p>
+<p>Il est important de noter cependant, que les liens situés dans les documents
+ne seront pas réécrits. Ainsi, tout lien absolu sur
+<code>internal.example.com</code> fera décrocher le client
+du serveur mandataire et effectuer sa requête directement sur
+<code>internal.example.com</code>. Un module tiers
+<a href="http://apache.webthing.com/mod_proxy_html/">mod_proxy_html</a>
+permet de réécrire les liens dans les documents HTML et XHTML.</p>
+</section>
+
+<section id="rewrite"><title>Moteur de réécriture</title>
+
+ <p>Le moteur de réécriture <module>mod_rewrite</module> 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
+ <a href="misc/rewriteguide.html">Guide de réécriture des URLs</a>.</p>
+</section>
+
+<section id="notfound"><title>Fichier non trouvé (File Not Found)</title>
+
+ <p>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
+ <a href="#redirect">redirection d'URL</a> 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.</p>
+
+ <p>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
+ <module>mod_speling</module> (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.</p>
+
+ <p>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.</p>
+
+ <p>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 <directive module="core">ErrorDocument</directive>
+ et peut être personnalisée de manière très flexible comme discuté dans le
+ document
+ <a href="custom-error.html">Réponses personnalisées aux erreurs</a>.</p>
+</section>
+
+</manualpage>
projects / apache / commitdiff