From: André Malo Date: Tue, 1 Mar 2005 15:52:13 +0000 (+0000) Subject: Update French translation X-Git-Tag: 2.0.54~41 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=2dcee5ecf2d3890ff58572a2c1298736ded61474;p=thirdparty%2Fapache%2Fhttpd.git Update French translation * manual/dns-caveats.xml.fr * manual/handler.xml.fr * manual/dso.xml.fr * manual/filter.xml.fr * manual/env.xml.fr new translations Translated by: Vincent Deffontaines Reviewed by: alain B git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x@155795 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/dns-caveats.xml.fr b/docs/manual/dns-caveats.xml.fr new file mode 100644 index 00000000000..7eea0159585 --- /dev/null +++ b/docs/manual/dns-caveats.xml.fr @@ -0,0 +1,239 @@ + + + + + + + + + + + Problèmes DNS avec Apache + + +

L'ensemble de cette page pourrait se résumer à la phrase : ne + jamais configurer Apache de telle sorte qu'il s'appuie sur des + résolutions DNS pour parcourir ses fichiers de configuration. + Une telle configuration risque d'engendrer des problèmes de + fiabilité (le serveur peut ne pas démarrer), des attaques de type + déni et de vol de service (comme par exemple des utilisateurs volant + les hits d'autres utilisateurs).

+ + +
+ Un exemple simple + + + <VirtualHost www.abc.dom>
+ ServerAdmin webgirl@abc.dom
+ DocumentRoot /www/abc
+ </VirtualHost> + + +

Pour qu'Apache fonctionne correctement, il a absolument besoin + de deux informations pour chacun de ses serveurs virtuels : + ServerName ainsi qu'au moins une + adresse IP à laquelle le serveur s'attachera pour répondre. + L'exemple ci-dessus ne précise pas l'adresse IP, si bien qu'Apache doit + utiliser le DNS pour trouver l'adresse de www.abc.dom. + Si, pour une raison ou une autre, le DNS ne fonctionne pas au moment + où Apache lit ses fichiers de configuration, le serveur virtuel + ne sera pas configuré. Il sera incapable de répondre + aux requêtes. Jusqu'à la version 1.2, Apache refusait même de + démarrer dans ce cas de figure.

+ +

Prenons le cas où l'adresse de www.abc.dom est 10.0.0.1 + et considérons cet extrait de configuration :

+ + + <VirtualHost 10.0.0.1>
+ ServerAdmin webgirl@abc.dom
+ DocumentRoot /www/abc
+ </VirtualHost> + + +

Cette fois, Apache a besoin d'utiliser la résolution DNS + inversée pour déterminer le nom ServerName de ce + serveur virtuel. Si cette résolution n'aboutit pas, le serveur + virtuel sera partiellement mis hors service (jusqu'à la version + 1.2, Apache refusait même de démarrer dans ce cas de figure). Si + le serveur virtuel est un serveur basé sur un nom (name-based), + il sera totalement hors service, mais s'il s'agit d'un serveur + par IP (IP-based), il fonctionnera correctement. Cependant, dans + le cas où Apache doit générer une adresse complète URL en + s'appuyant sur le nom du serveur, il échouera à fournir une + adresse valide.

+ +

Voici un extrait de configuration qui résout ces deux problèmes :

+ + + <VirtualHost 10.0.0.1>
+ ServerName www.abc.dom
+ ServerAdmin webgirl@abc.dom
+ DocumentRoot /www/abc
+ </VirtualHost> + +
+ +
+ Déni de Service + +

Il existe (au moins) deux problèmes possibles de déni de service. + Les versions d'Apache antérieures à 1.2 ne démarreront pas si + l'une des deux requêtes DNS citées ci-dessus n'aboutissent pas pour + un de vos serveurs virtuels. Dans certains cas, les entrées DNS + sont hors de contrôle de l'administrateur Web ; par exemple si + abc.dom appartient à un de vos clients qui a la + maîtrise de son propre DNS, celui-ci peut empêcher votre serveur + Web (avant la version 1.2) de démarrer, simplement en effaçant + l'enregistrement www.abc.dom du DNS.

+ +

L'autre problème possible est bien plus pernicieux. Dans la + configuration suivante :

+ + + <VirtualHost www.abc.dom>
+   ServerAdmin webgirl@abc.dom
+   DocumentRoot /www/abc
+ </VirtualHost>
+
+ <VirtualHost www.def.dom>
+   ServerAdmin webguy@def.dom
+   DocumentRoot /www/def
+ </VirtualHost> + + +

Supposons que www.abc.dom ait l'adresse 10.0.0.1, + et que www.def.dom ait l'adresse 10.0.0.2. Supposons + également que def.com ait la main sur son DNS. + Cette configuration peut permettre à def.dom de + détourner vers son serveur tout le trafic destiné à + abc.dom. Pour ce faire, il doit simplement + positionner le champ DNS de www.def.dom sur 10.0.0.1, + et rien ne peut l'empêcher de faire, puisqu'il a la main sur + son DNS.

+ +

Les requêtes à destination de 10.0.0.1 (incluant celles dont + l'URL contient http://www.abc.com/tout_et_n_importe_quoi) + seront envoyées au serveur virtuel de def.dom. Une + bonne compréhension des mécanismes internes d'Apache concernant + la gestion des serveur virtuels est requise. + Ce document explique ce + fonctionnement.

+
+ +
+ L'Adresse du "serveur principal" + +

L'implémentation du support des serveur virtuels par nom depuis Apache 1.1 suppose + qu'Apache connaisse la ou les adresse(s) IP sur lesquelles le serveur + écoute. Pour déterminer cette adresse, Apache utilise soit la + directive globale ServerName + (si elle est présente), soit un appel à la fonction C + gethostname (cet appel renvoie le même résultat + que la commande "hostname" entrée sur une ligne de commande). + Une résolution DNS est alors effectuée sur l'adresse obtenue. + Pour l'instant, il n'existe aucun moyen de contourner cette + requête DNS.

+ +

Pour se prémunir du cas où cette résolution DNS échouerait à + cause de la défaillance du serveur DNS, le nom d'hôte peut être + ajouté dans /etc/hosts (il y est probablement déjà). + Assurez vous que votre machine est configurée pour lire ce fichier + /etc/hosts en cas de défaillance du serveur DNS. + Pour cela, selon votre système d'exploitation, il vous faudra configurer + /etc/resolv.conf ou /etc/nsswitch.conf.

+ +

Au cas où votre serveur n'a pas besoin de réaliser des requêtes + DNS pour d'autres raisons que de démarrer Apache, il est possible + que vous puissiez vous en sortir en positionnant la variable + d'environnement HOSTRESORDER sur "local". Ceci dépend + cependant de votre système d'exploitation et des librairies de + résolution DNS que vous utilisez. Ceci affecte également le + comportement des scripts CGIs, à moins que vous n'utilisiez + mod_env pour contrôler leur environnement. La + meilleure solution est de consulter les pages "man" ou les FAQs + spécifiques à votre système d'exploitation.

+
+ +
+ Comment éviter ces problèmes + +
    +
  • + spécifier les adresses IP dans les + VirtualHost +
    • + +
  • + spécifier les adresses IP au moyen de + Listen +
    • + +
  • + s'assurer que tous les serveurs virtuels spécifient explicitement + leur ServerName +
    • + +
  • créer un serveur virtuel <VirtualHost _default_:*> + qui ne sert aucune page
    • +
+
+ +
+ Appendice: Perspectives futures + +

Les problèmes liés au DNS sont très indésirables. À partir + d'Apache 1.2, nous avons travaillé à ce qu'Apache démarre même + dans le cas où les requêtes DNS échouent, mais ce n'est pas + forcément la meilleure des solutions. En tous cas, obliger + l'administrateur à spécifier explicitement des adresses IP est + également très indésirable sur le réseau Internet tel qu'il + existe actuellement, où le nombre d'adresses IP commence à manquer.

+ +

Une réponse possible au problème de vol de trafic décrit ci-avant + pourrait être de réaliser une résolution inverse DNS sur l'adresse IP + renvoyée par la première requête, et de comparer les deux noms + obtenus -- lorsqu'ils sont différents, le serveur virtuel serait + désactivé. Ceci suppose que la configuration pour la résolution + inverse DNS soit faite correctement (c'est une chose à laquelle + les administrateurs DNS commencent à s'habituer, en raison de + l'utilisation de plus en plus répandue des requêtes DNS + "double-reverse" par les serveurs FTP et les filtrages + "TCP wrappers").

+ +

Dans tous les cas de figures, il ne semble pas possible de + démarrer de façon fiable un serveur virtuel quand la requête + DNS a échoué, à moins de recourir à l'utilisation d'adresses + IP fixes. Des solutions partielles, telles que désactiver des + portions de la configuration selon les tâches attribuées au + serveur Web, risquent d'être pires que ne pas démarrer du tout.

+ +

Au fur et à mesure que HTTP/1.1 se répand, et que les navigateurs + et les serveurs mandataires envoient l'en-tête Host, + il devient possible d'éviter complètement l'utilisation de serveurs + virtuels par IP. Dans ce cas, les serveurs Web n'ont plus aucun + besoin de réaliser des requêtes DNS lors de leur démarrage. Au 1er + mars 1997, ces fonctionnalités ne sont pas suffisamment déployées pour + que des serveurs Web sensibles les mettent en oeuvre (NdT : cette + remarque est aujourd'hui complètement dépassée, HTTP/1.1 est + désormais supporté par l'immense majorité des navigateurs et + des serveurs mandataires).

+
+ diff --git a/docs/manual/dso.xml.fr b/docs/manual/dso.xml.fr new file mode 100644 index 00000000000..de0cc172b24 --- /dev/null +++ b/docs/manual/dso.xml.fr @@ -0,0 +1,314 @@ + + + + + + + + + + + Support des objets partagés dynamiques (DSO) + + +

Le serveur HTTP Apache est un programme modulaire permettant à + l'administrateur de choisir les fonctionnalités qu'il souhaite + activer, au moyen de modules. Les modules peuvent être intégrés + dans le programme binaire httpd au moment de la + compilation. Il est également possible de compiler à part des + modules en tant qu'objets dynamiques partagés (Dynamic Shared + Objects : DSOs) existant séparément du fichier binaire principal + httpd. Les modules DSO peuvent être compilés en même + temps que le serveur, ou après, au moyen de l'outil Apache pour + les extensions (apxs).

+ +

Ce document décrit les principes de fonctionnement des modules DSO, et + montre comment les utiliser.

+ + + +
Implémentation + + + +mod_so + + +LoadModule + + + +

Le support DSO servant à charger des modules Apache, est lui-même + codé dans un module, nommé mod_so, qui doit être + compilé dans le noyau d'Apache. Ce module, ainsi que le module + core, sont les deux seuls modules qui ne peuvent + être compilés séparément d'Apache. En pratique, tous les autres + modules d'Apache peuvent être compilés en tant que modules DSO, + en passant au script configure l'option + --enable-module=shared, comme précisé dans + la documentation d'installation. Après + qu'un module ait été compilé en DSO (nommé + mod_monmodule.so), il est possible d'utiliser la + directive de mod_so : LoadModule dans le fichier httpd.conf, + afin qu'Apache charge ledit module au démarrage ou redémarrage du + serveur.

+ +

Afin de simplifier la création de fichiers DSO pour les + modules Apache (et en particulier les modules tiers), un nouveau + programme de support a été ajouté : apxs (APache eXtenSion). Ce programme peut être + utilisé pour créer des modules DSO en se passant de + l'arborescence source d'Apache. L'idée en est simple : lors de + l'installation d'Apache, la commande make install + positionne les fichiers d'en-têtes C d'Apache, ainsi que les + options du compilateur et les options propres à la plate-forme + dans le programme apxs. Ceci permet à l'utilisateur + de compiler ses modules Apache, au moyen de apxs, + sans disposer de l'arborescence source d'Apache et sans devoir + manipuler les options de compilation ou les options propres à + sa plate-forme.

+
+ +
Résumé sur l'utilisation des DSO + +

Voici un résumé bref des fonctionnalités DSO d'Apache 2.0 :

+ +
    +
  1. + Pour compiler et installer un module Apache distribué + avec Apache, par exemple mod_foo.c, en tant + que DSO, sous le nom mod_foo.so : + + +$ ./configure --prefix=/path/to/install --enable-foo=shared
    +$ make install +     +
    2. + +
  2. + Pour compiler et installer un module Apache fourni par un + tiers, par exemple mod_foo.c, en tant que DSO, + sous le nom mod_foo.so : + + +$ ./configure --add-module=module_type:/chemin/vers/le/tiers/mod_foo.c --enable-foo=shared
    +$ make install +     +
    3. + +
  3. + Pour configurer Apache afin qu'il puisse accepter les modules DSO : + + +$ ./configure --enable-so
    +$ make install +     +
    4. + +
  4. + Pour compiler et installer un module Apache fourni par un + tiers, par exemple mod_foo.c, en tant que + DSO, et sans disposer de l'arborescence source d'Apache + (utilisation d'apxs) : + + +$ cd /chemin/vers/le/tiers
    +$ apxs -c mod_foo.c
    +$ apxs -i -a -n foo mod_foo.la +     +
    5. +
+ +

Dans tous les cas, une fois qu'un module a été compilé en tant + que DSO, vous devrez utiliser la directive + LoadModule dans le + fichier httpd.conf afin qu'Apache active le module.

+
+ +
Contexte + +

Sur les systèmes récents, dérivés d'Unix, il existe un procédé + élégant, habituellement appelé chargement dynamique d'objets + partagés DSO, permettant de compiler un morceau de code sous un + format spécial, et de pouvoir le charger en temps réel dans + l'espace d'adressage d'un programme exécutable.

+ +

Ce chargement peut être réalisé de deux manières : + automatiquement, grâce à un programme système nommé ld.so + lors du démarrage d'un exécutable, ou manuellement depuis un programme + en exécution via une interface programmée au moyen des appels + systèmes dlopen()/dlsym() du "chargeur" Unix

+ +

Dans le premier cas, il est courant d'appeler les DSO des + bibliothèques partagées ou des bibliothèques DSO ; + on les nomme libfoo.so ou libfoo.so.1.2. + Elles sont toutes placées dans un répertoire système (souvent + /usr/lib) et sont liées par les programmes exécutables + lors de la compilation de ces derniers, en précisant au moment de + la compilation l'option -lfoo à la commande de link + (linker command). Cette manière de procéder insère les références + des bibliothèques dans le coeur des programmes, afin qu'au moment + du démarrage du programme, le "chargeur" Unix puisse trouver + libfoo.so dans /usr/lib, ou bien dans + les chemins codés en dur au moyen de l'option de link -R, + ou dans un chemin configuré au moyen de la variable d'environnement + LD_LIBRARY_PATH. Tous les symboles non résolus présents + dans le programme sont alors résolus au moyen de DSO.

+ +

Les symboles propres au programme exécutable ne sont généralement + pas référencés par le DSO (puisque c'est une bibliothèque de code + générique), et donc aucune résolution ne doit être suivie au delà + de ce point. Le programme exécutable n'a pas de travail particulier + à faire pour résoudre les symboles des DSO, puisque c'est le + "chargeur" Unix qui s'occupe de cette tâche. (En réalité, le code + utilisé pour invoquer ld.so fait partie du code de + démarrage run-time, qui est lié à chaque programme exécutable + non statique). L'avantage du chargement dynamique des bibliothèques + de code générique est évident : le code n'est conservé qu'à un seul + endroit du disque, dans une bibliothèque système comme + libc.so, ce qui permet de gagner de l'espace disque + pour chaque programme.

+ +

Dans le second cas, les DSO sont appelés objets partagés + ou fichiers DSO et on peut leur attribuer une extension au + choix (bien que leur nom soit habituellement foo.so). + Ces fichiers résident normalement dans un répertoire propre au + programme qui les utilise, et ils ne sont pas liés de manière + automatique au programme qui les appelle. Celui-ci les charge en + temps réel lors de son exécution, au moyen de dlopen(). + À cet instant, aucune résolution des symboles du DSO n'est réalisée. + C'est le "chargeur" Unix qui réalise la tâche de résoudre les + symboles non résolus du DSO, à partir du jeu de symboles exportés + par le programme et ses bibliothèques DSO (en particulier, tous + les symboles de l'omniprésente libc.so). Ainsi, le DSO + gagne la connaissance des symboles du programme exécutable, comme + s'il lui avait été lié statiquement au départ.

+ +

Enfin, pour tirer parti de l'API DSO, l'exécutable doit résoudre + les symboles propres au DSO via dlsym(), pour les + utiliser plus tard dans les tables de répartition (NdT : "dispatch + tables"), etc. En d'autres termes, le programme exécutable + doit résoudre lui-même chaque symbole pour utiliser chacun d'entre + eux. L'avantage de ce mécanisme est que les parties optionnelles + d'un programme ne sont pas chargées (et donc, n'encombrent pas la + mémoire) avant que le programme n'en ait effectivement besoin. + Quand elles deviennent nécessaires, ces parties du programme peuvent + être chargées dynamiquement pour étendre les fonctionnalités du + programme.

+ +

Bien que ce fonctionnement de DSO puisse paraître simple à + comprendre, il existe au moins une difficulté d'implémentation : + permettre au DSO de résoudre les symboles du programme quand un DSO + est utilisé pour étendre un programme. Pourquoi cela ? Parce que la + "résolution à l'envers" des symboles DSO à partir des symboles du + programme exécutable est contraire au principe de conception des + bibliothèques (où, rappelons-le, la bibliothèque ne sait rien du + programme qui l'utilise) ; cette "résolution à l'envers" n'est pas + standardisée, et n'existe pas sur toutes les plates-formes. En + pratique, les symboles globaux d'un programme exécutable ne sont + que rarement réexportés vers un DSO, et donc ne sont pas accessibles. + Celui qui veut pouvoir étendre les fonctionnalités d'un programme + dynamiquement, lors de l'exécution, doit trouver un moyen de forcer + le programme de liaison à exporter tous les symboles globaux de ce + programme.

+ +

L'approche par bibliothèques partagées est de loin la plus courante + parce que c'est celle pour laquelle les mécanismes DSO ont été conçus ; + elle est donc utilisée par presque toutes les bibliothèques du système + d'exploitation. De l'autre coté, l'utilisation des objets partagés reste + une approche marginale.

+ +

Depuis 1998, seules quelques solutions logiciels existantes + utilisent le mécanisme des DSO pour étendre leurs fonctionnalités + en cours exécution : Perl 5 (via son "XS mechanism" et le module + DynaLoader), Netscape Server, etc. Depuis la version 1.3, + Apache a rejoint ce groupe, car Apache utilise une approche + modulaire pour étendre ses fonctionnalités, et utilise de manière + interne des mécanismes de répartition par liste pour lier des + modules externes à son noyau. Apache était vraiment prédestiné, + par concept, à utiliser les DSO pour charger ses modules en temps + réel.

+
+ +
Avantages et Inconvénients + +

Les possibilités des DSO décrites ci-avant présentent les + avantages suivants :

+ +
    +
  • Le paquetage du serveur est plus flexible lors de son exécution, + car les processus du serveur central peuvent être étendus pendant + son exécution, au moyen de la directive + LoadModule, dans + httpd.conf, plutôt que forcer les utilisateurs à + recompiler le serveur pour modifier ses fonctionnalités. Par + exemple, ce mode de fonctionnement permet de faire tourner + plusieurs instances du serveur (version standard & SSL + version, version minimaliste & étendue [mod_perl, PHP3], + etc.) au moyen d'une seule installation d'Apache.
    • + +
  • Il est très facile d'étendre les fonctionnalités du serveur + de base, même après son installation. Ceci est d'un grand secours + aux mainteneurs des paquets qui peuvent facilement créer des + paquets pour l'installation de base d'Apache et d'autres paquets + différents pour les extensions, comme PHP3, mod_perl, + mod_fastcgi, etc.
    • + +
  • Facilité de développement des modules Apache ; grâce aux outils + DSO/apxs, ce travail est faisable sans l'arborescence + source d'Apache, et ne nécessite qu'une commande apxs -i + suivi d'un apachectl restart pour ajouter au serveur + déjà en marche les fonctionnalités du module développé.
    • +
+ +

Les inconvénients liés à l'utilisation des DSO :

+ +
    +
  • Les mécanismes de DSO ne sont pas portables 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 en marche.
    • + +
  • Le serveur est à peu prêt 20% plus lent au démarrage, à cause de la + charge prise par le "chargeur" Unix de la résolution des symboles.
    • + +
  • Le serveur est à peu prêt 5% plus lent en fonctionnement sur + certaines plates-formes parce que le code indépendant de la + position ("position independent code" - PIC) requiert parfois des + tours de passe-passe en assembleur pour l'adressage relatif, ce qui + n'est pas toujours aussi rapide que l'adressage absolu.
    • + +
  • Les modules DSO ne pouvant pas être liés à d'autres bibliothèques + DSO (ld -lfoo) sur toutes les plates-formes (par + exemple, les plates-formes basées sur a.out ne le permettent pas, + alors que celles basées sur ELF le permettent), il n'est pas possible + d'utiliser les mécanismes de DSO pour tous les modules. En d'autres + termes, les modules compilés en tant que fichiers DSO sont limités + à l'utilisation des symboles exportés par le noyau d'Apache, par + la bibliothèque C (libc) et toute autre bibliothèque + dynamique ou statique utilisée par le noyau d'Apache, ou par des + archives de bibliothèques statiques (libfoo.a) qui + contiennent du code indépendant de la position. Les seuls moyens + d'utiliser du code à l'extérieur d'un fichier DSO sont, soit de + s'assurer que le noyau d'Apache contienne une référence vers ce + code, soit de charger ce code au moyen de dlopen().
    • +
+ +
+ diff --git a/docs/manual/env.xml.fr b/docs/manual/env.xml.fr new file mode 100644 index 00000000000..862b74b967a --- /dev/null +++ b/docs/manual/env.xml.fr @@ -0,0 +1,450 @@ + + + + + + + + + + + Apache et les variables d'environnement + + +

Le serveur HTTP Apache permet de conserver et d'utiliser + certaines informations dans des variables appelées variables + d'environnement. Ces informations peuvent servir à contrôler + divers paramètres tels que la journalisation ou le contrôle d'accès. + Ces variables sont également utilisées pour communiquer avec d'autres + programmes, comme les scripts CGI. Ce document traite des manières + de manipuler et de tirer parti de ces variables.

+ +

Bien qu'elles soient appelées variables d'environnement, + il ne s'agit pas de variables d'environnement contrôlées par le + système d'exploitation. Ces variables sont conservées, et manipulées + suivant des mécanismes internes à Apache. Elles sont transformées + en véritables variables d'environnement (au sens système) seulement + quand elles doivent être passées à des scripts CGI ou à des scripts + 'Server Side Includes'. Pour manipuler l'environnement du système + d'exploitation sur lequel tourne un serveur Apache, il suffit + d'utiliser les méthodes standard fournies par l'interpréteur de + commandes du système d'exploitation.

+ + +
+ Définir les variables d'environnement + + + mod_env + mod_rewrite + mod_setenvif + mod_unique_id + + + BrowserMatch + BrowserMatchNoCase + PassEnv + RewriteRule + SetEnv + SetEnvIf + SetEnvIfNoCase + UnsetEnv + + + +
+ Manipulations simples de l'environnement + +

La méthode la plus simple pour définir une variable + d'environnement dans Apache est d'utiliser la directive + SetEnv. Les variables + peuvent également être chargées depuis l'interpréteur de + commandes à partir duquel le serveur a été démarré, au moyen + de la directive PassEnv.

+ +
+
+ Paramétrage selon les requêtes + +

Dans un but de souplesse, les directives que mod_setenvif + permet d'utiliser sont ajustables en fonction de certaines + caractéristiques des requêtes parvenant au serveur. Par exemple, + il est possible de définir une variable seulement si la requête + provient d'un certain type de navigateur (User-Agent), ou bien + si un champ Referer bien précis est trouvé. Une souplesse encore + plus grande est offerte par la directive + RewriteRule du + module mod_rewrite qui accepte le paramètre [E=...] + pour définir des variables d'environnement.

+ +
+
+ Identifiants uniques + +

Enfin, la variable d'environnement UNIQUE_ID + est créée par mod_unique_id pour chaque requête, de manière à + être unique et donc représentative de chaque requête.

+ +
+
+ Variables CGI standard + +

En plus de toutes les variables d'environnement définies dans + la configuration d'Apache et celles du système d'exploitation, + les spécifications + CGI demandent que certaines variables d'environnement + contenant des informations propres à la requête soient toujours + passées aux scripts CGI et aux pages SSI.

+ +
+
+ Problèmes possibles + +
    +
  • Il n'est pas possible de remplacer la valeur des variables + CGI standard au moyen des directives qui manipulent les + variables d'environnement.
    • + +
  • Dans les cas où les scripts CGI sont lancés au moyen de + suexec, l'environnement est nettoyé et + les variables sont initialisées avec des valeurs sûres, + définies lors de la compilation de suexec.c.
    • + +
  • Pour des raisons d'interopérabilité, les noms des variables + d'environnement ne peuvent être constitués que de lettres, de + chiffres et du caractère de soulignement '_'. De plus, le + premier caractère du nom ne peut pas être un chiffre. Les + caractères en contradiction avec ces règles sont remplacés par + des caractères de soulignement avant que les variables ne + soient transmises aux scripts CGI ou aux pages SSI.
    • +
+
+
+
+ Utilisation des variables d'environnement + + + + mod_access + mod_cgi + mod_ext_filter + mod_headers + mod_include + mod_log_config + mod_rewrite + + + Allow + CustomLog + Deny + ExtFilterDefine + Header + LogFormat + RewriteCond + RewriteRule + + + +
+ Scripts CGI + +

Une des principales utilisations des variables d'environnement + est l'envoi d'informations aux scripts CGI. Comme précisé ci- + avant, l'environnement passé aux scripts CGI contient des + informations standard au sujet de la requête en plus de toutes + les variables initialisées au travers de la configuration + d'Apache. Pour plus de détails, consultez le + tutorial CGI.

+ +
+
+ Pages SSI + +

Les documents analysés par le serveur (documents SSI), gérés + par le filtre INCLUDES de mod_include, peuvent + demander l'affichage de variables d'environnement au moyen de + l'élément echo, et peuvent les utiliser pour + personnaliser des pages en fonctions de certaines caractéristiques + de la requête. Apache permet aussi l'utilisation de pages SSI avec + les variables d'environnement standard CGI comme discuté ci-avant. + Consultez le tutorial SSI + pour plus d'informations.

+ +
+
+ Contrôle d'accès + +

Les droits d'accès au serveur peuvent être contrôlés au moyen + de variables d'environnement en utilisant les directives + allow from env= et deny from env=. + Celles ci, utilisées avec SetEnvIf, permettent un contrôle d'accès au serveur + très souple en fonction de caractéristiques propres au client. Par + exemple, il est possible d'utiliser ces directives pour refuser + l'accès au serveur à certains navigateurs (User-Agent).

+ +
+
+ Journalisation sous certaines conditions + +

Les variables d'environnement peuvent être enregistrées dans + le journal des accès ('access log') au moyen de l'option + %e de LogFormat. De plus, la décision d'enregistrer ou + non certaines requêtes peut être prise en fonction des variables + d'environnement au moyen de la directive + CustomLog. Cette + méthode, utilisée avec la directive SetEnvIf, permet un contrôle très souple de + l'enregistrement des requêtes. Par exemple, il est possible de + ne pas garder de trace des requêtes demandant des noms de fichiers + se terminant par gif, ou de n'enregistrer que les + requêtes des clients situés hors du sous-réseau auquel appartient + le serveur.

+ +
+
+ Personnaliser les en-têtes des réponses HTTP + +

La directive Header + peut tirer parti de l'existence ou non d'une variable + d'environnement afin de choisir d'inclure certains en-têtes + HTTP dans la réponse retournée au client. Ceci permet, par + exemple, d'envoyer un certain en-tête de réponse seulement si un + en-tête similaire a été positionné dans la requête émanant du + client.

+ +
+ +
+ Activation des filtres externes + +

Il est possible d'utiliser une variable d'environnement pour + activer les filtres externes (gérés par + mod_ext_filter au moyen de la directive + ExtFilterDefine) + grâce aux options disableenv= et + enableenv=.

+
+ +
+ Réécriture d'URL + +

La forme %{ENV:...} de TestString, dans + la directive RewriteCond, permet au moteur de réécriture de + mod_rewrite d'utiliser les variables d'environnement pour + contrôler les réécritures. Notez que toutes les variables + internes à mod_rewrite, accessibles sans le préfixe + ENV:, ne sont pas des variables d'environnement + d'Apache. Elles sont uniquement propres à mod_rewrite et ne + peuvent pas être utilisées par d'autres modules.

+
+
+ +
+ Variables d'environnement spéciales + +

Certains problèmes liés à l'interopérabilité ont conduit à la + mise en place de mécanismes spéciaux, qui modifient le + fonctionnement d'Apache selon le type des clients auxquels il + répond. Afin de garantir la plus grande souplesse possible, ces + mécanismes sont contrôlés par des variables d'environnement + spéciales, telles que BrowserMatch, bien qu'on puisse également utiliser + SetEnv et + PassEnv par exemple.

+ +
+ downgrade-1.0 + +

Ceci oblige Apache à traiter la requête comme du HTTP/1.0 même + si elle a été construite sur une norme plus récente.

+ +
+
+ force-no-vary + +

Ceci provoque l'effacement de tous les champs Vary + de l'en-tête de réponse avant qu'il ne soit envoyé au client. + Certains clients interprètent mal ce champ (voir + les problèmes avec + certains clients), et initialiser cette variable peut + permettre de résoudre ce problème. Cette variable requiert + également l'utilisation de force-response-1.0.

+ +
+
+ force-response-1.0 + +

Ceci oblige Apache à n'envoyer que des réponses en HTTP/1.0 aux + clients réalisant une requête en HTTP/1.0. Cette fonction a été + implémentée au départ pour résoudre un problème avec les serveurs + mandataires d'AOL. Certains clients HTTP/1.0 réagissent mal quand + ils reçoivent une réponse en HTTP/1.1, ce qui peut poser des + problèmes d'interopérabilité avec eux.

+ +
+ +
+ gzip-only-text/html + +

Si cette variable est positionnée avec une valeur de "1", le + filtre de sortie DEFLATE du module mod_deflate + se retrouve désactivé pour les documents dont le type mime n'est + pas text/html.

+ +
+ +
no-gzip + +

Si cette variable est initialisée, le filtre DEFLATE + du module mod_deflate est totalement désactivé.

+ +
+ +
+ nokeepalive + +

Si cette variable est initialisée, les fonctions + KeepAlive sont désactivées.

+ +
+ +
prefer-language + +

Cette variable modifie le fonctionnement de + mod_negotiation. Si la variable contient un + marqueur de langue (comme en, ja ou + x-klingon), le module mod_negotiation + va tenter de fournir une réponse dans cette langue parmi les + variantes possibles. Si aucune de ces variantes n'existe, une + négociation normale aura + lieu.

+ +
+ +
+ redirect-carefully + +

Cette variable rend le serveur plus attentif quand il doit + envoyer une redirection au client. Cette variable est + habituellement utilisée quand un client a un problème connu + pour gérer les redirections. Cette variable a été implémentée + pour pallier à un problème du logiciel WebFolders de Microsoft + qui ne sait pas gérer correctement les redirections vers les + répertoires via les méthodes DAV.

+ +
+ +
+ suppress-error-charset + +

Existe depuis la version 2.0.40

+ +

Quand Apache envoie une redirection en réponse à une requête, la + réponse contient un message à afficher par le client, au cas où il + ne peut suivre automatiquement la redirection. Le fonctionnement + par défaut d'Apache est d'écrire ce texte avec le jeu de caractère + qu'il utilise, c'est à dire ISO-8859-1.

+

Cependant, si la redirection pointe vers une page présentant un jeu + de caractères différent, certains navigateurs buggés utilisent le jeu + de caractères du texte de la redirection, au lieu de celui de la page + qu'ils affichaient. De ce fait, un texte en grec serait mal affiché.

+

Si cette variable d'environnement est utilisée, Apache n'indiquera + pas le jeu de caractère dans le texte de la redirection, ce qui permet + à ces navigateurs d'afficher correctement la page de destination.

+ +
+ +
+ +
+ Exemples + +
+ Modifier le fonctionnement d'un protocole pour les clients + qui le gèrent mal + +

Il est conseillé de placer les lignes suivantes dans httpd.conf + afin de gérer des problèmes connus de certains clients.

+
+#
+# Les directives ci-après modifient le fonctionnement standard de HTTP.
+# La première directive désactive les fonctions keepalive pour les 
+# navigateurs disant s'appeler 'Netscape 2.x'
+# Il existe des problèmes connus avec ces navigateurs.
+# La deuxième directive gère Internet Explorer 4.0b2 de Microsoft qui
+# n'implémente pas correctement HTTP/1.1 et qui ne supporte pas les 
+# fonctions keepalive quand la réponse du serveur contient des codes 301 
+# ou 302 (redirections)
+#
+BrowserMatch "Mozilla/2" nokeepalive
+BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0
+
+#
+# Les directives ci-dessous désactivent HTTP/1.1 pour les navigateurs qui 
+# violent les spécifications HTTP/1.0, en ne sachant pas analyser des 
+# réponses basiques en HTTP/1.1.
+#
+BrowserMatch "RealPlayer 4\.0" force-response-1.0
+BrowserMatch "Java/1\.0" force-response-1.0
+BrowserMatch "JDK/1\.0" force-response-1.0
 + +
+
+ Ne pas enregistrer les requêtes pour des images dans le + journal des accès + +

Cet exemple montre comment ne pas enregistrer les requêtes à + destination d'images dans le journal des accès. Il est facile + de le modifier, pour limiter l'enregistrement à certains + répertoires, ou pour des requêtes venant de machines précises.

+ 
+SetEnvIf Request_URI \.gif image-request
+SetEnvIf Request_URI \.jpg image-request
+SetEnvIf Request_URI \.png image-request
+CustomLog logs/access_log common env=!image-request
 + +
+
+ Empêcher le « vol d'images » + +

Cet exemple montre comment empêcher le chargement d'images de + votre serveur depuis des pages qui ne sont pas hébergées sur + celui-ci. Cette configuration n'est pas conseillée, mais elle + peut être utile dans certaines circonstances. Il est supposé ici + que toutes les images sont stockées dans le répertoire + /web/images.

+ 
+SetEnvIf Referer "^http://www.example.com/" local_referal
+# Autorise les navigateurs qui n'envoient pas de champ Referer
+SetEnvIf Referer "^$" local_referal
+<Directory /web/images>
+   Order Deny,Allow
+   Deny from all
+   Allow from env=local_referal
+</Directory>
 + +

Pour plus d'informations sur cette technique, consultez le + tutorial ApacheToday « Keeping Your Images from Adorning Other Sites ».

+
+
+ diff --git a/docs/manual/filter.xml.fr b/docs/manual/filter.xml.fr new file mode 100644 index 00000000000..cdd46f8a253 --- /dev/null +++ b/docs/manual/filter.xml.fr @@ -0,0 +1,92 @@ + + + + + + + + + + + Filtres + + +

Ce document explique le fonctionnement des filtres avec Apache.

+ + +
+ Filtres + + + mod_deflate + mod_ext_filter + mod_include + + + AddInputFilter + AddOutputFilter + RemoveInputFilter + RemoveOutputFilter + ExtFilterDefine + ExtFilterOptions + SetInputFilter + SetOutputFilter + + + +

On appelle filtre un processus qui s'applique aux + données reçues ou envoyées par le serveur. Les filtres en + entrée (input filters) servent à filtrer les données envoyées + par les clients vers le serveur, tandis que les filtres en sortie + (output filters) traitent les données envoyées par le + serveur vers un client. Il est possible d'appliquer plusieurs + filtres sur un flux de données, et l'ordre de ces filtres est + configurable.

+ +

Apache utilise des filtres en interne pour gérer les « grosses » + requêtes ou les requêtes partielles (NdT sur "byte-range" : + requêtes portant seulement sur une partie d'un fichier, partie + spécifiée par un pointeur de départ, et un pointeur de fin). + Certains modules permettent en plus d'utiliser des filtres en + utilisant des directives de configuration. Les filtres sont utilisables + au moyen des directives + SetInputFilter, + SetOutputFilter, + AddInputFilter, + AddOutputFilter, + RemoveInputFilter, et + RemoveOutputFilter + .

+ +

Les filtres listés ci-après sont fournis dans le paquetage Apache et + sont utilisables par tout administrateur.

+ +
+
INCLUDES
+
Gestion des "Server-Side Includes" grâce au module + mod_include
+
DEFLATE
+
Compression des données avant leur envoi au client (filtre en + sortie) au moyen de mod_deflate +
+
+ +

Le module mod_ext_filter permet également + d'utiliser des programmes externes à Apache en tant que filtres.

+
+ diff --git a/docs/manual/handler.xml.fr b/docs/manual/handler.xml.fr new file mode 100644 index 00000000000..86e8c37e663 --- /dev/null +++ b/docs/manual/handler.xml.fr @@ -0,0 +1,167 @@ + + + + + + + + + + + Utilisation des gestionnaires apache + + +

Ce document décrit l'utilisation des gestionnaires (Handlers) Apache.

+ + +
+ Qu'est ce qu'un Gestionnaire ? + + + mod_actions + mod_asis + mod_cgi + mod_imap + mod_info + mod_mime + mod_negotiation + mod_status + + + Action + AddHandler + RemoveHandler + SetHandler + + + + +

Un Gestionnaire "handler" est une représentation interne à + Apache, qui décrit quoi faire quand un fichier est appelé. De + manière générale, les fichiers disposent d'un gestionnaire + implicite en fonction de leurs types. Le fonctionnement standard + est de simplement servir le fichier tel qu'il est demandé, mais + certains types de fichiers peuvent être gérés différemment.

+ +

Depuis Apache 1.1, il est possible de forcer l'utilisation + des gestionnaires. Ils peuvent être spécifiés pour des fichiers + présentant une certaine extension ou présents dans un certain + répertoire, et peuvent être utilisés indépendamment des types + des fichiers. Cette technique est avantageuse, d'abord parce + que plus élégante, mais aussi parce qu'on peut ainsi associer + un type de fichier et un gestionnaire à un + fichier. (Voir aussi : Fichiers à Extensions Multiples.)

+ +

Les gestionnaires peuvent être intégrés au serveur, ou inclus + dans un module, ou encore être configurés au moyen de la directive + Action. Les + gestionnaires fournis par défaut dans la distribution d'Apache + se présentent comme suit :

+ +
    +
  • default-handler : Envoie le fichier en + utilisant default_handler() qui est le + gestionnaire utilisé par défaut pour gérer les contenus + statiques. (noyau d'Apache)
    • + +
  • send-as-is : Envoie le fichier avec les + en-têtes HTTP tels quels. (mod_asis)
    • + +
  • cgi-script : Traite le fichier comme un + script CGI. (mod_cgi)
    • + +
  • imap-file : Traite le fichier comme un + ensemble de règles imagemap. NdT : ces fonctionnalités sont + désuètes, et sont réalisées à présent coté client. + (mod_imap)
    • + +
  • server-info : Envoie les informations + de configuration du serveur. (mod_info)
    • + +
  • server-status : Envoie les informations sur + le fonctionnement et la charge du serveur. + (mod_status)
    • + +
  • type-map : Traite le fichier comme un + fichier de types pour la négociation de contenu. + (mod_negotiation)
    • +
+
+
+ Exemples + +
+ Modifier un contenu statique au moyen d'un script CGI + +

Les directives ci-après provoquent l'exécution du script + CGI footer.pl à chaque requête de fichier + présentant l'extension html.

+ + + Action add-footer /cgi-bin/footer.pl
+ AddHandler add-footer .html + + +

Le travail du script CGI est alors d'envoyer le document + demandé (désigné au moyen de la variable d'environnement + PATH_TRANSLATED) en lui faisant subir au préalable + les transformations désirées.

+ +
+
+ Fichiers contenant des en-têtes HTTP + +

Les directives ci-après activent le gestionnaire + send-as-is, utilisé pour gérer les fichiers + qui contiennent leurs propres en-têtes HTTP. Tous les fichiers + contenus dans le répertoire /web/htdocs/asis/ + seront traités par le gestionnaire send-as-is, + sans tenir compte de leurs extensions.

+ + + <Directory /web/htdocs/asis>
+ SetHandler send-as-is
+ </Directory> + + +
+
+
+ Note aux programmeurs + +

L'API d'Apache a été modifiée + lors de l'implémentation des gestionnaires ; cette modification + peut se révéler intéressante. Un nouvel enregistrement a été ajouté + à la structure request_rec :

+ + + char *handler + + +

Pour qu'un module utilise un gestionnaire, il suffit d'affecter + r->handler avec le nom du gestionnaire avant + l'étape invoke_handler de la requête. Les + gestionnaires fonctionnent comme auparavant, bien que leurs noms + soient nécessaires au lieu d'un type de contenu. Bien qu'elle ne + soit pas nécessaire, la convention de nommage des gestionnaires + demande l'utilisation de mots séparés par des tirets, ne contenant + aucun slash, afin de ne pas interférer avec l'espace de nommage + des types de médias.

+
+