Date: Tue, 1 Mar 2005 15:57:21 +0000 (+0000) Subject: update transformation X-Git-Tag: 2.0.54~40 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=333b025942dd559fe091b15f98c8cef2055e7274;p=thirdparty%2Fapache%2Fhttpd.git update transformation git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x@155796 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/dns-caveats.html b/docs/manual/dns-caveats.html index 9996161f96f..8c9d7fda934 100644 --- a/docs/manual/dns-caveats.html +++ b/docs/manual/dns-caveats.html @@ -2,6 +2,10 @@ URI: dns-caveats.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 +URI: dns-caveats.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 + URI: dns-caveats.html.ja.euc-jp Content-Language: ja Content-type: text/html; charset=EUC-JP diff --git a/docs/manual/dns-caveats.html.en b/docs/manual/dns-caveats.html.en index 6e2bab0f548..8135a272fb8 100644 --- a/docs/manual/dns-caveats.html.en +++ b/docs/manual/dns-caveats.html.en @@ -19,6 +19,7 @@ Apache > HTTP Server > Documentation > Version 2.0

Issues Regarding DNS and Apache

Available Languages: en | + fr | ja | ko

@@ -231,6 +232,7 @@

Available Languages: en | + fr | ja | ko

diff --git a/docs/manual/dns-caveats.html.fr b/docs/manual/dns-caveats.html.fr new file mode 100644 index 00000000000..ec18ef3b4cc --- /dev/null +++ b/docs/manual/dns-caveats.html.fr @@ -0,0 +1,251 @@ + + + +Problèmes DNS avec Apache - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.0

Problèmes DNS avec Apache

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

+ +

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
Déni de Service
L'Adresse du "serveur principal"
Comment éviter ces problèmes
Appendice: Perspectives futures

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

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

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

DNS ¤È Apache ¤Ë¤Þ¤Ä¤ï¤ëÃí°Õ»ö¹à

Available Languages: en | + fr | ja | ko

@@ -235,6 +236,7 @@

Available Languages: en | + fr | ja | ko

DNS¿Í ¾ÆÆÄÄ¡¿Í °ü·ÃµÈ »çÇ×

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

@@ -215,6 +216,7 @@

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

diff --git a/docs/manual/dns-caveats.xml.meta b/docs/manual/dns-caveats.xml.meta index a218acd9dda..b8be6700620 100644 --- a/docs/manual/dns-caveats.xml.meta +++ b/docs/manual/dns-caveats.xml.meta @@ -7,6 +7,7 @@ en + fr ja ko diff --git a/docs/manual/dso.html b/docs/manual/dso.html index 3d86148e796..5ef3f256379 100644 --- a/docs/manual/dso.html +++ b/docs/manual/dso.html @@ -2,6 +2,10 @@ URI: dso.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 +URI: dso.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 + URI: dso.html.ja.euc-jp Content-Language: ja Content-type: text/html; charset=EUC-JP diff --git a/docs/manual/dso.html.en b/docs/manual/dso.html.en index 197f4ccddb4..21417c5cbff 100644 --- a/docs/manual/dso.html.en +++ b/docs/manual/dso.html.en @@ -19,6 +19,7 @@ Apache > HTTP Server > Documentation > Version 2.0

Dynamic Shared Object (DSO) Support

Available Languages: en | + fr | ja | ko

@@ -304,6 +305,7 @@ $ apxs -i -a -n foo mod_foo.la

Available Languages: en | + fr | ja | ko

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

+Apache > Serveur HTTP > Documentation > Version 2.0

Support des objets partagés dynamiques (DSO)

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

+ +

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
Résumé sur l'utilisation des DSO
Contexte
Avantages et Inconvénients

Implémentation

Modules Apparentés	Directives Apparentées
`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 :

+ +

+ 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 +
+
+ 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 +
+
+ Pour configurer Apache afin qu'il puisse accepter les modules DSO : + +
+$ ./configure --enable-so +$ make install +
+
+ 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 +
+

+ +

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().

+ +

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

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

Æ°Åª¶¦Í¥ª¥Ö¥¸¥§¥¯¥È (DSO) ¥µ¥Ý¡¼¥È

Available Languages: en | + fr | ja | ko

@@ -287,6 +288,7 @@ $ apxs -i -a -n foo mod_foo.la

Available Languages: en | + fr | ja | ko

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

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

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

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

diff --git a/docs/manual/dso.xml.meta b/docs/manual/dso.xml.meta index 47355afd332..ea39c2eef99 100644 --- a/docs/manual/dso.xml.meta +++ b/docs/manual/dso.xml.meta @@ -7,6 +7,7 @@ en + fr ja ko diff --git a/docs/manual/env.html b/docs/manual/env.html index 1bc45338241..5bc9a72f068 100644 --- a/docs/manual/env.html +++ b/docs/manual/env.html @@ -2,6 +2,10 @@ URI: env.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 +URI: env.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 + URI: env.html.ja.euc-jp Content-Language: ja Content-type: text/html; charset=EUC-JP diff --git a/docs/manual/env.html.en b/docs/manual/env.html.en index dc15411d450..f17560e5967 100644 --- a/docs/manual/env.html.en +++ b/docs/manual/env.html.en @@ -19,6 +19,7 @@ Apache > HTTP Server > Documentation > Version 2.0

Environment Variables in Apache

Available Languages: en | + fr | ja | ko

@@ -389,6 +390,7 @@ SetEnvIf Referer "^$" local_referal

Available Languages: en | + fr | ja | ko

diff --git a/docs/manual/env.html.fr b/docs/manual/env.html.fr new file mode 100644 index 00000000000..e50bf338dc9 --- /dev/null +++ b/docs/manual/env.html.fr @@ -0,0 +1,419 @@ + + + +Apache et les variables d'environnement - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.0

Apache et les variables d'environnement

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

+ +

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
Utilisation des variables d'environnement
Variables d'environnement spéciales
Exemples

Définir les variables d'environnement

Modules Apparentés	Directives Apparentées
`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

Modules Apparentés	Directives Apparentées
`mod_access` `mod_cgi` `mod_ext_filter` `mod_headers` `mod_include` `mod_log_config` `mod_rewrite`	`Allow` `CustomLog` `Deny` `ExtFilterDefine` `Header` `LogFormat` `RewriteCond` `RewriteRule`

+ + +

Réécriture d'URL

+ + +

+ + +

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.

+ + + +

+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 ».

+ +

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

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

Apache ¤Î´Ä¶ÊÑ¿ô

Available Languages: en | + fr | ja | ko

@@ -377,6 +378,7 @@ SetEnvIf Referer "^$" local_referal

Available Languages: en | + fr | ja | ko

¾ÆÆÄÄ¡ÀÇ È¯°æº¯¼ö

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

@@ -356,6 +357,7 @@ SetEnvIf Referer "^$" local_referal

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

diff --git a/docs/manual/env.xml.meta b/docs/manual/env.xml.meta index aad5235168f..5949842ac0f 100644 --- a/docs/manual/env.xml.meta +++ b/docs/manual/env.xml.meta @@ -7,6 +7,7 @@ en + fr ja ko diff --git a/docs/manual/filter.html b/docs/manual/filter.html index 4fd0ef54c80..11256b50b1f 100644 --- a/docs/manual/filter.html +++ b/docs/manual/filter.html @@ -6,6 +6,10 @@ URI: filter.html.es Content-Language: es Content-type: text/html; charset=ISO-8859-1 +URI: filter.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 + URI: filter.html.ja.euc-jp Content-Language: ja Content-type: text/html; charset=EUC-JP diff --git a/docs/manual/filter.html.en b/docs/manual/filter.html.en index 02df8187ae5..3d0d27a344a 100644 --- a/docs/manual/filter.html.en +++ b/docs/manual/filter.html.en @@ -20,6 +20,7 @@

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

@@ -71,6 +72,7 @@

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

diff --git a/docs/manual/filter.html.es b/docs/manual/filter.html.es index 4d374b85268..1326b19fb73 100644 --- a/docs/manual/filter.html.es +++ b/docs/manual/filter.html.es @@ -20,6 +20,7 @@

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

@@ -68,6 +69,7 @@

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

diff --git a/docs/manual/filter.html.fr b/docs/manual/filter.html.fr new file mode 100644 index 00000000000..553291464af --- /dev/null +++ b/docs/manual/filter.html.fr @@ -0,0 +1,87 @@ + + + +Filtres - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.0

Filtres

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

+ +

Ce document explique le fonctionnement des filtres avec Apache.

Filtres

+ +

Modules Apparentés	Directives Apparentées
`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.

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

+ \ No newline at end of file diff --git a/docs/manual/filter.html.ja.euc-jp b/docs/manual/filter.html.ja.euc-jp index 4dd84014625..882484a22f2 100644 --- a/docs/manual/filter.html.ja.euc-jp +++ b/docs/manual/filter.html.ja.euc-jp @@ -20,6 +20,7 @@

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

@@ -71,6 +72,7 @@

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

diff --git a/docs/manual/filter.html.ko.euc-kr b/docs/manual/filter.html.ko.euc-kr index 6fe82c79864..1dbdb54e4a5 100644 --- a/docs/manual/filter.html.ko.euc-kr +++ b/docs/manual/filter.html.ko.euc-kr @@ -20,6 +20,7 @@

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

@@ -69,6 +70,7 @@

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

diff --git a/docs/manual/filter.html.ru.koi8-r b/docs/manual/filter.html.ru.koi8-r index 880dfa9b62c..28da6017b78 100644 --- a/docs/manual/filter.html.ru.koi8-r +++ b/docs/manual/filter.html.ru.koi8-r @@ -20,6 +20,7 @@

äÏÓÔÕÐÎÙÅ ÑÚÙËÉ: en | es | + fr | ja | ko | ru

@@ -74,6 +75,7 @@

äÏÓÔÕÐÎÙÅ ÑÚÙËÉ: en | es | + fr | ja | ko | ru

diff --git a/docs/manual/filter.xml.meta b/docs/manual/filter.xml.meta index 02b489b626b..da6333da536 100644 --- a/docs/manual/filter.xml.meta +++ b/docs/manual/filter.xml.meta @@ -8,6 +8,7 @@ en es + fr ja ko ru diff --git a/docs/manual/handler.html b/docs/manual/handler.html index dafdeac0c4d..e41ed135e11 100644 --- a/docs/manual/handler.html +++ b/docs/manual/handler.html @@ -6,6 +6,10 @@ URI: handler.html.es Content-Language: es Content-type: text/html; charset=ISO-8859-1 +URI: handler.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 + URI: handler.html.ja.euc-jp Content-Language: ja Content-type: text/html; charset=EUC-JP diff --git a/docs/manual/handler.html.en b/docs/manual/handler.html.en index a6acfedeea7..b1ee787e2b7 100644 --- a/docs/manual/handler.html.en +++ b/docs/manual/handler.html.en @@ -20,6 +20,7 @@

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

@@ -146,6 +147,7 @@

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

diff --git a/docs/manual/handler.html.es b/docs/manual/handler.html.es index 4b2e75eab9f..63e5f4ef1a0 100644 --- a/docs/manual/handler.html.es +++ b/docs/manual/handler.html.es @@ -20,6 +20,7 @@

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

@@ -155,6 +156,7 @@

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

diff --git a/docs/manual/handler.html.fr b/docs/manual/handler.html.fr new file mode 100644 index 00000000000..d74606c219b --- /dev/null +++ b/docs/manual/handler.html.fr @@ -0,0 +1,166 @@ + + + +Utilisation des gestionnaires apache - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.0

Utilisation des gestionnaires apache

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

+ +

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

Qu'est ce qu'un Gestionnaire ?
Exemples
Note aux programmeurs

Qu'est ce qu'un Gestionnaire ?

Modules Apparentés	Directives Apparentées
`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.

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

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

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

@@ -150,6 +151,7 @@

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

diff --git a/docs/manual/handler.html.ko.euc-kr b/docs/manual/handler.html.ko.euc-kr index 4f498281217..9dbcbe353a4 100644 --- a/docs/manual/handler.html.ko.euc-kr +++ b/docs/manual/handler.html.ko.euc-kr @@ -20,6 +20,7 @@

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

@@ -140,6 +141,7 @@

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

diff --git a/docs/manual/handler.html.ru.koi8-r b/docs/manual/handler.html.ru.koi8-r index ceaacc9d584..701a048d563 100644 --- a/docs/manual/handler.html.ru.koi8-r +++ b/docs/manual/handler.html.ru.koi8-r @@ -20,6 +20,7 @@

äÏÓÔÕÐÎÙÅ ÑÚÙËÉ: en | es | + fr | ja | ko | ru

@@ -155,6 +156,7 @@

äÏÓÔÕÐÎÙÅ ÑÚÙËÉ: en | es | + fr | ja | ko | ru

diff --git a/docs/manual/handler.xml.meta b/docs/manual/handler.xml.meta index 6b8fa140375..481dd8bef8b 100644 --- a/docs/manual/handler.xml.meta +++ b/docs/manual/handler.xml.meta @@ -8,6 +8,7 @@ en es + fr ja ko ru

Issues Regarding DNS and Apache

Problèmes DNS avec Apache

DNS ¤È Apache ¤Ë¤Þ¤Ä¤ï¤ëÃí°Õ»ö¹à

DNS¿Í ¾ÆÆÄÄ¡¿Í °ü·ÃµÈ »çÇ×

Dynamic Shared Object (DSO) Support

Support des objets partagés dynamiques (DSO)

Æ°Åª¶¦Í­¥ª¥Ö¥¸¥§¥¯¥È (DSO) ¥µ¥Ý¡¼¥È

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

Environment Variables in Apache

Apache et les variables d'environnement

Apache ¤Î´Ä¶­ÊÑ¿ô

¾ÆÆÄÄ¡ÀÇ È¯°æº¯¼ö

Filtres

Utilisation des gestionnaires apache

Æ°Åª¶¦Í¥ª¥Ö¥¸¥§¥¯¥È (DSO) ¥µ¥Ý¡¼¥È

Apache ¤Î´Ä¶ÊÑ¿ô