<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
-<!-- English Revision: 587444:922236 (outdated) -->
+<!-- English Revision: 922236 -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<title>Adresse IP et port d'écoute</title>
<summary>
- <p>Configuration d'Apache pour l'écoute sur un port et une adresse IP spécifiques.</p>
+ <p>Configuration du serveur HTTP Apache (httpd) pour l'écoute
+ sur un port et une adresse IP spécifiques.</p>
</summary>
<seealso><a href="vhosts/">Hôtes virtuels</a></seealso>
</related>
- <p>Au démarrage d'Apache, un port et une adresse lui sont associés sur
+ <p>Au démarrage de httpd, un port et une adresse lui sont associés sur
l'hôte local et le serveur se met en attente de l'arrivée d'une requête.
Par défaut, le serveur écoute toutes les adresses de l'hôte local.
Cependant, on peut lui préciser des ports et des adresses spécifiques à écouter,
ou une combinaison des deux.
Tout ceci est souvent associé avec la fonctionnalité des hôtes virtuels
- qui détermine la manière dont Apache répond aux différents ports,
+ qui détermine la manière dont httpd répond aux différents ports,
noms d'hôtes et adresses IP.</p>
<p>La directive <directive module="mpm_common">Listen</directive>
<p>Un nombre croissant de plateformes implémentent IPv6, et
<glossary>APR</glossary> supporte IPv6 sur la plupart d'entre elles,
- ce qui permet à Apache d'allouer des points de connexion (sockets) IPv6
+ ce qui permet à httpd d'allouer des points de connexion (sockets) IPv6
et de traiter des requêtes envoyées sur IPv6.</p>
- <p>Les administrateurs d'Apache doivent se préoccuper de la possibilité
+ <p>Les administrateurs de httpd doivent se préoccuper de la possibilité
pour un point de connexion IPv6 de traiter à la fois des connexions IPv4
et des connexions IPv6.
Le traitement de connexions IPv4 avec un point de connexion IPv6 utilise
et OpenBSD, afin de respecter la politique de sécurité du système sur ces plateformes.
Sur les systèmes où ces adresses sont interdites par défaut, un
paramètre spécial du script <program>configure</program> permet de modifier
- ce comportement pour Apache.</p>
+ ce comportement pour httpd.</p>
<p>En revanche, sur certaines plateformes comme Linux et Tru64, la
<strong>seule</strong> manière de gérer à la fois IPv6 et IPv4 passe
- par l'utilisation d'adresses traduites. Si vous voulez qu'Apache gère
+ par l'utilisation d'adresses traduites. Si vous voulez que httpd gère
des connexions IPv4 et IPv6 avec un minimum de points de connexion,
ce qui nécessite l'utilisation d'adresses IPv6 traduites en IPv4,
utilisez l'option <code>--enable-v4-mapped</code> du script <program>
<p>L'option <code>--enable-v4-mapped</code> est utilisée par défaut sur
toutes les plateformes sauf FreeBSD, NetBSD, et OpenBSD;
- votre Apache a donc probablement été construit avec cette option.</p>
+ votre httpd a donc probablement été construit avec cette option.</p>
- <p>Si vous souhaitez qu'Apache ne gère que des connexions IPv4, sans se
+ <p>Si vous souhaitez que httpd ne gère que des connexions IPv4, sans se
soucier de ce que vos plateforme et APR supportent, spécifiez une adresse
IPv4 dans toutes les directives
<directive module="mpm_common">Listen</directive>, comme dans l'exemple
Listen 192.0.2.1:80
</example>
- <p>Si votre plateforme le supporte et si vous souhaitez qu'Apache gère
+ <p>Si votre plateforme le supporte et si vous souhaitez que httpd gère
des connexions IPv4 et IPv6 sur des points de connexion séparés
(c'est à dire désactiver la traduction des adresses IPv6 au format IPv4),
utilisez l'option <code>--disable-v4-mapped</code> du script
<?xml-stylesheet type="text/xsl" href="style/manual.fr.xsl"?>
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
-<!-- English Revision : 823563 -->
+<!-- English Revision : 922237 -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<module>mod_cache</module>, <module>mod_disk_cache</module>,
<module>mod_file_cache</module> et du programme <a
href="programs/htcacheclean.html">htcacheclean</a>.
- Il décrit l'utilisation des fonctionnalités de mise en cache d'Apache
+ Il décrit l'utilisation des fonctionnalités de mise en
+ cache du serveur HTTP Apache
pour accélérer les services web et proxy, tout en évitant les problèmes
courants et les erreurs de configuration.</p>
</summary>
possibilité de mise en cache d'URLs,
<module>mod_file_cache</module> fournit des méthodes pour la gestion
et l'édition de fichiers en mémoire afin de maintenir un cache de fichiers
- dans l'état où ils étaient la dernière fois qu'Apache a démarré.
+ dans l'état où ils étaient la dernière
+ fois qu'httpd a démarré.
En tant que tel, <module>mod_file_cache</module> a été conçu pour améliorer
le temps d'accès à des fichiers locaux statiques qui ne sont modifiés
que rarement.</p>
<p>Si l'URL ne se trouve pas dans le cache, <module>mod_cache</module>
va ajouter un <a href="filter.html">filtre</a> au traitement de la requête.
- Une fois le contenu localisé par Apache selon la conception courante, le
+ Une fois le contenu localisé par httpd selon la conception courante, le
filtre sera exécuté en même temps que le contenu sera servi.
S'il est déterminé que le contenu peut être mis en cache,
il sera sauvegardé dans le cache pour une utilisation future.</p>
<p>Lorsqu'un contenu est arrivé à expiration dans le cache et fait
l'objet d'une nouvelle demande d'accès, plutôt que traiter directement
- la requête originale, Apache préfère utiliser une
+ la requête originale, httpd préfère utiliser une
requête conditionnelle.</p>
<p>HTTP propose toute une panoplie d'en-têtes qui permettent à un client,
Pour ce qui est des fichiers
statiques, l'action type est un appel à <code>stat()</code> ou un appel
système similaire, pour déterminer si la taille du fichier ou sa date de
- modification ont changé. Ainsi, même si Apache met en cache le contenu
+ modification ont changé. Ainsi, même si httpd met en cache le contenu
local, un contenu arrivé à expiration pourra être servi plus rapidement
depuis le cache s'il n'a pas été modifié, parce que la lecture depuis le
cache est plus rapide que la lecture depuis le processus en arrière-plan
<section>
<title>Que peut-on mettre en cache ?</title>
- <p>Comme mentionné plus haut, les deux styles de mise en cache d'Apache
+ <p>Comme mentionné plus haut, les deux styles de mise en
+ cache de httpd
fonctionnent différemment; la mise en cache de
<module>mod_file_cache</module> conserve les contenus des fichiers
- tels qu'ils étaient au démarrage d'Apache. Quand une requête pour un
+ tels qu'ils étaient au démarrage de httpd. Quand une requête pour un
fichier mis en cache par ce module est envoyée, elle est interceptée
et le fichier mis en cache est servi.</p>
seront servies par le module de mise en cache sauf si ce dernier
détermine qu'un processus d'arrière-plan doit être appelé. La mise en
cache de ressources locales modifie considérablement le modèle de
- sécurité d'Apache.</p>
+ sécurité de httpd.</p>
<p>Comme le parcours de la hiérarchie d'un système de fichiers pour
examiner le contenu d'éventuels fichiers
<p>Etant donné que les requêtes des utilisateurs finaux peuvent être
servies depuis le cache, ce dernier est une cible potentielle pour ceux
qui veulent défigurer un contenu ou interférer avec lui. Il est important
- de garder à l'esprit que l'utilisateur sous lequel tourne Apache doit
+ de garder à l'esprit que l'utilisateur sous lequel tourne
+ httpd doit
toujours avoir l'accès en écriture dans le cache. Ceci est en contraste
total avec la recommandation usuelle d'interdire à l'utilisateur sous
lequel tourne Apache
<p>Cela représente un risque relativement élévé par rapport aux autres
types d'attaques qu'il est possible de mener sous l'utilisateur apache.
Si vous utilisez <module>mod_disk_cache</module>, vous devez garder ceci
- à l'esprit : effectuez toujours les mises à jour d'Apache quand des
+ à l'esprit : effectuez toujours les mises à jour de
+ httpdquand des
correctifs de sécurité sont annoncés et exécutez les processus CGI sous
un utilisateur autre qu'apache en utilisant
<a href="suexec.html">suEXEC</a> dans la mesure du possible.</p>
<section>
<title>Empoisonnement du cache (Cache Poisoning)</title>
- <p>Si vous utilisez Apache comme serveur mandataire avec mise en cache,
+ <p>Si vous utilisez httpd comme serveur mandataire avec mise en cache,
vous vous exposez aussi à un éventuel "Empoisonnement du
cache" (Cache poisoning). L'empoisonnement du cache est un terme général
pour désigner les attaques au cours desquelles l'attaquant fait en sorte
</p>
<p>Par exemple, si les serveur DNS qu'utilise votre système où tourne
- Apache sont vulnérables à l'empoisonnement du cache des DNS, un attaquant
- pourra contrôler vers où Apache se connecte lorsqu'il demande un contenu
+ httpd sont vulnérables à l'empoisonnement du cache des DNS, un attaquant
+ pourra contrôler vers où httpd se connecte lorsqu'il demande un contenu
depuis le serveur d'origine.
Un autre exemple est constitué par les attaques ainsi nommées
"Dissimulation de requêtes HTTP" (HTTP request-smuggling).</p>
</related>
<p>Le fait d'ouvrir un fichier peut en lui-même introduire un délai,
- en particulier dans les systèmes de fichiers répartis sur le réseau. Apache
+ en particulier dans les systèmes de fichiers répartis
+ sur le réseau. httpd
peut s'affranchir de ce délai en maintenant
un cache des descripteurs de fichiers
- ouverts pour ce qui concerne les fichiers souvent accédés. Apache propose
+ ouverts pour ce qui concerne les fichiers souvent
+ accédés. httpd propose
actuellement une implémentation de mise en cache de la
gestion de fichier.</p>
<section>
<title>Directive CacheFile</title>
- <p>La forme la plus élémentaire de mise en cache que propose Apache est
+ <p>La forme la plus élémentaire de mise en cache que
+ propose httpd est
fournie par le module <module>mod_file_cache</module>.
Plutôt que de mettre en cache le contenu des fichiers, ce cache maintient
une table des descripteurs de fichiers ouverts. Les fichiers à mettre en
<directive module="mod_file_cache">CacheFile</directive>.</p>
<p>La directive
- <directive module="mod_file_cache">CacheFile</directive> demande à Apache
+ <directive module="mod_file_cache">CacheFile</directive> demande
+ à httpd
d'ouvrir le fichier lors de son démarrage et de réutiliser le descripteur
de fichier élaboré à cette occasion pour tous les
accès ultérieurs à ce fichier.</p>
<p>Bien que l'utilisation de la directive
<directive module="mod_file_cache">CacheFile</directive>
n'entraîne pas la mise en cache du contenu du fichier, cela ne signifie
- pas qu'en cas de modification du fichier pendant l'exécution d'Apache,
+ pas qu'en cas de modification du fichier pendant
+ l'exécution de httpd,
ces changements seront pris en compte. Le fichier sera toujours servi
- dans l'état où il était quand Apache a démarré.</p>
+ dans l'état où il était quand httpd a démarré.</p>
- <p>Si le fichier est supprimé pendant l'exécution d'Apache, ce dernier
+ <p>Si le fichier est supprimé pendant l'exécution de
+ httpd, ce dernier
continuera à maintenir un descripteur de fichier ouvert et à servir le
- fichier dans l'état où il était quand Apache a démarré. Cela signifie
+ fichier dans l'état où il était quand httpd a démarré. Cela signifie
aussi habituellement que malgré le fait que le fichier ait été supprimé,
et ne soit
plus accessible par le système de fichiers, l'espace libéré ne sera
- restitué qu'à l'arrêt d'Apache quand le
+ restitué qu'à l'arrêt de httpd quand le
descripteur de fichier sera fermé.</p>
</section>
disponible. Comme nous le verrons plus loin, ce n'est pas un problème en
soi dans le cas de la mise en cache par l'intermédiaire du système
d'exploitation, mais si l'on utilise la mise en cache en mémoire propre à
- Apache, il faut prendre garde à ne pas allouer trop de mémoire au cache.
+ httpd, il faut prendre garde à ne pas allouer trop de mémoire au cache.
Sinon le système sera contraint d'utiliser le swap, ce qui dégradera
sensiblement les performances.</p>
être assuré qu'il y aura de plus en plus de contenus de fichiers stockés
dans ce cache. Ceci peut s'avérer une méthode de mise en cache en mémoire
très efficace, et ne nécessite aucune configuration supplémentaire
- d'Apache.</p>
+ de httpd.</p>
<p>De plus, comme le système d'exploitation sait si des fichiers
ont été
supprimés ou modifiés, il peut effacer automatiquement des contenus de
fichiers du cache lorsque cela s'avère nécessaire. Ceci constitue un gros
- avantage par rapport à la mise en cache en mémoire d'Apache qui n'a
+ avantage par rapport à la mise en cache en mémoire
+ de httpd qui n'a
aucune possibilité de savoir si un fichier a été modifié.</p>
</section>
<p>En dépit des performances et des avantages de la mise en cache
automatique par le système d'exploitation, la mise en cache en mémoire
- peut être effectuée plus efficacement par Apache dans certaines
+ peut être effectuée plus efficacement par httpd dans certaines
circonstances.</p>
<section>
<p>La directive <directive module="mod_file_cache">MMapFile</directive>
fournie par le module <module>mod_file_cache</module> vous permet de
- demander à Apache de charger un contenu de fichier statique en mémoire
- lors de son démarrage (à l'aide de l'appel système mmap). Apache
+ demander à httpd de charger un contenu de fichier statique en mémoire
+ lors de son démarrage (à l'aide de l'appel
+ système mmap). httpd
utilisera le contenu chargé en mémoire pour satisfaire ultérieurement
toutes les demandes d'accès à ce fichier.</p>
<p>Comme dans le cas de la directive
<directive module="mod_file_cache">CacheFile</directive>, toute
- modification du fichier ne sera plus prise en compte par Apache une fois
+ modification du fichier ne sera plus prise en compte par httpd une fois
ce dernier démarré.</p>
<p> La directive
<directive module="mod_file_cache">MMapFile</directive> ne gardant
pas la trace de la quantité de mémoire qu'elle alloue, vous devez prendre
- garde de ne pas en abuser. Chaque processus enfant d'Apache utilisant
+ garde de ne pas en abuser. Chaque processus enfant de httpd utilisant
sa propre réplique de la mémoire allouée, il est donc d'une importance
critique de s'assurer que les fichiers chargés ne sont pas d'une taille
trop importante afin d'épargner au système l'utilisation du swap.</p>
disponible.</p>
<p>Par contre l'utilitaire
- <a href="programs/htcacheclean.html">htcacheclean</a> fourni avec Apache
+ <a href="programs/htcacheclean.html">htcacheclean</a> fourni avec
+ httpd
vous permet, comme son nom l'indique, de nettoyer le cache périodiquement.
Déterminer la fréquence à laquelle lancer <a
href="programs/htcacheclean.html">htcacheclean</a> et la taille souhaitée
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
-<!-- English Revision : 558686 -->
+<!-- English Revision : 922267 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<title>Messages d'erreur personnalisés</title>
<summary>
- <p>Une fonctionnalité additionnelle permet aux webmasters de
- configurer la réponse d'Apache à certaines erreurs ou problèmes.</p>
-
- <p>Il est possible de définir des réponses personnalisables comme
- devant être activées lorsque le serveur détecte une erreur ou un
- problème.</p>
-
- <p>Si un script se crashe et provoque l'envoi d'une réponse "500
- Server Error", cette dernière peut être remplacée soit par un texte
- plus convivial, soit par une redirection vers une autre URL (locale
- ou externe).</p>
+ <p>Le serveur HTTP Apache fournit des messages d'erreur génériques
+ pour les codes de statut 4xx ou 5xx ; ces messages sont cependant
+ relativement austères, imprécis, et peuvent s'avérer intimidants
+ pour les visiteurs du site. Si vous le souhaitez, vous pouvez
+ afficher des messages d'erreur plus conviviaux, dans un langage
+ autre que l'anglais, ou même sous une forme plus en adéquation avec
+ le style de votre site.</p>
+
+ <p>Il est possible de définir des messages d'erreur personnalisés
+ pour chaque code de statut HTTP associé à une condition d'erreur -
+ c'est à dire tout code de statut 4xx ou 5xx.</p>
+
+ <p>De plus, il est possible de
+ personnaliser le message d'erreur en fonction d'un jeu de valeurs
+ fourni, en utilisant les <a href="howto/ssi.html">Inclusions Côté
+ Serveur (SSI)</a>. Un programme CGI ou un autre gestionnaire
+ dynamique (PHP, mod_perl, etc...) peut aussi utiliser ces variables
+ pour gérer les conditions d'erreur.</p>
+
+
</summary>
- <section id="behavior">
- <title>Comportement</title>
-
- <section>
- <title>Ancien comportement</title>
+ <section id="configuration"><title>Configuration</title>
- <p>httpd 1.3 de NCSA renvoyait d'antiques et obscurs messages
- d'erreur ou de problème qui la plupart du temps n'avaient aucune
- signification pour l'utilisateur, et ne permettaient pas de
- journaliser les symptomes qui les avaient causés.</p>
- </section>
+ <p>Les messages d'erreur personnalisés sont configurés via la
+ directive <directive module="core">ErrorDocument</directive>, qui
+ peut être utilisée dans un contexte global, serveur virtuel ou
+ répertoire. On peut utiliser cette directive dans les fichiers
+ .htaccess si <directive module="core">AllowOverride</directive> est
+ définie à FileInfo.</p>
- <section>
- <title>Nouveau comportement</title>
-
- <p>Il est possible de demander au serveur :</p>
+ <example>
+ ErrorDocument 500 "Désolé, notre script s'est crashé ; comme c'est
+ dommage !"<br />
+ ErrorDocument 500 /cgi-bin/crash-recover<br />
+ ErrorDocument 500 http://erreur.example.com/erreur_serveur.html<br />
+ ErrorDocument 404 /erreurs/non_trouve.html <br />
+ ErrorDocument 401 /inscription/comment_s_inscrire.html
+ </example>
+
+<p>La syntaxe de la directive <code>ErrorDocument</code> est :</p>
+ <example>
+ ErrorDocument <code_3_chiffres> <action>
+ </example>
+ <p>où action peut être :</p>
+ <ol>
+ <li>Le texte à afficher. Entourez le texte de guillemets (").</li>
+ <li>Une URL de redirection local.</li>
+ <li>Une URL de redirection externe.</li>
+ </ol>
- <ol>
- <li>d'afficher un autre texte à la place du message NCSA codé en
- dur, ou</li>
+ <p>Dans le cas d'une redirection vers une URL locale, des variables
+ d'environnement supplémentaires sont définies de façon à ce que la
+ réponse puisse être personnalisée par la suite. Elles ne sont pas
+ envoyées aux URLs externes.</p>
- <li>rediriger vers une URL locale, ou</li>
+ </section>
- <li>rediriger vers une URL externe.</li>
- </ol>
+ <section id="variables"><title>Variables disponibles</title>
<p>La redirection vers une autre URL peut être utile, mais
seulement s'il est possible de transmettre certaines informations
- qui pourront être utilisées pour expliquer et/ou journaliser
- l'erreur ou le problème plus clairement.</p>
+ qui pourront être utilisées pour expliquer ou journaliser
+ la condition d'erreur ou le problème plus clairement.</p>
- <p>Pour y parvenir, Apache va définir de nouvelles variables
- d'environnement de style CGI :</p>
+ <p>Pour y parvenir, lorsque la redirection d'erreur est envoyée,
+ des variables d'environnement supplémentaires sont définies à
+ partir des en-têtes de la requête originale en préfixant le nom
+ d'origine de l'en-tête par 'REDIRECT_', ce qui permet de fournir au
+ message d'erreur le contexte de la requête originelle.</p>
+
+ <p>Par exemple, en plus des variables d'environnement habituelles,
+ vous pouvez recevoir ce qui suit :</p>
+
<example>
- REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/x-xbitmap,
- image/jpeg<br />
- REDIRECT_HTTP_USER_AGENT=Mozilla/1.1b2 (X11; I; HP-UX A.09.05
- 9000/712)<br />
- REDIRECT_PATH=.:/bin:/usr/local/bin:/etc<br />
+ REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/jpeg, image/png<br />
+ REDIRECT_HTTP_USER_AGENT=Mozilla/5.0 Fedora/3.5.8-1.fc12 Firefox/3.5.8<br />
+ REDIRECT_PATH=.:/bin:/usr/local/bin:/sbin<br />
REDIRECT_QUERY_STRING=<br />
REDIRECT_REMOTE_ADDR=121.345.78.123<br />
- REDIRECT_REMOTE_HOST=ooh.ahhh.com<br />
- REDIRECT_SERVER_NAME=crash.bang.edu<br />
+ REDIRECT_REMOTE_HOST=client.example.com<br />
+ REDIRECT_SERVER_NAME=www.example.edu<br />
REDIRECT_SERVER_PORT=80<br />
- REDIRECT_SERVER_SOFTWARE=Apache/0.8.15<br />
+ REDIRECT_SERVER_SOFTWARE=Apache/2.2.15<br />
REDIRECT_URL=/cgi-bin/buggy.pl
</example>
- <p>Notez le préfixe <code>REDIRECT_</code>.</p>
+ <p>Les variables d'environnement <code>REDIRECT_</code> sont
+ créées à partir des variables d'environnement préexistantes à la
+ redirection qui sont préfixées par la chaîne <code>REDIRECT_</code> ;
+ par exemple, <code>HTTP_USER_AGENT</code> devient
+ <code>REDIRECT_HTTP_USER_AGENT</code>.</p>
+
+ <p><code>REDIRECT_URL</code>, <code>REDIRECT_STATUS</code>, et
+ <code>REDIRECT_QUERY_STRING</code> sont systématiquement définies,
+ les autres variables n'étant définies que si l'en-tête
+ correspondant existait avant la condition d'erreur.</p>
- <p>Au minimum <code>REDIRECT_URL</code> et
- <code>REDIRECT_QUERY_STRING</code> seront transmises à la nouvelle
- URL (en supposant qu'il s'agit d'une inclusion ou d'un script
- cgi). Les autres variables ne seront présentes que si elles
- existaient avant que l'erreur ou le problème ne survienne.
- <strong>Aucune</strong> d'entre elles ne sera définie si votre
+ <p><strong>Aucune</strong> d'entre elles ne sera définie si votre
directive <directive module="core">ErrorDocument</directive>
spécifie une redirection <em>externe</em> (toute URL commençant
par un protocole du style <code>http:</code>, même si elle fait
référence au même hôte que le serveur).</p>
- </section>
+
</section>
- <section id="configuration">
- <title>Configuration</title>
-
- <p>L'utilisation de la directive <directive
- module="core">ErrorDocument</directive> est activée pour les
- fichiers .htaccess si la directive <directive
- module="core">AllowOverride</directive> est positionnée dans cette
- optique.</p>
-
- <p>Voici quelques exemples...</p>
-
- <example>
- ErrorDocument 500 /cgi-bin/crash-recover <br />
- ErrorDocument 500 "Toutes nos excuses, notre script s'est crashé."
- <br />
- ErrorDocument 500 http://xxx/ <br />
- ErrorDocument 404 /Lame_excuses/not_found.html <br />
- ErrorDocument 401 /Subscription/how_to_subscribe.html
- </example>
-
- <p>La syntaxe est la suivante :</p>
-
- <example>
- ErrorDocument <code à 3 chiffres> <action>
- </example>
-
- <p>où action peut être :</p>
-
- <ol>
- <li>Un texte à afficher. Entourez-le de guillemets (").</li>
-
- <li>Une URL externe vers laquelle on sera redirigé.</li>
-
- <li>Une URL locale vers laquelle on sera redirigé.</li>
- </ol>
- </section>
+ <section id="custom"><title>Personnalisation des messages d'erreur</title>
- <section id="custom">
- <title>Messages d'erreur et de redirection personnalisés</title>
-
- <p>Lors d'une redirection d'URL, Apache a modifié son comportement
- et les scripts ou inclusions côté serveur disposent maintenant de
- variables d'environnement supplémentaires.</p>
-
- <section>
- <title>Ancien comportement</title>
-
- <p>Un script vers lequel une requête avait été redirigée
- avait accès aux variables CGI standards, sans indication sur
- l'origine de la redirection.</p>
- </section>
-
- <section>
- <title>Nouveau comportement</title>
-
- <p>Un nouveau jeu de variables d'environnement va être initialisé
- à des fins d'utilisation par un script vers lequel une requête
- aura été redirigée. Chaque nouvelle variable sera préfixée par
- <code>REDIRECT_</code>. Les variables d'environnement
- <code>REDIRECT_</code> sont créées à partir des variables
- d'environnement CGI existant avant la redirection, et renommées en
- leur ajoutant le préfixe <code>REDIRECT_</code> ; par exemple,
- <code>HTTP_USER_AGENT</code> devient
- <code>REDIRECT_HTTP_USER_AGENT</code>. En plus de ces nouvelles
- variables, Apache va définir <code>REDIRECT_URL</code> et
- <code>REDIRECT_STATUS</code> pour aider le script à remonter à
- l'origine de la redirection. L'URL originale et l'URL de
- redirection peuvent être enregistrées dans le journal des
- accès.</p>
+
+ <p>Si vous faites pointer votre directive
+ <code>ErrorDocument</code> vers certains gestionnaires
+ dynamiques comme les inclusions côté serveur, les scripts CGI ou
+ d'autres gestionnaires, vous pouvez utiliser les variables
+ d'environnement supplémentaires disponibles pour personnaliser
+ le message.</p>
+
<p>Si la directive ErrorDocument spécifie une redirection locale
vers un script CGI, ce dernier doit ajouter un en-tête
place.</p>
<p>Notez que si la réponse contient un en-tête
- <code>Location:</code>, le script <em>doit</em> émettre un en-tête
- <code>Status:</code> approprié (tel que
- <code>302 Found</code>) afin de provoquer une redirection au
- niveau du client. Dans le cas contraire, l'en-tête
- <code>Location:</code> risque de n'avoir aucun effet.</p>
- </section>
+ <code>Location:</code> (afin d'initier une redirection côté
+ client), le script <em>doit</em> émettre un en-tête approprié
+ (comme <code>302 Found</code>). Dans le cas contraire,
+ l'en-tête <code>Location:</code> ne produira aucun effet.</p>
</section>
+
+ <section id="multi-lang"><title>Messages d'erreur personnalisés
+ multilingues</title>
+
+ <p>Vous trouverez dans la distribution du serveur HTTP Apache un
+ répertoire contenant des messages d'erreur personnalisés traduits en
+ 16 langues différentes. Pour activer cette fonctionnalité, vous
+ pouvez aussi inclure un fichier de configuration qui se trouve dans
+ le répertoire de configuration <code>conf/extra</code>.</p>
+
+ <p>Dans le fichier de configuration de votre serveur, vous trouverez
+ un groupe de lignes du style :</p>
+
+ <example>
+ # Multi-language error messages<br />
+ #Include conf/extra/httpd-multilang-errordoc.conf
+ </example>
+
+ <p>Décommentez la ligne <code>Include</code> pour activer cette
+ fonctionnalité, et présenter des messages d'erreur dont le langage
+ sera négocié en fonction du langage préféré défini au niveau du
+ navigateur du client.</p>
+
+ <p>De plus, ces documents contiennent diverses variables
+ <code>REDIRECT_</code>, de façon à ce que l'utilisateur final
+ dispose d'informations supplémentaires à propos de ce qui a pu se
+ produire, et de ce qu'il est susceptible de faire maintenant.</p>
+
+ <p>Ces documents peuvent être personnalisés en fournissant autant
+ d'informations utiles que vous le souhaitez aux utilisateurs à
+ propos de votre site, et de ce qu'ils sont susceptibles d'y trouver.</p>
+
+ <p>Pour pouvoir utiliser cette fonctionnalité, vous devez activer
+ <module>mod_include</module> et <module>mod_negotiation</module>.</p>
+
+ </section>
+
+
</manualpage>
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
-<!-- English Revision: 883878:922232 (outdated) -->
+<!-- English Revision: 922232 -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<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
+ n'ajoute pas le slash final au nom du répertoire, httpd 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>
</related>
<p>Ces directives contrôlent la localisation des différents fichiers
- nécessaires au bon fonctionnement d'Apache. Quand le chemin utilisé ne
+ nécessaires au bon fonctionnement de httpd. 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
</related>
<p>Les directives <directive>LimitRequest</directive>* permettent de
- limiter la quantité de ressources consommées par Apache pour le traitement
+ limiter la quantité de ressources consommées par httpd 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 processus enfants httpd. 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>
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
-<!-- English Revision: 883878:922234 (outdated) -->
+<!-- English Revision: 922234 -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<title>Arrêt et redémarrage</title>
<summary>
- <p>Ce document couvre l'arrêt et le redémarrage d'Apache sur
+ <p>Ce document couvre l'arrêt et le redémarrage du
+ serveur HTTP Apache (httpd) sur
les systèmes Unix et similaires. Les utilisateurs de Windows NT, 2000
and XP doivent consulter
- <a href="platform/windows.html#winsvc">Exécuter Apache en tant que
+ <a href="platform/windows.html#winsvc">Exécuter httpd en tant que
service</a> et les utilisateurs de Windows 9x et ME doivent consulter
- <a href="platform/windows.html#wincons">Exécuter Apache comme une
+ <a href="platform/windows.html#wincons">Exécuter httpd comme une
application de type console</a> pour plus d'informations sur le contrôle
- d'Apache à partir de ces plateformes.</p>
+ de httpd à partir de ces plateformes.</p>
</summary>
<seealso><program>httpd</program></seealso>
<section id="introduction"><title>Introduction</title>
- <p>Afin d'arrêter ou redémarrer Apache, vous devez envoyer un signal aux
+ <p>Afin d'arrêter ou redémarrer le serveur HTTP Apache, vous devez envoyer un signal aux
processus <program>httpd</program> en cours d'exécution. Les signaux
peuvent être envoyés de deux manières. Tout d'abord, vous pouvez
utiliser la commande unix <code>kill</code>
<note><p>Le signal <code>graceful-stop</code> vous permet d'exécuter
simultanément plusieurs instances de <program>httpd</program>
avec des configurations identiques. Ceci s'avère une fonctionnalité
- puissante quand vous effectuez des mises à jour "en douceur" d'Apache;
- cependant, cela peut aussi causer des blocages fatals et des
+ puissante quand vous effectuez des mises à jour "en douceur"
+ de httpd ; cependant, cela peut aussi causer des blocages fatals et des
situations de compétition (race conditions)
avec certaines configurations.</p>
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
-<!-- English Revision: 698389:921866 (outdated) -->
+<!-- English Revision: 921866 -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<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>
+ vous devez tenir compte de certaines hypothèses concernant vous-même
+ et l'environnement dans lequel vous allez utiliser suexec.</p>
<p>Premièrement, vous devez utiliser un système d'exploitation
UNIX ou dérivé, capable d'effectuer des opérations
<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>
+ travail avec l'équipe de développement du serveur HTTP Apache afin
+ de pouvoir en discuter.</p>
- <p>Quatrièmement et dernièrement, le Groupe Apache a décidé de ne
+ <p>Quatrièmement et dernièrement, l'équipe de développement du
+ serveur HTTP 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
+ d'Apache httpd. 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.
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
+ ce processus minutieux que nous espérons réserver
l'installation de suEXEC aux administrateurs prudents et
suffisamment déterminés à vouloir l'utiliser.</p>
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.
+ (wrapper) setuid qui est appelé par le serveur HTTP 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
+ Lorsqu'il reçoit une telle requête, Apache httpd 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 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
+ d'arguments correct. Le serveur HTTP 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.
+ votre binaire Apache httpd.
</p>
</li>
<li>
<strong>Le répertoire est-il dans l'espace web
- d'Apache ?</strong>
+ de httpd ?</strong>
<p class="indent">
Si la requête concerne une portion de la racine du serveur,
<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
+ lequel httpd s'exécute habituellement. C'est le seul utilisateur
autorisé à utiliser suexec.</dd>
<dt><code>--with-suexec-userdir=<em>DIR</em></code></dt>
<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
+ httpd. 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
<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
+ que httpd) lorsque vous exécuterez la commande
<code>make</code>.</p>
<p>Lorsque tous les composants auront été construits, vous pourrez
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>
+ s'exécute httpd puisse faire appel à suEXEC.</p>
<p>Si, par exemple, votre serveur web est configuré pour
s'exécuter en tant que :</p>
chmod 4750 /usr/local/apache2/bin/suexec<br />
</example>
- <p>Ceci permet de s'assurer que seul le groupe sous lequel Apache
+ <p>Ceci permet de s'assurer que seul le groupe sous lequel httpd
s'exécute (ici webgroup) puisse faire appel au conteneur
suEXEC.</p>
</section>
<section id="enable"><title>Activation et désactivation
de suEXEC</title>
- <p>Au démarrage, Apache vérifie la présence du fichier
+ <p>Au démarrage, httpd 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
+ httpd trouve un conteneur suEXEC correctement configuré, il
enregistrera le message suivant dans le journal des erreurs :</p>
<example>
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
+ <p>Si le serveur HTTP 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
+ devez arrêter et redémarrer httpd. 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>
+ httpd.</p>
</section>
<section id="usage"><title>Utilisation de suEXEC</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>
+ >Documentation en ligne</a>.</p>
<p>Quelques points importants du conteneur peuvent
imposer des contraintes du point de vue de la configuration du
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
+ de httpd, afin de tirer parti de suEXEC dans le contexte des
hôtes virtuels (Exemple à venir).
</p>
</li>
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
-<!-- English Revision: 420990:922232 (outdated) -->
+<!-- English Revision: 922232 -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<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
+ utilisent déjà le serveur HTTP 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>
</summary>
<seealso><a href="new_features_2_4.html">Vue d'ensemble des nouvelles
-fonctionnalités de Apache 2.4</a></seealso>
+fonctionnalités du serveur HTTP Apache 2.4</a></seealso>
<section id="compile-time">
<title>Modifications de la configuration au moment de la compilation</title>
<!-- <ul>
</ul> -->
+ </ul>
</section>
<section id="misc">
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
-<!-- English Revision: 732819:921872 (outdated) -->
+<!-- English Revision: 921872 -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<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
+ <p>Ce document explique comment le serveur HTTP 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="documentroot"><title>Racine des documents (DocumentRoot)</title>
- <p>La méthode par défaut d'Apache pour déterminer quel fichier servir pour
+ <p>La méthode par défaut de httpd 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
<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>,
+ <p>
httpd 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;
<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
+ module="core">DocumentRoot</directive>. httpd 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
+ httpd 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>
<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
+ demandent à httpd 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
<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
+ <p>httpd 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
<section id="proxy"><title>Mandataire inverse (Reverse Proxy)</title>
-<p>Apache vous permet aussi de rapatrier des documents distants
+<p>httpd 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
<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
+ soit dans les liens HTML. httpd 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
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
+ <p>Si toutes les tentatives pour localiser le contenu
+ échouent, httpd
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>
projects / apache / commitdiff