From: Rich Bowen Date: Wed, 15 Apr 2015 16:35:10 +0000 (+0000) Subject: Rebuilds Daniel's change to the order of directictives vs topics in X-Git-Tag: 2.4.13~234 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=9fed79814211668e00b799f50385a464a3bdbe6b;p=thirdparty%2Fapache%2Fhttpd.git Rebuilds Daniel's change to the order of directictives vs topics in manual docs git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1673855 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/core.html.de b/docs/manual/mod/core.html.de index 3c11383ebd3..84e65068c7b 100644 --- a/docs/manual/mod/core.html.de +++ b/docs/manual/mod/core.html.de @@ -120,7 +120,6 @@ Servers
  • <VirtualHost>
    • -
    top

    AcceptFilter-Direktive

    @@ -3602,6 +3601,7 @@ IP-Adressen angewendet werden kombiniert werden, wenn eine Anfrage empfangen wird +

    Verfügbare Sprachen:  de  | diff --git a/docs/manual/mod/core.html.en b/docs/manual/mod/core.html.en index 3ceaa2a7f8c..0b70b04729c 100644 --- a/docs/manual/mod/core.html.en +++ b/docs/manual/mod/core.html.en @@ -117,7 +117,6 @@ available

  • <VirtualHost>
    • -
    top

    AcceptFilter Directive

    @@ -4488,6 +4487,7 @@ hostname or IP address different sections are combined when a request is received +

    Available Languages:  de  | diff --git a/docs/manual/mod/core.html.es b/docs/manual/mod/core.html.es index 263fb40c8a0..c21c6ae5a1e 100644 --- a/docs/manual/mod/core.html.es +++ b/docs/manual/mod/core.html.es @@ -120,7 +120,6 @@

  • <VirtualHost>
    • -
    top

    AcceptFilter Directiva

    @@ -4299,6 +4298,7 @@ hostname or IP address different sections are combined when a request is received +

    Idiomas disponibles:  de  | diff --git a/docs/manual/mod/core.html.fr b/docs/manual/mod/core.html.fr index 73dd6f3de8a..ec62f5950f4 100644 --- a/docs/manual/mod/core.html.fr +++ b/docs/manual/mod/core.html.fr @@ -119,7 +119,6 @@ disponibles

  • <VirtualHost>
    • -
    top

    Directive AcceptFilter

    @@ -4799,6 +4798,7 @@ explication de la mani entre elles à la réception d'une requête +

    Langues Disponibles:  de  | diff --git a/docs/manual/mod/core.html.ja.utf8 b/docs/manual/mod/core.html.ja.utf8 index 20ea278f8e7..5f71de66897 100644 --- a/docs/manual/mod/core.html.ja.utf8 +++ b/docs/manual/mod/core.html.ja.utf8 @@ -120,7 +120,6 @@

  • <VirtualHost>
    • -
    top

    AcceptFilter ディレクティブ

    @@ -3517,6 +3516,7 @@ of a request or the last 63, assuming the request itself is greater than <Directory>, <Location>, <Files> セクションの動作法 +

    翻訳済み言語:  de  | diff --git a/docs/manual/mod/core.html.tr.utf8 b/docs/manual/mod/core.html.tr.utf8 index 9a2765d7dd9..541888f2add 100644 --- a/docs/manual/mod/core.html.tr.utf8 +++ b/docs/manual/mod/core.html.tr.utf8 @@ -118,7 +118,6 @@

  • <VirtualHost>
    • -
    top

    AcceptFilter Yönergesi

    @@ -4420,6 +4419,7 @@ gerçekleşmesi için sunucunun geçmesini bekleyeceği süre. çalışır? belgesine bakınız. +

    Mevcut Diller:  de  | diff --git a/docs/manual/mod/event.html.en b/docs/manual/mod/event.html.en index fcc6e95ec7e..6f25612acb7 100644 --- a/docs/manual/mod/event.html.en +++ b/docs/manual/mod/event.html.en @@ -80,6 +80,58 @@ of consuming threads only for connections with active processing

  • The worker MPM
    • top
    +

    AsyncRequestWorkerFactor Directive

    +
    + + + + + + + +
    Description:Limit concurrent connections per process
    Syntax:AsyncRequestWorkerFactor factor
    Default:2
    Context:server config
    Status:MPM
    Module:event
    Compatibility:Available in version 2.3.13 and later
    +

    The event MPM handles some connections in an asynchronous way, where + request worker threads are only allocated for short periods of time as + needed, and other connections with one request worker thread reserved per + connection. This can lead to situations where all workers are tied up and + no worker thread is available to handle new work on established async + connections.

    + +

    To mitigate this problem, the event MPM does two things: Firstly, it + limits the number of connections accepted per process, depending on the + number of idle request workers. Secondly, if all workers are busy, it will + close connections in keep-alive state even if the keep-alive timeout has + not expired. This allows the respective clients to reconnect to a + different process which may still have worker threads available.

    + +

    This directive can be used to fine-tune the per-process connection + limit. A process will only accept new connections if the current number of + connections (not counting connections in the "closing" state) is lower + than:

    + +

    + ThreadsPerChild + + (AsyncRequestWorkerFactor * + number of idle workers) +

    + +

    This means the absolute maximum numbers of concurrent connections is:

    + +

    + (AsyncRequestWorkerFactor + 1) * + MaxRequestWorkers +

    + +

    MaxRequestWorkers was called + MaxClients prior to version 2.3.13. The above value + shows that the old name did not accurately describe its meaning for the event MPM.

    + +

    AsyncRequestWorkerFactor can take non-integer + arguments, e.g "1.5".

    + + +
    +
    top

    How it Works

    This MPM tries to fix the 'keep alive problem' in HTTP. After a client @@ -145,58 +197,6 @@ of consuming threads only for connections with active processing with support for EPoll. -

    -
    top
    -

    AsyncRequestWorkerFactor Directive

    - - - - - - - - -
    Description:Limit concurrent connections per process
    Syntax:AsyncRequestWorkerFactor factor
    Default:2
    Context:server config
    Status:MPM
    Module:event
    Compatibility:Available in version 2.3.13 and later
    -

    The event MPM handles some connections in an asynchronous way, where - request worker threads are only allocated for short periods of time as - needed, and other connections with one request worker thread reserved per - connection. This can lead to situations where all workers are tied up and - no worker thread is available to handle new work on established async - connections.

    - -

    To mitigate this problem, the event MPM does two things: Firstly, it - limits the number of connections accepted per process, depending on the - number of idle request workers. Secondly, if all workers are busy, it will - close connections in keep-alive state even if the keep-alive timeout has - not expired. This allows the respective clients to reconnect to a - different process which may still have worker threads available.

    - -

    This directive can be used to fine-tune the per-process connection - limit. A process will only accept new connections if the current number of - connections (not counting connections in the "closing" state) is lower - than:

    - -

    - ThreadsPerChild + - (AsyncRequestWorkerFactor * - number of idle workers) -

    - -

    This means the absolute maximum numbers of concurrent connections is:

    - -

    - (AsyncRequestWorkerFactor + 1) * - MaxRequestWorkers -

    - -

    MaxRequestWorkers was called - MaxClients prior to version 2.3.13. The above value - shows that the old name did not accurately describe its meaning for the event MPM.

    - -

    AsyncRequestWorkerFactor can take non-integer - arguments, e.g "1.5".

    - -
    diff --git a/docs/manual/mod/event.html.fr b/docs/manual/mod/event.html.fr index 87d19b8b3db..3fae687135f 100644 --- a/docs/manual/mod/event.html.fr +++ b/docs/manual/mod/event.html.fr @@ -82,6 +82,64 @@ mobiliser des threads que pour les connexions en cours de traitement
  • Le MPM worker
    • top
    +

    Directive AsyncRequestWorkerFactor

    + + + + + + + + +
    Description:Limite le nombre de connexions simultanées par thread
    Syntaxe:AsyncRequestWorkerFactor facteur
    Défaut:2
    Contexte:configuration du serveur
    Statut:MPM
    Module:event
    Compatibilité:Disponible depuis la version 2.3.13
    +

    Le MPM event gère certaines connexions de manière asynchrone ; + dans ce cas, les threads traitant la requête sont alloués selon les + besoins et pour de courtes périodes. Dans les autres cas, un + thread est réservé par + connexion. Ceci peut conduire à des situations où tous les threads + sont saturés et où aucun thread n'est capable d'effectuer de + nouvelles tâches pour les connexions asynchrones établies.

    + +

    Pour minimiser les effets de ce problème, le MPM event utilise + deux méthodes : tout d'abord, il limite le nombre de connexions + simultanées par thread en fonction du nombre de processus + inactifs. Ensuite, si tous les processus sont occupés, il ferme des + connexions permanentes, même si la limite de durée de la connexion + n'a pas été atteinte. Ceci autorise les clients concernés à se + reconnecter à un autre processus possèdant encore des threads + disponibles.

    + +

    Cette directive permet de personnaliser finement la limite du + nombre de connexions par thread. Un processus n'acceptera de + nouvelles connexions que si le nombre actuel de connexions (sans + compter les connexions à l'état "closing") est + inférieur à :

    + +

    + ThreadsPerChild + + (AsyncRequestWorkerFactor * + nombre de threads inactifs) +

    + +

    En d'autres termes, le nombre maximum de connexions simultanées + sera :

    + +

    + (AsyncRequestWorkerFactor + 1) * + MaxRequestWorkers +

    + +

    La directive MaxRequestWorkers se nommait + MaxClients avant la version 2.3.13. La valeur + ci-dessus montre que cet ancien nom ne correspondait pas à sa + signification exacte pour le MPM event.

    + +

    La directive AsyncRequestWorkerFactor + accepte des valeurs d'argument de type non entier, comme "1.5".

    + + +
    +
    top

    Comment tout cela fonctionne

    Ce MPM essaie de résoudre le 'problème keep alive' de HTTP. @@ -159,64 +217,6 @@ mobiliser des threads que pour les connexions en cours de traitement avec le support pour EPoll. -

    -
    top
    -

    Directive AsyncRequestWorkerFactor

    - - - - - - - - -
    Description:Limite le nombre de connexions simultanées par thread
    Syntaxe:AsyncRequestWorkerFactor facteur
    Défaut:2
    Contexte:configuration du serveur
    Statut:MPM
    Module:event
    Compatibilité:Disponible depuis la version 2.3.13
    -

    Le MPM event gère certaines connexions de manière asynchrone ; - dans ce cas, les threads traitant la requête sont alloués selon les - besoins et pour de courtes périodes. Dans les autres cas, un - thread est réservé par - connexion. Ceci peut conduire à des situations où tous les threads - sont saturés et où aucun thread n'est capable d'effectuer de - nouvelles tâches pour les connexions asynchrones établies.

    - -

    Pour minimiser les effets de ce problème, le MPM event utilise - deux méthodes : tout d'abord, il limite le nombre de connexions - simultanées par thread en fonction du nombre de processus - inactifs. Ensuite, si tous les processus sont occupés, il ferme des - connexions permanentes, même si la limite de durée de la connexion - n'a pas été atteinte. Ceci autorise les clients concernés à se - reconnecter à un autre processus possèdant encore des threads - disponibles.

    - -

    Cette directive permet de personnaliser finement la limite du - nombre de connexions par thread. Un processus n'acceptera de - nouvelles connexions que si le nombre actuel de connexions (sans - compter les connexions à l'état "closing") est - inférieur à :

    - -

    - ThreadsPerChild + - (AsyncRequestWorkerFactor * - nombre de threads inactifs) -

    - -

    En d'autres termes, le nombre maximum de connexions simultanées - sera :

    - -

    - (AsyncRequestWorkerFactor + 1) * - MaxRequestWorkers -

    - -

    La directive MaxRequestWorkers se nommait - MaxClients avant la version 2.3.13. La valeur - ci-dessus montre que cet ancien nom ne correspondait pas à sa - signification exacte pour le MPM event.

    - -

    La directive AsyncRequestWorkerFactor - accepte des valeurs d'argument de type non entier, comme "1.5".

    - -
    diff --git a/docs/manual/mod/mod_access_compat.html.en b/docs/manual/mod/mod_access_compat.html.en index 3edb3606784..405b2dcbdd7 100644 --- a/docs/manual/mod/mod_access_compat.html.en +++ b/docs/manual/mod/mod_access_compat.html.en @@ -91,7 +91,6 @@ have been deprecated by the new authz refactoring. Please see
  • mod_authz_host
  • mod_authz_core
    • -
    top

    Allow Directive

    @@ -459,6 +458,7 @@ Satisfy Any
  • Require
    • +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_access_compat.html.fr b/docs/manual/mod/mod_access_compat.html.fr index fb3d157dcfb..e4918ba6eff 100644 --- a/docs/manual/mod/mod_access_compat.html.fr +++ b/docs/manual/mod/mod_access_compat.html.fr @@ -98,7 +98,6 @@ ce module sont devenues obsol

  • mod_authz_host
  • mod_authz_core
    • -
    top

    Directive Allow

    @@ -485,6 +484,7 @@ Satisfy Any
  • Require
    • +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_access_compat.html.ja.utf8 b/docs/manual/mod/mod_access_compat.html.ja.utf8 index 0580643e5f5..199fc9b9d70 100644 --- a/docs/manual/mod/mod_access_compat.html.ja.utf8 +++ b/docs/manual/mod/mod_access_compat.html.ja.utf8 @@ -92,7 +92,6 @@

  • mod_authz_host
  • mod_authz_core
    • -
    top

    Allow ディレクティブ

    @@ -442,6 +441,7 @@
  • Require
    • +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_actions.html.de b/docs/manual/mod/mod_actions.html.de index af045803989..29a15933d53 100644 --- a/docs/manual/mod/mod_actions.html.de +++ b/docs/manual/mod/mod_actions.html.de @@ -57,7 +57,6 @@

  • Dynamische Inhalte mit CGI
  • Die Verwendung von Handlern
    • -
    top

    Action-Direktive

    @@ -161,6 +160,7 @@

    +

    Verfügbare Sprachen:  de  | diff --git a/docs/manual/mod/mod_actions.html.en b/docs/manual/mod/mod_actions.html.en index d0011b8dc3d..2479c581315 100644 --- a/docs/manual/mod/mod_actions.html.en +++ b/docs/manual/mod/mod_actions.html.en @@ -53,7 +53,6 @@

  • Dynamic Content with CGI
  • Apache httpd's Handler Use
    • -
    top

    Action Directive

    @@ -150,6 +149,7 @@ Script PUT "/~bob/put.cgi" +

    Available Languages:  de  | diff --git a/docs/manual/mod/mod_actions.html.fr b/docs/manual/mod/mod_actions.html.fr index 3387e84cb35..8f5ce646797 100644 --- a/docs/manual/mod/mod_actions.html.fr +++ b/docs/manual/mod/mod_actions.html.fr @@ -58,7 +58,6 @@ type de m

  • Utilisation des gestionnaires d'Apache httpd
    • -
    top

    Directive Action

    @@ -162,6 +161,7 @@ Script PUT /~bob/put.cgi +

    Langues Disponibles:  de  | diff --git a/docs/manual/mod/mod_actions.html.ja.utf8 b/docs/manual/mod/mod_actions.html.ja.utf8 index 6c745bb9a60..7c1ca3e2dd4 100644 --- a/docs/manual/mod/mod_actions.html.ja.utf8 +++ b/docs/manual/mod/mod_actions.html.ja.utf8 @@ -59,7 +59,6 @@ CGI スクリプトを実行する機能を提供

  • CGI による動的コンテンツ
  • Apache のハンドラの使用
    • -
    top

    Action ディレクティブ

    @@ -169,6 +168,7 @@ Apache 2.1 で導入されました

    +

    翻訳済み言語:  de  | diff --git a/docs/manual/mod/mod_actions.html.ko.euc-kr b/docs/manual/mod/mod_actions.html.ko.euc-kr index 8323694f37d..98b0229a512 100644 --- a/docs/manual/mod/mod_actions.html.ko.euc-kr +++ b/docs/manual/mod/mod_actions.html.ko.euc-kr @@ -56,7 +56,6 @@

  • CGI·Î µ¿Àû ÆäÀÌÁö »ý¼º
  • ¾ÆÆÄÄ¡¿¡¼­ Çڵ鷯 »ç¿ë
    • -
    top

    Action Áö½Ã¾î

    @@ -158,6 +157,7 @@

    +

    °¡´ÉÇÑ ¾ð¾î:  de  | diff --git a/docs/manual/mod/mod_alias.html.en b/docs/manual/mod/mod_alias.html.en index c4f84f68223..b6118865197 100644 --- a/docs/manual/mod/mod_alias.html.en +++ b/docs/manual/mod/mod_alias.html.en @@ -86,47 +86,6 @@

  • Mapping URLs to the filesystem
    • top
    -
    -

    Order of Processing

    - -

    Aliases and Redirects occurring in different contexts are processed - like other directives according to standard merging rules. But when multiple - Aliases or Redirects occur in the same context (for example, in the - same <VirtualHost> - section) they are processed in a particular order.

    - -

    First, all Redirects are processed before Aliases are processed, - and therefore a request that matches a Redirect or RedirectMatch will never have Aliases - applied. Second, the Aliases and Redirects are processed in the order - they appear in the configuration files, with the first match taking - precedence.

    - -

    For this reason, when two or more of these directives apply to the - same sub-path, you must list the most specific path first in order for - all the directives to have an effect. For example, the following - configuration will work as expected:

    - - 
    Alias "/foo/bar" "/baz"
-Alias "/foo" "/gaq"
    - - -

    But if the above two directives were reversed in order, the - /foo Alias - would always match before the /foo/bar Alias, so the latter directive would be - ignored.

    - -

    When the Alias, - ScriptAlias and - Redirect directives are used - within a <Location> - or <LocationMatch> - section, these directives will take precedence over any globally - defined Alias, - ScriptAlias and - Redirect directives.

    - -
    -
    top

    Alias Directive

    @@ -597,6 +556,47 @@ and designates the target as a CGI script details.

    + +
    top
    +
    +

    Order of Processing

    + +

    Aliases and Redirects occurring in different contexts are processed + like other directives according to standard merging rules. But when multiple + Aliases or Redirects occur in the same context (for example, in the + same <VirtualHost> + section) they are processed in a particular order.

    + +

    First, all Redirects are processed before Aliases are processed, + and therefore a request that matches a Redirect or RedirectMatch will never have Aliases + applied. Second, the Aliases and Redirects are processed in the order + they appear in the configuration files, with the first match taking + precedence.

    + +

    For this reason, when two or more of these directives apply to the + same sub-path, you must list the most specific path first in order for + all the directives to have an effect. For example, the following + configuration will work as expected:

    + + 
    Alias "/foo/bar" "/baz"
+Alias "/foo" "/gaq"
    + + +

    But if the above two directives were reversed in order, the + /foo Alias + would always match before the /foo/bar Alias, so the latter directive would be + ignored.

    + +

    When the Alias, + ScriptAlias and + Redirect directives are used + within a <Location> + or <LocationMatch> + section, these directives will take precedence over any globally + defined Alias, + ScriptAlias and + Redirect directives.

    +
    diff --git a/docs/manual/mod/mod_alias.html.fr b/docs/manual/mod/mod_alias.html.fr index 3492c5c760e..80bdd9f5590 100644 --- a/docs/manual/mod/mod_alias.html.fr +++ b/docs/manual/mod/mod_alias.html.fr @@ -89,46 +89,6 @@ redirection d'URL système de fichiers
    top
    -
    -

    Chronologie du traitement

    - -

    Les alias et redirections apparaissant dans différents contextes - sont traités comme les autres directives en respectant les règles de fusion standards. Par - contre, ils sont traités selon une chronologie particulière - lorsqu'ils apparaissent dans le même contexte (par exemple, dans la - même section <VirtualHost>).

    - -

    Premièrement, toutes les redirections sont traitées avant les - alias, et ainsi, une requête qui correspond à une directive - Redirect ou RedirectMatch ne se verra jamais - appliquer d'alias. Deuxièmement, les alias et redirections sont - traités selon l'ordre dans lequel ils apparaissent dans le fichier - de configuration, seule la première correspondance étant prise en - compte.

    - -

    Ainsi, lorsqu'une ou plusieurs de ces directives s'appliquent au - même sous-répertoire, vous devez classer les chemins du plus précis - au moins précis afin que toutes les directives puissent - éventuellement s'appliquer, comme dans l'exemple suivant :

    - - 
    Alias /foo/bar /baz
-Alias /foo /gaq
    - - -

    Si l'ordre des directives était inversé, la directive Alias ayant pour argument - /foo serait toujours appliquée avant la directive - Alias ayant pour argument - /foo/bar, et cette dernière serait toujours - ignorée.

    - -

    La définition de directives Alias, ScriptAlias ou Redirect au sein de sections - <Location> ou - <LocationMatch> - l'emporte sur d'autres définitions éventuelles de ces mêmes - directives au niveau de la configuration générale du serveur.

    - -
    -
    top

    Directive Alias

    Description:Maps URLs to filesystem locations
    détails.

    + +
    top
    +
    +

    Chronologie du traitement

    + +

    Les alias et redirections apparaissant dans différents contextes + sont traités comme les autres directives en respectant les règles de fusion standards. Par + contre, ils sont traités selon une chronologie particulière + lorsqu'ils apparaissent dans le même contexte (par exemple, dans la + même section <VirtualHost>).

    + +

    Premièrement, toutes les redirections sont traitées avant les + alias, et ainsi, une requête qui correspond à une directive + Redirect ou RedirectMatch ne se verra jamais + appliquer d'alias. Deuxièmement, les alias et redirections sont + traités selon l'ordre dans lequel ils apparaissent dans le fichier + de configuration, seule la première correspondance étant prise en + compte.

    + +

    Ainsi, lorsqu'une ou plusieurs de ces directives s'appliquent au + même sous-répertoire, vous devez classer les chemins du plus précis + au moins précis afin que toutes les directives puissent + éventuellement s'appliquer, comme dans l'exemple suivant :

    + + 
    Alias /foo/bar /baz
+Alias /foo /gaq
    + + +

    Si l'ordre des directives était inversé, la directive Alias ayant pour argument + /foo serait toujours appliquée avant la directive + Alias ayant pour argument + /foo/bar, et cette dernière serait toujours + ignorée.

    + +

    La définition de directives Alias, ScriptAlias ou Redirect au sein de sections + <Location> ou + <LocationMatch> + l'emporte sur d'autres définitions éventuelles de ces mêmes + directives au niveau de la configuration générale du serveur.

    +
    diff --git a/docs/manual/mod/mod_alias.html.ja.utf8 b/docs/manual/mod/mod_alias.html.ja.utf8 index 161056b9687..4d1ce9312c4 100644 --- a/docs/manual/mod/mod_alias.html.ja.utf8 +++ b/docs/manual/mod/mod_alias.html.ja.utf8 @@ -84,34 +84,6 @@
  • URL からファイルシステム上の位置へのマッピング
    • top
    -
    -

    処理の順番

    - -

    様々なコンテキスト中での Alias や Redirect は他のディレクティブと -同じように標準の マージ規則 に -従って処理されます。ただし、(例えば <VirtualHost> セクションの中のように) 複数の Alias や Redirect が -同じコンテキスト中に現れた場合は決まった順番で処理されます。

    - -

    まず、Alias の前にすべての Redirect が処理されます。ですから、Redirect か RedirectMatch にマッチするリクエストには -Alias は決して適用されません。次に、Alias と Redirect が設定ファイル中の -順番に適用され、最初にマッチしたものが優先されます。

    - -

    ですから、二つ以上のディレクティブが同じパスに適用されるときは、 -すべてのディレクティブの効果を得るためにはより詳しいパスを先に書く -必要があります。例えば、次の設定は期待通りの動作をします:

    - -

    -Alias /foo/bar /baz
    -Alias /foo /gaq -

    - -

    しかし、上記の二つのディレクティブの順番が逆になると、 -/foo Alias が -常に /foo/bar Alias より先にマッチしますので、後者は -決して適用されることはありません。

    - -
    -
    top

    Alias ディレクティブ

    Description:Met en correspondance des URLs avec des chemins du système @@ -606,6 +566,46 @@ comme un script CGI
    @@ -382,6 +354,34 @@ CGI スクリプトに指定 ScriptAliasMatch ^/cgi-bin(.*) /usr/local/apache/cgi-bin$1

    + +
    top
    +
    +

    処理の順番

    + +

    様々なコンテキスト中での Alias や Redirect は他のディレクティブと +同じように標準の マージ規則 に +従って処理されます。ただし、(例えば <VirtualHost> セクションの中のように) 複数の Alias や Redirect が +同じコンテキスト中に現れた場合は決まった順番で処理されます。

    + +

    まず、Alias の前にすべての Redirect が処理されます。ですから、Redirect か RedirectMatch にマッチするリクエストには +Alias は決して適用されません。次に、Alias と Redirect が設定ファイル中の +順番に適用され、最初にマッチしたものが優先されます。

    + +

    ですから、二つ以上のディレクティブが同じパスに適用されるときは、 +すべてのディレクティブの効果を得るためにはより詳しいパスを先に書く +必要があります。例えば、次の設定は期待通りの動作をします:

    + +

    +Alias /foo/bar /baz
    +Alias /foo /gaq +

    + +

    しかし、上記の二つのディレクティブの順番が逆になると、 +/foo Alias が +常に /foo/bar Alias より先にマッチしますので、後者は +決して適用されることはありません。

    +
    diff --git a/docs/manual/mod/mod_alias.html.ko.euc-kr b/docs/manual/mod/mod_alias.html.ko.euc-kr index 26bde588b5a..e917b92922e 100644 --- a/docs/manual/mod/mod_alias.html.ko.euc-kr +++ b/docs/manual/mod/mod_alias.html.ko.euc-kr @@ -74,35 +74,6 @@
  • URLÀ» ÆÄÀϽýºÅÛ¿¡ ´ëÀÀ
    • top
    -
    -

    ó¸® ¼ø¼­

    - -

    ¼­·Î ´Ù¸¥ »ç¿ëÀå¼Ò¿¡¼­ Alias¿Í Redirect¸¦ »ç¿ëÇÏ¸é ´Ù¸¥ Áö½Ã¾î¿Í -°°ÀÌ Ç¥ÁØ °áÇÕ ¹æ¹ý¿¡ -µû¶ó ó¸®ÇÑ´Ù. ±×·¯³ª °°Àº »ç¿ëÀå¼Ò¿¡ (¿¹¸¦ µé¾î, °°Àº <VirtualHost> ¼½¼Ç¿¡) -Alias¿Í Redirect¸¦ »ç¿ëÇÏ¸é ¾Æ·¡ ¼ø¼­´ë·Î ó¸®ÇÑ´Ù.

    - -

    ¸ÕÀú ¸ðµç Redirect¸¦ ó¸®ÇÑ ÈÄ Alias¸¦ ó¸®ÇÑ´Ù. ±×·¡¼­ -Redirect³ª RedirectMatch¿¡ ÇØ´çÇÏ´Â ¿äûÀº -Àý´ë·Î AliasÇÏÁö ¾Ê´Â´Ù. ±×¸®°í Alias¿Í Redirect´Â ¼³Á¤ÆÄÀÏ¿¡¼­ -ù¹ø°·Î ³ª¿À´Â °ÍÀ» »ç¿ëÇÑ´Ù.

    - -

    ±×·¡¼­ ¿©·¯ Áö½Ã¾î°¡ µ¿ÀÏÇÑ ÇÏÀ§°æ·Î¿¡ ÇØ´çÇÏ´Â °æ¿ì ¸ðµç -Áö½Ã¾î¸¦ Àû¿ëÇϱâÀ§Çؼ­´Â °¡Àå »ó¼¼ÇÑ °æ·Î¸¦ ¸ÕÀú »ç¿ëÇØ¾ß ÇÑ´Ù. -¿¹¸¦ µé¾î, ´ÙÀ½ ¼³Á¤Àº ÀǵµÇÑ´ë·Î µ¿ÀÛÇÑ´Ù:

    - -

    -Alias /foo/bar /baz
    -Alias /foo /gaq -

    - -

    ±×·¯³ª À§ÀÇ µÎ Áö½Ã¾î ¼ø¼­¸¦ ¹Ù²Ù¸é /foo/bar -Alias ÀÌÀü¿¡ -/foo Alias¸¦ -Àû¿ëÇϹǷΠÇ×»ó µÎ¹ø° Áö½Ã¾î¸¦ ¹«½ÃÇÑ´Ù.

    - -
    -
    top

    Alias Áö½Ã¾î

    説明:URL をファイルシステムの位置にマップする
    @@ -349,6 +320,35 @@ Alias /foo /gaq ScriptAliasMatch ^/cgi-bin(.*) /usr/local/apache/cgi-bin$1

    + +
    top
    +
    +

    ó¸® ¼ø¼­

    + +

    ¼­·Î ´Ù¸¥ »ç¿ëÀå¼Ò¿¡¼­ Alias¿Í Redirect¸¦ »ç¿ëÇÏ¸é ´Ù¸¥ Áö½Ã¾î¿Í +°°ÀÌ Ç¥ÁØ °áÇÕ ¹æ¹ý¿¡ +µû¶ó ó¸®ÇÑ´Ù. ±×·¯³ª °°Àº »ç¿ëÀå¼Ò¿¡ (¿¹¸¦ µé¾î, °°Àº <VirtualHost> ¼½¼Ç¿¡) +Alias¿Í Redirect¸¦ »ç¿ëÇÏ¸é ¾Æ·¡ ¼ø¼­´ë·Î ó¸®ÇÑ´Ù.

    + +

    ¸ÕÀú ¸ðµç Redirect¸¦ ó¸®ÇÑ ÈÄ Alias¸¦ ó¸®ÇÑ´Ù. ±×·¡¼­ +Redirect³ª RedirectMatch¿¡ ÇØ´çÇÏ´Â ¿äûÀº +Àý´ë·Î AliasÇÏÁö ¾Ê´Â´Ù. ±×¸®°í Alias¿Í Redirect´Â ¼³Á¤ÆÄÀÏ¿¡¼­ +ù¹ø°·Î ³ª¿À´Â °ÍÀ» »ç¿ëÇÑ´Ù.

    + +

    ±×·¡¼­ ¿©·¯ Áö½Ã¾î°¡ µ¿ÀÏÇÑ ÇÏÀ§°æ·Î¿¡ ÇØ´çÇÏ´Â °æ¿ì ¸ðµç +Áö½Ã¾î¸¦ Àû¿ëÇϱâÀ§Çؼ­´Â °¡Àå »ó¼¼ÇÑ °æ·Î¸¦ ¸ÕÀú »ç¿ëÇØ¾ß ÇÑ´Ù. +¿¹¸¦ µé¾î, ´ÙÀ½ ¼³Á¤Àº ÀǵµÇÑ´ë·Î µ¿ÀÛÇÑ´Ù:

    + +

    +Alias /foo/bar /baz
    +Alias /foo /gaq +

    + +

    ±×·¯³ª À§ÀÇ µÎ Áö½Ã¾î ¼ø¼­¸¦ ¹Ù²Ù¸é /foo/bar +Alias ÀÌÀü¿¡ +/foo Alias¸¦ +Àû¿ëÇϹǷΠÇ×»ó µÎ¹ø° Áö½Ã¾î¸¦ ¹«½ÃÇÑ´Ù.

    +
    diff --git a/docs/manual/mod/mod_alias.html.tr.utf8 b/docs/manual/mod/mod_alias.html.tr.utf8 index 4a944c469c7..948a1d29d38 100644 --- a/docs/manual/mod/mod_alias.html.tr.utf8 +++ b/docs/manual/mod/mod_alias.html.tr.utf8 @@ -84,48 +84,6 @@ eşlenmesini sağlar ve URL yönlendirmesi yapar.
    top
    -
    -

    İşlem Sırası

    - -

    Farklı bağlamlarda bulunan Alias ve Redirect - yönergeleri standart katıştırma - kuralları ile ilgili diğer yönergeler gibi işleme sokulur. Fakat - aynı bağlam dahilinde (örneğin, aynı <VirtualHost> bölümünde) çok fazla Alias ve Redirect varsa bunlar belli bir - sıraya göre işleme sokulurlar.

    - -

    İlk adımda, Alias’lardan önce - bütün Redirect yönergeleri - işleme sokulur. Bu bakımdan bir Redirect veya RedirectMatch ile eşleşen bir istek için - hiçbir Alias - uygulanmayacaktır. İkinci adımda yapılandırma dosyasında yer aldıkları - sıraya göre Redirect ve - Alias yönergeleri işleme - sokulurlar, dolayısıyla ilk eşleşme öncelikli olmuş olur.

    - -

    İlk eşleşmenin öncelikli olması sebebiyle, bu yönergelerin birden - fazlası aynı alt yola uygulandığı takdirde, tüm yönergelerin etkili - olabilmesi için en uzun yolu sıralamada en öne almalısınız. Örneğin - aşağıdaki yapılandırma beklendiği gibi çalışacaktır:

    - - 
    Alias /foo/bar /baz
-Alias /foo /gaq
    - - -

    Ama yukarıdaki iki satır ters sırada yerleştirilmiş olsaydı, - /foo rumuzu daima /foo/bar rumuzundan önce - eşleşecek, dolayısıyla ikinci yönerge yok sayılacaktı.

    - -

    Alias, - ScriptAlias ve - Redirect - yönergeleri bir <Location> veya <LocationMatch> bölümü içinde kullanıldığında - bu yönergeler genel alanda tanımlanmış Alias, - ScriptAlias ve - Redirect yönergelerine göre - öncelik alırlar.

    - -
    -
    top

    Alias Yönergesi

    ¼³¸í:URLÀ» ƯÁ¤ ÆÄÀϽýºÅÛ Àå¼Ò·Î ´ëÀÀÇÑ´Ù
    @@ -584,6 +542,48 @@ eşler ve hedefi bir CGI betiği olarak çalıştırır. +
    top
    +
    +

    İşlem Sırası

    + +

    Farklı bağlamlarda bulunan Alias ve Redirect + yönergeleri standart katıştırma + kuralları ile ilgili diğer yönergeler gibi işleme sokulur. Fakat + aynı bağlam dahilinde (örneğin, aynı <VirtualHost> bölümünde) çok fazla Alias ve Redirect varsa bunlar belli bir + sıraya göre işleme sokulurlar.

    + +

    İlk adımda, Alias’lardan önce + bütün Redirect yönergeleri + işleme sokulur. Bu bakımdan bir Redirect veya RedirectMatch ile eşleşen bir istek için + hiçbir Alias + uygulanmayacaktır. İkinci adımda yapılandırma dosyasında yer aldıkları + sıraya göre Redirect ve + Alias yönergeleri işleme + sokulurlar, dolayısıyla ilk eşleşme öncelikli olmuş olur.

    + +

    İlk eşleşmenin öncelikli olması sebebiyle, bu yönergelerin birden + fazlası aynı alt yola uygulandığı takdirde, tüm yönergelerin etkili + olabilmesi için en uzun yolu sıralamada en öne almalısınız. Örneğin + aşağıdaki yapılandırma beklendiği gibi çalışacaktır:

    + + 
    Alias /foo/bar /baz
+Alias /foo /gaq
    + + +

    Ama yukarıdaki iki satır ters sırada yerleştirilmiş olsaydı, + /foo rumuzu daima /foo/bar rumuzundan önce + eşleşecek, dolayısıyla ikinci yönerge yok sayılacaktı.

    + +

    Alias, + ScriptAlias ve + Redirect + yönergeleri bir <Location> veya <LocationMatch> bölümü içinde kullanıldığında + bu yönergeler genel alanda tanımlanmış Alias, + ScriptAlias ve + Redirect yönergelerine göre + öncelik alırlar.

    + +

    Mevcut Diller:  en  | diff --git a/docs/manual/mod/mod_allowmethods.html.en b/docs/manual/mod/mod_allowmethods.html.en index 0b492eef138..09833ec632e 100644 --- a/docs/manual/mod/mod_allowmethods.html.en +++ b/docs/manual/mod/mod_allowmethods.html.en @@ -47,7 +47,6 @@ used on an server. The most common configuration would be:

  • AllowMethods
    • -
    top

    AllowMethods Directive

    Açıklama:URL’leri dosya sistemi konumlarıyla eşler.
    @@ -80,6 +79,7 @@ kludgy implementation of LimitExcept.

    +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_allowmethods.html.fr b/docs/manual/mod/mod_allowmethods.html.fr index c73fcea7139..54e23fbdbce 100644 --- a/docs/manual/mod/mod_allowmethods.html.fr +++ b/docs/manual/mod/mod_allowmethods.html.fr @@ -51,7 +51,6 @@ est du style :

  • AllowMethods
    • -
    top

    Directive AllowMethods

    @@ -85,6 +84,7 @@ d'imbrication :

    remplacer l'implémentation "bricolée" des directives Limit et LimitExcept.

    +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_auth_basic.html.en b/docs/manual/mod/mod_auth_basic.html.en index 0aa646a0964..e939cd30a62 100644 --- a/docs/manual/mod/mod_auth_basic.html.en +++ b/docs/manual/mod/mod_auth_basic.html.en @@ -58,7 +58,6 @@

  • Require
  • Authentication howto
    • -
    top

    AuthBasicAuthoritative Directive

    @@ -253,6 +252,7 @@ Digest Authentication was in force instead of Basic Authentication. +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_auth_basic.html.fr b/docs/manual/mod/mod_auth_basic.html.fr index 568ee1e5415..4a27dd5402d 100644 --- a/docs/manual/mod/mod_auth_basic.html.fr +++ b/docs/manual/mod/mod_auth_basic.html.fr @@ -62,7 +62,6 @@

  • Mode d'emploi de l'authentification
    • -
    top

    Directive AuthBasicAuthoritative

    @@ -282,6 +281,7 @@ Apache refuser l'accès. +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_auth_basic.html.ja.utf8 b/docs/manual/mod/mod_auth_basic.html.ja.utf8 index a80348db0e3..437d4a6de28 100644 --- a/docs/manual/mod/mod_auth_basic.html.ja.utf8 +++ b/docs/manual/mod/mod_auth_basic.html.ja.utf8 @@ -66,7 +66,6 @@

  • <SatisfyOne>
  • Authentication howto
    • -
    top

    AuthBasicAuthoritative ディレクティブ

    @@ -163,6 +162,7 @@ Digest Authentication was in force instead of Basic Authentication.

    このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

    +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_auth_basic.html.ko.euc-kr b/docs/manual/mod/mod_auth_basic.html.ko.euc-kr index fde27f13b6d..df33b8b9f7b 100644 --- a/docs/manual/mod/mod_auth_basic.html.ko.euc-kr +++ b/docs/manual/mod/mod_auth_basic.html.ko.euc-kr @@ -55,7 +55,6 @@

  • AuthName
  • AuthType
    • -
    top

    AuthBasicAuthoritative Áö½Ã¾î

    @@ -156,6 +155,7 @@ Digest Authentication was in force instead of Basic Authentication.

    The documentation for this directive has not been translated yet. Please have a look at the English version.

    +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_auth_digest.html.en b/docs/manual/mod/mod_auth_digest.html.en index f4d31162389..bb967ce3398 100644 --- a/docs/manual/mod/mod_auth_digest.html.en +++ b/docs/manual/mod/mod_auth_digest.html.en @@ -66,48 +66,6 @@

  • Authentication howto
    • top
    -
    -

    Using Digest Authentication

    - -

    To use MD5 Digest authentication, simply - change the normal AuthType Basic and - AuthBasicProvider - to AuthType Digest and - AuthDigestProvider, - when setting up authentication, then add a - AuthDigestDomain directive containing at least the root - URI(s) for this protection space.

    - -

    Appropriate user (text) files can be created using the - htdigest tool.

    - -

    Example:

    <Location "/private/">
-    AuthType Digest
-    AuthName "private area"
-    AuthDigestDomain "/private/" "http://mirror.my.dom/private2/"
-    
-    AuthDigestProvider file
-    AuthUserFile "/web/auth/.digest_pw"
-    Require valid-user
-</Location>
    -
    - -

    Note

    -

    Digest authentication was intended to be more secure than basic - authentication, but no longer fulfills that design goal. A - man-in-the-middle attacker can trivially force the browser to downgrade - to basic authentication. And even a passive eavesdropper can brute-force - the password using today's graphics hardware, because the hashing - algorithm used by digest authentication is too fast. Another problem is - that the storage of the passwords on the server is insecure. The contents - of a stolen htdigest file can be used directly for digest authentication. - Therefore using mod_ssl to encrypt the whole connection is - strongly recommended.

    -

    mod_auth_digest only works properly on platforms - where APR supports shared memory.

    -
    -
    -
    top

    AuthDigestAlgorithm Directive

    - +

    Performances dans le cas des groupes imbriqués

    +

    Lorsque les directives + AuthLDAPSubGroupAttribute et + AuthLDAPGroupAttribute se recouvrent (comme + c'est le cas par défaut et requis par les schémas LDAP courants), la + recherche de sous-groupes au sein de grands groupes peut être très + longue. Si vos groupes sont très grands et non imbriqués, définissez + la directive AuthLDAPMaxSubGroupDepth à 0.

    +
    - - - - + +
    top
    +

    Directive AuthLDAPRemoteUserAttribute

    +
    Description:Selects the algorithm used to calculate the challenge and @@ -264,6 +222,48 @@ AuthDigestShmemSize 1024K AuthDigestShmemSize 1M + +
    top
    +
    +

    Using Digest Authentication

    + +

    To use MD5 Digest authentication, simply + change the normal AuthType Basic and + AuthBasicProvider + to AuthType Digest and + AuthDigestProvider, + when setting up authentication, then add a + AuthDigestDomain directive containing at least the root + URI(s) for this protection space.

    + +

    Appropriate user (text) files can be created using the + htdigest tool.

    + +

    Example:

    <Location "/private/">
+    AuthType Digest
+    AuthName "private area"
+    AuthDigestDomain "/private/" "http://mirror.my.dom/private2/"
+    
+    AuthDigestProvider file
+    AuthUserFile "/web/auth/.digest_pw"
+    Require valid-user
+</Location>
    +
    + +

    Note

    +

    Digest authentication was intended to be more secure than basic + authentication, but no longer fulfills that design goal. A + man-in-the-middle attacker can trivially force the browser to downgrade + to basic authentication. And even a passive eavesdropper can brute-force + the password using today's graphics hardware, because the hashing + algorithm used by digest authentication is too fast. Another problem is + that the storage of the passwords on the server is insecure. The contents + of a stolen htdigest file can be used directly for digest authentication. + Therefore using mod_ssl to encrypt the whole connection is + strongly recommended.

    +

    mod_auth_digest only works properly on platforms + where APR supports shared memory.

    +
    diff --git a/docs/manual/mod/mod_auth_digest.html.fr b/docs/manual/mod/mod_auth_digest.html.fr index f18901e5a02..357b810dbba 100644 --- a/docs/manual/mod/mod_auth_digest.html.fr +++ b/docs/manual/mod/mod_auth_digest.html.fr @@ -72,48 +72,6 @@ condens l'authentification
    top
    -
    -

    Utilisation de l'authentification à base de -condensés

    - -

    Pour utiliser l'authentification à base de condensés MD5, vous - devez simplement remplacer AuthType Basic et AuthBasicProvider respectivement - par AuthType Digest et AuthDigestProvider lorsque vous - configurez l'authentification, puis ajouter une directive AuthDigestDomain contenant au - moins la(les) URI(s) racine(s) de la zone à protéger.

    - -

    On peut créer les fichiers utilisateur appropriés (au format - texte) à l'aide de l'outil htdigest.

    - -

    Exemple :

    <Location /private/>
-    AuthType Digest
-    AuthName "private area"
-    AuthDigestDomain /private/ http://mirror.my.dom/private2/
-    
-    AuthDigestProvider file
-    AuthUserFile /web/auth/.digest_pw
-    Require valid-user
-</Location>
    -
    - -

    Note

    -

    L'authentification à base de condensé a été conçue pour améliorer - la sécurité par rapport à l'authentification basique, mais il - s'avère que ce but n'a pas été atteint. Un attaquant de type - "man-in-the-middle" peut facilement forcer le navigateur à revenir à - une authentification basique. Même une oreille indiscrète passive - peut retrouver le mot de passe par force brute avec les moyens - modernes, car l'algorithme de hashage utilisé par l'authentification - à base de condensé est trop rapide. Autre problème, le stockage des - mots de passe sur le serveur n'est pas sûr. Le contenu d'un fichier - htdigest volé peut être utilisé directement pour l'authentification - à base de condensé. Il est donc fortement recommandé d'utiliser - mod_ssl pour chiffrer la connexion.

    -

    mod_auth_digest ne fonctionne correctement que - sur les plates-formes où APR supporte la mémoire partagée.

    -
    -
    -
    top

    Directive AuthDigestAlgorithm

    - -
    Description:Sélectionne l'algorithme utilisé pour calculer les @@ -283,6 +241,48 @@ AuthDigestShmemSize 1024K AuthDigestShmemSize 1M + +
    top
    +
    +

    Utilisation de l'authentification à base de +condensés

    + +

    Pour utiliser l'authentification à base de condensés MD5, vous + devez simplement remplacer AuthType Basic et AuthBasicProvider respectivement + par AuthType Digest et AuthDigestProvider lorsque vous + configurez l'authentification, puis ajouter une directive AuthDigestDomain contenant au + moins la(les) URI(s) racine(s) de la zone à protéger.

    + +

    On peut créer les fichiers utilisateur appropriés (au format + texte) à l'aide de l'outil htdigest.

    + +

    Exemple :

    <Location /private/>
+    AuthType Digest
+    AuthName "private area"
+    AuthDigestDomain /private/ http://mirror.my.dom/private2/
+    
+    AuthDigestProvider file
+    AuthUserFile /web/auth/.digest_pw
+    Require valid-user
+</Location>
    +
    + +

    Note

    +

    L'authentification à base de condensé a été conçue pour améliorer + la sécurité par rapport à l'authentification basique, mais il + s'avère que ce but n'a pas été atteint. Un attaquant de type + "man-in-the-middle" peut facilement forcer le navigateur à revenir à + une authentification basique. Même une oreille indiscrète passive + peut retrouver le mot de passe par force brute avec les moyens + modernes, car l'algorithme de hashage utilisé par l'authentification + à base de condensé est trop rapide. Autre problème, le stockage des + mots de passe sur le serveur n'est pas sûr. Le contenu d'un fichier + htdigest volé peut être utilisé directement pour l'authentification + à base de condensé. Il est donc fortement recommandé d'utiliser + mod_ssl pour chiffrer la connexion.

    +

    mod_auth_digest ne fonctionne correctement que + sur les plates-formes où APR supporte la mémoire partagée.

    +
    diff --git a/docs/manual/mod/mod_auth_digest.html.ko.euc-kr b/docs/manual/mod/mod_auth_digest.html.ko.euc-kr index 29074e2423b..01c2bd59616 100644 --- a/docs/manual/mod/mod_auth_digest.html.ko.euc-kr +++ b/docs/manual/mod/mod_auth_digest.html.ko.euc-kr @@ -60,75 +60,6 @@
  • Satisfy
    • top
    -
    -

    Digest Authentication »ç¿ëÇϱâ

    - -

    MD5 Digest authenticationÀº ¸Å¿ì ½±°Ô »ç¿ëÇÒ ¼ö ÀÖ´Ù. - AuthType Basic°ú AuthBasicProvider ´ë½Å - AuthType Digest¿Í AuthDigestProvider¸¦ - »ç¿ëÇÏ¿© °£´ÜÈ÷ ÀÎÁõÀ» ¼³Á¤ÇÒ ¼ö ÀÖ´Ù. ±×¸®°í ÃÖ¼ÒÇÑ º¸È£ÇÏ·Á´Â - ¿µ¿ªÀÇ ±âº» URIÀ» AuthDigestDomain Áö½Ã¾î¿¡ »ç¿ëÇÑ´Ù.

    - -

    htdigest µµ±¸¸¦ - »ç¿ëÇÏ¿© »ç¿ëÀÚ (¹®ÀÚ)ÆÄÀÏÀ» ¸¸µé ¼ö ÀÖ´Ù.

    - -

    ¿¹Á¦:

    - <Location /private/>
    - - AuthType Digest
    - AuthName "private area"
    - AuthDigestDomain /private/ http://mirror.my.dom/private2/
    -
    - AuthDigestProvider file
    - AuthUserFile /web/auth/.digest_pw
    - Require valid-user
    -     - </Location> -

    - -

    ÁÖÀÇ

    -

    Digest authenticationÀº Basic authenticationº¸´Ù ´õ - ¾ÈÀüÇÏÁö¸¸, ºê¶ó¿ìÀú°¡ Áö¿øÇØ¾ß ÇÑ´Ù. 2002³â 11¿ù ÇöÀç digest - authenticationÀ» Áö¿øÇÏ´Â ºê¶ó¿ìÀú¿¡´Â Amaya, Konqueror, (Windows¿ëÀº - ÁúÀǹ®ÀÚ¿­°ú ÇÔ²² »ç¿ëÇÏ¸é ¾ÈµÇÁö¸¸ - ÇØ°á¹æ¹ýÀº ¾Æ·¡ "MS Internet Explorer ¹®Á¦ ÇØ°áÇϱâ"¸¦ Âü°í) - Mac OS X¿Í Windows¿ë MS Internet - Explorer, Mozilla, - Netscape ¹öÀü 7, Opera, - Safari µîÀÌ ÀÖ´Ù. - lynx´Â digest authenticationÀ» - Áö¿øÇÏÁö ¾Ê´Â´Ù. digest authenticationÀÌ - basic authentication ¸¸Å­ ³Î¸® ±¸ÇöµÇÁö ¾Ê¾Ò±â¶§¹®¿¡ ¸ðµç - »ç¿ëÀÚ°¡ Áö¿øÇÏ´Â ºê¶ó¿ìÀú¸¦ »ç¿ëÇÏ´Â °æ¿ì¿¡¸¸ »ç¿ëÇØ¾ß - ÇÑ´Ù.

    -
    -
    top
    -
    -

    MS Internet Explorer ¹®Á¦ ÇØ°áÇϱâ

    -

    ÇöÀç Windows¿ë Internet Explorer´Â Digest authentication - »ç¿ë½Ã ÁúÀǹ®ÀÚ¿­ÀÌ ÀÖ´Â GET ¿äûÀ» RFC¿Í ´Ù¸£°Ô - ó¸®ÇÏ´Â ¹®Á¦°¡ ÀÖ´Ù. ¸î°¡Áö ¹æ¹ýÀ¸·Î ÀÌ ¹®Á¦¸¦ ÇØ°áÇÒ ¼ö - ÀÖ´Ù.

    - -

    - ù¹ø°´Â ÇÁ·Î±×·¥¿¡ ÀڷḦ ³Ñ°ÜÁÖ±âÀ§ÇØ GET - ´ë½Å POST ¿äûÀ» »ç¿ëÇÏ´Â ¹æ¹ýÀÌ´Ù. ÀÌ ¹æ¹ýÀÌ - °¡´ÉÇÏ´Ù¸é °¡Àå °£´ÜÇÑ ÇØ°áÃ¥ÀÌ´Ù. -

    - -

    ¶Ç, ¾ÆÆÄÄ¡ 2.0.51ºÎÅÍ AuthDigestEnableQueryStringHack - ȯ°æº¯¼ö¸¦ Á¦°øÇÏ¿© ¹®Á¦¸¦ ÇØ°áÇÑ´Ù. ¿äû¿¡ - AuthDigestEnableQueryStringHackÀ» ¼³Á¤Çϸé - ¾ÆÆÄÄ¡´Â MSIE ¹ö±×¸¦ ÇÇÇØ°¥ Á¶Ä¡¸¦ ÃëÇÏ°í ¿äû URI¸¦ digest - ºñ±³¿¡¼­ Á¦¿ÜÇÑ´Ù. ÀÌ ¹æ¹ýÀº ´ÙÀ½°ú °°ÀÌ »ç¿ëÇÑ´Ù.

    - -

    MSIE¿¡¼­ Digest Authentication »ç¿ëÇϱâ:

    - BrowserMatch "MSIE" AuthDigestEnableQueryStringHack=On -

    - -

    ¼±ÅÃÀûÀΠȯ°æº¯¼ö ¼³Á¤¿¡ ´ëÇÑ ÀÚ¼¼ÇÑ ³»¿ëÀº BrowserMatch Áö½Ã¾î¸¦ - Âü°íÇ϶ó.

    -
    -
    top

    AuthDigestAlgorithm Áö½Ã¾î

    - +

    The ldap-filter and ldap-dn authorization + checks use searches.

    - - +

    This directive only has effect on the comparisons performed during + nested group processing when + AuthLDAPCompareAsUser is also enabled.

    - - +

    This directive should only be used when your LDAP server doesn't + accept anonymous searches and you cannot use a dedicated + AuthLDAPBindDN. +

    + +

    See also

    + + +
    top
    +

    AuthLDAPSubGroupAttribute Directive

    +
    ¼³¸í:digest authentication¿¡¼­ challenge¿Í response @@ -283,6 +214,75 @@ URI

    +
    top
    +
    +

    Digest Authentication »ç¿ëÇϱâ

    + +

    MD5 Digest authenticationÀº ¸Å¿ì ½±°Ô »ç¿ëÇÒ ¼ö ÀÖ´Ù. + AuthType Basic°ú AuthBasicProvider ´ë½Å + AuthType Digest¿Í AuthDigestProvider¸¦ + »ç¿ëÇÏ¿© °£´ÜÈ÷ ÀÎÁõÀ» ¼³Á¤ÇÒ ¼ö ÀÖ´Ù. ±×¸®°í ÃÖ¼ÒÇÑ º¸È£ÇÏ·Á´Â + ¿µ¿ªÀÇ ±âº» URIÀ» AuthDigestDomain Áö½Ã¾î¿¡ »ç¿ëÇÑ´Ù.

    + +

    htdigest µµ±¸¸¦ + »ç¿ëÇÏ¿© »ç¿ëÀÚ (¹®ÀÚ)ÆÄÀÏÀ» ¸¸µé ¼ö ÀÖ´Ù.

    + +

    ¿¹Á¦:

    + <Location /private/>
    + + AuthType Digest
    + AuthName "private area"
    + AuthDigestDomain /private/ http://mirror.my.dom/private2/
    +
    + AuthDigestProvider file
    + AuthUserFile /web/auth/.digest_pw
    + Require valid-user
    +     + </Location> +

    + +

    ÁÖÀÇ

    +

    Digest authenticationÀº Basic authenticationº¸´Ù ´õ + ¾ÈÀüÇÏÁö¸¸, ºê¶ó¿ìÀú°¡ Áö¿øÇØ¾ß ÇÑ´Ù. 2002³â 11¿ù ÇöÀç digest + authenticationÀ» Áö¿øÇÏ´Â ºê¶ó¿ìÀú¿¡´Â Amaya, Konqueror, (Windows¿ëÀº + ÁúÀǹ®ÀÚ¿­°ú ÇÔ²² »ç¿ëÇÏ¸é ¾ÈµÇÁö¸¸ - ÇØ°á¹æ¹ýÀº ¾Æ·¡ "MS Internet Explorer ¹®Á¦ ÇØ°áÇϱâ"¸¦ Âü°í) + Mac OS X¿Í Windows¿ë MS Internet + Explorer, Mozilla, + Netscape ¹öÀü 7, Opera, + Safari µîÀÌ ÀÖ´Ù. + lynx´Â digest authenticationÀ» + Áö¿øÇÏÁö ¾Ê´Â´Ù. digest authenticationÀÌ + basic authentication ¸¸Å­ ³Î¸® ±¸ÇöµÇÁö ¾Ê¾Ò±â¶§¹®¿¡ ¸ðµç + »ç¿ëÀÚ°¡ Áö¿øÇÏ´Â ºê¶ó¿ìÀú¸¦ »ç¿ëÇÏ´Â °æ¿ì¿¡¸¸ »ç¿ëÇØ¾ß + ÇÑ´Ù.

    +
    +
    top
    +
    +

    MS Internet Explorer ¹®Á¦ ÇØ°áÇϱâ

    +

    ÇöÀç Windows¿ë Internet Explorer´Â Digest authentication + »ç¿ë½Ã ÁúÀǹ®ÀÚ¿­ÀÌ ÀÖ´Â GET ¿äûÀ» RFC¿Í ´Ù¸£°Ô + ó¸®ÇÏ´Â ¹®Á¦°¡ ÀÖ´Ù. ¸î°¡Áö ¹æ¹ýÀ¸·Î ÀÌ ¹®Á¦¸¦ ÇØ°áÇÒ ¼ö + ÀÖ´Ù.

    + +

    + ù¹ø°´Â ÇÁ·Î±×·¥¿¡ ÀڷḦ ³Ñ°ÜÁÖ±âÀ§ÇØ GET + ´ë½Å POST ¿äûÀ» »ç¿ëÇÏ´Â ¹æ¹ýÀÌ´Ù. ÀÌ ¹æ¹ýÀÌ + °¡´ÉÇÏ´Ù¸é °¡Àå °£´ÜÇÑ ÇØ°áÃ¥ÀÌ´Ù. +

    + +

    ¶Ç, ¾ÆÆÄÄ¡ 2.0.51ºÎÅÍ AuthDigestEnableQueryStringHack + ȯ°æº¯¼ö¸¦ Á¦°øÇÏ¿© ¹®Á¦¸¦ ÇØ°áÇÑ´Ù. ¿äû¿¡ + AuthDigestEnableQueryStringHackÀ» ¼³Á¤Çϸé + ¾ÆÆÄÄ¡´Â MSIE ¹ö±×¸¦ ÇÇÇØ°¥ Á¶Ä¡¸¦ ÃëÇÏ°í ¿äû URI¸¦ digest + ºñ±³¿¡¼­ Á¦¿ÜÇÑ´Ù. ÀÌ ¹æ¹ýÀº ´ÙÀ½°ú °°ÀÌ »ç¿ëÇÑ´Ù.

    + +

    MSIE¿¡¼­ Digest Authentication »ç¿ëÇϱâ:

    + BrowserMatch "MSIE" AuthDigestEnableQueryStringHack=On +

    + +

    ¼±ÅÃÀûÀΠȯ°æº¯¼ö ¼³Á¤¿¡ ´ëÇÑ ÀÚ¼¼ÇÑ ³»¿ëÀº BrowserMatch Áö½Ã¾î¸¦ + Âü°íÇ϶ó.

    +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_auth_form.html.en b/docs/manual/mod/mod_auth_form.html.en index b13cbc7008c..118443059fe 100644 --- a/docs/manual/mod/mod_auth_form.html.en +++ b/docs/manual/mod/mod_auth_form.html.en @@ -96,253 +96,6 @@

  • Authentication howto
    • top
    -
    -

    Basic Configuration

    - -

    To protect a particular URL with mod_auth_form, you need to - decide where you will store your session, and you will need to - decide what method you will use to authenticate. In this simple example, the - login details will be stored in a session based on - mod_session_cookie, and authentication will be attempted against - a file using mod_authn_file. If authentication is unsuccessful, - the user will be redirected to the form login page.

    - -

    Basic example

    AuthFormProvider file
-AuthUserFile "conf/passwd"
-AuthType form
-AuthName realm
-AuthFormLoginRequiredLocation "http://example.com/login.html"
-Session On
-SessionCookieName session path=/
-SessionCryptoPassphrase secret
    -
    - -

    The directive AuthType will enable - the mod_auth_form authentication when set to the value form. - The directives AuthFormProvider and - AuthUserFile specify that usernames - and passwords should be checked against the chosen file.

    - -

    The directives Session, - SessionCookieName and - SessionCryptoPassphrase create an - encrypted session stored within an HTTP cookie on the browser. For more information - on the different options for configuring a session, read the documentation for - mod_session.

    - -

    In the simple example above, a URL has been protected by - mod_auth_form, but the user has yet to be given an opportunity to - enter their username and password. Options for doing so include providing a - dedicated standalone login page for this purpose, or for providing the login - page inline.

    -
    top
    -
    -

    Standalone Login

    - -

    The login form can be hosted as a standalone page, or can be provided inline on - the same page.

    - -

    When configuring the login as a standalone page, unsuccessful authentication - attempts should be redirected to a login form created by the website for this purpose, - using the AuthFormLoginRequiredLocation - directive. Typically this login page will contain an HTML form, asking the user to - provide their usename and password.

    - -

    Example login form

    <form method="POST" action="/dologin.html">
-  Username: <input type="text" name="httpd_username" value="" />
-  Password: <input type="password" name="httpd_password" value="" />
-  <input type="submit" name="login" value="Login" />
-</form>
    -
    - -

    The part that does the actual login is handled by the form-login-handler. - The action of the form should point at this handler, which is configured within - Apache httpd as follows:

    - -

    Form login handler example

    <Location "/dologin.html">
-    SetHandler form-login-handler
-    AuthFormLoginRequiredLocation "http://example.com/login.html"
-    AuthFormLoginSuccessLocation "http://example.com/success.html"
-    AuthFormProvider file
-    AuthUserFile "conf/passwd"
-    AuthType form
-    AuthName realm
-    Session On
-    SessionCookieName session path=/
-    SessionCryptoPassphrase secret
-</Location>
    -
    - -

    The URLs specified by the - AuthFormLoginRequiredLocation directive will typically - point to a page explaining to the user that their login attempt was unsuccessful, and they - should try again. The AuthFormLoginSuccessLocation - directive specifies the URL the user should be redirected to upon successful login.

    - -

    Alternatively, the URL to redirect the user to on success can be embedded within the login - form, as in the example below. As a result, the same form-login-handler can be - reused for different areas of a website.

    - -

    Example login form with location

    <form method="POST" action="/dologin.html">
-  Username: <input type="text" name="httpd_username" value="" />
-  Password: <input type="password" name="httpd_password" value="" />
-  <input type="submit" name="login" value="Login" />
-  <input type="hidden" name="httpd_location" value="http://example.com/success.html" />
-</form>
    -
    - -
    top
    -
    -

    Inline Login

    - -

    Warning

    -

    A risk exists that under certain circumstances, the login form configured - using inline login may be submitted more than once, revealing login credentials to - the application running underneath. The administrator must ensure that the underlying - application is properly secured to prevent abuse. If in doubt, use the - standalone login configuration.

    -
    - -

    As an alternative to having a dedicated login page for a website, it is possible to - configure mod_auth_form to authenticate users inline, without being - redirected to another page. This allows the state of the current page to be preserved - during the login attempt. This can be useful in a situation where a time limited - session is in force, and the session times out in the middle of the user request. The - user can be re-authenticated in place, and they can continue where they left off.

    - -

    If a non-authenticated user attempts to access a page protected by - mod_auth_form that isn't configured with a - AuthFormLoginRequiredLocation directive, - a HTTP_UNAUTHORIZED status code is returned to the browser indicating to the user - that they are not authorized to view the page.

    - -

    To configure inline authentication, the administrator overrides the error document - returned by the HTTP_UNAUTHORIZED status code with a custom error document - containing the login form, as follows:

    - -

    Basic inline example

    AuthFormProvider file
-ErrorDocument 401 "/login.shtml"
-AuthUserFile "conf/passwd"
-AuthType form
-AuthName realm
-AuthFormLoginRequiredLocation "http://example.com/login.html"
-Session On
-SessionCookieName session path=/
-SessionCryptoPassphrase secret
    -
    - -

    The error document page should contain a login form with an empty action property, - as per the example below. This has the effect of submitting the form to - the original protected URL, without the page having to know what that - URL is.

    - -

    Example inline login form

    <form method="POST" action="">
-  Username: <input type="text" name="httpd_username" value="" />
-  Password: <input type="password" name="httpd_password" value="" />
-  <input type="submit" name="login" value="Login" />
-</form>
    -
    - -

    When the end user has filled in their login details, the form will make - an HTTP POST request to the original password protected URL. - mod_auth_form will intercept this POST request, and if - HTML fields are found present for the username and password, the user - will be logged in, and the original password protected URL will be returned - to the user as a GET request.

    - -
    top
    -
    -

    Inline Login with Body Preservation

    - -

    A limitation of the inline login technique described above is that should an - HTML form POST have resulted in the request to authenticate or - reauthenticate, the - contents of the original form posted by the browser will be lost. Depending on - the function of the website, this could present significant inconvenience for the - end user.

    - -

    mod_auth_form addresses this by allowing the method and body - of the original request to be embedded in the login form. If authentication - is successful, the original method and body will be retried by Apache httpd, preserving - the state of the original request.

    - -

    To enable body preservation, add three additional fields to the login form as - per the example below.

    - -

    Example with body preservation

    <form method="POST" action="">
-  Username: <input type="text" name="httpd_username" value="" />
-  Password: <input type="password" name="httpd_password" value="" />
-  <input type="submit" name="login" value="Login" />
-  
      <input type="hidden" name="httpd_method" value="POST" />
-  <input type="hidden" name="httpd_mimetype" value="application/x-www-form-urlencoded" />
-  <input type="hidden" name="httpd_body" value="name1=value1&name2=value2" />
    
-</form>
    -
    - -

    How the method, mimetype and body of the original request are embedded within the - login form will depend on the platform and technology being used within the website. -

    - -

    One option is to use the mod_include module along with the - KeptBodySize directive, along with a suitable - CGI script to embed the variables in the form.

    - -

    Another option is to render the login form using a CGI script or other dynamic - technology.

    - -

    CGI example

            AuthFormProvider file
-        ErrorDocument 401 "/cgi-bin/login.cgi"
-        ...
    -
    - -
    top
    -
    -

    Logging Out

    - -

    To enable a user to log out of a particular session, configure a page to - be handled by the form-logout-handler. Any attempt to access this - URL will cause the username and password to be removed from the current - session, effectively logging the user out.

    - -

    By setting the - AuthFormLogoutLocation directive, - a URL can be specified that the browser will be redirected to on successful - logout. This URL might explain to the user that they have been logged out, and - give the user the option to log in again.

    - -

    Basic logout example

    SetHandler form-logout-handler
-AuthName realm
-AuthFormLogoutLocation "http://example.com/loggedout.html"
-Session On
-SessionCookieName session path=/
-SessionCryptoPassphrase secret
    -
    - -

    Note that logging a user out does not delete the session; it merely removes - the username and password from the session. If this results in an empty session, - the net effect will be the removal of that session, but this is not - guaranteed. If you want to guarantee the removal of a session, set the - SessionMaxAge directive to a small - value, like 1 (setting the directive to zero would mean no session age limit). -

    - -

    Basic session expiry example

    SetHandler form-logout-handler
-AuthFormLogoutLocation "http://example.com/loggedout.html"
-Session On
-SessionMaxAge 1
-SessionCookieName session path=/
-SessionCryptoPassphrase secret
    -
    - -
    top
    -
    -

    Usernames and Passwords

    -

    Note that form submission involves URLEncoding the form data: - in this case the username and password. You should therefore - pick usernames and passwords that avoid characters that are - URLencoded in form submission, or you may get unexpected results.

    -
    -
    top

    AuthFormAuthoritative Directive

    in.

    +
    top
    +
    +

    Basic Configuration

    + +

    To protect a particular URL with mod_auth_form, you need to + decide where you will store your session, and you will need to + decide what method you will use to authenticate. In this simple example, the + login details will be stored in a session based on + mod_session_cookie, and authentication will be attempted against + a file using mod_authn_file. If authentication is unsuccessful, + the user will be redirected to the form login page.

    + +

    Basic example

    AuthFormProvider file
+AuthUserFile "conf/passwd"
+AuthType form
+AuthName realm
+AuthFormLoginRequiredLocation "http://example.com/login.html"
+Session On
+SessionCookieName session path=/
+SessionCryptoPassphrase secret
    +
    + +

    The directive AuthType will enable + the mod_auth_form authentication when set to the value form. + The directives AuthFormProvider and + AuthUserFile specify that usernames + and passwords should be checked against the chosen file.

    + +

    The directives Session, + SessionCookieName and + SessionCryptoPassphrase create an + encrypted session stored within an HTTP cookie on the browser. For more information + on the different options for configuring a session, read the documentation for + mod_session.

    + +

    In the simple example above, a URL has been protected by + mod_auth_form, but the user has yet to be given an opportunity to + enter their username and password. Options for doing so include providing a + dedicated standalone login page for this purpose, or for providing the login + page inline.

    +
    top
    +
    +

    Standalone Login

    + +

    The login form can be hosted as a standalone page, or can be provided inline on + the same page.

    + +

    When configuring the login as a standalone page, unsuccessful authentication + attempts should be redirected to a login form created by the website for this purpose, + using the AuthFormLoginRequiredLocation + directive. Typically this login page will contain an HTML form, asking the user to + provide their usename and password.

    + +

    Example login form

    <form method="POST" action="/dologin.html">
+  Username: <input type="text" name="httpd_username" value="" />
+  Password: <input type="password" name="httpd_password" value="" />
+  <input type="submit" name="login" value="Login" />
+</form>
    +
    + +

    The part that does the actual login is handled by the form-login-handler. + The action of the form should point at this handler, which is configured within + Apache httpd as follows:

    + +

    Form login handler example

    <Location "/dologin.html">
+    SetHandler form-login-handler
+    AuthFormLoginRequiredLocation "http://example.com/login.html"
+    AuthFormLoginSuccessLocation "http://example.com/success.html"
+    AuthFormProvider file
+    AuthUserFile "conf/passwd"
+    AuthType form
+    AuthName realm
+    Session On
+    SessionCookieName session path=/
+    SessionCryptoPassphrase secret
+</Location>
    +
    + +

    The URLs specified by the + AuthFormLoginRequiredLocation directive will typically + point to a page explaining to the user that their login attempt was unsuccessful, and they + should try again. The AuthFormLoginSuccessLocation + directive specifies the URL the user should be redirected to upon successful login.

    + +

    Alternatively, the URL to redirect the user to on success can be embedded within the login + form, as in the example below. As a result, the same form-login-handler can be + reused for different areas of a website.

    + +

    Example login form with location

    <form method="POST" action="/dologin.html">
+  Username: <input type="text" name="httpd_username" value="" />
+  Password: <input type="password" name="httpd_password" value="" />
+  <input type="submit" name="login" value="Login" />
+  <input type="hidden" name="httpd_location" value="http://example.com/success.html" />
+</form>
    +
    + +
    top
    +
    +

    Inline Login

    + +

    Warning

    +

    A risk exists that under certain circumstances, the login form configured + using inline login may be submitted more than once, revealing login credentials to + the application running underneath. The administrator must ensure that the underlying + application is properly secured to prevent abuse. If in doubt, use the + standalone login configuration.

    +
    + +

    As an alternative to having a dedicated login page for a website, it is possible to + configure mod_auth_form to authenticate users inline, without being + redirected to another page. This allows the state of the current page to be preserved + during the login attempt. This can be useful in a situation where a time limited + session is in force, and the session times out in the middle of the user request. The + user can be re-authenticated in place, and they can continue where they left off.

    + +

    If a non-authenticated user attempts to access a page protected by + mod_auth_form that isn't configured with a + AuthFormLoginRequiredLocation directive, + a HTTP_UNAUTHORIZED status code is returned to the browser indicating to the user + that they are not authorized to view the page.

    + +

    To configure inline authentication, the administrator overrides the error document + returned by the HTTP_UNAUTHORIZED status code with a custom error document + containing the login form, as follows:

    + +

    Basic inline example

    AuthFormProvider file
+ErrorDocument 401 "/login.shtml"
+AuthUserFile "conf/passwd"
+AuthType form
+AuthName realm
+AuthFormLoginRequiredLocation "http://example.com/login.html"
+Session On
+SessionCookieName session path=/
+SessionCryptoPassphrase secret
    +
    + +

    The error document page should contain a login form with an empty action property, + as per the example below. This has the effect of submitting the form to + the original protected URL, without the page having to know what that + URL is.

    + +

    Example inline login form

    <form method="POST" action="">
+  Username: <input type="text" name="httpd_username" value="" />
+  Password: <input type="password" name="httpd_password" value="" />
+  <input type="submit" name="login" value="Login" />
+</form>
    +
    + +

    When the end user has filled in their login details, the form will make + an HTTP POST request to the original password protected URL. + mod_auth_form will intercept this POST request, and if + HTML fields are found present for the username and password, the user + will be logged in, and the original password protected URL will be returned + to the user as a GET request.

    + +
    top
    +
    +

    Inline Login with Body Preservation

    + +

    A limitation of the inline login technique described above is that should an + HTML form POST have resulted in the request to authenticate or + reauthenticate, the + contents of the original form posted by the browser will be lost. Depending on + the function of the website, this could present significant inconvenience for the + end user.

    + +

    mod_auth_form addresses this by allowing the method and body + of the original request to be embedded in the login form. If authentication + is successful, the original method and body will be retried by Apache httpd, preserving + the state of the original request.

    + +

    To enable body preservation, add three additional fields to the login form as + per the example below.

    + +

    Example with body preservation

    <form method="POST" action="">
+  Username: <input type="text" name="httpd_username" value="" />
+  Password: <input type="password" name="httpd_password" value="" />
+  <input type="submit" name="login" value="Login" />
+  
      <input type="hidden" name="httpd_method" value="POST" />
+  <input type="hidden" name="httpd_mimetype" value="application/x-www-form-urlencoded" />
+  <input type="hidden" name="httpd_body" value="name1=value1&name2=value2" />
    
+</form>
    +
    + +

    How the method, mimetype and body of the original request are embedded within the + login form will depend on the platform and technology being used within the website. +

    + +

    One option is to use the mod_include module along with the + KeptBodySize directive, along with a suitable + CGI script to embed the variables in the form.

    + +

    Another option is to render the login form using a CGI script or other dynamic + technology.

    + +

    CGI example

            AuthFormProvider file
+        ErrorDocument 401 "/cgi-bin/login.cgi"
+        ...
    +
    + +
    top
    +
    +

    Logging Out

    + +

    To enable a user to log out of a particular session, configure a page to + be handled by the form-logout-handler. Any attempt to access this + URL will cause the username and password to be removed from the current + session, effectively logging the user out.

    + +

    By setting the + AuthFormLogoutLocation directive, + a URL can be specified that the browser will be redirected to on successful + logout. This URL might explain to the user that they have been logged out, and + give the user the option to log in again.

    + +

    Basic logout example

    SetHandler form-logout-handler
+AuthName realm
+AuthFormLogoutLocation "http://example.com/loggedout.html"
+Session On
+SessionCookieName session path=/
+SessionCryptoPassphrase secret
    +
    + +

    Note that logging a user out does not delete the session; it merely removes + the username and password from the session. If this results in an empty session, + the net effect will be the removal of that session, but this is not + guaranteed. If you want to guarantee the removal of a session, set the + SessionMaxAge directive to a small + value, like 1 (setting the directive to zero would mean no session age limit). +

    + +

    Basic session expiry example

    SetHandler form-logout-handler
+AuthFormLogoutLocation "http://example.com/loggedout.html"
+Session On
+SessionMaxAge 1
+SessionCookieName session path=/
+SessionCryptoPassphrase secret
    +
    + +
    top
    +
    +

    Usernames and Passwords

    +

    Note that form submission involves URLEncoding the form data: + in this case the username and password. You should therefore + pick usernames and passwords that avoid characters that are + URLencoded in form submission, or you may get unexpected results.

    +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_auth_form.html.fr b/docs/manual/mod/mod_auth_form.html.fr index 66e74723a1b..7b348cf397e 100644 --- a/docs/manual/mod/mod_auth_form.html.fr +++ b/docs/manual/mod/mod_auth_form.html.fr @@ -105,295 +105,6 @@ l'authentification

    top
    -
    -

    Configuration de base

    - -

    Pour protéger une URL particulière avec le module - mod_auth_form, vous devez déterminer l'endroit où - vous allez stocker votre session, ainsi que la méthode - d'authentification. Dans cet exemple simple, les informations de - connexion sont stockées dans une session à l'aide du module - mod_session_cookie, et l'authentification utilise - un fichier en s'appuyant sur le module - mod_authn_file. Si l'authentification échoue, - l'utilisateur dera redirigé vers la page du formulaire de - connexion.

    - -

    Exemple simple

    AuthFormProvider file
-AuthUserFile conf/passwd
-AuthType form
-AuthName realm
-AuthFormLoginRequiredLocation http://example.com/login.html
-Session On
-SessionCookieName session path=/
-SessionCryptoPassphrase secret
    -
    - -

    L'authentification mod_auth_form est activée - en affectant la valeur form à la directive AuthType. Les directives - AuthFormProvider et - AuthUserFile - spécifient que les noms d'utilisateurs et mots de passe seront - vérifiés en utilisant le fichier choisi.

    - -

    Les directives Session, SessionCookieName et - SessionCryptoPassphrase - créent une session chiffrée stockée dans un cookie HTTP au niveau - du navigateur. Pour plus d'informations à propos des différentes - options de configuration des sessions, reportez-vous à la - documentation du module mod_session.

    - -

    Dans l'exemple simple ci-dessus, une URL a été protégée par - mod_auth_form, mais on doit maintenant fournir - à l'utilisateur un moyen d'entrer un nom et un mot de passe. À cet - effet, on peut soit écrire une page de connexion indépendante - dédiée, soit inclure le formulaire de connexion dans la page - courante.

    -
    top
    -
    -

    Page de connexion dédiée

    - -

    Le formulaire de connexion peut être contenu dans une page - indépendante, ou être inclus dans la page courante.

    - -

    Lorsque la connexion s'effectue à partir d'une page - indépendante et si la tentative d'authentification échoue, - l'utilisateur doit être redirigé vers un formulaire de connexion, - créé à cet effet sur le site web, en utilisant la directive - AuthFormLoginRequiredLocation. - En général, la page de connexion contiendra un formulaire HTML - demandant à l'utilisateur de fournir un nom et un mot de passe.

    - -

    Exemple de formulaire de connexion

    <form method="POST" action="/dologin.html">
-  Username: <input type="text" name="httpd_username" value="" />
-  Password: <input type="password" name="httpd_password" value="" />
-  <input type="submit" name="login" value="Login" />
-</form>
    -
    - -

    La partie où s'effectue la connexion proprement dite est - traitée par le gestionnaire form-login-handler. - L'action de ce formulaire doit pointer vers ce gestionnaire, ce - que l'on configure dans Apache httpd comme suit :

    - -

    Exemple de configuration du gestionnaire de - formulaire de connexion

    <Location /dologin.html>
-    SetHandler form-login-handler
-    AuthFormLoginRequiredLocation http://example.com/login.html
-    AuthFormLoginSuccessLocation http://example.com/success.html
-    AuthFormProvider file
-    AuthUserFile conf/passwd
-    AuthType form
-    AuthName realm
-    Session On
-    SessionCookieName session path=/
-    SessionCryptoPassphrase secret
-</Location>
    -
    - -

    L'URL spécifiée par la directive - AuthFormLoginRequiredLocation - référencera en général une page expliquant à l'utilisateur que sa - tentative de connexion a échoué, et qu'il doit la renouveler. La - directive AuthFormLoginSuccessLocation - spécifie l'URL vers laquelle l'utilisateur doit être redirigé s'il - s'est authentifié avec succès.

    - -

    Alternativement, l'URL vers laquelle doit être redirigé - l'utilisateur s'il s'est authentifié avec succès peut être - intégrée dans le formulaire de connexion, comme dans l'exemple - ci-dessous. Il en découle que le même gestionnaire - form-login-handler pourra être utilisé pour différentes - zones du site web.

    - -

    Exemple de formulaire d'authentification multizone

    <form method="POST" action="/dologin.html">
-  Username: <input type="text" name="httpd_username" value="" />
-  Password: <input type="password" name="httpd_password" value="" />
-  <input type="submit" name="login" value="Login" />
-  <input type="hidden" name="httpd_location" value="http://example.com/success.html" />
-</form>
    -
    - -
    top
    -
    -

    Connexion à la volée

    - -

    Avertissement

    -

    Il existe un risque, dans certaines circonstances, que le - formulaire de connexion configuré pour une connexion à la volée - soit soumis plusieurs fois, révélant de ce fait les paramètres - de connexion à l'application sous-jacente. L'administrateur doit - s'assurer que cette dernière est correctement sécurisée afin - d'éviter les éventuels abus. En cas de doute, utilisez une page - de connexion indépendante dédiée.

    -
    - -

    Comme alternative à la page de connexion dédiée pour un site - web, il est possible de configurer mod_auth_form - pour authentifier les utilisateurs à la volée, sans les rediriger - vers une autre page, ce qui permet de conserver l'état de la page - courante au cours de la tentative de connexion. Ceci peut s'avérer - utile dans le cas d'une session limitée dans le temps, si le délai - de la session a expiré pendant la requête de l'utilisateur. Ce - dernier peut alors se réauthentifier à la même place, et - poursuivre son activité à partir du point où il en était resté.

    - -

    Si un utilisateur non authentifié tente d'accéder à une page - protégée par mod_auth_form, et si ce dernier - n'est pas configuré avec une directive AuthFormLoginRequiredLocation, - un code de statut HTTP_UNAUTHORIZED est renvoyé vers le - navigateur, indiquant à l'utilisateur qu'il n'est pas autorisé à - accéder à cette page.

    - -

    Pour configurer l'authentification à la volée, l'administrateur - remplace le message d'erreur renvoyé par le code de statut - HTTP_UNAUTHORIZED par un message d'erreur personnalisé - contenant le formulaire de connexion comme suit :

    - -

    Exemple simple d'authentification à la volée

    AuthFormProvider file
-ErrorDocument 401 /login.shtml
-AuthUserFile conf/passwd
-AuthType form
-AuthName realm
-AuthFormLoginRequiredLocation http://example.com/login.html
-Session On
-SessionCookieName session path=/
-SessionCryptoPassphrase secret
    -
    - -

    La page du message d'erreur doit contenir un formulaire de - connexion dont la propriété action est vide, comme dans l'exemple - ci-dessous. Ceci a pour effet de soumettre le formulaire à l'URL - protégée originale, cette dernière n'ayant pas besoin d'être - connue de la page en cours.

    - -

    Exemple de formulaire de connexion à la volée

    <form method="POST" action="">
-  Username: <input type="text" name="httpd_username" value="" />
-  Password: <input type="password" name="httpd_password" value="" />
-  <input type="submit" name="login" value="Login" />
-</form>
    -
    - -

    Lorsque l'utilisateur final a entré ses informations de - connexion, le formulaire effectue une requête HTTP POST pour l'URL - originale protégée par mot de passe. - mod_auth_form va alors intercepter cette requête - POST, et dans le cas où des champs HTML Utilisateur et Mot de - passe corrects sont présents, l'utilisateur sera connecté, et - l'URL originale protégée par mot de passe lui sera retournée en - tant que requête GET.

    - -
    top
    -
    -

    Connexion à la volée avec - conservation du contenu

    - -

    Il existe une limite à la technique de connexion à la volée - décrite ci-dessus ; si un formulaire HTML POST entraîne une - demande d'authentification ou de réauthentification, le contenu du - formulaire original envoyé par le navigateur sera perdu. Cela peut - s'avérer plus ou moins gênant pour l'utilisateur final selon la - fonction du site web.

    - -

    Comme solution à ce problème, mod_auth_form - permet d'intégrer la méthode et le contenu de la requête originale - dans le formulaire de connexion. Si l'authentification réussit, - Apache httpd pourra refaire une tentative avec la méthode et le contenu - originaux, tout en conservant l'état de la requête originale.

    - -

    Pour mettre en oeuvre la conservation du contenu, vous devez - ajouter trois champs supplémentaires au formulaire de connexion - comme dans l'exemple suivant :

    - -

    Exemple de formulaire avec conservation du - contenu

    <form method="POST" action="">
-  Username: <input type="text" name="httpd_username" value="" />
-  Password: <input type="password" name="httpd_password" value="" />
-  <input type="submit" name="login" value="Login" />
-  
      <input type="hidden" name="httpd_method" value="POST" />
-  <input type="hidden" name="httpd_mimetype" value="application/x-www-form-urlencoded" />
-  <input type="hidden" name="httpd_body" value="name1=value1&name2=value2" />
    
-</form>
    -
    - -

    La manière dont la méthode, le type MIME et le contenu de la - requête originale seront intégrés dans le formulaire de connexion - vont dépendre de la plate-forme et de la technologie utilisées au - sein du site web. -

    - -

    Une option consiste à utiliser le module - mod_include en association avec la directive - KeptBodySize, ainsi - qu'un script CGI adapté pour intégrer les variables dans le - formulaire.

    - -

    Une autre option consiste à présenter le formulaire de - connexion en utilisant un script CGI ou une autre technologie - dynamique.

    - -

    Exemple avec script CGI

            AuthFormProvider file
-        ErrorDocument 401 /cgi-bin/login.cgi
-        ...
    -
    - -
    top
    -
    -

    Déconnexion

    - -

    Pour permettre à un utilisateur de se déconnecter d'une session - particulière, vous devez configurer une page pour qu'elle soit - traitée par le gestionnaire form-logout-handler. Tout - accès à cette URL va entraîner la suppression de l'Utilisateur et - du Mot de passe de la session courante, ce qui aura pour effet de - déconnecter l'utilisateur.

    - -

    Vous pouvez spécifier une URL vers laquelle le navigateur sera - redirigé en cas de déconnection réussie, en définissant la - directive AuthFormLogoutLocation. Cette - URL devra expliquer à l'utilisateur qu'il a été déconnecté, et lui - donner la possibilité de se connecter à nouveau.

    - -

    Exemple simple de configuration de la - déconnexion

    SetHandler form-logout-handler
-AuthName realm
-AuthFormLogoutLocation http://example.com/loggedout.html
-Session On
-SessionCookieName session path=/
-SessionCryptoPassphrase secret
    -
    - -

    Notez que la déconnexion d'un utilisateur ne supprime pas la - session ; elle supprime seulement l'utilisateur et le mot de passe - de la session. Si la session qui en résulte est vide, elle sera - probablement supprimée, mais ce n'est pas garanti. Si vous voulez - être sûr que la session sera supprimée, affectez une valeur faible - à la directive SessionMaxAge, par exemple 1 - (affecter à cette directive la valeur zéro signifie une session - sans limite d'âge). -

    - -

    Exemple simple avec durée de validité de session - limitée

    SetHandler form-logout-handler
-AuthFormLogoutLocation http://example.com/loggedout.html
-Session On
-SessionMaxAge 1
-SessionCookieName session path=/
-SessionCryptoPassphrase secret
    -
    - -
    top
    -
    -

    Noms d'utilisateurs et mots de - passe

    -

    Notez que la soumission d'un formulaire implique l'encodage URL - (URLEncoding) des données du formulaire, ici le nom d'utilisateur et - le mot de passe. Vous devez donc choisir des noms d'utilisateurs et - mots de passe qui ne contiennent pas de caractères susceptibles - d'être encodés URL lors de la soumission du formulaire, sous peine - d'obtenir des résultats inattendus.

    -
    -
    top

    Directive AuthFormAuthoritative

    Description:Sets whether authorization and authentication are passed to @@ -698,6 +451,253 @@ parser has been added in 2.4.4.
    - + +
    top
    +

    AuthLDAPSearchAsUser Directive

    +
    Description:Détermine si l'autorisation et l'authentification sont confiés à @@ -508,284 +219,573 @@ r
    top
    -

    Directive AuthFormLoginRequiredLocation

    +

    Directive AuthFormLoginRequiredLocation

    + + + + + + + + +
    Description:L'URL de la page vers laquelle on doit être redirigé si une +authentification est requise
    Syntaxe:AuthFormLoginRequiredLocation url
    Défaut:none
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP +Apache. L'interprétation des expressions rationnelles est supportée +depuis la version 2.4.4.
    +

    La directive AuthFormLoginRequiredLocation + spécifie l'URL vers laquelle l'utilisateur devra être + redirigé s'il n'est pas autorisé à accéder à une page. Sa valeur est + interprétée via l'interpréteur ap_expr + avant d'être envoyée au client. Par défaut, + si un utilisateur n'est pas autorisé à accéder à une page, le code + de réponse HTTP HTTP_UNAUTHORIZED est renvoyé avec la + page spécifiée par la directive ErrorDocument. La directive AuthFormLoginRequiredLocation + permet de remplacer cette valeur par défaut.

    + +

    Vous pouvez utiliser cette directive si vous voulez présenter une + page de connexion personnalisée à vos utilisateurs.

    + + +
    +
    top
    +

    Directive AuthFormLoginSuccessLocation

    + + + + + + + + +
    Description:L'URL de la page vers laquelle on doit être redirigé en cas +de connexion réussie
    Syntaxe:AuthFormLoginSuccessLocation url
    Défaut:none
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP +Apache. L'interprétation des expressions rationnelles est supportée +depuis la version 2.4.4.
    +

    La directive AuthFormLoginSuccessLocation + spécifie l'URL vers laquelle l'utilisateur doit être + redirigé en cas de connexion réussie. Sa valeur est + interprétée via l'interpréteur ap_expr + avant d'être envoyée au client. L'effet de cette directive + peut être annulé si l'on a défini un champ de formulaire contenant + une autre URL à l'aide de la directive AuthFormLocation.

    + +

    Vous pouvez utiliser cette directive si vous possédez une URL de + connexion personnalisée, et si vous n'avez pas intégré la page de + destination dans le formulaire de connexion.

    + + +
    +
    top
    +

    Directive AuthFormLogoutLocation

    + + + + + + + + +
    Description:L'URL vers laquelle un utilisateur devra être redirigé +après s'être déconnecté
    Syntaxe:AuthFormLogoutLocation uri
    Défaut:none
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP +Apache. L'interprétation des expressions rationnelles est supportée +depuis la version 2.4.4.
    +

    La directive AuthFormLogoutLocation + spécifie l'URL de la page du serveur vers laquelle l'utilisateur + devra être redirigé s'il se déconnecte. Sa valeur est + interprétée via l'interpréteur ap_expr + avant d'être envoyée au client.

    + +

    Lorsqu'un accès est tenté sur un URI traité par le gestionnaire + form-logout-handler, la page spécifiée par cette + directive sera présentée à l'utilisateur final. Par exemple :

    + +

    Exemple

    <Location /logout>
+    SetHandler form-logout-handler
+    AuthFormLogoutLocation http://example.com/loggedout.html
+    Session on
+    #...
+</Location>
    +
    + +

    Si un utilisateur tente d'accéder à l'URI /logout/, il + sera déconnecté, et la page /loggedout.html lui sera + présentée. Assurez-vous que la page loggedout.html n'est + pas protégée par mot de passe, car dans le cas contraire, elle ne + serait pas affichée.

    + + +
    +
    top
    +

    Directive AuthFormMethod

    + + + + + + + + +
    Description:Le nom du champ de formulaire contenant la méthode de la +requête à effectuer en cas de connexion réussie
    Syntaxe:AuthFormMethod nom du champ
    Défaut:httpd_method
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP Apache
    +

    La directive AuthFormMethod + spécifie le nom du champ HTML qui, s'il existe, contiendra le type + MIME de la requête à effectuer en cas de connexion réussie.

    + +

    En ajoutant au formulaire les champs décrits dans AuthFormMethod, AuthFormMimetype et AuthFormBody, un site web sera en + mesure de relancer une requête qui a été éventuellement interrompue + par l'écran de connexion, ou par l'expiration d'un délai de + session.

    + +
    +
    top
    +

    Directive AuthFormMimetype

    + + + + + + + + +
    Description:Le nom du champ de formulaire contenant le type MIME du +corps de la requête à effectuer en cas de connexion +réussie
    Syntaxe:AuthFormMimetype nom du champ
    Défaut:httpd_mimetype
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP Apache
    +

    La directive AuthFormMimetype + spécifie le nom du champ HTML qui, s'il existe, contiendra le type + MIME de la requête à effectuer en cas de connexion réussie.

    + +

    En ajoutant au formulaire les champs décrits dans AuthFormMethod, AuthFormMimetype et AuthFormBody, un site web sera en + mesure de relancer une requête qui a été éventuellement interrompue + par l'écran de connexion, ou par l'expiration d'un délai de + session.

    + +
    +
    top
    +

    Directive AuthFormPassword

    + + + + + + + + +
    Description:Le nom du champ de formulaire qui contient le mot de passe +de connexion
    Syntaxe:AuthFormPassword nom du champ
    Défaut:httpd_password
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP Apache
    +

    La directive AuthFormPassword permet de + spécifier le nom du champ HTML qui, s'il existe, contiendra le mot + de passe qui sera utilisé pour la connexion.

    + +
    +
    top
    +

    Directive AuthFormProvider

    + + + + + + + + +
    Description:Définit le(s) fournisseur(s) d'authentification pour la +zone concernée
    Syntaxe:AuthFormProvider nom fournisseur +[nom fournisseur] ...
    Défaut:AuthFormProvider file
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Base
    Module:mod_auth_form
    +

    La directive AuthFormProvider permet de + définir quel fournisseur sera utilisé pour authentifier les + utilisateurs pour la zone concernée. Le fournisseur par défaut + file est implémenté par le module + mod_authn_file. Assurez-vous que le fournisseur + choisi soit bien présent dans le serveur.

    + +

    Exemple

    <Location /secure>
+    AuthType form
+    AuthName "private area"
+    AuthFormProvider  dbm
+    AuthDBMType        SDBM
+    AuthDBMUserFile    /www/etc/dbmpasswd
+    Require            valid-user
+    #...
+</Location>
    +
    + +

    Les différents fournisseurs sont implémentés par les modules + mod_authn_dbm, mod_authn_file, + mod_authn_dbd et + mod_authnz_ldap.

    + +
    +
    top
    +

    Directive AuthFormSitePassphrase

    + + + + + + + + +
    Description:Court-circuite l'authentification pour les sites à fort +trafic
    Syntaxe:AuthFormSitePassphrase secret
    Défaut:none
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP Apache
    +

    La directive AuthFormSitePassphrase + spécifie un mot de passe qui, s'il est présent dans la session + utilisateur, indique à Apache httpd de court-circuiter l'authentification + pour l'URL considérée. On peut l'utiliser dans le cas de sites web à + fort trafic afin de réduire la charge induite sur l'infrastructure + d'authentification.

    + +

    On peut insérer le mot de passe dans une session utilisateur en + ajoutant cette directive à la configuration concernant le + gestionnaire form-login-handler. Le gestionnaire + form-login-handler, quant à lui, effectuera toujours les + vérifications d'authentification, qu'un mot de passe soit spécifié + ou non.

    + +

    Avertissement

    +

    Si la session est présentée à l'utilisateur à l'aide du module + mod_session_cookie, et si la session n'est pas + protégée par le module mod_session_crypto, le mot + de passe peut faire l'objet d'une attaque de type dictionnaire. + Quelle que soit la configuration de la session, assurez-vous que + cette directive n'est pas utilisée dans un espace d'URLs contenant + des données privées, ou à partir desquelles des transactions + sensibles pourraient être menées. En tout état de cause, vous + devez être conscient des risques encourus avant de l'utiliser.

    +
    + + +
    +
    top
    +

    Directive AuthFormSize

    - - - + + + - +
    Description:L'URL de la page vers laquelle on doit être redirigé si une -authentification est requise
    Syntaxe:AuthFormLoginRequiredLocation url
    Défaut:none
    Description:La taille maximale en octets du formulaire dont seront +extraites les informations de connexion
    Syntaxe:AuthFormSize taille
    Défaut:8192
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP -Apache. L'interprétation des expressions rationnelles est supportée -depuis la version 2.4.4.
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP Apache
    -

    La directive AuthFormLoginRequiredLocation - spécifie l'URL vers laquelle l'utilisateur devra être - redirigé s'il n'est pas autorisé à accéder à une page. Sa valeur est - interprétée via l'interpréteur ap_expr - avant d'être envoyée au client. Par défaut, - si un utilisateur n'est pas autorisé à accéder à une page, le code - de réponse HTTP HTTP_UNAUTHORIZED est renvoyé avec la - page spécifiée par la directive ErrorDocument. La directive AuthFormLoginRequiredLocation - permet de remplacer cette valeur par défaut.

    +

    La directive AuthFormSize spécifie + la taille maximale du corps de la requête qui sera utilisée pour + trouver le formulaire de connexion.

    -

    Vous pouvez utiliser cette directive si vous voulez présenter une - page de connexion personnalisée à vos utilisateurs.

    +

    Si une requête de connexion entrante possède une taille + supérieure à cette valeur, elle sera rejetée avec le code de réponse + HTTP HTTP_REQUEST_TOO_LARGE.

    + +

    Si vous avez ajouté au formulaire des champs décrits dans AuthFormMethod, AuthFormMimetype et AuthFormBody, il est recommandé + de définir cette directive à une valeur similaire à celle de la + directive KeptBodySize.

    top
    -

    Directive AuthFormLoginSuccessLocation

    +

    Directive AuthFormUsername

    - - - + + + - +
    Description:L'URL de la page vers laquelle on doit être redirigé en cas -de connexion réussie
    Syntaxe:AuthFormLoginSuccessLocation url
    Défaut:none
    Description:Le nom du champ de formulaire qui contient le nom de +connexion
    Syntaxe:AuthFormUsername nom du champ
    Défaut:httpd_username
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP -Apache. L'interprétation des expressions rationnelles est supportée -depuis la version 2.4.4.
    Compatibilité:Disponible depuis la version 2.3.3 du serveur HTTP Apache
    -

    La directive AuthFormLoginSuccessLocation - spécifie l'URL vers laquelle l'utilisateur doit être - redirigé en cas de connexion réussie. Sa valeur est - interprétée via l'interpréteur ap_expr - avant d'être envoyée au client. L'effet de cette directive - peut être annulé si l'on a défini un champ de formulaire contenant - une autre URL à l'aide de la directive AuthFormLocation.

    +

    La directive AuthFormUsername permet de + spécifier le nom du champ HTML qui, s'il existe, contiendra le nom + d'utilisateur qui sera utilisé pour la connexion.

    -

    Vous pouvez utiliser cette directive si vous possédez une URL de - connexion personnalisée, et si vous n'avez pas intégré la page de - destination dans le formulaire de connexion.

    +
    +
    top
    +
    +

    Configuration de base

    +

    Pour protéger une URL particulière avec le module + mod_auth_form, vous devez déterminer l'endroit où + vous allez stocker votre session, ainsi que la méthode + d'authentification. Dans cet exemple simple, les informations de + connexion sont stockées dans une session à l'aide du module + mod_session_cookie, et l'authentification utilise + un fichier en s'appuyant sur le module + mod_authn_file. Si l'authentification échoue, + l'utilisateur dera redirigé vers la page du formulaire de + connexion.

    +

    Exemple simple

    AuthFormProvider file
+AuthUserFile conf/passwd
+AuthType form
+AuthName realm
+AuthFormLoginRequiredLocation http://example.com/login.html
+Session On
+SessionCookieName session path=/
+SessionCryptoPassphrase secret
    -
    top
    -

    Directive AuthFormLogoutLocation

    - - - - - - - - -
    Description:L'URL vers laquelle un utilisateur devra être redirigé -après s'être déconnecté
    Syntaxe:AuthFormLogoutLocation uri
    Défaut:none
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP -Apache. L'interprétation des expressions rationnelles est supportée -depuis la version 2.4.4.
    -

    La directive AuthFormLogoutLocation - spécifie l'URL de la page du serveur vers laquelle l'utilisateur - devra être redirigé s'il se déconnecte. Sa valeur est - interprétée via l'interpréteur ap_expr - avant d'être envoyée au client.

    -

    Lorsqu'un accès est tenté sur un URI traité par le gestionnaire - form-logout-handler, la page spécifiée par cette - directive sera présentée à l'utilisateur final. Par exemple :

    +

    L'authentification mod_auth_form est activée + en affectant la valeur form à la directive AuthType. Les directives + AuthFormProvider et + AuthUserFile + spécifient que les noms d'utilisateurs et mots de passe seront + vérifiés en utilisant le fichier choisi.

    -

    Exemple

    <Location /logout>
-    SetHandler form-logout-handler
-    AuthFormLogoutLocation http://example.com/loggedout.html
-    Session on
-    #...
+      
    Les directives Session, SessionCookieName et
+      SessionCryptoPassphrase
+      créent une session chiffrée stockée dans un cookie HTTP au niveau
+      du navigateur. Pour plus d'informations à propos des différentes
+      options de configuration des sessions, reportez-vous à la
+      documentation du module mod_session.
    
+
+      
    Dans l'exemple simple ci-dessus, une URL a été protégée par
+      mod_auth_form, mais on doit maintenant fournir
+      à l'utilisateur un moyen d'entrer un nom et un mot de passe. À cet
+      effet, on peut soit écrire une page de connexion indépendante
+      dédiée, soit inclure le formulaire de connexion dans la page
+      courante.
    
+
    top
    +
    +

    Page de connexion dédiée

    + +

    Le formulaire de connexion peut être contenu dans une page + indépendante, ou être inclus dans la page courante.

    + +

    Lorsque la connexion s'effectue à partir d'une page + indépendante et si la tentative d'authentification échoue, + l'utilisateur doit être redirigé vers un formulaire de connexion, + créé à cet effet sur le site web, en utilisant la directive + AuthFormLoginRequiredLocation. + En général, la page de connexion contiendra un formulaire HTML + demandant à l'utilisateur de fournir un nom et un mot de passe.

    + +

    Exemple de formulaire de connexion

    <form method="POST" action="/dologin.html">
+  Username: <input type="text" name="httpd_username" value="" />
+  Password: <input type="password" name="httpd_password" value="" />
+  <input type="submit" name="login" value="Login" />
+</form>
    +
    + +

    La partie où s'effectue la connexion proprement dite est + traitée par le gestionnaire form-login-handler. + L'action de ce formulaire doit pointer vers ce gestionnaire, ce + que l'on configure dans Apache httpd comme suit :

    + +

    Exemple de configuration du gestionnaire de + formulaire de connexion

    <Location /dologin.html>
+    SetHandler form-login-handler
+    AuthFormLoginRequiredLocation http://example.com/login.html
+    AuthFormLoginSuccessLocation http://example.com/success.html
+    AuthFormProvider file
+    AuthUserFile conf/passwd
+    AuthType form
+    AuthName realm
+    Session On
+    SessionCookieName session path=/
+    SessionCryptoPassphrase secret
 </Location>
    -

    Si un utilisateur tente d'accéder à l'URI /logout/, il - sera déconnecté, et la page /loggedout.html lui sera - présentée. Assurez-vous que la page loggedout.html n'est - pas protégée par mot de passe, car dans le cas contraire, elle ne - serait pas affichée.

    +

    L'URL spécifiée par la directive + AuthFormLoginRequiredLocation + référencera en général une page expliquant à l'utilisateur que sa + tentative de connexion a échoué, et qu'il doit la renouveler. La + directive AuthFormLoginSuccessLocation + spécifie l'URL vers laquelle l'utilisateur doit être redirigé s'il + s'est authentifié avec succès.

    + +

    Alternativement, l'URL vers laquelle doit être redirigé + l'utilisateur s'il s'est authentifié avec succès peut être + intégrée dans le formulaire de connexion, comme dans l'exemple + ci-dessous. Il en découle que le même gestionnaire + form-login-handler pourra être utilisé pour différentes + zones du site web.

    + +

    Exemple de formulaire d'authentification multizone

    <form method="POST" action="/dologin.html">
+  Username: <input type="text" name="httpd_username" value="" />
+  Password: <input type="password" name="httpd_password" value="" />
+  <input type="submit" name="login" value="Login" />
+  <input type="hidden" name="httpd_location" value="http://example.com/success.html" />
+</form>
    +
    + +
    top
    +
    +

    Connexion à la volée

    + +

    Avertissement

    +

    Il existe un risque, dans certaines circonstances, que le + formulaire de connexion configuré pour une connexion à la volée + soit soumis plusieurs fois, révélant de ce fait les paramètres + de connexion à l'application sous-jacente. L'administrateur doit + s'assurer que cette dernière est correctement sécurisée afin + d'éviter les éventuels abus. En cas de doute, utilisez une page + de connexion indépendante dédiée.

    +
    + +

    Comme alternative à la page de connexion dédiée pour un site + web, il est possible de configurer mod_auth_form + pour authentifier les utilisateurs à la volée, sans les rediriger + vers une autre page, ce qui permet de conserver l'état de la page + courante au cours de la tentative de connexion. Ceci peut s'avérer + utile dans le cas d'une session limitée dans le temps, si le délai + de la session a expiré pendant la requête de l'utilisateur. Ce + dernier peut alors se réauthentifier à la même place, et + poursuivre son activité à partir du point où il en était resté.

    + +

    Si un utilisateur non authentifié tente d'accéder à une page + protégée par mod_auth_form, et si ce dernier + n'est pas configuré avec une directive AuthFormLoginRequiredLocation, + un code de statut HTTP_UNAUTHORIZED est renvoyé vers le + navigateur, indiquant à l'utilisateur qu'il n'est pas autorisé à + accéder à cette page.

    +

    Pour configurer l'authentification à la volée, l'administrateur + remplace le message d'erreur renvoyé par le code de statut + HTTP_UNAUTHORIZED par un message d'erreur personnalisé + contenant le formulaire de connexion comme suit :

    +

    Exemple simple d'authentification à la volée

    AuthFormProvider file
+ErrorDocument 401 /login.shtml
+AuthUserFile conf/passwd
+AuthType form
+AuthName realm
+AuthFormLoginRequiredLocation http://example.com/login.html
+Session On
+SessionCookieName session path=/
+SessionCryptoPassphrase secret
    -
    top
    -

    Directive AuthFormMethod

    - - - - - - - - -
    Description:Le nom du champ de formulaire contenant la méthode de la -requête à effectuer en cas de connexion réussie
    Syntaxe:AuthFormMethod nom du champ
    Défaut:httpd_method
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP Apache
    -

    La directive AuthFormMethod - spécifie le nom du champ HTML qui, s'il existe, contiendra le type - MIME de la requête à effectuer en cas de connexion réussie.

    -

    En ajoutant au formulaire les champs décrits dans AuthFormMethod, AuthFormMimetype et AuthFormBody, un site web sera en - mesure de relancer une requête qui a été éventuellement interrompue - par l'écran de connexion, ou par l'expiration d'un délai de - session.

    +

    La page du message d'erreur doit contenir un formulaire de + connexion dont la propriété action est vide, comme dans l'exemple + ci-dessous. Ceci a pour effet de soumettre le formulaire à l'URL + protégée originale, cette dernière n'ayant pas besoin d'être + connue de la page en cours.

    +

    Exemple de formulaire de connexion à la volée

    <form method="POST" action="">
+  Username: <input type="text" name="httpd_username" value="" />
+  Password: <input type="password" name="httpd_password" value="" />
+  <input type="submit" name="login" value="Login" />
+</form>
    -
    top
    -

    Directive AuthFormMimetype

    - - - - - - - - -
    Description:Le nom du champ de formulaire contenant le type MIME du -corps de la requête à effectuer en cas de connexion -réussie
    Syntaxe:AuthFormMimetype nom du champ
    Défaut:httpd_mimetype
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP Apache
    -

    La directive AuthFormMimetype - spécifie le nom du champ HTML qui, s'il existe, contiendra le type - MIME de la requête à effectuer en cas de connexion réussie.

    -

    En ajoutant au formulaire les champs décrits dans AuthFormMethod, AuthFormMimetype et AuthFormBody, un site web sera en - mesure de relancer une requête qui a été éventuellement interrompue - par l'écran de connexion, ou par l'expiration d'un délai de - session.

    +

    Lorsque l'utilisateur final a entré ses informations de + connexion, le formulaire effectue une requête HTTP POST pour l'URL + originale protégée par mot de passe. + mod_auth_form va alors intercepter cette requête + POST, et dans le cas où des champs HTML Utilisateur et Mot de + passe corrects sont présents, l'utilisateur sera connecté, et + l'URL originale protégée par mot de passe lui sera retournée en + tant que requête GET.

    -
    -
    top
    -

    Directive AuthFormPassword

    - - - - - - - - -
    Description:Le nom du champ de formulaire qui contient le mot de passe -de connexion
    Syntaxe:AuthFormPassword nom du champ
    Défaut:httpd_password
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP Apache
    -

    La directive AuthFormPassword permet de - spécifier le nom du champ HTML qui, s'il existe, contiendra le mot - de passe qui sera utilisé pour la connexion.

    +
    top
    +
    +

    Connexion à la volée avec + conservation du contenu

    -
    -
    top
    -

    Directive AuthFormProvider

    - - - - - - - - -
    Description:Définit le(s) fournisseur(s) d'authentification pour la -zone concernée
    Syntaxe:AuthFormProvider nom fournisseur -[nom fournisseur] ...
    Défaut:AuthFormProvider file
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Base
    Module:mod_auth_form
    -

    La directive AuthFormProvider permet de - définir quel fournisseur sera utilisé pour authentifier les - utilisateurs pour la zone concernée. Le fournisseur par défaut - file est implémenté par le module - mod_authn_file. Assurez-vous que le fournisseur - choisi soit bien présent dans le serveur.

    +

    Il existe une limite à la technique de connexion à la volée + décrite ci-dessus ; si un formulaire HTML POST entraîne une + demande d'authentification ou de réauthentification, le contenu du + formulaire original envoyé par le navigateur sera perdu. Cela peut + s'avérer plus ou moins gênant pour l'utilisateur final selon la + fonction du site web.

    -

    Exemple

    <Location /secure>
-    AuthType form
-    AuthName "private area"
-    AuthFormProvider  dbm
-    AuthDBMType        SDBM
-    AuthDBMUserFile    /www/etc/dbmpasswd
-    Require            valid-user
-    #...
-</Location>
    -
    +

    Comme solution à ce problème, mod_auth_form + permet d'intégrer la méthode et le contenu de la requête originale + dans le formulaire de connexion. Si l'authentification réussit, + Apache httpd pourra refaire une tentative avec la méthode et le contenu + originaux, tout en conservant l'état de la requête originale.

    -

    Les différents fournisseurs sont implémentés par les modules - mod_authn_dbm, mod_authn_file, - mod_authn_dbd et - mod_authnz_ldap.

    +

    Pour mettre en oeuvre la conservation du contenu, vous devez + ajouter trois champs supplémentaires au formulaire de connexion + comme dans l'exemple suivant :

    +

    Exemple de formulaire avec conservation du + contenu

    <form method="POST" action="">
+  Username: <input type="text" name="httpd_username" value="" />
+  Password: <input type="password" name="httpd_password" value="" />
+  <input type="submit" name="login" value="Login" />
+  
      <input type="hidden" name="httpd_method" value="POST" />
+  <input type="hidden" name="httpd_mimetype" value="application/x-www-form-urlencoded" />
+  <input type="hidden" name="httpd_body" value="name1=value1&name2=value2" />
    
+</form>
    -
    top
    -

    Directive AuthFormSitePassphrase

    - - - - - - - - -
    Description:Court-circuite l'authentification pour les sites à fort -trafic
    Syntaxe:AuthFormSitePassphrase secret
    Défaut:none
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP Apache
    -

    La directive AuthFormSitePassphrase - spécifie un mot de passe qui, s'il est présent dans la session - utilisateur, indique à Apache httpd de court-circuiter l'authentification - pour l'URL considérée. On peut l'utiliser dans le cas de sites web à - fort trafic afin de réduire la charge induite sur l'infrastructure - d'authentification.

    -

    On peut insérer le mot de passe dans une session utilisateur en - ajoutant cette directive à la configuration concernant le - gestionnaire form-login-handler. Le gestionnaire - form-login-handler, quant à lui, effectuera toujours les - vérifications d'authentification, qu'un mot de passe soit spécifié - ou non.

    +

    La manière dont la méthode, le type MIME et le contenu de la + requête originale seront intégrés dans le formulaire de connexion + vont dépendre de la plate-forme et de la technologie utilisées au + sein du site web. +

    -

    Avertissement

    -

    Si la session est présentée à l'utilisateur à l'aide du module - mod_session_cookie, et si la session n'est pas - protégée par le module mod_session_crypto, le mot - de passe peut faire l'objet d'une attaque de type dictionnaire. - Quelle que soit la configuration de la session, assurez-vous que - cette directive n'est pas utilisée dans un espace d'URLs contenant - des données privées, ou à partir desquelles des transactions - sensibles pourraient être menées. En tout état de cause, vous - devez être conscient des risques encourus avant de l'utiliser.

    -
    +

    Une option consiste à utiliser le module + mod_include en association avec la directive + KeptBodySize, ainsi + qu'un script CGI adapté pour intégrer les variables dans le + formulaire.

    +

    Une autre option consiste à présenter le formulaire de + connexion en utilisant un script CGI ou une autre technologie + dynamique.

    +

    Exemple avec script CGI

            AuthFormProvider file
+        ErrorDocument 401 /cgi-bin/login.cgi
+        ...
    -
    top
    -

    Directive AuthFormSize

    - - - - - - - - -
    Description:La taille maximale en octets du formulaire dont seront -extraites les informations de connexion
    Syntaxe:AuthFormSize taille
    Défaut:8192
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.0 du serveur HTTP Apache
    -

    La directive AuthFormSize spécifie - la taille maximale du corps de la requête qui sera utilisée pour - trouver le formulaire de connexion.

    -

    Si une requête de connexion entrante possède une taille - supérieure à cette valeur, elle sera rejetée avec le code de réponse - HTTP HTTP_REQUEST_TOO_LARGE.

    +
    top
    +
    +

    Déconnexion

    -

    Si vous avez ajouté au formulaire des champs décrits dans AuthFormMethod, AuthFormMimetype et AuthFormBody, il est recommandé - de définir cette directive à une valeur similaire à celle de la - directive KeptBodySize.

    +

    Pour permettre à un utilisateur de se déconnecter d'une session + particulière, vous devez configurer une page pour qu'elle soit + traitée par le gestionnaire form-logout-handler. Tout + accès à cette URL va entraîner la suppression de l'Utilisateur et + du Mot de passe de la session courante, ce qui aura pour effet de + déconnecter l'utilisateur.

    +

    Vous pouvez spécifier une URL vers laquelle le navigateur sera + redirigé en cas de déconnection réussie, en définissant la + directive AuthFormLogoutLocation. Cette + URL devra expliquer à l'utilisateur qu'il a été déconnecté, et lui + donner la possibilité de se connecter à nouveau.

    +

    Exemple simple de configuration de la + déconnexion

    SetHandler form-logout-handler
+AuthName realm
+AuthFormLogoutLocation http://example.com/loggedout.html
+Session On
+SessionCookieName session path=/
+SessionCryptoPassphrase secret
    -
    top
    -

    Directive AuthFormUsername

    - - - - - - - - -
    Description:Le nom du champ de formulaire qui contient le nom de -connexion
    Syntaxe:AuthFormUsername nom du champ
    Défaut:httpd_username
    Contexte:répertoire
    Statut:Base
    Module:mod_auth_form
    Compatibilité:Disponible depuis la version 2.3.3 du serveur HTTP Apache
    -

    La directive AuthFormUsername permet de - spécifier le nom du champ HTML qui, s'il existe, contiendra le nom - d'utilisateur qui sera utilisé pour la connexion.

    +

    Notez que la déconnexion d'un utilisateur ne supprime pas la + session ; elle supprime seulement l'utilisateur et le mot de passe + de la session. Si la session qui en résulte est vide, elle sera + probablement supprimée, mais ce n'est pas garanti. Si vous voulez + être sûr que la session sera supprimée, affectez une valeur faible + à la directive SessionMaxAge, par exemple 1 + (affecter à cette directive la valeur zéro signifie une session + sans limite d'âge). +

    + +

    Exemple simple avec durée de validité de session + limitée

    SetHandler form-logout-handler
+AuthFormLogoutLocation http://example.com/loggedout.html
+Session On
+SessionMaxAge 1
+SessionCookieName session path=/
+SessionCryptoPassphrase secret
    + +
    top
    +
    +

    Noms d'utilisateurs et mots de + passe

    +

    Notez que la soumission d'un formulaire implique l'encodage URL + (URLEncoding) des données du formulaire, ici le nom d'utilisateur et + le mot de passe. Vous devez donc choisir des noms d'utilisateurs et + mots de passe qui ne contiennent pas de caractères susceptibles + d'être encodés URL lors de la soumission du formulaire, sous peine + d'obtenir des résultats inattendus.

    +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_authn_anon.html.en b/docs/manual/mod/mod_authn_anon.html.en index 2b5d57399b3..c023922b9e8 100644 --- a/docs/manual/mod/mod_authn_anon.html.en +++ b/docs/manual/mod/mod_authn_anon.html.en @@ -68,49 +68,6 @@

  • Example
    • top
    -
    -

    Example

    -

    The example below is combined with "normal" htpasswd-file based - authentication and allows users in additionally as 'guests' with the - following properties:

    - -
      -
    • It insists that the user enters a userID. - (Anonymous_NoUserID)
      • - -
    • It insists that the user enters a password. - (Anonymous_MustGiveEmail)
      • - -
    • The password entered must be a valid email address, i.e. - contain at least one '@' and a '.'. - (Anonymous_VerifyEmail)
      • - -
    • The userID must be one of anonymous guest www test - welcome and comparison is not case - sensitive. (Anonymous)
      • - -
    • And the Email addresses entered in the passwd field are - logged to the error log file. - (Anonymous_LogEmail)
      • -
    - -

    Example

    <Directory "/var/www/html/private">
-    AuthName "Use 'anonymous' & Email address for guest entry"
-    AuthType Basic
-    AuthBasicProvider file anon
-    AuthUserFile "/path/to/your/.htpasswd"
-    
-    Anonymous_NoUserID off
-    Anonymous_MustGiveEmail on
-    Anonymous_VerifyEmail on
-    Anonymous_LogEmail on
-    Anonymous anonymous guest www test welcome
-    
-    Require valid-user
-</Directory>
    -
    -
    -
    top

    Anonymous Directive

    at least one '@' and a '.' to encourage users to enter valid email addresses (see the above Anonymous_LogEmail).

    + +
    top
    +
    +

    Example

    +

    The example below is combined with "normal" htpasswd-file based + authentication and allows users in additionally as 'guests' with the + following properties:

    + +
      +
    • It insists that the user enters a userID. + (Anonymous_NoUserID)
      • + +
    • It insists that the user enters a password. + (Anonymous_MustGiveEmail)
      • + +
    • The password entered must be a valid email address, i.e. + contain at least one '@' and a '.'. + (Anonymous_VerifyEmail)
      • + +
    • The userID must be one of anonymous guest www test + welcome and comparison is not case + sensitive. (Anonymous)
      • + +
    • And the Email addresses entered in the passwd field are + logged to the error log file. + (Anonymous_LogEmail)
      • +
    + +

    Example

    <Directory "/var/www/html/private">
+    AuthName "Use 'anonymous' & Email address for guest entry"
+    AuthType Basic
+    AuthBasicProvider file anon
+    AuthUserFile "/path/to/your/.htpasswd"
+    
+    Anonymous_NoUserID off
+    Anonymous_MustGiveEmail on
+    Anonymous_VerifyEmail on
+    Anonymous_LogEmail on
+    Anonymous anonymous guest www test welcome
+    
+    Require valid-user
+</Directory>
    +
    diff --git a/docs/manual/mod/mod_authn_anon.html.fr b/docs/manual/mod/mod_authn_anon.html.fr index e3cd69bd463..66b19f8a2c7 100644 --- a/docs/manual/mod/mod_authn_anon.html.fr +++ b/docs/manual/mod/mod_authn_anon.html.fr @@ -73,51 +73,6 @@ prot
  • Exemple
    • top
    -
    -

    Exemple

    -

    L'exemple ci-dessous présente un exemple de combinaison avec - l'authentification à base de fichier htpasswd "normale", et permet - la connexion d'utilisateurs en tant qu'invités avec les propriétés - suivantes :

    - -
      -
    • Il incite l'utilisateur à fournir un identifiant. - (Anonymous_NoUserID)
      • - -
    • Il incite l'utilisateur à fournir un mot de passe. - (Anonymous_MustGiveEmail)
      • - -
    • Le mot de passe fourni doit être une adresse email valide, - c'est à dire contenant au moins un '@' et un '.'. - (Anonymous_VerifyEmail)
      • - -
    • Les valeurs possibles pour l'identifiant utilisateur sont - anonymous, guest, www, test ou welcome, et la - vérification n'est pas sensible à la casse. - (Anonymous)
      • - -
    • Les adresses email entrées dans le champ passwd sont - enregistrées dans le fichier journal des erreurs. - (Anonymous_LogEmail)
      • -
    - -

    Exemple

    <Directory /var/www/html/private>
-    AuthName "Use 'anonymous' & Email address for guest entry"
-    AuthType Basic
-    AuthBasicProvider file anon
-    AuthUserFile /path/to/your/.htpasswd
-
-    Anonymous_NoUserID off
-    Anonymous_MustGiveEmail on
-    Anonymous_VerifyEmail on
-    Anonymous_LogEmail on
-    Anonymous anonymous guest www test welcome
-
-    Require valid-user
-</Directory>
    -
    -
    -
    top

    Directive Anonymous

    Description:Specifies userIDs that are allowed access without @@ -209,6 +166,49 @@ formatted email address
    '.' afin d'inciter les utilisateurs à fournir des adresses email valides (voir ci-dessus la directive Anonymous_LogEmail).

    + +
    top
    +
    +

    Exemple

    +

    L'exemple ci-dessous présente un exemple de combinaison avec + l'authentification à base de fichier htpasswd "normale", et permet + la connexion d'utilisateurs en tant qu'invités avec les propriétés + suivantes :

    + +
      +
    • Il incite l'utilisateur à fournir un identifiant. + (Anonymous_NoUserID)
      • + +
    • Il incite l'utilisateur à fournir un mot de passe. + (Anonymous_MustGiveEmail)
      • + +
    • Le mot de passe fourni doit être une adresse email valide, + c'est à dire contenant au moins un '@' et un '.'. + (Anonymous_VerifyEmail)
      • + +
    • Les valeurs possibles pour l'identifiant utilisateur sont + anonymous, guest, www, test ou welcome, et la + vérification n'est pas sensible à la casse. + (Anonymous)
      • + +
    • Les adresses email entrées dans le champ passwd sont + enregistrées dans le fichier journal des erreurs. + (Anonymous_LogEmail)
      • +
    + +

    Exemple

    <Directory /var/www/html/private>
+    AuthName "Use 'anonymous' & Email address for guest entry"
+    AuthType Basic
+    AuthBasicProvider file anon
+    AuthUserFile /path/to/your/.htpasswd
+
+    Anonymous_NoUserID off
+    Anonymous_MustGiveEmail on
+    Anonymous_VerifyEmail on
+    Anonymous_LogEmail on
+    Anonymous anonymous guest www test welcome
+
+    Require valid-user
+</Directory>
    +
    diff --git a/docs/manual/mod/mod_authn_anon.html.ja.utf8 b/docs/manual/mod/mod_authn_anon.html.ja.utf8 index 69e1c4def88..0e8009e9acf 100644 --- a/docs/manual/mod/mod_authn_anon.html.ja.utf8 +++ b/docs/manual/mod/mod_authn_anon.html.ja.utf8 @@ -73,49 +73,6 @@
  • 例
    • top
    -
    -

    例

    -

    以下の例は「普通」の htpasswd ファイルに基づいた認証と組み合わされて - おり、以下の要件を見たすユーザを「ゲスト」として許可します:

    - -
      -
    • ユーザは userID を入力しなければなりません。 - (Anonymous_NoUserID)
      • - -
    • ユーザはパスワードを入力しなければなりません。 - (Anonymous_MustGiveEmail)
      • - -
    • 入力されたパスワードは有効な電子メールアドレスでなければ - なりません。すなわち、少くとも一つの '@' と '.' が - 含まれている必要があります。 - (Anonymous_VerifyEmail)
      • - -
    • userID は anonymous guest www test - welcome のどれかでなければなりません。 - ユーザ名の比較は大文字小文字を区別しません。
      • - -
    • パスワード欄に入力された電子メールアドレスはエラーログファイルに - ロギングされます。 - (Anonymous_LogEmail)
      • -
    - -

    例

    <Directory /var/www/html/private>
-    AuthName "Use 'anonymous' & Email address for guest entry"
-    AuthType Basic
-    AuthBasicProvider file anon
-    AuthUserFile /path/to/your/.htpasswd
-    
-    Anonymous_NoUserID off
-    Anonymous_MustGiveEmail on
-    Anonymous_VerifyEmail on
-    Anonymous_LogEmail on
-    Anonymous anonymous guest www test welcome
-    
-    Require valid-user
-</Directory>
    -
    -
    -
    top

    Anonymous ディレクティブ

    Description:Définit la liste des identifiants utilisateur autorisés à @@ -226,6 +181,51 @@ email fournie comme mot de passe est correct
    - + +
    top
    +

    AuthLDAPRemoteUserIsDN Directive

    +
    説明:パスワードの検査無しでアクセスを許可する userID を指定する @@ -213,6 +170,49 @@ 少なくとも一つの '@' と '.' を含んでいるかどうかを調べます (上の Anonymous_LogEmail 参照)。

    + +
    top
    +
    +

    例

    +

    以下の例は「普通」の htpasswd ファイルに基づいた認証と組み合わされて + おり、以下の要件を見たすユーザを「ゲスト」として許可します:

    + +
      +
    • ユーザは userID を入力しなければなりません。 + (Anonymous_NoUserID)
      • + +
    • ユーザはパスワードを入力しなければなりません。 + (Anonymous_MustGiveEmail)
      • + +
    • 入力されたパスワードは有効な電子メールアドレスでなければ + なりません。すなわち、少くとも一つの '@' と '.' が + 含まれている必要があります。 + (Anonymous_VerifyEmail)
      • + +
    • userID は anonymous guest www test + welcome のどれかでなければなりません。 + ユーザ名の比較は大文字小文字を区別しません。
      • + +
    • パスワード欄に入力された電子メールアドレスはエラーログファイルに + ロギングされます。 + (Anonymous_LogEmail)
      • +
    + +

    例

    <Directory /var/www/html/private>
+    AuthName "Use 'anonymous' & Email address for guest entry"
+    AuthType Basic
+    AuthBasicProvider file anon
+    AuthUserFile /path/to/your/.htpasswd
+    
+    Anonymous_NoUserID off
+    Anonymous_MustGiveEmail on
+    Anonymous_VerifyEmail on
+    Anonymous_LogEmail on
+    Anonymous anonymous guest www test welcome
+    
+    Require valid-user
+</Directory>
    +
    diff --git a/docs/manual/mod/mod_authn_anon.html.ko.euc-kr b/docs/manual/mod/mod_authn_anon.html.ko.euc-kr index 0912ddeea56..7a3dd9b7cca 100644 --- a/docs/manual/mod/mod_authn_anon.html.ko.euc-kr +++ b/docs/manual/mod/mod_authn_anon.html.ko.euc-kr @@ -66,51 +66,6 @@
  • ¿¹Á¦
    • top
    -
    -

    ¿¹Á¦

    -

    ´ÙÀ½ ¿¹´Â "ÀϹÝÀûÀÎ" htpasswd-ÆÄÀϱâ¹Ý ÀÎÁõ¿¡ Ãß°¡·Î - »ç¿ëÀÚ°¡ ´ÙÀ½ Á¶°ÇÀ» ¸¸Á·ÇÑ´Ù¸é '¼Õ´Ô(guest)'À¸·Î Á¢±ÙÇÒ - ¼ö ÀÖµµ·Ï ÇÑ´Ù:

    - -
      -
    • »ç¿ëÀÚ´Â »ç¿ëÀÚ ¾ÆÀ̵𸦠ÀÔ·ÂÇØ¾ß ÇÑ´Ù. (Anonymous_NoUserID)
      • - -
    • »ç¿ëÀÚ´Â ¾ÏÈ£¸¦ ÀÔ·ÂÇØ¾ß ÇÑ´Ù. (Anonymous_MustGiveEmail)
      • - -
    • ¾ÏÈ£·Î À¯È¿ÇÑ ÀüÀÚ¿ìÆí ÁÖ¼Ò¸¦ ÀÔ·ÂÇØ¾ß ÇÑ´Ù. ¿¹¸¦ - µé¾î ÃÖ¼ÒÇÑ '@'¿Í '.' ÇÑ°³¸¦ Æ÷ÇÔÇØ¾ß ÇÑ´Ù. (Anonymous_VerifyEmail)
      • - -
    • »ç¿ëÀÚ ¾ÆÀ̵ð´Â anonymous guest www test - welcome Áß ÇϳªÀ̸ç, ´ë¼Ò¹®ÀÚ¸¦ ±¸º°ÇÏÁö - ¾Ê´Â´Ù. (Anonymous)
      • - -
    • ±×¸®°í ¾ÏÈ£·Î ÀÔ·ÂÇÑ ÀüÀÚ¿ìÆí ÁÖ¼Ò¸¦ ¿À·ù·Î±×ÆÄÀÏ¿¡ - ±â·ÏÇÑ´Ù. (Anonymous_LogEmail)
      • -
    - -

    ¿¹Á¦

    - <Directory /foo> - - AuthName "¼Õ´ÔÀ¸·Î ¹æ¹®ÇÏ·Á¸é 'anonymous'¿Í ÀüÀÚ¿ìÆí ÁÖ¼Ò¸¦ »ç¿ëÇ϶ó"
    - AuthType Basic
    - AuthBasicProvider file anon
    - AuthUserFile /path/to/your/.htpasswd
    -
    - Anonymous_NoUserID off
    - Anonymous_MustGiveEmail on
    - Anonymous_VerifyEmail on
    - Anonymous_LogEmail on
    - Anonymous anonymous guest www test welcome
    -
    - Order Deny,Allow
    - Allow from all
    -
    - Require valid-user
    -     - </Directory> -

    -
    -
    top

    Anonymous Áö½Ã¾î

    - +

    Nested groups performance

    +

    When AuthLDAPSubGroupAttribute overlaps with + AuthLDAPGroupAttribute (as it does by default and + as required by common LDAP schemas), uncached searching for subgroups in + large groups can be very slow. If you use large, non-nested groups, set + AuthLDAPMaxSubGroupDepth to zero.

    +
    - - - - + +
    top
    +

    AuthLDAPRemoteUserAttribute Directive

    +
    ¼³¸í:¾ÏÈ£°Ë»ç¾øÀÌ Á¢±ÙÀ» Çã¿ëÇÒ »ç¿ëÀÚ ¾ÆÀ̵ðµéÀ» @@ -206,6 +161,51 @@ Æ÷ÇÔÇÏ´ÂÁö °Ë»çÇÑ´Ù (À§ÀÇ Anonymous_LogEmail Âü°í).

    +
    top
    +
    +

    ¿¹Á¦

    +

    ´ÙÀ½ ¿¹´Â "ÀϹÝÀûÀÎ" htpasswd-ÆÄÀϱâ¹Ý ÀÎÁõ¿¡ Ãß°¡·Î + »ç¿ëÀÚ°¡ ´ÙÀ½ Á¶°ÇÀ» ¸¸Á·ÇÑ´Ù¸é '¼Õ´Ô(guest)'À¸·Î Á¢±ÙÇÒ + ¼ö ÀÖµµ·Ï ÇÑ´Ù:

    + +
      +
    • »ç¿ëÀÚ´Â »ç¿ëÀÚ ¾ÆÀ̵𸦠ÀÔ·ÂÇØ¾ß ÇÑ´Ù. (Anonymous_NoUserID)
      • + +
    • »ç¿ëÀÚ´Â ¾ÏÈ£¸¦ ÀÔ·ÂÇØ¾ß ÇÑ´Ù. (Anonymous_MustGiveEmail)
      • + +
    • ¾ÏÈ£·Î À¯È¿ÇÑ ÀüÀÚ¿ìÆí ÁÖ¼Ò¸¦ ÀÔ·ÂÇØ¾ß ÇÑ´Ù. ¿¹¸¦ + µé¾î ÃÖ¼ÒÇÑ '@'¿Í '.' ÇÑ°³¸¦ Æ÷ÇÔÇØ¾ß ÇÑ´Ù. (Anonymous_VerifyEmail)
      • + +
    • »ç¿ëÀÚ ¾ÆÀ̵ð´Â anonymous guest www test + welcome Áß ÇϳªÀ̸ç, ´ë¼Ò¹®ÀÚ¸¦ ±¸º°ÇÏÁö + ¾Ê´Â´Ù. (Anonymous)
      • + +
    • ±×¸®°í ¾ÏÈ£·Î ÀÔ·ÂÇÑ ÀüÀÚ¿ìÆí ÁÖ¼Ò¸¦ ¿À·ù·Î±×ÆÄÀÏ¿¡ + ±â·ÏÇÑ´Ù. (Anonymous_LogEmail)
      • +
    + +

    ¿¹Á¦

    + <Directory /foo> + + AuthName "¼Õ´ÔÀ¸·Î ¹æ¹®ÇÏ·Á¸é 'anonymous'¿Í ÀüÀÚ¿ìÆí ÁÖ¼Ò¸¦ »ç¿ëÇ϶ó"
    + AuthType Basic
    + AuthBasicProvider file anon
    + AuthUserFile /path/to/your/.htpasswd
    +
    + Anonymous_NoUserID off
    + Anonymous_MustGiveEmail on
    + Anonymous_VerifyEmail on
    + Anonymous_LogEmail on
    + Anonymous anonymous guest www test welcome
    +
    + Order Deny,Allow
    + Allow from all
    +
    + Require valid-user
    +     + </Directory> +

    +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_authn_core.html.en b/docs/manual/mod/mod_authn_core.html.en index c218b3955a0..09d40860b8f 100644 --- a/docs/manual/mod/mod_authn_core.html.en +++ b/docs/manual/mod/mod_authn_core.html.en @@ -50,78 +50,6 @@

  • Creating Authentication Provider Aliases
    • top
    -
    -

    Creating Authentication Provider Aliases

    - -

    Extended authentication providers can be created - within the configuration file and assigned an alias name. The alias - providers can then be referenced through the directives - AuthBasicProvider or - AuthDigestProvider in - the same way as a base authentication provider. Besides the ability - to create and alias an extended provider, it also allows the same - extended authentication provider to be reference by multiple - locations.

    - -

    Examples

    - -

    This example checks for passwords in two different text - files.

    - -

    Checking multiple text password files

    # Check here first
-<AuthnProviderAlias file file1>
-    AuthUserFile "/www/conf/passwords1"
-</AuthnProviderAlias>
-
-# Then check here
-<AuthnProviderAlias file file2>   
-    AuthUserFile "/www/conf/passwords2"
-</AuthnProviderAlias>
-
-<Directory "/var/web/pages/secure">
-    AuthBasicProvider file1 file2
-    
-    AuthType Basic
-    AuthName "Protected Area"
-    Require valid-user
-</Directory>
    -
    - -

    The example below creates two different ldap authentication - provider aliases based on the ldap provider. This allows - a single authenticated location to be serviced by multiple ldap - hosts:

    - -

    Checking multiple LDAP servers

    <AuthnProviderAlias ldap ldap-alias1>
-    AuthLDAPBindDN cn=youruser,o=ctx
-    AuthLDAPBindPassword yourpassword
-    AuthLDAPURL ldap://ldap.host/o=ctx
-</AuthnProviderAlias>
-<AuthnProviderAlias ldap ldap-other-alias>
-    AuthLDAPBindDN cn=yourotheruser,o=dev
-    AuthLDAPBindPassword yourotherpassword
-    AuthLDAPURL ldap://other.ldap.host/o=dev?cn
-</AuthnProviderAlias>
-
-Alias "/secure" "/webpages/secure"
-<Directory "/webpages/secure">
-    Order deny,allow
-    Allow from all
-    
-    AuthBasicProvider ldap-other-alias  ldap-alias1
-    
-    AuthType Basic
-    AuthName "LDAP Protected Place"
-    Require valid-user
-    # Note that Require ldap-* would not work here, since the 
-    # AuthnProviderAlias does not provide the config to authorization providers
-    # that are implemented in the same module as the authentication provider.
-</Directory>
    -
    - - -
    -
    top

    AuthName Directive

  • Authentication, Authorization, and Access Control
    • + +
    top
    +
    +

    Creating Authentication Provider Aliases

    + +

    Extended authentication providers can be created + within the configuration file and assigned an alias name. The alias + providers can then be referenced through the directives + AuthBasicProvider or + AuthDigestProvider in + the same way as a base authentication provider. Besides the ability + to create and alias an extended provider, it also allows the same + extended authentication provider to be reference by multiple + locations.

    + +

    Examples

    + +

    This example checks for passwords in two different text + files.

    + +

    Checking multiple text password files

    # Check here first
+<AuthnProviderAlias file file1>
+    AuthUserFile "/www/conf/passwords1"
+</AuthnProviderAlias>
+
+# Then check here
+<AuthnProviderAlias file file2>   
+    AuthUserFile "/www/conf/passwords2"
+</AuthnProviderAlias>
+
+<Directory "/var/web/pages/secure">
+    AuthBasicProvider file1 file2
+    
+    AuthType Basic
+    AuthName "Protected Area"
+    Require valid-user
+</Directory>
    +
    + +

    The example below creates two different ldap authentication + provider aliases based on the ldap provider. This allows + a single authenticated location to be serviced by multiple ldap + hosts:

    + +

    Checking multiple LDAP servers

    <AuthnProviderAlias ldap ldap-alias1>
+    AuthLDAPBindDN cn=youruser,o=ctx
+    AuthLDAPBindPassword yourpassword
+    AuthLDAPURL ldap://ldap.host/o=ctx
+</AuthnProviderAlias>
+<AuthnProviderAlias ldap ldap-other-alias>
+    AuthLDAPBindDN cn=yourotheruser,o=dev
+    AuthLDAPBindPassword yourotherpassword
+    AuthLDAPURL ldap://other.ldap.host/o=dev?cn
+</AuthnProviderAlias>
+
+Alias "/secure" "/webpages/secure"
+<Directory "/webpages/secure">
+    Order deny,allow
+    Allow from all
+    
+    AuthBasicProvider ldap-other-alias  ldap-alias1
+    
+    AuthType Basic
+    AuthName "LDAP Protected Place"
+    Require valid-user
+    # Note that Require ldap-* would not work here, since the 
+    # AuthnProviderAlias does not provide the config to authorization providers
+    # that are implemented in the same module as the authentication provider.
+</Directory>
    +
    + +
    diff --git a/docs/manual/mod/mod_authn_core.html.fr b/docs/manual/mod/mod_authn_core.html.fr index 99cde1e0773..16d93590810 100644 --- a/docs/manual/mod/mod_authn_core.html.fr +++ b/docs/manual/mod/mod_authn_core.html.fr @@ -54,84 +54,6 @@ d'authentification
    top
    -
    -

    Création d'alias de fournisseurs -d'authentification

    - -

    Il est possible de créer des fournisseurs d'authentification - étendus dans le fichier de configuration et de leur assigner un - alias. Le fournisseur ainsi nommé peut alors être référencé à l'aide - des directives AuthBasicProvider ou AuthDigestProvider tout comme - un fournisseur d'authentification de base. Outre la possibilité de - créer et attribuer un alias à un fournisseur étendu, le même - fournisseur d'authentification peut aussi être référencé par - plusieurs sections relatives à une zone du site web.

    - -

    Exemples

    - -

    Cet exemple vérifie les mots de passe dans deux fichiers - textes différents.

    - -

    Vérification dans plusieurs fichiers de mots de - passe au format texte

    # Première vérification
-<AuthnProviderAlias file file1>
-    AuthUserFile /www/conf/passwords1
-</AuthnProviderAlias>
-
-# Vérification suivante
-<AuthnProviderAlias file file2>   
-    AuthUserFile /www/conf/passwords2
-</AuthnProviderAlias>
-
-<Directory /var/web/pages/secure>
-    AuthBasicProvider file1 file2
-    
-    AuthType Basic
-    AuthName "Protected Area"
-    Require valid-user
-</Directory>
    -
    - - - -

    Dans l'exemple ci-dessous, deux fournisseurs - d'authentification ldap sont créés à partir du fournisseur ldap - de base, et se voient attribuer un alias. L'authentification - d'une même zone peut alors être traitée par plusieurs serveurs - ldap :

    - -

    Vérification auprès de plusieurs serveurs - LDAP

    <AuthnProviderAlias ldap ldap-alias1>
-    AuthLDAPBindDN cn=youruser,o=ctx
-    AuthLDAPBindPassword yourpassword
-    AuthLDAPURL ldap://ldap.host/o=ctx
-    </AuthnProviderAlias>
-    <AuthnProviderAlias ldap ldap-other-alias>
-    AuthLDAPBindDN cn=yourotheruser,o=dev
-    AuthLDAPBindPassword yourotherpassword
-    AuthLDAPURL ldap://other.ldap.host/o=dev?cn
-</AuthnProviderAlias>
-
-Alias /secure /webpages/secure
-<Directory /webpages/secure>
-    Order deny,allow
-    Allow from all
-    
-    AuthBasicProvider ldap-other-alias  ldap-alias1
-    
-    AuthType Basic
-    AuthName LDAP_Protected Place
-    Require valid-user
-    # Notez que Require ldap-* ne fonctionnerait pas ici, car
-    # AuthnProviderAlias ne fournit pas de configuration pour les
-    # fournisseurs d'autorisation implémentés dans le même module que le
-    # fournisseur d'authentification.
-</Directory>
    -
    - - -
    -
    top

    Directive AuthName

    Description:Authorization realm for use in HTTP @@ -236,6 +164,78 @@ the specified alias
    - +

    The file contains lines in the following format:

    - - +

    + Language-Extension charset [Language-String] ... +

    - - -
    Description:L'identifiant de l'autorisation à utiliser avec @@ -250,6 +172,84 @@ l'alias sp
  • Authentification, autorisation et contrôle d'accès
    • + +
    top
    +
    +

    Création d'alias de fournisseurs +d'authentification

    + +

    Il est possible de créer des fournisseurs d'authentification + étendus dans le fichier de configuration et de leur assigner un + alias. Le fournisseur ainsi nommé peut alors être référencé à l'aide + des directives AuthBasicProvider ou AuthDigestProvider tout comme + un fournisseur d'authentification de base. Outre la possibilité de + créer et attribuer un alias à un fournisseur étendu, le même + fournisseur d'authentification peut aussi être référencé par + plusieurs sections relatives à une zone du site web.

    + +

    Exemples

    + +

    Cet exemple vérifie les mots de passe dans deux fichiers + textes différents.

    + +

    Vérification dans plusieurs fichiers de mots de + passe au format texte

    # Première vérification
+<AuthnProviderAlias file file1>
+    AuthUserFile /www/conf/passwords1
+</AuthnProviderAlias>
+
+# Vérification suivante
+<AuthnProviderAlias file file2>   
+    AuthUserFile /www/conf/passwords2
+</AuthnProviderAlias>
+
+<Directory /var/web/pages/secure>
+    AuthBasicProvider file1 file2
+    
+    AuthType Basic
+    AuthName "Protected Area"
+    Require valid-user
+</Directory>
    +
    + + + +

    Dans l'exemple ci-dessous, deux fournisseurs + d'authentification ldap sont créés à partir du fournisseur ldap + de base, et se voient attribuer un alias. L'authentification + d'une même zone peut alors être traitée par plusieurs serveurs + ldap :

    + +

    Vérification auprès de plusieurs serveurs + LDAP

    <AuthnProviderAlias ldap ldap-alias1>
+    AuthLDAPBindDN cn=youruser,o=ctx
+    AuthLDAPBindPassword yourpassword
+    AuthLDAPURL ldap://ldap.host/o=ctx
+    </AuthnProviderAlias>
+    <AuthnProviderAlias ldap ldap-other-alias>
+    AuthLDAPBindDN cn=yourotheruser,o=dev
+    AuthLDAPBindPassword yourotherpassword
+    AuthLDAPURL ldap://other.ldap.host/o=dev?cn
+</AuthnProviderAlias>
+
+Alias /secure /webpages/secure
+<Directory /webpages/secure>
+    Order deny,allow
+    Allow from all
+    
+    AuthBasicProvider ldap-other-alias  ldap-alias1
+    
+    AuthType Basic
+    AuthName LDAP_Protected Place
+    Require valid-user
+    # Notez que Require ldap-* ne fonctionnerait pas ici, car
+    # AuthnProviderAlias ne fournit pas de configuration pour les
+    # fournisseurs d'autorisation implémentés dans le même module que le
+    # fournisseur d'authentification.
+</Directory>
    +
    + +
    diff --git a/docs/manual/mod/mod_authn_dbd.html.en b/docs/manual/mod/mod_authn_dbd.html.en index f060aea2c77..84a983f0aab 100644 --- a/docs/manual/mod/mod_authn_dbd.html.en +++ b/docs/manual/mod/mod_authn_dbd.html.en @@ -74,70 +74,6 @@
  • Password Formats
    • top
    -
    -

    Performance and Cacheing

    - -

    Some users of DBD authentication in HTTPD 2.2/2.4 have reported that it -imposes a problematic load on the database. This is most likely where -an HTML page contains hundreds of objects (e.g. images, scripts, etc) -each of which requires authentication. Users affected (or concerned) -by this kind of problem should use mod_authn_socache -to cache credentials and take most of the load off the database.

    -
    top
    -
    -

    Configuration Example

    - -

    This simple example shows use of this module in the context of -the Authentication and DBD frameworks.

    -
    # mod_dbd configuration
-# UPDATED to include authentication cacheing
-DBDriver pgsql
-DBDParams "dbname=apacheauth user=apache password=xxxxxx"
-
-DBDMin  4
-DBDKeep 8
-DBDMax  20
-DBDExptime 300
-
-<Directory "/usr/www/myhost/private">
-  # mod_authn_core and mod_auth_basic configuration
-  # for mod_authn_dbd
-  AuthType Basic
-  AuthName "My Server"
-
-  # To cache credentials, put socache ahead of dbd here
-  AuthBasicProvider socache dbd
-
-  # Also required for caching: tell the cache to cache dbd lookups!
-  AuthnCacheProvideFor dbd
-  AuthnCacheContext my-server
-
-  # mod_authz_core configuration
-  Require valid-user
-
-  # mod_authn_dbd SQL query to authenticate a user
-  AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
-</Directory>
    - -
    top
    -
    -

    Exposing Login Information

    - -

    -If httpd was built against APR version 1.3.0 -or higher, then whenever a query is made to the database server, all -column values in the first row returned by the query are placed in the -environment, using environment variables with the prefix "AUTHENTICATE_". -

    -

    If a database query for example returned the username, full name -and telephone number of a user, a CGI program will have access to -this information without the need to make a second independent database -query to gather this additional information.

    -

    This has the potential to dramatically simplify the coding and -configuration required in some web applications. -

    -
    -
    top

    AuthDBDUserPWQuery Directive

    @@ -200,6 +136,70 @@ configuration required in some web applications. mod_auth_digest) is being used. See Password Formats for more information.

    + +
    top
    +
    +

    Performance and Cacheing

    + +

    Some users of DBD authentication in HTTPD 2.2/2.4 have reported that it +imposes a problematic load on the database. This is most likely where +an HTML page contains hundreds of objects (e.g. images, scripts, etc) +each of which requires authentication. Users affected (or concerned) +by this kind of problem should use mod_authn_socache +to cache credentials and take most of the load off the database.

    +
    top
    +
    +

    Configuration Example

    + +

    This simple example shows use of this module in the context of +the Authentication and DBD frameworks.

    +
    # mod_dbd configuration
+# UPDATED to include authentication cacheing
+DBDriver pgsql
+DBDParams "dbname=apacheauth user=apache password=xxxxxx"
+
+DBDMin  4
+DBDKeep 8
+DBDMax  20
+DBDExptime 300
+
+<Directory "/usr/www/myhost/private">
+  # mod_authn_core and mod_auth_basic configuration
+  # for mod_authn_dbd
+  AuthType Basic
+  AuthName "My Server"
+
+  # To cache credentials, put socache ahead of dbd here
+  AuthBasicProvider socache dbd
+
+  # Also required for caching: tell the cache to cache dbd lookups!
+  AuthnCacheProvideFor dbd
+  AuthnCacheContext my-server
+
+  # mod_authz_core configuration
+  Require valid-user
+
+  # mod_authn_dbd SQL query to authenticate a user
+  AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
+</Directory>
    + +
    top
    +
    +

    Exposing Login Information

    + +

    +If httpd was built against APR version 1.3.0 +or higher, then whenever a query is made to the database server, all +column values in the first row returned by the query are placed in the +environment, using environment variables with the prefix "AUTHENTICATE_". +

    +

    If a database query for example returned the username, full name +and telephone number of a user, a CGI program will have access to +this information without the need to make a second independent database +query to gather this additional information.

    +

    This has the potential to dramatically simplify the coding and +configuration required in some web applications. +

    diff --git a/docs/manual/mod/mod_authn_dbd.html.fr b/docs/manual/mod/mod_authn_dbd.html.fr index 219a7b2f496..ad1802dda80 100644 --- a/docs/manual/mod/mod_authn_dbd.html.fr +++ b/docs/manual/mod/mod_authn_dbd.html.fr @@ -77,75 +77,6 @@ SQL passe
    top
    -
    -

    Performances et mise en cache

    - -

    Certains utilisateurs de l'authentification DBD sous HTTPD 2.2/2.4 ont -signalé une charge problématique au niveau de la base de données. Cela -se produit en général lorsqu'une page HTML contient des centaines d'objets -(comme des images, des scripts, etc...), chacun d'entre eux nécessitant -une authentification. Les utilisateurs qui rencontrent ce genre de -problème peuvent utiliser le module mod_authn_socache -qui permet de mettre les données d'authentification en cache, et -soulager ainsi la base de données de la plus grande partie de la charge.

    -
    top
    -
    -

    Exemple de configuration

    - -

    Voici un exemple simple d'utilisation de ce module dans un contexte -d'authentification et de bases de données.

    -
    # configuration de mod_dbd
-# MISE À JOUR pour inclure la mise en cache de l'authentification
-DBDriver pgsql
-DBDParams "dbname=apacheauth user=apache password=xxxxxx"
-
-DBDMin  4
-DBDKeep 8
-DBDMax  20
-DBDExptime 300
-
-<Directory /usr/www/mon-serveur/private>
-  # configuration de mod_authn_core et mod_auth_basic
-  # pour mod_authn_dbd
-  AuthType Basic
-  AuthName "Mon serveur"
-
-  # Pour mettre en cache les données d'authentification, placez socache
-  # avant dbd
-  AuthBasicProvider socache dbd
-
-  # Aussi nécessaire à la mise en cache : dire au cache de mettre en
-  # cache les recherches dbd !
-  AuthnCacheProvideFor dbd
-  AuthnCacheContext mon-serveur
-
-  # configuration de mod_authz_core
-  Require valid-user
-
-  # la requête SQL de mod_authn_dbd pour authentifier un utilisateur
-  AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
-</Directory>
    - -
    top
    -
    -

    Mise à disposition des informations de connexion

    - -

    -Si httpd a été compilé avec la version 1.3.0 ou supérieure de -l'APR, pour chaque requête envoyée au serveur de -base de données, toutes les valeurs de colonnes du premier -enregistrement renvoyé par la requête sont affectées à des variables -d'environnement avec le préfixe "AUTHENTICATE_". -

    -

    Par exemple, si une requête renvoie un nom d'utilisateur, un nom -complet et un numéro de téléphone, un programme CGI pourra accéder à ces -informations sans avoir besoin d'effectuer une deuxième requête vers la -base de données.

    -

    Ceci va entraîner une simplification considérable du code et de la -configuration nécessaire de certaines applications web. -

    -
    -
    top

    Directive AuthDBDUserPWQuery

    Description:SQL query to look up a password for a user
  • mod_authz_groupfile
    • top
    -
    -

    Contents

    - - -
    top
    -
    -

    Operation

    - -

    There are two phases in granting access to a user. The first - phase is authentication, in which the mod_authnz_ldap - authentication provider verifies that the user's credentials are valid. - This is also called the search/bind phase. The second phase is - authorization, in which mod_authnz_ldap determines - if the authenticated user is allowed access to the resource in - question. This is also known as the compare - phase.

    +

    AuthLDAPAuthorizePrefix Directive

    +
    Description:Requête SQL servant à vérifier le mot de passe d'un @@ -219,6 +150,75 @@ passe pour un utilisateur et un identifiant d'authentification. mod_auth_digest). Voir la documentation sur les Formats de mots de passe pour plus de détails.

    + +
    top
    +
    +

    Performances et mise en cache

    + +

    Certains utilisateurs de l'authentification DBD sous HTTPD 2.2/2.4 ont +signalé une charge problématique au niveau de la base de données. Cela +se produit en général lorsqu'une page HTML contient des centaines d'objets +(comme des images, des scripts, etc...), chacun d'entre eux nécessitant +une authentification. Les utilisateurs qui rencontrent ce genre de +problème peuvent utiliser le module mod_authn_socache +qui permet de mettre les données d'authentification en cache, et +soulager ainsi la base de données de la plus grande partie de la charge.

    +
    top
    +
    +

    Exemple de configuration

    + +

    Voici un exemple simple d'utilisation de ce module dans un contexte +d'authentification et de bases de données.

    +
    # configuration de mod_dbd
+# MISE À JOUR pour inclure la mise en cache de l'authentification
+DBDriver pgsql
+DBDParams "dbname=apacheauth user=apache password=xxxxxx"
+
+DBDMin  4
+DBDKeep 8
+DBDMax  20
+DBDExptime 300
+
+<Directory /usr/www/mon-serveur/private>
+  # configuration de mod_authn_core et mod_auth_basic
+  # pour mod_authn_dbd
+  AuthType Basic
+  AuthName "Mon serveur"
+
+  # Pour mettre en cache les données d'authentification, placez socache
+  # avant dbd
+  AuthBasicProvider socache dbd
+
+  # Aussi nécessaire à la mise en cache : dire au cache de mettre en
+  # cache les recherches dbd !
+  AuthnCacheProvideFor dbd
+  AuthnCacheContext mon-serveur
+
+  # configuration de mod_authz_core
+  Require valid-user
+
+  # la requête SQL de mod_authn_dbd pour authentifier un utilisateur
+  AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
+</Directory>
    + +
    top
    +
    +

    Mise à disposition des informations de connexion

    + +

    +Si httpd a été compilé avec la version 1.3.0 ou supérieure de +l'APR, pour chaque requête envoyée au serveur de +base de données, toutes les valeurs de colonnes du premier +enregistrement renvoyé par la requête sont affectées à des variables +d'environnement avec le préfixe "AUTHENTICATE_". +

    +

    Par exemple, si une requête renvoie un nom d'utilisateur, un nom +complet et un numéro de téléphone, un programme CGI pourra accéder à ces +informations sans avoir besoin d'effectuer une deuxième requête vers la +base de données.

    +

    Ceci va entraîner une simplification considérable du code et de la +configuration nécessaire de certaines applications web. +

    diff --git a/docs/manual/mod/mod_authn_dbm.html.en b/docs/manual/mod/mod_authn_dbm.html.en index b4dd72860a2..a3de3afda3e 100644 --- a/docs/manual/mod/mod_authn_dbm.html.en +++ b/docs/manual/mod/mod_authn_dbm.html.en @@ -67,7 +67,6 @@
  • htdbm
  • Password Formats
    • -
    top

    AuthDBMType Directive

    @@ -139,6 +138,7 @@ passwords for authenticationhtdbm.

    +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_authn_dbm.html.fr b/docs/manual/mod/mod_authn_dbm.html.fr index 2c5a150b3d0..c26f6f573a7 100644 --- a/docs/manual/mod/mod_authn_dbm.html.fr +++ b/docs/manual/mod/mod_authn_dbm.html.fr @@ -68,7 +68,6 @@ d'Apache

  • Formats de mots de passe
    • -
    top

    Directive AuthDBMType

    @@ -147,6 +146,7 @@ des utilisateurs et de leurs mots de passe inclus dans le programme htdbm.

    +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_authn_dbm.html.ja.utf8 b/docs/manual/mod/mod_authn_dbm.html.ja.utf8 index 05774f11cdd..b8159d85775 100644 --- a/docs/manual/mod/mod_authn_dbm.html.ja.utf8 +++ b/docs/manual/mod/mod_authn_dbm.html.ja.utf8 @@ -68,7 +68,6 @@ AuthDigestProvider

    -
    top

    AuthDBMType ディレクティブ

    @@ -132,6 +131,7 @@ 更新したりすることができます。

    +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_authn_dbm.html.ko.euc-kr b/docs/manual/mod/mod_authn_dbm.html.ko.euc-kr index b3ea3924bad..8a56318c9d3 100644 --- a/docs/manual/mod/mod_authn_dbm.html.ko.euc-kr +++ b/docs/manual/mod/mod_authn_dbm.html.ko.euc-kr @@ -64,7 +64,6 @@ AuthDigestProvider

    -
    top

    AuthDBMType Áö½Ã¾î

    @@ -124,6 +123,7 @@ DBMÇü½Ä ¾ÏÈ£ÆÄÀÏÀ» ¸¸µé°í ¼öÁ¤ÇÑ´Ù.

    +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_authn_file.html.en b/docs/manual/mod/mod_authn_file.html.en index 58c2220c82b..b7cd33e83f2 100644 --- a/docs/manual/mod/mod_authn_file.html.en +++ b/docs/manual/mod/mod_authn_file.html.en @@ -63,7 +63,6 @@

  • htdigest
  • Password Formats
    • -
    top

    AuthUserFile Directive

    @@ -129,6 +128,7 @@ passwords for authentication +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_authn_file.html.fr b/docs/manual/mod/mod_authn_file.html.fr index 1c460758281..468d0b514b5 100644 --- a/docs/manual/mod/mod_authn_file.html.fr +++ b/docs/manual/mod/mod_authn_file.html.fr @@ -65,7 +65,6 @@ d'Apache

  • Formats de mots de passe
    • -
    top

    Directive AuthUserFile

    @@ -138,6 +137,7 @@ passe +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_authn_file.html.ja.utf8 b/docs/manual/mod/mod_authn_file.html.ja.utf8 index 756ef7b3a61..90c6c3d9d8e 100644 --- a/docs/manual/mod/mod_authn_file.html.ja.utf8 +++ b/docs/manual/mod/mod_authn_file.html.ja.utf8 @@ -67,7 +67,6 @@

  • htpasswd
  • htdigest
    • -
    top

    AuthUserFile ディレクティブ

    @@ -139,6 +138,7 @@ +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_authn_file.html.ko.euc-kr b/docs/manual/mod/mod_authn_file.html.ko.euc-kr index 11e788f3e46..e506684e5fa 100644 --- a/docs/manual/mod/mod_authn_file.html.ko.euc-kr +++ b/docs/manual/mod/mod_authn_file.html.ko.euc-kr @@ -63,7 +63,6 @@

  • htpasswd
  • htdigest
    • -
    top

    AuthUserFile Áö½Ã¾î

    @@ -122,6 +121,7 @@ +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_authn_socache.html.en b/docs/manual/mod/mod_authn_socache.html.en index 2a445617637..a799f69619d 100644 --- a/docs/manual/mod/mod_authn_socache.html.en +++ b/docs/manual/mod/mod_authn_socache.html.en @@ -53,61 +53,6 @@ the load on backends

  • Cacheing with custom modules
    • top
    -
    -

    Authentication Cacheing

    -

    Some users of more heavyweight authentication such as SQL database - lookups (mod_authn_dbd) have reported it putting an - unacceptable load on their authentication provider. A typical case - in point is where an HTML page contains hundreds of objects - (images, scripts, stylesheets, media, etc), and a request to the page - generates hundreds of effectively-immediate requests for authenticated - additional contents.

    -

    mod_authn_socache provides a solution to this problem by - maintaining a cache of authentication credentials.

    -
    top
    -
    -

    Usage

    -

    The authentication cache should be used where authentication - lookups impose a significant load on the server, or a backend or - network. Authentication by file (mod_authn_file) - or dbm (mod_authn_dbm) are unlikely to benefit, - as these are fast and lightweight in their own right (though in some - cases, such as a network-mounted file, cacheing may be worthwhile). - Other providers such as SQL or LDAP based authentication are more - likely to benefit, particularly where there is an observed - performance issue. Amongst the standard modules, mod_authnz_ldap manages its own cache, so only - mod_authn_dbd will usually benefit from this cache.

    -

    The basic rules to cache for a provider are:

    -
    1. Include the provider you're cacheing for in an - AuthnCacheProvideFor directive.
      2. -
    2. List socache ahead of the provider you're - cacheing for in your AuthBasicProvider or AuthDigestProvider directive.
      3. -
    -

    A simple usage example to accelerate mod_authn_dbd - using dbm as a cache engine:

    - 
    #AuthnCacheSOCache is optional.  If specified, it is server-wide
-AuthnCacheSOCache dbm
-<Directory "/usr/www/myhost/private">
-    AuthType Basic
-    AuthName "Cached Authentication Example"
-    AuthBasicProvider socache dbd
-    AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
-    AuthnCacheProvideFor dbd
-    Require valid-user
-    #Optional
-    AuthnCacheContext dbd-authn-example
-</Directory>
    - -
    top
    -
    -

    Cacheing with custom modules

    -

    Module developers should note that their modules must be enabled - for cacheing with mod_authn_socache. A single optional API function - ap_authn_cache_store is provided to cache credentials - a provider has just looked up or generated. Usage examples are - available in r957072, in which three authn providers are enabled for cacheing.

    -
    -
    top

    AuthnCacheContext Directive

    @@ -222,6 +167,61 @@ Apache HTTP Server 2.4.7 and later your timeout.

    +
    top
    +
    +

    Authentication Cacheing

    +

    Some users of more heavyweight authentication such as SQL database + lookups (mod_authn_dbd) have reported it putting an + unacceptable load on their authentication provider. A typical case + in point is where an HTML page contains hundreds of objects + (images, scripts, stylesheets, media, etc), and a request to the page + generates hundreds of effectively-immediate requests for authenticated + additional contents.

    +

    mod_authn_socache provides a solution to this problem by + maintaining a cache of authentication credentials.

    +
    top
    +
    +

    Usage

    +

    The authentication cache should be used where authentication + lookups impose a significant load on the server, or a backend or + network. Authentication by file (mod_authn_file) + or dbm (mod_authn_dbm) are unlikely to benefit, + as these are fast and lightweight in their own right (though in some + cases, such as a network-mounted file, cacheing may be worthwhile). + Other providers such as SQL or LDAP based authentication are more + likely to benefit, particularly where there is an observed + performance issue. Amongst the standard modules, mod_authnz_ldap manages its own cache, so only + mod_authn_dbd will usually benefit from this cache.

    +

    The basic rules to cache for a provider are:

    +
    1. Include the provider you're cacheing for in an + AuthnCacheProvideFor directive.
      2. +
    2. List socache ahead of the provider you're + cacheing for in your AuthBasicProvider or AuthDigestProvider directive.
      3. +
    +

    A simple usage example to accelerate mod_authn_dbd + using dbm as a cache engine:

    + 
    #AuthnCacheSOCache is optional.  If specified, it is server-wide
+AuthnCacheSOCache dbm
+<Directory "/usr/www/myhost/private">
+    AuthType Basic
+    AuthName "Cached Authentication Example"
+    AuthBasicProvider socache dbd
+    AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
+    AuthnCacheProvideFor dbd
+    Require valid-user
+    #Optional
+    AuthnCacheContext dbd-authn-example
+</Directory>
    + +
    top
    +
    +

    Cacheing with custom modules

    +

    Module developers should note that their modules must be enabled + for cacheing with mod_authn_socache. A single optional API function + ap_authn_cache_store is provided to cache credentials + a provider has just looked up or generated. Usage examples are + available in r957072, in which three authn providers are enabled for cacheing.

    +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_authn_socache.html.fr b/docs/manual/mod/mod_authn_socache.html.fr index a74033eaa20..7de8ee9b497 100644 --- a/docs/manual/mod/mod_authn_socache.html.fr +++ b/docs/manual/mod/mod_authn_socache.html.fr @@ -55,73 +55,6 @@ la charge des serveurs d'arri

  • La mise en cache avec les modules tiers
    • top
    -
    -

    Mise en cache des données d'authentification

    -

    Certains utilisateurs qui mettent oeuvre une authentification - lourde s'appuyant par exemple sur des requêtes SQL - (mod_authn_dbd) ont signalé une charge induite - inacceptable sur leur fournisseur d'authentification. Cela se - produit typiquement dans le cas où une page HTML contient des - centaines d'objets (images, scripts, pages de styles, media, - etc...), et où une requête pour cette page génère des centaines de - sous-requêtes à effet immédiat pour des contenus supplémentaires - authentifiés.

    -

    Pour résoudre ce problème, mod_authn_socache fournit une solution - qui permet de maintenir un cache des données d'authentification.

    -
    top
    -
    -

    Utilisation

    -

    Le cache d'authentification doit être utilisé lorsque les - requêtes d'authentification induisent une charge significative sur le - serveur, le serveur d'arrière-plan ou le réseau. Cette mise en cache - n'apportera probablement aucune amélioration dans le cas d'une - authentification à base de fichier (mod_authn_file) - ou de base de données dbm (mod_authn_dbm) car ces - méthodes sont de par leur conception rapides et légères (la mise en - cache peut cependant s'avérer utile dans le cas où le fichier est - situé sur un montage réseau). Les fournisseurs d'authentification - basés sur SQL ou LDAP ont plus de chances de tirer parti de cette - mise en cache, en particulier lorsqu'un problème de performances est - détecté. mod_authnz_ldap gérant son propre cache, - seul mod_authn_dbd est concerné par notre sujet.

    -

    Les principales règles à appliquer pour la mise en cache sont :

    -
    1. Inclure le fournisseur pour lequel vous voulez effectuer une - mise en cache dans une directive - AuthnCacheProvideFor.
      2. -
    2. Mettre socache avant le fournisseur pour lequel - vous voulez effectuer une mise en cache dans votre directive - AuthBasicProvider - ou AuthDigestProvider.
      3. -
    -

    Voici un exemple simple permettant d'accélérer - mod_authn_dbd et utilisant dbm comme moteur de la - mise en cache :

    - 
        #AuthnCacheSOCache est optionnel. S'il est défini, il l'est pour
-    #l'ensemble du serveur
-AuthnCacheSOCache dbm
-<Directory /usr/www/myhost/private>
-    AuthType Basic
-    AuthName "Cached Authentication Example"
-    AuthBasicProvider socache dbd
-    AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
-    AuthnCacheProvideFor dbd
-    Require valid-user
-    #Optionnel
-    AuthnCacheContext dbd-authn-example
-</Directory>
    - -
    top
    -
    -

    La mise en cache avec les modules tiers

    -

    Les développeurs de modules doivent savoir que la mise en cache - avec mod_authn_socache doit être activée dans leurs modules. La - fonction de l'API ap_authn_cache_store permet de - mettre en cache les données d'authentification qu'un fournisseur - vient de rechercher ou de générer. Vous trouverez des exemples - d'utilisation à r957072, où trois fournisseurs authn sont activés pour la mise - en cache.

    -
    -
    top

    Directive AuthnCacheContext

    Description:Specify a context string for use in the cache key
    définissez la durée de vie.

    +
    top
    +
    +

    Mise en cache des données d'authentification

    +

    Certains utilisateurs qui mettent oeuvre une authentification + lourde s'appuyant par exemple sur des requêtes SQL + (mod_authn_dbd) ont signalé une charge induite + inacceptable sur leur fournisseur d'authentification. Cela se + produit typiquement dans le cas où une page HTML contient des + centaines d'objets (images, scripts, pages de styles, media, + etc...), et où une requête pour cette page génère des centaines de + sous-requêtes à effet immédiat pour des contenus supplémentaires + authentifiés.

    +

    Pour résoudre ce problème, mod_authn_socache fournit une solution + qui permet de maintenir un cache des données d'authentification.

    +
    top
    +
    +

    Utilisation

    +

    Le cache d'authentification doit être utilisé lorsque les + requêtes d'authentification induisent une charge significative sur le + serveur, le serveur d'arrière-plan ou le réseau. Cette mise en cache + n'apportera probablement aucune amélioration dans le cas d'une + authentification à base de fichier (mod_authn_file) + ou de base de données dbm (mod_authn_dbm) car ces + méthodes sont de par leur conception rapides et légères (la mise en + cache peut cependant s'avérer utile dans le cas où le fichier est + situé sur un montage réseau). Les fournisseurs d'authentification + basés sur SQL ou LDAP ont plus de chances de tirer parti de cette + mise en cache, en particulier lorsqu'un problème de performances est + détecté. mod_authnz_ldap gérant son propre cache, + seul mod_authn_dbd est concerné par notre sujet.

    +

    Les principales règles à appliquer pour la mise en cache sont :

    +
    1. Inclure le fournisseur pour lequel vous voulez effectuer une + mise en cache dans une directive + AuthnCacheProvideFor.
      2. +
    2. Mettre socache avant le fournisseur pour lequel + vous voulez effectuer une mise en cache dans votre directive + AuthBasicProvider + ou AuthDigestProvider.
      3. +
    +

    Voici un exemple simple permettant d'accélérer + mod_authn_dbd et utilisant dbm comme moteur de la + mise en cache :

    + 
        #AuthnCacheSOCache est optionnel. S'il est défini, il l'est pour
+    #l'ensemble du serveur
+AuthnCacheSOCache dbm
+<Directory /usr/www/myhost/private>
+    AuthType Basic
+    AuthName "Cached Authentication Example"
+    AuthBasicProvider socache dbd
+    AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
+    AuthnCacheProvideFor dbd
+    Require valid-user
+    #Optionnel
+    AuthnCacheContext dbd-authn-example
+</Directory>
    + +
    top
    +
    +

    La mise en cache avec les modules tiers

    +

    Les développeurs de modules doivent savoir que la mise en cache + avec mod_authn_socache doit être activée dans leurs modules. La + fonction de l'API ap_authn_cache_store permet de + mettre en cache les données d'authentification qu'un fournisseur + vient de rechercher ou de générer. Vous trouverez des exemples + d'utilisation à r957072, où trois fournisseurs authn sont activés pour la mise + en cache.

    +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_authnz_fcgi.html.en b/docs/manual/mod/mod_authnz_fcgi.html.en index 57575a360e7..9c7d8d8f7a1 100644 --- a/docs/manual/mod/mod_authnz_fcgi.html.en +++ b/docs/manual/mod/mod_authnz_fcgi.html.en @@ -65,6 +65,127 @@ and Access Control

  • mod_proxy_fcgi
    • top
    +

    AuthnzFcgiCheckAuthnProvider Directive

    +
    Description:Spécifie une chaîne de contexte à utiliser dans la clé du @@ -253,6 +186,73 @@ utiliser
    + + + + + + +
    Description:Enables a FastCGI application to handle the check_authn +authentication hook.
    Syntax:AuthnzFcgiCheckAuthnProvider provider-name|None +option ...
    Default:none
    Context:directory
    Status:Extension
    Module:mod_authnz_fcgi
    +

    This directive is used to enable a FastCGI authorizer to + handle a specific processing phase of authentication or + authorization.

    + +

    Some capabilities of FastCGI authorizers require enablement + using this directive instead of + AuthBasicProvider:

    + +
      +
    • Non-Basic authentication; generally, determining the user + id of the client and returning it from the authorizer; see the + UserExpr option below
      • +
    • Selecting a custom response code; for a non-200 response + from the authorizer, the code from the authorizer will be the + status of the response
      • +
    • Setting the body of a non-200 response; if the authorizer + provides a response body with a non-200 response, that body + will be returned to the client; up to 8192 bytes of text are + supported
      • +
    + +
    +
    provider-name
    +
    This is the name of a provider defined with + AuthnzFcgiDefineProvider.
    + +
    None
    +
    Specify None to disable a provider enabled + with this directive in an outer scope, such as in a parent + directory.
    + +
    option
    +
    The following options are supported: + +
    +
    Authoritative On|Off (default On)
    +
    This controls whether or not other modules are allowed + to run when this module has a FastCGI authorizer configured + and it fails the request.
    + +
    DefaultUser userid
    +
    When the authorizer returns success and UserExpr + is configured and evaluates to an empty string (e.g., authorizer + didn't return a variable), this value will be used as the user + id. This is typically used when the authorizer has a concept of + guest, or unauthenticated, users and guest users are mapped to + some specific user id for logging and other purposes.
    + +
    RequireBasicAuth On|Off (default Off)
    +
    This controls whether or not Basic auth is required + before passing the request to the authorizer. If required, + the authorizer won't be invoked without a user id and + password; 401 will be returned for a request without that.
    + +
    UserExpr expr (no default)
    +
    When Basic authentication isn't provided by the client + and the authorizer determines the user, this expression, + evaluated after calling the authorizer, determines the + user. The expression follows + ap_expr syntax and must resolve to a string. A typical + use is to reference a Variable-XXX + setting returned by the authorizer using an option like + UserExpr "%{reqenv:XXX}". If + this option is specified and the user id can't be retrieved + using the expression after a successful authentication, the + request will be rejected with a 500 error.
    + +
    +
    +
    + +
    +
    top
    +

    AuthnzFcgiDefineProvider Directive

    + + + + + + + +
    Description:Defines a FastCGI application as a provider for +authentication and/or authorization
    Syntax:AuthnzFcgiDefineProvider type provider-name +backend-address
    Default:none
    Context:server config
    Status:Extension
    Module:mod_authnz_fcgi
    +

    This directive is used to define a FastCGI application as + a provider for a particular phase of authentication or + authorization.

    + +
    +
    type
    +
    This must be set to authn for authentication, + authz for authorization, or authnz for + a generic FastCGI authorizer which performs both checks.
    + +
    provider-name
    +
    This is used to assign a name to the provider which is + used in other directives such as + AuthBasicProvider + and + Require.
    + +
    backend-address
    +
    This specifies the address of the application, in the form + fcgi://hostname:port/. The application process(es) + must be managed independently, such as with + fcgistarter.
    +
    + +
    +
    top

    Invocation modes

    @@ -406,127 +527,6 @@ Require FooAuthnz 
    LogLevel info authnz_fcgi:trace8
    -
    -
    top
    -

    AuthnzFcgiCheckAuthnProvider Directive

    - - - - - - - -
    Description:Enables a FastCGI application to handle the check_authn -authentication hook.
    Syntax:AuthnzFcgiCheckAuthnProvider provider-name|None -option ...
    Default:none
    Context:directory
    Status:Extension
    Module:mod_authnz_fcgi
    -

    This directive is used to enable a FastCGI authorizer to - handle a specific processing phase of authentication or - authorization.

    - -

    Some capabilities of FastCGI authorizers require enablement - using this directive instead of - AuthBasicProvider:

    - -
      -
    • Non-Basic authentication; generally, determining the user - id of the client and returning it from the authorizer; see the - UserExpr option below
      • -
    • Selecting a custom response code; for a non-200 response - from the authorizer, the code from the authorizer will be the - status of the response
      • -
    • Setting the body of a non-200 response; if the authorizer - provides a response body with a non-200 response, that body - will be returned to the client; up to 8192 bytes of text are - supported
      • -
    - -
    -
    provider-name
    -
    This is the name of a provider defined with - AuthnzFcgiDefineProvider.
    - -
    None
    -
    Specify None to disable a provider enabled - with this directive in an outer scope, such as in a parent - directory.
    - -
    option
    -
    The following options are supported: - -
    -
    Authoritative On|Off (default On)
    -
    This controls whether or not other modules are allowed - to run when this module has a FastCGI authorizer configured - and it fails the request.
    - -
    DefaultUser userid
    -
    When the authorizer returns success and UserExpr - is configured and evaluates to an empty string (e.g., authorizer - didn't return a variable), this value will be used as the user - id. This is typically used when the authorizer has a concept of - guest, or unauthenticated, users and guest users are mapped to - some specific user id for logging and other purposes.
    - -
    RequireBasicAuth On|Off (default Off)
    -
    This controls whether or not Basic auth is required - before passing the request to the authorizer. If required, - the authorizer won't be invoked without a user id and - password; 401 will be returned for a request without that.
    - -
    UserExpr expr (no default)
    -
    When Basic authentication isn't provided by the client - and the authorizer determines the user, this expression, - evaluated after calling the authorizer, determines the - user. The expression follows - ap_expr syntax and must resolve to a string. A typical - use is to reference a Variable-XXX - setting returned by the authorizer using an option like - UserExpr "%{reqenv:XXX}". If - this option is specified and the user id can't be retrieved - using the expression after a successful authentication, the - request will be rejected with a 500 error.
    - -
    -
    -
    - -
    -
    top
    -

    AuthnzFcgiDefineProvider Directive

    - - - - - - - -
    Description:Defines a FastCGI application as a provider for -authentication and/or authorization
    Syntax:AuthnzFcgiDefineProvider type provider-name -backend-address
    Default:none
    Context:server config
    Status:Extension
    Module:mod_authnz_fcgi
    -

    This directive is used to define a FastCGI application as - a provider for a particular phase of authentication or - authorization.

    - -
    -
    type
    -
    This must be set to authn for authentication, - authz for authorization, or authnz for - a generic FastCGI authorizer which performs both checks.
    - -
    provider-name
    -
    This is used to assign a name to the provider which is - used in other directives such as - AuthBasicProvider - and - Require.
    - -
    backend-address
    -
    This specifies the address of the application, in the form - fcgi://hostname:port/. The application process(es) - must be managed independently, such as with - fcgistarter.
    -
    -
    diff --git a/docs/manual/mod/mod_authnz_ldap.html.en b/docs/manual/mod/mod_authnz_ldap.html.en index 0cd37010554..37e1c0e8cdc 100644 --- a/docs/manual/mod/mod_authnz_ldap.html.en +++ b/docs/manual/mod/mod_authnz_ldap.html.en @@ -102,1283 +102,1283 @@ for HTTP Basic authentication.
    + + + + + + + + +
    Description:Specifies the prefix for environment variables set during +authorization
    Syntax:AuthLDAPAuthorizePrefix prefix
    Default:AuthLDAPAuthorizePrefix AUTHORIZE_
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.6 and later
    +

    This directive allows you to override the prefix used for environment + variables set during LDAP authorization. If AUTHENTICATE_ is + specified, consumers of these environment variables see the same information + whether LDAP has performed authentication, authorization, or both.

    -

    mod_authnz_ldap registers both an authn_ldap authentication - provider and an authz_ldap authorization handler. The authn_ldap - authentication provider can be enabled through the - AuthBasicProvider directive - using the ldap value. The authz_ldap handler extends the - Require directive's authorization types - by adding ldap-user, ldap-dn and ldap-group - values.

    +

    Note

    + No authorization variables are set when a user is authorized on the basis of + Require valid-user. +
    -

    The Authentication - Phase

    +
    +
    top
    +

    AuthLDAPBindAuthoritative Directive

    + + + + + + + + +
    Description:Determines if other authentication providers are used when a user can be mapped to a DN but the server cannot successfully bind with the user's credentials.
    Syntax:AuthLDAPBindAuthoritativeoff|on
    Default:AuthLDAPBindAuthoritative on
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    +

    By default, subsequent authentication providers are only queried if a + user cannot be mapped to a DN, but not if the user can be mapped to a DN and their + password cannot be verified with an LDAP bind. + If AuthLDAPBindAuthoritative + is set to off, other configured authentication modules will have + a chance to validate the user if the LDAP bind (with the current user's credentials) + fails for any reason.

    +

    This allows users present in both LDAP and + AuthUserFile to authenticate + when the LDAP server is available but the user's account is locked or password + is otherwise unusable.

    -

    During the authentication phase, mod_authnz_ldap - searches for an entry in the directory that matches the username - that the HTTP client passes. If a single unique match is found, - then mod_authnz_ldap attempts to bind to the - directory server using the DN of the entry plus the password - provided by the HTTP client. Because it does a search, then a - bind, it is often referred to as the search/bind phase. Here are - the steps taken during the search/bind phase.

    +

    See also

    + +
    +
    top
    +

    AuthLDAPBindDN Directive

    + + + + + + + +
    Description:Optional DN to use in binding to the LDAP server
    Syntax:AuthLDAPBindDN distinguished-name
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    +

    An optional DN used to bind to the server when searching for + entries. If not provided, mod_authnz_ldap will use + an anonymous bind.

    -
      -
    1. Generate a search filter by combining the attribute and - filter provided in the AuthLDAPURL directive with - the username passed by the HTTP client.
      2. +
    +
    top
    +

    AuthLDAPBindPassword Directive

    + + + + + + + + +
    Description:Password used in conjuction with the bind DN
    Syntax:AuthLDAPBindPassword password
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:exec: was added in 2.4.5.
    +

    A bind password to use in conjunction with the bind DN. Note + that the bind password is probably sensitive data, and should be + properly protected. You should only use the AuthLDAPBindDN and AuthLDAPBindPassword if you + absolutely need them to search the directory.

    -
  • Search the directory using the generated filter. If the - search does not return exactly one entry, deny or decline - access.
    • +

    If the value begins with exec: the resulting command will be + executed and the first line returned to standard output by the + program will be used as the password.

    +
    #Password used as-is
+AuthLDAPBindPassword secret
 
-      
  • Fetch the distinguished name of the entry retrieved from
-      the search and attempt to bind to the LDAP server using that
-      DN and the password passed by the HTTP client. If the bind is
-      unsuccessful, deny or decline access.
    • 
-    
+#Run /path/to/program to get my password
+AuthLDAPBindPassword exec:/path/to/program
 
-    
    The following directives are used during the search/bind
-    phase
    
+#Run /path/to/otherProgram and provide arguments
+AuthLDAPBindPassword "exec:/path/to/otherProgram argument1"
    - - - - - - - - + +
    top
    +

    AuthLDAPCharsetConfig Directive

    +
    AuthLDAPURLSpecifies the LDAP server, the - base DN, the attribute to use in the search, as well as the - extra search filter to use.
    AuthLDAPBindDN
    + + + + + +
    Description:Language to charset conversion configuration file
    Syntax:AuthLDAPCharsetConfig file-path
    Context:server config
    Status:Extension
    Module:mod_authnz_ldap
    +

    The AuthLDAPCharsetConfig directive sets the location + of the language to charset conversion configuration file. File-path is relative + to the ServerRoot. This file specifies + the list of language extensions to character sets. + Most administrators use the provided charset.conv + file, which associates common language extensions to character sets.

    -
    		An optional DN to bind with - during the search phase.
    AuthLDAPBindPasswordAn optional password to bind - with during the search phase.
    +

    The case of the extension does not matter. Blank lines, and lines + beginning with a hash character (#) are ignored.

    +
    +
    top
    +

    AuthLDAPCompareAsUser Directive

    + + + + + + + + + +
    Description:Use the authenticated user's credentials to perform authorization comparisons
    Syntax:AuthLDAPCompareAsUser on|off
    Default:AuthLDAPCompareAsUser off
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.6 and later
    +

    When set, and mod_authnz_ldap has authenticated the + user, LDAP comparisons for authorization use the queried distinguished name (DN) + and HTTP basic authentication password of the authenticated user instead of + the servers configured credentials.

    -

    The Authorization Phase

    +

    The ldap-attribute, ldap-user, and ldap-group (single-level only) + authorization checks use comparisons.

    -

    During the authorization phase, mod_authnz_ldap - attempts to determine if the user is authorized to access the - resource. Many of these checks require - mod_authnz_ldap to do a compare operation on the - LDAP server. This is why this phase is often referred to as the - compare phase. mod_authnz_ldap accepts the - following Require - directives to determine if the credentials are acceptable:

    +

    This directive only has effect on the comparisons performed during + nested group processing when + AuthLDAPSearchAsUser is also enabled.

    -
      -
    • Grant access if there is a Require ldap-user directive, and the - username in the directive matches the username passed by the - client.
      • +

      This directive should only be used when your LDAP server doesn't + accept anonymous comparisons and you cannot use a dedicated + AuthLDAPBindDN. +

      -
    • Grant access if there is a Require - ldap-dn directive, and the DN in the directive matches - the DN fetched from the LDAP directory.
      • +

      See also

      + +
    +
    top
    +

    AuthLDAPCompareDNOnServer Directive

    + + + + + + + + +
    Description:Use the LDAP server to compare the DNs
    Syntax:AuthLDAPCompareDNOnServer on|off
    Default:AuthLDAPCompareDNOnServer on
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    +

    When set, mod_authnz_ldap will use the LDAP + server to compare the DNs. This is the only foolproof way to + compare DNs. mod_authnz_ldap will search the + directory for the DN specified with the Require dn directive, then, + retrieve the DN and compare it with the DN retrieved from the user + entry. If this directive is not set, + mod_authnz_ldap simply does a string comparison. It + is possible to get false negatives with this approach, but it is + much faster. Note the mod_ldap cache can speed up + DN comparison in most situations.

    -
  • Grant access if there is a Require ldap-group directive, and - the DN fetched from the LDAP directory (or the username - passed by the client) occurs in the LDAP group or, potentially, in - one of its sub-groups.
    • +
    +
    top
    +

    AuthLDAPDereferenceAliases Directive

    + + + + + + + + +
    Description:When will the module de-reference aliases
    Syntax:AuthLDAPDereferenceAliases never|searching|finding|always
    Default:AuthLDAPDereferenceAliases always
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    +

    This directive specifies when mod_authnz_ldap will + de-reference aliases during LDAP operations. The default is + always.

    -
  • Grant access if there is a - Require ldap-attribute - directive, and the attribute fetched from the LDAP directory - matches the given value.
    • +
    +
    top
    +

    AuthLDAPGroupAttribute Directive

    + + + + + + + + +
    Description:LDAP attributes used to identify the user members of +groups.
    Syntax:AuthLDAPGroupAttribute attribute
    Default:AuthLDAPGroupAttribute member uniquemember
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    +

    This directive specifies which LDAP attributes are used to + check for user members within groups. Multiple attributes can be used + by specifying this directive multiple times. If not specified, + then mod_authnz_ldap uses the member and + uniquemember attributes.

    -
  • Grant access if there is a - Require ldap-filter - directive, and the search filter successfully finds a single user - object that matches the dn of the authenticated user.
    • +
    +
    top
    +

    AuthLDAPGroupAttributeIsDN Directive

    + + + + + + + + +
    Description:Use the DN of the client username when checking for +group membership
    Syntax:AuthLDAPGroupAttributeIsDN on|off
    Default:AuthLDAPGroupAttributeIsDN on
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    +

    When set on, this directive says to use the + distinguished name of the client username when checking for group + membership. Otherwise, the username will be used. For example, + assume that the client sent the username bjenson, + which corresponds to the LDAP DN cn=Babs Jenson, + o=Example. If this directive is set, + mod_authnz_ldap will check if the group has + cn=Babs Jenson, o=Example as a member. If this + directive is not set, then mod_authnz_ldap will + check if the group has bjenson as a member.

    -
  • otherwise, deny or decline access
    • - +
    +
    top
    +

    AuthLDAPInitialBindAsUser Directive

    + + + + + + + + + +
    Description:Determines if the server does the initial DN lookup using the basic authentication users' +own username, instead of anonymously or with hard-coded credentials for the server
    Syntax:AuthLDAPInitialBindAsUser off|on
    Default:AuthLDAPInitialBindAsUser off
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.6 and later
    +

    By default, the server either anonymously, or with a dedicated user and + password, converts the basic authentication username into an LDAP + distinguished name (DN). This directive forces the server to use the verbatim username + and password provided by the incoming user to perform the initial DN + search.

    -

    Other Require values may also - be used which may require loading additional authorization modules.

    +

    If the verbatim username can't directly bind, but needs some + cosmetic transformation, see + AuthLDAPInitialBindPattern.

    -
      -
    • Grant access to all successfully authenticated users if - there is a Require valid-user - directive. (requires mod_authz_user)
      • +

      This directive should only be used when your LDAP server doesn't + accept anonymous searches and you cannot use a dedicated + AuthLDAPBindDN. +

      -
    • Grant access if there is a Require group directive, and - mod_authz_groupfile has been loaded with the - AuthGroupFile - directive set.
      • +

      Not available with authorization-only

      + This directive can only be used if this module authenticates the user, and + has no effect when this module is used exclusively for authorization. +
      -
    • others...
      • -
    +

    See also

    + +
    +
    top
    +

    AuthLDAPInitialBindPattern Directive

    + + + + + + + + + +
    Description:Specifies the transformation of the basic authentication username to be used when binding to the LDAP server +to perform a DN lookup
    Syntax:AuthLDAPInitialBindPatternregex substitution
    Default:AuthLDAPInitialBindPattern (.*) $1 (remote username used verbatim)
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.6 and later
    +

    If AuthLDAPInitialBindAsUser is set to + ON, the basic authentication username will be transformed according to the + regular expression and substituion arguments.

    +

    The regular expression argument is compared against the current basic authentication username. + The substitution argument may contain backreferences, but has no other variable interpolation.

    -

    mod_authnz_ldap uses the following directives during the - compare phase:

    +

    This directive should only be used when your LDAP server doesn't + accept anonymous searches and you cannot use a dedicated + AuthLDAPBindDN. +

    - - - - + 
    AuthLDAPInitialBindPattern (.+) $1@example.com
    - - + 
    AuthLDAPInitialBindPattern (.+) cn=$1,dc=example,dc=com
    - - - - +

    Not available with authorization-only

    + This directive can only be used if this module authenticates the user, and + has no effect when this module is used exclusively for authorization. +
    +

    debugging

    + The substituted DN is recorded in the environment variable + LDAP_BINDASUSER. If the regular expression does not match the input, + the verbatim username is used. +
    - - +

    See also

    + + +
    top
    +

    AuthLDAPMaxSubGroupDepth Directive

    +
    AuthLDAPURL The attribute specified in the - URL is used in compare operations for the Require - ldap-user operation.
    AuthLDAPCompareDNOnServerDetermines the behavior of the - Require ldap-dn directive.
    AuthLDAPGroupAttribute
    + + + + + + + + +
    Description:Specifies the maximum sub-group nesting depth that will be +evaluated before the user search is discontinued.
    Syntax:AuthLDAPMaxSubGroupDepth Number
    Default:AuthLDAPMaxSubGroupDepth 10
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.0 and later
    +

    When this directive is set to a non-zero value X + combined with use of the Require ldap-group someGroupDN + directive, the provided user credentials will be searched for + as a member of the someGroupDN directory object or of + any group member of the current group up to the maximum nesting + level X specified by this directive.

    +

    See the Require ldap-group + section for a more detailed example.

    -
    		Determines the attribute to - use for comparisons in the Require ldap-group - directive.
    AuthLDAPGroupAttributeIsDNSpecifies whether to use the - user DN or the username when doing comparisons for the - Require ldap-group directive.
    + + + + + + + +
    Description:Use the value of the attribute returned during the user +query to set the REMOTE_USER environment variable
    Syntax:AuthLDAPRemoteUserAttribute uid
    Default:none
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    +

    If this directive is set, the value of the + REMOTE_USER environment variable will be set to the + value of the attribute specified. Make sure that this attribute is + included in the list of attributes in the AuthLDAPUrl definition, + otherwise this directive will have no effect. This directive, if + present, takes precedence over AuthLDAPRemoteUserIsDN. This + directive is useful should you want people to log into a website + using an email address, but a backend application expects the + username as a userid.

    -
    AuthLDAPMaxSubGroupDepth
    + + + + + + + +
    Description:Use the DN of the client username to set the REMOTE_USER +environment variable
    Syntax:AuthLDAPRemoteUserIsDN on|off
    Default:AuthLDAPRemoteUserIsDN off
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    +

    If this directive is set to on, the value of the + REMOTE_USER environment variable will be set to the full + distinguished name of the authenticated user, rather than just + the username that was passed by the client. It is turned off by + default.

    -
    		Determines the maximum depth of sub-groups that will be evaluated - during comparisons in the Require ldap-group directive.
    + + + + + + + + +
    Description:Use the authenticated user's credentials to perform authorization searches
    Syntax:AuthLDAPSearchAsUser on|off
    Default:AuthLDAPSearchAsUser off
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.6 and later
    +

    When set, and mod_authnz_ldap has authenticated the + user, LDAP searches for authorization use the queried distinguished name (DN) + and HTTP basic authentication password of the authenticated user instead of + the servers configured credentials.

    -
    AuthLDAPSubGroupAttributeDetermines the attribute to use when obtaining sub-group members - of the current group during comparisons in the Require ldap-group - directive.
    AuthLDAPSubGroupClass
    + + + + + + + + +
    Description:Specifies the attribute labels, one value per +directive line, used to distinguish the members of the current group that +are groups.
    Syntax:AuthLDAPSubGroupAttribute attribute
    Default:AuthLDAPSubgroupAttribute member uniquemember
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.0 and later
    +

    An LDAP group object may contain members that are users and + members that are groups (called nested or sub groups). The + AuthLDAPSubGroupAttribute directive identifies the + labels of group members and the AuthLDAPGroupAttribute + directive identifies the labels of the user members. Multiple + attributes can be used by specifying this directive multiple times. + If not specified, then mod_authnz_ldap uses the + member and uniqueMember attributes.

    -
    		Specifies the LDAP objectClass values used to identify if queried directory - objects really are group objects (as opposed to user objects) during the - Require ldap-group directive's sub-group processing.
    +
    +
    top
    +

    AuthLDAPSubGroupClass Directive

    + + + + + + + + + +
    Description:Specifies which LDAP objectClass values identify directory +objects that are groups during sub-group processing.
    Syntax:AuthLDAPSubGroupClass LdapObjectClass
    Default:AuthLDAPSubGroupClass groupOfNames groupOfUniqueNames
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.0 and later
    +

    An LDAP group object may contain members that are users and + members that are groups (called nested or sub groups). The + AuthLDAPSubGroupAttribute directive identifies the + labels of members that may be sub-groups of the current group + (as opposed to user members). The AuthLDAPSubGroupClass + directive specifies the LDAP objectClass values used in verifying that + these potential sub-groups are in fact group objects. Verified sub-groups + can then be searched for more user or sub-group members. Multiple + attributes can be used by specifying this directive multiple times. + If not specified, then mod_authnz_ldap uses the + groupOfNames and groupOfUniqueNames values.

    -
    top
    -
    -

    The Require Directives

    +
    +
    top
    +

    AuthLDAPUrl Directive

    + + + + + + + +
    Description:URL specifying the LDAP search parameters
    Syntax:AuthLDAPUrl url [NONE|SSL|TLS|STARTTLS]
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    +

    An RFC 2255 URL which specifies the LDAP search parameters + to use. The syntax of the URL is

    +

    ldap://host:port/basedn?attribute?scope?filter

    +

    If you want to specify more than one LDAP URL that Apache should try in turn, the syntax is:

    +
    AuthLDAPUrl "ldap://ldap1.example.com ldap2.example.com/dc=..."
    -

    Apache's Require - directives are used during the authorization phase to ensure that - a user is allowed to access a resource. mod_authnz_ldap extends the - authorization types with ldap-user, ldap-dn, - ldap-group, ldap-attribute and - ldap-filter. Other authorization types may also be - used but may require that additional authorization modules be loaded.

    +

    Caveat: If you specify multiple servers, you need to enclose the entire URL string in quotes; +otherwise you will get an error: "AuthLDAPURL takes one argument, URL to define LDAP connection.." +You can of course use search parameters on each of these.

    -

    Since v2.4.8, expressions are supported - within the LDAP require directives.

    +
    +
    ldap
    -

    Require ldap-user

    +
    For regular ldap, use the + string ldap. For secure LDAP, use ldaps + instead. Secure LDAP is only available if Apache was linked + to an LDAP library with SSL support.
    -

    The Require ldap-user directive specifies what - usernames can access the resource. Once - mod_authnz_ldap has retrieved a unique DN from the - directory, it does an LDAP compare operation using the username - specified in the Require ldap-user to see if that username - is part of the just-fetched LDAP entry. Multiple users can be - granted access by putting multiple usernames on the line, - separated with spaces. If a username has a space in it, then it - must be surrounded with double quotes. Multiple users can also be - granted access by using multiple Require ldap-user - directives, with one user per line. For example, with a AuthLDAPURL of - ldap://ldap/o=Example?cn (i.e., cn is - used for searches), the following Require directives could be used - to restrict access:

    -
    Require ldap-user "Barbara Jenson"
-Require ldap-user "Fred User"
-Require ldap-user "Joe Manager"
    +
    host:port
    +
    +

    The name/port of the ldap server (defaults to + localhost:389 for ldap, and + localhost:636 for ldaps). To + specify multiple, redundant LDAP servers, just list all + servers, separated by spaces. mod_authnz_ldap + will try connecting to each server in turn, until it makes a + successful connection. If multiple ldap servers are specified, + then entire LDAP URL must be encapsulated in double quotes.

    -

    Because of the way that mod_authnz_ldap handles this - directive, Barbara Jenson could sign on as Barbara - Jenson, Babs Jenson or any other cn that - she has in her LDAP entry. Only the single Require - ldap-user line is needed to support all values of the attribute - in the user's entry.

    +

    Once a connection has been made to a server, that + connection remains active for the life of the + httpd process, or until the LDAP server goes + down.

    -

    If the uid attribute was used instead of the - cn attribute in the URL above, the above three lines - could be condensed to

    -
    Require ldap-user bjenson fuser jmanager
    +

    If the LDAP server goes down and breaks an existing + connection, mod_authnz_ldap will attempt to + re-connect, starting with the primary server, and trying + each redundant server in turn. Note that this is different + than a true round-robin search.

    +
    +
    basedn
    +
    The DN of the branch of the + directory where all searches should start from. At the very + least, this must be the top of your directory tree, but + could also specify a subtree in the directory.
    -

    Require ldap-group

    +
    attribute
    -

    This directive specifies an LDAP group whose members are - allowed access. It takes the distinguished name of the LDAP - group. Note: Do not surround the group name with quotes. - For example, assume that the following entry existed in - the LDAP directory:

    -
    dn: cn=Administrators, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Barbara Jenson, o=Example
-uniqueMember: cn=Fred User, o=Example
    +
    The attribute to search for. + Although RFC 2255 allows a comma-separated list of + attributes, only the first attribute will be used, no + matter how many are provided. If no attributes are + provided, the default is to use uid. It's a good + idea to choose an attribute that will be unique across all + entries in the subtree you will be using. All attributes + listed will be put into the environment with an AUTHENTICATE_ prefix + for use by other modules.
    -

    The following directive would grant access to both Fred and - Barbara:

    -
    Require ldap-group cn=Administrators, o=Example
    +
    scope
    +
    The scope of the search. Can be either one or + sub. Note that a scope of base is + also supported by RFC 2255, but is not supported by this + module. If the scope is not provided, or if base scope + is specified, the default is to use a scope of + sub.
    -

    Members can also be found within sub-groups of a specified LDAP group - if AuthLDAPMaxSubGroupDepth - is set to a value greater than 0. For example, assume the following entries - exist in the LDAP directory:

    -
    dn: cn=Employees, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Managers, o=Example
-uniqueMember: cn=Administrators, o=Example
-uniqueMember: cn=Users, o=Example
+
    filter
    
 
-dn: cn=Managers, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Bob Ellis, o=Example
-uniqueMember: cn=Tom Jackson, o=Example
+        
    A valid LDAP search filter. If
+        not provided, defaults to (objectClass=*), which
+        will search for all objects in the tree. Filters are
+        limited to approximately 8000 characters (the definition of
+        MAX_STRING_LEN in the Apache source code). This
+        should be more than sufficient for any application. In 2.4.10 and later,
+        The word "none" may be used to not use any filter, which may be 
+        required by some primitive LDAP servers.
    
+
    -dn: cn=Administrators, o=Example -objectClass: groupOfUniqueNames -uniqueMember: cn=Barbara Jenson, o=Example -uniqueMember: cn=Fred User, o=Example +

    When doing searches, the attribute, filter and username passed + by the HTTP client are combined to create a search filter that + looks like + (&(filter)(attribute=username)).

    -dn: cn=Users, o=Example -objectClass: groupOfUniqueNames -uniqueMember: cn=Allan Jefferson, o=Example -uniqueMember: cn=Paul Tilley, o=Example -uniqueMember: cn=Temporary Employees, o=Example +

    For example, consider an URL of + ldap://ldap.example.com/o=Example?cn?sub?(posixid=*). When + a client attempts to connect using a username of Babs + Jenson, the resulting search filter will be + (&(posixid=*)(cn=Babs Jenson)).

    -dn: cn=Temporary Employees, o=Example -objectClass: groupOfUniqueNames -uniqueMember: cn=Jim Swenson, o=Example -uniqueMember: cn=Elliot Rhodes, o=Example
    +

    An optional parameter can be added to allow the LDAP Url to override + the connection type. This parameter can be one of the following:

    -

    The following directives would allow access for Bob Ellis, Tom Jackson, - Barbara Jenson, Fred User, Allan Jefferson, and Paul Tilley but would not - allow access for Jim Swenson, or Elliot Rhodes (since they are at a - sub-group depth of 2):

    -
    Require ldap-group cn=Employees, o=Example
-AuthLDAPMaxSubGroupDepth 1
    +
    +
    NONE
    +
    Establish an unsecure connection on the default LDAP port. This + is the same as ldap:// on port 389.
    +
    SSL
    +
    Establish a secure connection on the default secure LDAP port. + This is the same as ldaps://
    +
    TLS | STARTTLS
    +
    Establish an upgraded secure connection on the default LDAP port. + This connection will be initiated on port 389 by default and then + upgraded to a secure connection on the same port.
    +
    + +

    See above for examples of AuthLDAPURL URLs.

    + +
    top
    +
    +

    Contents

    -

    Behavior of this directive is modified by the AuthLDAPGroupAttribute, AuthLDAPGroupAttributeIsDN, AuthLDAPMaxSubGroupDepth, AuthLDAPSubGroupAttribute, and AuthLDAPSubGroupClass - directives.

    + +
    top
    +
    +

    Operation

    +

    There are two phases in granting access to a user. The first + phase is authentication, in which the mod_authnz_ldap + authentication provider verifies that the user's credentials are valid. + This is also called the search/bind phase. The second phase is + authorization, in which mod_authnz_ldap determines + if the authenticated user is allowed access to the resource in + question. This is also known as the compare + phase.

    -

    Require ldap-attribute

    +

    mod_authnz_ldap registers both an authn_ldap authentication + provider and an authz_ldap authorization handler. The authn_ldap + authentication provider can be enabled through the + AuthBasicProvider directive + using the ldap value. The authz_ldap handler extends the + Require directive's authorization types + by adding ldap-user, ldap-dn and ldap-group + values.

    -

    The Require ldap-attribute directive allows the - administrator to grant access based on attributes of the authenticated - user in the LDAP directory. If the attribute in the directory - matches the value given in the configuration, access is granted.

    +

    The Authentication + Phase

    -

    The following directive would grant access to anyone with - the attribute employeeType = active

    +

    During the authentication phase, mod_authnz_ldap + searches for an entry in the directory that matches the username + that the HTTP client passes. If a single unique match is found, + then mod_authnz_ldap attempts to bind to the + directory server using the DN of the entry plus the password + provided by the HTTP client. Because it does a search, then a + bind, it is often referred to as the search/bind phase. Here are + the steps taken during the search/bind phase.

    - 
    Require ldap-attribute employeeType=active
    +
      +
    1. Generate a search filter by combining the attribute and + filter provided in the AuthLDAPURL directive with + the username passed by the HTTP client.
      2. +
    2. Search the directory using the generated filter. If the + search does not return exactly one entry, deny or decline + access.
      3. -

      Multiple attribute/value pairs can be specified on the same line - separated by spaces or they can be specified in multiple - Require ldap-attribute directives. The effect of listing - multiple attribute/values pairs is an OR operation. Access will be - granted if any of the listed attribute values match the value of the - corresponding attribute in the user object. If the value of the - attribute contains a space, only the value must be within double quotes.

      +
    3. Fetch the distinguished name of the entry retrieved from + the search and attempt to bind to the LDAP server using that + DN and the password passed by the HTTP client. If the bind is + unsuccessful, deny or decline access.
      4. +
    -

    The following directive would grant access to anyone with - the city attribute equal to "San Jose" or status equal to "Active"

    +

    The following directives are used during the search/bind + phase

    - 
    Require ldap-attribute city="San Jose" status=active
    + + + + + + + + + + -

    Require ldap-filter

    + + -

    The Require ldap-filter directive allows the - administrator to grant access based on a complex LDAP search filter. - If the dn returned by the filter search matches the authenticated user - dn, access is granted.

    + + +
    AuthLDAPURLSpecifies the LDAP server, the + base DN, the attribute to use in the search, as well as the + extra search filter to use.
    AuthLDAPBindDNAn optional DN to bind with + during the search phase.
    AuthLDAPBindPasswordAn optional password to bind + with during the search phase.
    -

    The following directive would grant access to anyone having a cell phone - and is in the marketing department

    - 
    Require ldap-filter &(cell=*)(department=marketing)
    +

    The Authorization Phase

    +

    During the authorization phase, mod_authnz_ldap + attempts to determine if the user is authorized to access the + resource. Many of these checks require + mod_authnz_ldap to do a compare operation on the + LDAP server. This is why this phase is often referred to as the + compare phase. mod_authnz_ldap accepts the + following Require + directives to determine if the credentials are acceptable:

    -

    The difference between the Require ldap-filter directive and the - Require ldap-attribute directive is that ldap-filter - performs a search operation on the LDAP directory using the specified search - filter rather than a simple attribute comparison. If a simple attribute - comparison is all that is required, the comparison operation performed by - ldap-attribute will be faster than the search operation - used by ldap-filter especially within a large directory.

    +
      +
    • Grant access if there is a Require ldap-user directive, and the + username in the directive matches the username passed by the + client.
      • +
    • Grant access if there is a Require + ldap-dn directive, and the DN in the directive matches + the DN fetched from the LDAP directory.
      • +
    • Grant access if there is a Require ldap-group directive, and + the DN fetched from the LDAP directory (or the username + passed by the client) occurs in the LDAP group or, potentially, in + one of its sub-groups.
      • -
    top
    -
    -

    Examples

    +
  • Grant access if there is a + Require ldap-attribute + directive, and the attribute fetched from the LDAP directory + matches the given value.
    • -
      -
    • - Grant access to anyone who exists in the LDAP directory, - using their UID for searches. -
      AuthLDAPURL "ldap://ldap1.example.com:389/ou=People, o=Example?uid?sub?(objectClass=*)"
-Require valid-user
      +
    • Grant access if there is a + Require ldap-filter + directive, and the search filter successfully finds a single user + object that matches the dn of the authenticated user.
      • - +
    • otherwise, deny or decline access
      • +
    -
  • - The next example is the same as above; but with the fields - that have useful defaults omitted. Also, note the use of a - redundant LDAP server. -
    AuthLDAPURL "ldap://ldap1.example.com ldap2.example.com/ou=People, o=Example"
-Require valid-user
    +

    Other Require values may also + be used which may require loading additional authorization modules.

    -
    • +
      +
    • Grant access to all successfully authenticated users if + there is a Require valid-user + directive. (requires mod_authz_user)
      • -
    • - The next example is similar to the previous one, but it - uses the common name instead of the UID. Note that this - could be problematical if multiple people in the directory - share the same cn, because a search on cn - must return exactly one entry. That's why - this approach is not recommended: it's a better idea to - choose an attribute that is guaranteed unique in your - directory, such as uid. -
      AuthLDAPURL "ldap://ldap.example.com/ou=People, o=Example?cn"
-Require valid-user
      +
    • Grant access if there is a Require group directive, and + mod_authz_groupfile has been loaded with the + AuthGroupFile + directive set.
      • - +
    • others...
      • +
    -
  • - Grant access to anybody in the Administrators group. The - users must authenticate using their UID. -
    AuthLDAPURL ldap://ldap.example.com/o=Example?uid
-Require ldap-group cn=Administrators, o=Example
    -
    • +

    mod_authnz_ldap uses the following directives during the + compare phase:

    -
  • - Grant access to anybody in the group whose name matches the - hostname of the virtual host. In this example an - expression is used to build the filter. -
    AuthLDAPURL ldap://ldap.example.com/o=Example?uid
-Require ldap-group cn=%{SERVER_NAME}, o=Example
    + + + + - + + -
  • - The next example assumes that everyone at Example who - carries an alphanumeric pager will have an LDAP attribute - of qpagePagerID. The example will grant access - only to people (authenticated via their UID) who have - alphanumeric pagers: -
    AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(qpagePagerID=*)
-Require valid-user
    +
    • + - + + -
  • -

    The next example demonstrates the power of using filters - to accomplish complicated administrative requirements. - Without filters, it would have been necessary to create a - new LDAP group and ensure that the group's members remain - synchronized with the pager users. This becomes trivial - with filters. The goal is to grant access to anyone who has - a pager, plus grant access to Joe Manager, who doesn't - have a pager, but does need to access the same - resource:

    -
    AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(|(qpagePagerID=*)(uid=jmanager))
-Require valid-user
    +
    • + + + -

    This last may look confusing at first, so it helps to - evaluate what the search filter will look like based on who - connects, as shown below. If - Fred User connects as fuser, the filter would look - like

    + + -

    (&(|(qpagePagerID=*)(uid=jmanager))(uid=fuser))

    + + -

    The above search will only succeed if fuser has a - pager. When Joe Manager connects as jmanager, the - filter looks like

    + + -

    (&(|(qpagePagerID=*)(uid=jmanager))(uid=jmanager))

    + + -

    The above search will succeed whether jmanager - has a pager or not.

    - - -
    top
    -
    -

    Using TLS

    +
    + -

    To use TLS, see the mod_ldap directives LDAPTrustedClientCert, LDAPTrustedGlobalCert and LDAPTrustedMode.

    + + -

    An optional second parameter can be added to the - AuthLDAPURL to override - the default connection type set by LDAPTrustedMode. - This will allow the connection established by an ldap:// Url - to be upgraded to a secure connection on the same port.

    -
    top
    -
    -

    Using SSL

    +
    + -

    To use SSL, see the mod_ldap directives LDAPTrustedClientCert, LDAPTrustedGlobalCert and LDAPTrustedMode.

    + + +
    AuthLDAPURL The attribute specified in the + URL is used in compare operations for the Require + ldap-user operation.
    AuthLDAPCompareDNOnServerDetermines the behavior of the + Require ldap-dn directive.
    AuthLDAPGroupAttributeDetermines the attribute to + use for comparisons in the Require ldap-group + directive.
    AuthLDAPGroupAttributeIsDNSpecifies whether to use the + user DN or the username when doing comparisons for the + Require ldap-group directive.
    AuthLDAPMaxSubGroupDepthDetermines the maximum depth of sub-groups that will be evaluated + during comparisons in the Require ldap-group directive.
    AuthLDAPSubGroupAttributeDetermines the attribute to use when obtaining sub-group members + of the current group during comparisons in the Require ldap-group + directive.
    AuthLDAPSubGroupClassSpecifies the LDAP objectClass values used to identify if queried directory + objects really are group objects (as opposed to user objects) during the + Require ldap-group directive's sub-group processing.
    -

    To specify a secure LDAP server, use ldaps:// in the - AuthLDAPURL - directive, instead of ldap://.

    • top
    -

    Exposing Login Information

    +

    The Require Directives

    -

    when this module performs authentication, ldap attributes specified - in the authldapurl - directive are placed in environment variables with the prefix "AUTHENTICATE_".

    +

    Apache's Require + directives are used during the authorization phase to ensure that + a user is allowed to access a resource. mod_authnz_ldap extends the + authorization types with ldap-user, ldap-dn, + ldap-group, ldap-attribute and + ldap-filter. Other authorization types may also be + used but may require that additional authorization modules be loaded.

    -

    when this module performs authorization, ldap attributes specified - in the authldapurl - directive are placed in environment variables with the prefix "AUTHORIZE_".

    +

    Since v2.4.8, expressions are supported + within the LDAP require directives.

    -

    If the attribute field contains the username, common name - and telephone number of a user, a CGI program will have access to - this information without the need to make a second independent LDAP - query to gather this additional information.

    +

    Require ldap-user

    -

    This has the potential to dramatically simplify the coding and - configuration required in some web applications.

    +

    The Require ldap-user directive specifies what + usernames can access the resource. Once + mod_authnz_ldap has retrieved a unique DN from the + directory, it does an LDAP compare operation using the username + specified in the Require ldap-user to see if that username + is part of the just-fetched LDAP entry. Multiple users can be + granted access by putting multiple usernames on the line, + separated with spaces. If a username has a space in it, then it + must be surrounded with double quotes. Multiple users can also be + granted access by using multiple Require ldap-user + directives, with one user per line. For example, with a AuthLDAPURL of + ldap://ldap/o=Example?cn (i.e., cn is + used for searches), the following Require directives could be used + to restrict access:

    +
    Require ldap-user "Barbara Jenson"
+Require ldap-user "Fred User"
+Require ldap-user "Joe Manager"
    -
    top
    -
    -

    Using Active Directory

    -

    An Active Directory installation may support multiple domains at the - same time. To distinguish users between domains, an identifier called - a User Principle Name (UPN) can be added to a user's entry in the - directory. This UPN usually takes the form of the user's account - name, followed by the domain components of the particular domain, - for example somebody@nz.example.com.

    +

    Because of the way that mod_authnz_ldap handles this + directive, Barbara Jenson could sign on as Barbara + Jenson, Babs Jenson or any other cn that + she has in her LDAP entry. Only the single Require + ldap-user line is needed to support all values of the attribute + in the user's entry.

    -

    You may wish to configure the mod_authnz_ldap - module to authenticate users present in any of the domains making up - the Active Directory forest. In this way both - somebody@nz.example.com and someone@au.example.com - can be authenticated using the same query at the same time.

    +

    If the uid attribute was used instead of the + cn attribute in the URL above, the above three lines + could be condensed to

    +
    Require ldap-user bjenson fuser jmanager
    -

    To make this practical, Active Directory supports the concept of - a Global Catalog. This Global Catalog is a read only copy of selected - attributes of all the Active Directory servers within the Active - Directory forest. Querying the Global Catalog allows all the domains - to be queried in a single query, without the query spanning servers - over potentially slow links.

    -

    If enabled, the Global Catalog is an independent directory server - that runs on port 3268 (3269 for SSL). To search for a user, do a - subtree search for the attribute userPrincipalName, with - an empty search root, like so:

    -
    AuthLDAPBindDN apache@example.com
-AuthLDAPBindPassword password
-AuthLDAPURL ldap://10.0.0.1:3268/?userPrincipalName?sub
    +

    Require ldap-group

    +

    This directive specifies an LDAP group whose members are + allowed access. It takes the distinguished name of the LDAP + group. Note: Do not surround the group name with quotes. + For example, assume that the following entry existed in + the LDAP directory:

    +
    dn: cn=Administrators, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Barbara Jenson, o=Example
+uniqueMember: cn=Fred User, o=Example
    -

    Users will need to enter their User Principal Name as a login, in - the form somebody@nz.example.com.

    +

    The following directive would grant access to both Fred and + Barbara:

    +
    Require ldap-group cn=Administrators, o=Example
    -
    top
    -
    -

    Using Microsoft - FrontPage with mod_authnz_ldap

    -

    Normally, FrontPage uses FrontPage-web-specific user/group - files (i.e., the mod_authn_file and - mod_authz_groupfile modules) to handle all - authentication. Unfortunately, it is not possible to just - change to LDAP authentication by adding the proper directives, - because it will break the Permissions forms in - the FrontPage client, which attempt to modify the standard - text-based authorization files.

    +

    Members can also be found within sub-groups of a specified LDAP group + if AuthLDAPMaxSubGroupDepth + is set to a value greater than 0. For example, assume the following entries + exist in the LDAP directory:

    +
    dn: cn=Employees, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Managers, o=Example
+uniqueMember: cn=Administrators, o=Example
+uniqueMember: cn=Users, o=Example
 
-    
    Once a FrontPage web has been created, adding LDAP
-    authentication to it is a matter of adding the following
-    directives to every .htaccess file
-    that gets created in the web
    
-
    AuthLDAPURL       "the url"
-AuthGroupFile     "mygroupfile"
-Require group     "mygroupfile"
    
+dn: cn=Managers, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Bob Ellis, o=Example
+uniqueMember: cn=Tom Jackson, o=Example
 
+dn: cn=Administrators, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Barbara Jenson, o=Example
+uniqueMember: cn=Fred User, o=Example
 
-
    How It Works
    
+dn: cn=Users, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Allan Jefferson, o=Example
+uniqueMember: cn=Paul Tilley, o=Example
+uniqueMember: cn=Temporary Employees, o=Example
 
-    
    FrontPage restricts access to a web by adding the Require
-    valid-user directive to the .htaccess
-    files. The Require valid-user directive will succeed for
-    any user who is valid as far as LDAP is
-    concerned. This means that anybody who has an entry in
-    the LDAP directory is considered a valid user, whereas FrontPage
-    considers only those people in the local user file to be
-    valid. By substituting the ldap-group with group file authorization,
-    Apache is allowed to consult the local user file (which is managed by
-    FrontPage) - instead of LDAP - when handling authorizing the user.
    
+dn: cn=Temporary Employees, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Jim Swenson, o=Example
+uniqueMember: cn=Elliot Rhodes, o=Example
    -

    Once directives have been added as specified above, - FrontPage users will be able to perform all management - operations from the FrontPage client.

    +

    The following directives would allow access for Bob Ellis, Tom Jackson, + Barbara Jenson, Fred User, Allan Jefferson, and Paul Tilley but would not + allow access for Jim Swenson, or Elliot Rhodes (since they are at a + sub-group depth of 2):

    +
    Require ldap-group cn=Employees, o=Example
+AuthLDAPMaxSubGroupDepth 1
    -

    Caveats

    +

    Behavior of this directive is modified by the AuthLDAPGroupAttribute, AuthLDAPGroupAttributeIsDN, AuthLDAPMaxSubGroupDepth, AuthLDAPSubGroupAttribute, and AuthLDAPSubGroupClass + directives.

    -
      -
    • When choosing the LDAP URL, the attribute to use for - authentication should be something that will also be valid - for putting into a mod_authn_file user file. - The user ID is ideal for this.
      • -
    • When adding users via FrontPage, FrontPage administrators - should choose usernames that already exist in the LDAP - directory (for obvious reasons). Also, the password that the - administrator enters into the form is ignored, since Apache - will actually be authenticating against the password in the - LDAP database, and not against the password in the local user - file. This could cause confusion for web administrators.
      • +

      Require ldap-dn

      - -
    • Apache must be compiled with mod_auth_basic, - mod_authn_file and - mod_authz_groupfile in order to - use FrontPage support. This is because Apache will still use - the mod_authz_groupfile group file for determine - the extent of a user's access to the FrontPage web.
      • +

      The Require ldap-dn directive allows the administrator + to grant access based on distinguished names. It specifies a DN + that must match for access to be granted. If the distinguished + name that was retrieved from the directory server matches the + distinguished name in the Require ldap-dn, then + authorization is granted. Note: do not surround the distinguished + name with quotes.

      -
    • The directives must be put in the .htaccess - files. Attempting to put them inside <Location> or <Directory> directives won't work. This - is because mod_authnz_ldap has to be able to grab - the AuthGroupFile - directive that is found in FrontPage .htaccess - files so that it knows where to look for the valid user list. If - the mod_authnz_ldap directives aren't in the same - .htaccess file as the FrontPage directives, then - the hack won't work, because mod_authnz_ldap will - never get a chance to process the .htaccess file, - and won't be able to find the FrontPage-managed user file.
      • -
    +

    The following directive would grant access to a specific + DN:

    +
    Require ldap-dn cn=Barbara Jenson, o=Example
    -
    -
    top
    -

    AuthLDAPAuthorizePrefix Directive

    - - - - - - - - - -
    Description:Specifies the prefix for environment variables set during -authorization
    Syntax:AuthLDAPAuthorizePrefix prefix
    Default:AuthLDAPAuthorizePrefix AUTHORIZE_
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.6 and later
    -

    This directive allows you to override the prefix used for environment - variables set during LDAP authorization. If AUTHENTICATE_ is - specified, consumers of these environment variables see the same information - whether LDAP has performed authentication, authorization, or both.

    -

    Note

    - No authorization variables are set when a user is authorized on the basis of - Require valid-user. -
    +

    Behavior of this directive is modified by the AuthLDAPCompareDNOnServer + directive.

    + -
    -
    top
    -

    AuthLDAPBindAuthoritative Directive

    - - - - - - - - -
    Description:Determines if other authentication providers are used when a user can be mapped to a DN but the server cannot successfully bind with the user's credentials.
    Syntax:AuthLDAPBindAuthoritativeoff|on
    Default:AuthLDAPBindAuthoritative on
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    -

    By default, subsequent authentication providers are only queried if a - user cannot be mapped to a DN, but not if the user can be mapped to a DN and their - password cannot be verified with an LDAP bind. - If AuthLDAPBindAuthoritative - is set to off, other configured authentication modules will have - a chance to validate the user if the LDAP bind (with the current user's credentials) - fails for any reason.

    -

    This allows users present in both LDAP and - AuthUserFile to authenticate - when the LDAP server is available but the user's account is locked or password - is otherwise unusable.

    +

    Require ldap-attribute

    -

    See also

    - -
    -
    top
    -

    AuthLDAPBindDN Directive

    - - - - - - - -
    Description:Optional DN to use in binding to the LDAP server
    Syntax:AuthLDAPBindDN distinguished-name
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    -

    An optional DN used to bind to the server when searching for - entries. If not provided, mod_authnz_ldap will use - an anonymous bind.

    +

    The Require ldap-attribute directive allows the + administrator to grant access based on attributes of the authenticated + user in the LDAP directory. If the attribute in the directory + matches the value given in the configuration, access is granted.

    -
    -
    top
    -

    AuthLDAPBindPassword Directive

    - - - - - - - - -
    Description:Password used in conjuction with the bind DN
    Syntax:AuthLDAPBindPassword password
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:exec: was added in 2.4.5.
    -

    A bind password to use in conjunction with the bind DN. Note - that the bind password is probably sensitive data, and should be - properly protected. You should only use the AuthLDAPBindDN and AuthLDAPBindPassword if you - absolutely need them to search the directory.

    +

    The following directive would grant access to anyone with + the attribute employeeType = active

    -

    If the value begins with exec: the resulting command will be - executed and the first line returned to standard output by the - program will be used as the password.

    -
    #Password used as-is
-AuthLDAPBindPassword secret
+    
    Require ldap-attribute employeeType=active
    
 
-#Run /path/to/program to get my password
-AuthLDAPBindPassword exec:/path/to/program
 
-#Run /path/to/otherProgram and provide arguments
-AuthLDAPBindPassword "exec:/path/to/otherProgram argument1"
    +

    Multiple attribute/value pairs can be specified on the same line + separated by spaces or they can be specified in multiple + Require ldap-attribute directives. The effect of listing + multiple attribute/values pairs is an OR operation. Access will be + granted if any of the listed attribute values match the value of the + corresponding attribute in the user object. If the value of the + attribute contains a space, only the value must be within double quotes.

    +

    The following directive would grant access to anyone with + the city attribute equal to "San Jose" or status equal to "Active"

    + 
    Require ldap-attribute city="San Jose" status=active
    -
    -
    top
    -

    AuthLDAPCharsetConfig Directive

    - - - - - - -
    Description:Language to charset conversion configuration file
    Syntax:AuthLDAPCharsetConfig file-path
    Context:server config
    Status:Extension
    Module:mod_authnz_ldap
    -

    The AuthLDAPCharsetConfig directive sets the location - of the language to charset conversion configuration file. File-path is relative - to the ServerRoot. This file specifies - the list of language extensions to character sets. - Most administrators use the provided charset.conv - file, which associates common language extensions to character sets.

    -

    The file contains lines in the following format:

    -

    - Language-Extension charset [Language-String] ... -

    -

    The case of the extension does not matter. Blank lines, and lines - beginning with a hash character (#) are ignored.

    +

    Require ldap-filter

    -
    -
    top
    -

    AuthLDAPCompareAsUser Directive

    - - - - - - - - - -
    Description:Use the authenticated user's credentials to perform authorization comparisons
    Syntax:AuthLDAPCompareAsUser on|off
    Default:AuthLDAPCompareAsUser off
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.6 and later
    -

    When set, and mod_authnz_ldap has authenticated the - user, LDAP comparisons for authorization use the queried distinguished name (DN) - and HTTP basic authentication password of the authenticated user instead of - the servers configured credentials.

    +

    The Require ldap-filter directive allows the + administrator to grant access based on a complex LDAP search filter. + If the dn returned by the filter search matches the authenticated user + dn, access is granted.

    -

    The ldap-attribute, ldap-user, and ldap-group (single-level only) - authorization checks use comparisons.

    +

    The following directive would grant access to anyone having a cell phone + and is in the marketing department

    -

    This directive only has effect on the comparisons performed during - nested group processing when - AuthLDAPSearchAsUser is also enabled.

    + 
    Require ldap-filter &(cell=*)(department=marketing)
    -

    This directive should only be used when your LDAP server doesn't - accept anonymous comparisons and you cannot use a dedicated - AuthLDAPBindDN. -

    -

    See also

    - -
    -
    top
    -

    AuthLDAPCompareDNOnServer Directive

    - - - - - - - - -
    Description:Use the LDAP server to compare the DNs
    Syntax:AuthLDAPCompareDNOnServer on|off
    Default:AuthLDAPCompareDNOnServer on
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    -

    When set, mod_authnz_ldap will use the LDAP - server to compare the DNs. This is the only foolproof way to - compare DNs. mod_authnz_ldap will search the - directory for the DN specified with the Require dn directive, then, - retrieve the DN and compare it with the DN retrieved from the user - entry. If this directive is not set, - mod_authnz_ldap simply does a string comparison. It - is possible to get false negatives with this approach, but it is - much faster. Note the mod_ldap cache can speed up - DN comparison in most situations.

    +

    The difference between the Require ldap-filter directive and the + Require ldap-attribute directive is that ldap-filter + performs a search operation on the LDAP directory using the specified search + filter rather than a simple attribute comparison. If a simple attribute + comparison is all that is required, the comparison operation performed by + ldap-attribute will be faster than the search operation + used by ldap-filter especially within a large directory.

    -
    -
    top
    -

    AuthLDAPDereferenceAliases Directive

    - - - - - - - - -
    Description:When will the module de-reference aliases
    Syntax:AuthLDAPDereferenceAliases never|searching|finding|always
    Default:AuthLDAPDereferenceAliases always
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    -

    This directive specifies when mod_authnz_ldap will - de-reference aliases during LDAP operations. The default is - always.

    -
    -
    top
    -

    AuthLDAPGroupAttribute Directive

    - - - - - - - - -
    Description:LDAP attributes used to identify the user members of -groups.
    Syntax:AuthLDAPGroupAttribute attribute
    Default:AuthLDAPGroupAttribute member uniquemember
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    -

    This directive specifies which LDAP attributes are used to - check for user members within groups. Multiple attributes can be used - by specifying this directive multiple times. If not specified, - then mod_authnz_ldap uses the member and - uniquemember attributes.

    -
    -
    top
    -

    AuthLDAPGroupAttributeIsDN Directive

    - - - - - - - - -
    Description:Use the DN of the client username when checking for -group membership
    Syntax:AuthLDAPGroupAttributeIsDN on|off
    Default:AuthLDAPGroupAttributeIsDN on
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    -

    When set on, this directive says to use the - distinguished name of the client username when checking for group - membership. Otherwise, the username will be used. For example, - assume that the client sent the username bjenson, - which corresponds to the LDAP DN cn=Babs Jenson, - o=Example. If this directive is set, - mod_authnz_ldap will check if the group has - cn=Babs Jenson, o=Example as a member. If this - directive is not set, then mod_authnz_ldap will - check if the group has bjenson as a member.

    +
    top
    +
    +

    Examples

    + +
      +
    • + Grant access to anyone who exists in the LDAP directory, + using their UID for searches. +
      AuthLDAPURL "ldap://ldap1.example.com:389/ou=People, o=Example?uid?sub?(objectClass=*)"
+Require valid-user
      + +
      • + +
    • + The next example is the same as above; but with the fields + that have useful defaults omitted. Also, note the use of a + redundant LDAP server. +
      AuthLDAPURL "ldap://ldap1.example.com ldap2.example.com/ou=People, o=Example"
+Require valid-user
      + +
      • -
    -
    top
    -

    AuthLDAPInitialBindAsUser Directive

    - - - - - - - - - -
    Description:Determines if the server does the initial DN lookup using the basic authentication users' -own username, instead of anonymously or with hard-coded credentials for the server
    Syntax:AuthLDAPInitialBindAsUser off|on
    Default:AuthLDAPInitialBindAsUser off
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.6 and later
    -

    By default, the server either anonymously, or with a dedicated user and - password, converts the basic authentication username into an LDAP - distinguished name (DN). This directive forces the server to use the verbatim username - and password provided by the incoming user to perform the initial DN - search.

    +
  • + The next example is similar to the previous one, but it + uses the common name instead of the UID. Note that this + could be problematical if multiple people in the directory + share the same cn, because a search on cn + must return exactly one entry. That's why + this approach is not recommended: it's a better idea to + choose an attribute that is guaranteed unique in your + directory, such as uid. +
    AuthLDAPURL "ldap://ldap.example.com/ou=People, o=Example?cn"
+Require valid-user
    -

    If the verbatim username can't directly bind, but needs some - cosmetic transformation, see - AuthLDAPInitialBindPattern.

    +
    • -

    This directive should only be used when your LDAP server doesn't - accept anonymous searches and you cannot use a dedicated - AuthLDAPBindDN. -

    +
  • + Grant access to anybody in the Administrators group. The + users must authenticate using their UID. +
    AuthLDAPURL ldap://ldap.example.com/o=Example?uid
+Require ldap-group cn=Administrators, o=Example
    -

    Not available with authorization-only

    - This directive can only be used if this module authenticates the user, and - has no effect when this module is used exclusively for authorization. -
    +
    • -

    See also

    - -
    -
    top
    -

    AuthLDAPInitialBindPattern Directive

    - - - - - - - - - -
    Description:Specifies the transformation of the basic authentication username to be used when binding to the LDAP server -to perform a DN lookup
    Syntax:AuthLDAPInitialBindPatternregex substitution
    Default:AuthLDAPInitialBindPattern (.*) $1 (remote username used verbatim)
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.6 and later
    -

    If AuthLDAPInitialBindAsUser is set to - ON, the basic authentication username will be transformed according to the - regular expression and substituion arguments.

    +
  • + Grant access to anybody in the group whose name matches the + hostname of the virtual host. In this example an + expression is used to build the filter. +
    AuthLDAPURL ldap://ldap.example.com/o=Example?uid
+Require ldap-group cn=%{SERVER_NAME}, o=Example
    -

    The regular expression argument is compared against the current basic authentication username. - The substitution argument may contain backreferences, but has no other variable interpolation.

    +
    • -

    This directive should only be used when your LDAP server doesn't - accept anonymous searches and you cannot use a dedicated - AuthLDAPBindDN. -

    +
  • + The next example assumes that everyone at Example who + carries an alphanumeric pager will have an LDAP attribute + of qpagePagerID. The example will grant access + only to people (authenticated via their UID) who have + alphanumeric pagers: +
    AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(qpagePagerID=*)
+Require valid-user
    - 
    AuthLDAPInitialBindPattern (.+) $1@example.com
    +
    • - 
    AuthLDAPInitialBindPattern (.+) cn=$1,dc=example,dc=com
    +
  • +

    The next example demonstrates the power of using filters + to accomplish complicated administrative requirements. + Without filters, it would have been necessary to create a + new LDAP group and ensure that the group's members remain + synchronized with the pager users. This becomes trivial + with filters. The goal is to grant access to anyone who has + a pager, plus grant access to Joe Manager, who doesn't + have a pager, but does need to access the same + resource:

    +
    AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(|(qpagePagerID=*)(uid=jmanager))
+Require valid-user
    -

    Not available with authorization-only

    - This directive can only be used if this module authenticates the user, and - has no effect when this module is used exclusively for authorization. -
    -

    debugging

    - The substituted DN is recorded in the environment variable - LDAP_BINDASUSER. If the regular expression does not match the input, - the verbatim username is used. -
    +

    This last may look confusing at first, so it helps to + evaluate what the search filter will look like based on who + connects, as shown below. If + Fred User connects as fuser, the filter would look + like

    -

    See also

    - -
    • -
    top
    -

    AuthLDAPMaxSubGroupDepth Directive

    - - - - - - - - - -
    Description:Specifies the maximum sub-group nesting depth that will be -evaluated before the user search is discontinued.
    Syntax:AuthLDAPMaxSubGroupDepth Number
    Default:AuthLDAPMaxSubGroupDepth 10
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.0 and later
    -

    When this directive is set to a non-zero value X - combined with use of the Require ldap-group someGroupDN - directive, the provided user credentials will be searched for - as a member of the someGroupDN directory object or of - any group member of the current group up to the maximum nesting - level X specified by this directive.

    -

    See the Require ldap-group - section for a more detailed example.

    +

    (&(|(qpagePagerID=*)(uid=jmanager))(uid=fuser))

    -

    Nested groups performance

    -

    When AuthLDAPSubGroupAttribute overlaps with - AuthLDAPGroupAttribute (as it does by default and - as required by common LDAP schemas), uncached searching for subgroups in - large groups can be very slow. If you use large, non-nested groups, set - AuthLDAPMaxSubGroupDepth to zero.

    -
    +

    The above search will only succeed if fuser has a + pager. When Joe Manager connects as jmanager, the + filter looks like

    +

    (&(|(qpagePagerID=*)(uid=jmanager))(uid=jmanager))

    -
    -
    top
    -

    AuthLDAPRemoteUserAttribute Directive

    - - - - - - - - -
    Description:Use the value of the attribute returned during the user -query to set the REMOTE_USER environment variable
    Syntax:AuthLDAPRemoteUserAttribute uid
    Default:none
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    -

    If this directive is set, the value of the - REMOTE_USER environment variable will be set to the - value of the attribute specified. Make sure that this attribute is - included in the list of attributes in the AuthLDAPUrl definition, - otherwise this directive will have no effect. This directive, if - present, takes precedence over AuthLDAPRemoteUserIsDN. This - directive is useful should you want people to log into a website - using an email address, but a backend application expects the - username as a userid.

    +

    The above search will succeed whether jmanager + has a pager or not.

    + + +
    top
    +
    +

    Using TLS

    -
    -
    top
    -

    AuthLDAPRemoteUserIsDN Directive

    - - - - - - - - -
    Description:Use the DN of the client username to set the REMOTE_USER -environment variable
    Syntax:AuthLDAPRemoteUserIsDN on|off
    Default:AuthLDAPRemoteUserIsDN off
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    -

    If this directive is set to on, the value of the - REMOTE_USER environment variable will be set to the full - distinguished name of the authenticated user, rather than just - the username that was passed by the client. It is turned off by - default.

    +

    To use TLS, see the mod_ldap directives LDAPTrustedClientCert, LDAPTrustedGlobalCert and LDAPTrustedMode.

    -
    -
    top
    -

    AuthLDAPSearchAsUser Directive

    - - - - - - - - - -
    Description:Use the authenticated user's credentials to perform authorization searches
    Syntax:AuthLDAPSearchAsUser on|off
    Default:AuthLDAPSearchAsUser off
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.6 and later
    -

    When set, and mod_authnz_ldap has authenticated the - user, LDAP searches for authorization use the queried distinguished name (DN) - and HTTP basic authentication password of the authenticated user instead of - the servers configured credentials.

    +

    An optional second parameter can be added to the + AuthLDAPURL to override + the default connection type set by LDAPTrustedMode. + This will allow the connection established by an ldap:// Url + to be upgraded to a secure connection on the same port.

    +
    top
    +
    +

    Using SSL

    -

    The ldap-filter and ldap-dn authorization - checks use searches.

    +

    To use SSL, see the mod_ldap directives LDAPTrustedClientCert, LDAPTrustedGlobalCert and LDAPTrustedMode.

    -

    This directive only has effect on the comparisons performed during - nested group processing when - AuthLDAPCompareAsUser is also enabled.

    +

    To specify a secure LDAP server, use ldaps:// in the + AuthLDAPURL + directive, instead of ldap://.

    +
    top
    +
    +

    Exposing Login Information

    -

    This directive should only be used when your LDAP server doesn't - accept anonymous searches and you cannot use a dedicated - AuthLDAPBindDN. -

    +

    when this module performs authentication, ldap attributes specified + in the authldapurl + directive are placed in environment variables with the prefix "AUTHENTICATE_".

    + +

    when this module performs authorization, ldap attributes specified + in the authldapurl + directive are placed in environment variables with the prefix "AUTHORIZE_".

    -

    See also

    - -
    -
    top
    -

    AuthLDAPSubGroupAttribute Directive

    - - - - - - - - - -
    Description:Specifies the attribute labels, one value per -directive line, used to distinguish the members of the current group that -are groups.
    Syntax:AuthLDAPSubGroupAttribute attribute
    Default:AuthLDAPSubgroupAttribute member uniquemember
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.0 and later
    -

    An LDAP group object may contain members that are users and - members that are groups (called nested or sub groups). The - AuthLDAPSubGroupAttribute directive identifies the - labels of group members and the AuthLDAPGroupAttribute - directive identifies the labels of the user members. Multiple - attributes can be used by specifying this directive multiple times. - If not specified, then mod_authnz_ldap uses the - member and uniqueMember attributes.

    +

    If the attribute field contains the username, common name + and telephone number of a user, a CGI program will have access to + this information without the need to make a second independent LDAP + query to gather this additional information.

    -
    -
    top
    -

    AuthLDAPSubGroupClass Directive

    - - - - - - - - - -
    Description:Specifies which LDAP objectClass values identify directory -objects that are groups during sub-group processing.
    Syntax:AuthLDAPSubGroupClass LdapObjectClass
    Default:AuthLDAPSubGroupClass groupOfNames groupOfUniqueNames
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.0 and later
    -

    An LDAP group object may contain members that are users and - members that are groups (called nested or sub groups). The - AuthLDAPSubGroupAttribute directive identifies the - labels of members that may be sub-groups of the current group - (as opposed to user members). The AuthLDAPSubGroupClass - directive specifies the LDAP objectClass values used in verifying that - these potential sub-groups are in fact group objects. Verified sub-groups - can then be searched for more user or sub-group members. Multiple - attributes can be used by specifying this directive multiple times. - If not specified, then mod_authnz_ldap uses the - groupOfNames and groupOfUniqueNames values.

    +

    This has the potential to dramatically simplify the coding and + configuration required in some web applications.

    -
    -
    top
    -

    AuthLDAPUrl Directive

    - - - - - - - -
    Description:URL specifying the LDAP search parameters
    Syntax:AuthLDAPUrl url [NONE|SSL|TLS|STARTTLS]
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    -

    An RFC 2255 URL which specifies the LDAP search parameters - to use. The syntax of the URL is

    -

    ldap://host:port/basedn?attribute?scope?filter

    -

    If you want to specify more than one LDAP URL that Apache should try in turn, the syntax is:

    -
    AuthLDAPUrl "ldap://ldap1.example.com ldap2.example.com/dc=..."
    +
    top
    +
    +

    Using Active Directory

    -

    Caveat: If you specify multiple servers, you need to enclose the entire URL string in quotes; -otherwise you will get an error: "AuthLDAPURL takes one argument, URL to define LDAP connection.." -You can of course use search parameters on each of these.

    +

    An Active Directory installation may support multiple domains at the + same time. To distinguish users between domains, an identifier called + a User Principle Name (UPN) can be added to a user's entry in the + directory. This UPN usually takes the form of the user's account + name, followed by the domain components of the particular domain, + for example somebody@nz.example.com.

    -
    -
    ldap
    +

    You may wish to configure the mod_authnz_ldap + module to authenticate users present in any of the domains making up + the Active Directory forest. In this way both + somebody@nz.example.com and someone@au.example.com + can be authenticated using the same query at the same time.

    -
    For regular ldap, use the - string ldap. For secure LDAP, use ldaps - instead. Secure LDAP is only available if Apache was linked - to an LDAP library with SSL support.
    +

    To make this practical, Active Directory supports the concept of + a Global Catalog. This Global Catalog is a read only copy of selected + attributes of all the Active Directory servers within the Active + Directory forest. Querying the Global Catalog allows all the domains + to be queried in a single query, without the query spanning servers + over potentially slow links.

    -
    host:port
    +

    If enabled, the Global Catalog is an independent directory server + that runs on port 3268 (3269 for SSL). To search for a user, do a + subtree search for the attribute userPrincipalName, with + an empty search root, like so:

    -
    -

    The name/port of the ldap server (defaults to - localhost:389 for ldap, and - localhost:636 for ldaps). To - specify multiple, redundant LDAP servers, just list all - servers, separated by spaces. mod_authnz_ldap - will try connecting to each server in turn, until it makes a - successful connection. If multiple ldap servers are specified, - then entire LDAP URL must be encapsulated in double quotes.

    +
    AuthLDAPBindDN apache@example.com
+AuthLDAPBindPassword password
+AuthLDAPURL ldap://10.0.0.1:3268/?userPrincipalName?sub
    -

    Once a connection has been made to a server, that - connection remains active for the life of the - httpd process, or until the LDAP server goes - down.

    -

    If the LDAP server goes down and breaks an existing - connection, mod_authnz_ldap will attempt to - re-connect, starting with the primary server, and trying - each redundant server in turn. Note that this is different - than a true round-robin search.

    -
    +

    Users will need to enter their User Principal Name as a login, in + the form somebody@nz.example.com.

    -
    basedn
    +
    top
    +
    +

    Using Microsoft + FrontPage with mod_authnz_ldap

    -
    The DN of the branch of the - directory where all searches should start from. At the very - least, this must be the top of your directory tree, but - could also specify a subtree in the directory.
    +

    Normally, FrontPage uses FrontPage-web-specific user/group + files (i.e., the mod_authn_file and + mod_authz_groupfile modules) to handle all + authentication. Unfortunately, it is not possible to just + change to LDAP authentication by adding the proper directives, + because it will break the Permissions forms in + the FrontPage client, which attempt to modify the standard + text-based authorization files.

    -
    attribute
    +

    Once a FrontPage web has been created, adding LDAP + authentication to it is a matter of adding the following + directives to every .htaccess file + that gets created in the web

    +
    AuthLDAPURL       "the url"
+AuthGroupFile     "mygroupfile"
+Require group     "mygroupfile"
    -
    The attribute to search for. - Although RFC 2255 allows a comma-separated list of - attributes, only the first attribute will be used, no - matter how many are provided. If no attributes are - provided, the default is to use uid. It's a good - idea to choose an attribute that will be unique across all - entries in the subtree you will be using. All attributes - listed will be put into the environment with an AUTHENTICATE_ prefix - for use by other modules.
    -
    scope
    +

    How It Works

    -
    The scope of the search. Can be either one or - sub. Note that a scope of base is - also supported by RFC 2255, but is not supported by this - module. If the scope is not provided, or if base scope - is specified, the default is to use a scope of - sub.
    +

    FrontPage restricts access to a web by adding the Require + valid-user directive to the .htaccess + files. The Require valid-user directive will succeed for + any user who is valid as far as LDAP is + concerned. This means that anybody who has an entry in + the LDAP directory is considered a valid user, whereas FrontPage + considers only those people in the local user file to be + valid. By substituting the ldap-group with group file authorization, + Apache is allowed to consult the local user file (which is managed by + FrontPage) - instead of LDAP - when handling authorizing the user.

    -
    filter
    +

    Once directives have been added as specified above, + FrontPage users will be able to perform all management + operations from the FrontPage client.

    -
    A valid LDAP search filter. If - not provided, defaults to (objectClass=*), which - will search for all objects in the tree. Filters are - limited to approximately 8000 characters (the definition of - MAX_STRING_LEN in the Apache source code). This - should be more than sufficient for any application. In 2.4.10 and later, - The word "none" may be used to not use any filter, which may be - required by some primitive LDAP servers.
    - -

    When doing searches, the attribute, filter and username passed - by the HTTP client are combined to create a search filter that - looks like - (&(filter)(attribute=username)).

    +

    Caveats

    -

    For example, consider an URL of - ldap://ldap.example.com/o=Example?cn?sub?(posixid=*). When - a client attempts to connect using a username of Babs - Jenson, the resulting search filter will be - (&(posixid=*)(cn=Babs Jenson)).

    +
      +
    • When choosing the LDAP URL, the attribute to use for + authentication should be something that will also be valid + for putting into a mod_authn_file user file. + The user ID is ideal for this.
      • -

      An optional parameter can be added to allow the LDAP Url to override - the connection type. This parameter can be one of the following:

      +
    • When adding users via FrontPage, FrontPage administrators + should choose usernames that already exist in the LDAP + directory (for obvious reasons). Also, the password that the + administrator enters into the form is ignored, since Apache + will actually be authenticating against the password in the + LDAP database, and not against the password in the local user + file. This could cause confusion for web administrators.
      • -
      -
      NONE
      -
      Establish an unsecure connection on the default LDAP port. This - is the same as ldap:// on port 389.
      -
      SSL
      -
      Establish a secure connection on the default secure LDAP port. - This is the same as ldaps://
      -
      TLS | STARTTLS
      -
      Establish an upgraded secure connection on the default LDAP port. - This connection will be initiated on port 389 by default and then - upgraded to a secure connection on the same port.
      -
      + +
    • Apache must be compiled with mod_auth_basic, + mod_authn_file and + mod_authz_groupfile in order to + use FrontPage support. This is because Apache will still use + the mod_authz_groupfile group file for determine + the extent of a user's access to the FrontPage web.
      • -

      See above for examples of AuthLDAPURL URLs.

      +
    • The directives must be put in the .htaccess + files. Attempting to put them inside <Location> or <Directory> directives won't work. This + is because mod_authnz_ldap has to be able to grab + the AuthGroupFile + directive that is found in FrontPage .htaccess + files so that it knows where to look for the valid user list. If + the mod_authnz_ldap directives aren't in the same + .htaccess file as the FrontPage directives, then + the hack won't work, because mod_authnz_ldap will + never get a chance to process the .htaccess file, + and won't be able to find the FrontPage-managed user file.
      • +
    diff --git a/docs/manual/mod/mod_authnz_ldap.html.fr b/docs/manual/mod/mod_authnz_ldap.html.fr index 24425d8b193..ba47083df4c 100644 --- a/docs/manual/mod/mod_authnz_ldap.html.fr +++ b/docs/manual/mod/mod_authnz_ldap.html.fr @@ -109,1435 +109,1435 @@ Directory
  • mod_authz_groupfile
    • top
    -
    -

    Sommaire

    - -
      -
    • - Mode opératoire +

      Directive AuthLDAPAuthorizePrefix

      + + + + + + + + + +
      Description:Spécifie le préfixe ajouté aux variables d'environnement +durant la phase d'autorisation
      Syntaxe:AuthLDAPAuthorizePrefix préfixe
      Défaut:AuthLDAPAuthorizePrefix AUTHORIZE_
      Contexte:répertoire, .htaccess
      AllowOverride:AuthConfig
      Statut:Extension
      Module:mod_authnz_ldap
      Compatibilité:Disponible depuis la version 2.3.6
      +

      Cette directive permet de spécifier le préfixe ajouté aux + variables d'environnement durant la phase d'autorisation. Si la + valeur spécifiée est AUTHENTICATE_, les utilisateurs de ces + variables d'environnement verront les mêmes informations, que le + serveur effectue une authentification, une autorisation, ou les + deux.

      - -
      • +
    +
    top
    +

    Directive AuthLDAPBindAuthoritative

    + + + + + + + + +
    Description:Détermine si l'on doit utiliser d'autres fournisseurs +d'authentification lorsque le serveur ne peut pas valider les données +d'authentification de l'utilisateur, alors que ce dernier possède un +DN.
    Syntaxe:AuthLDAPBindAuthoritativeoff|on
    Défaut:AuthLDAPBindAuthoritative on
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    +

    Par défaut, des fournisseurs d'authentification sont appelés + si un utilisateur ne possède pas de DN, mais ne le sont pas si + l'utilisateur possède un DN et si son mot de passe ne peut pas être + vérifié lors d'une connexion au serveur LDAP. Si la directive + AuthLDAPBindAuthoritative est + définie à off, d'autres modules d'authentification + configurés auront une chance de valider le mot de passe de + l'utilisateur si la tentative de connexion au serveur LDAP échoue + pour une raison quelconque (avec les données d'authentification + fournies).

    +

    Ceci permet aux utilisateurs présent à la fois dans l'annuaire + LDAP et dans un fichier AuthUserFile de s'authentifier + lorsque le serveur LDAP est disponible, alors que le compte de + l'utilisateur est verrouillé ou que son mot de passe est + inutilisable pour une raison quelconque.

    -
  • - Les directives requises +

    Voir aussi

    + +
    • +
    top
    +

    Directive AuthLDAPBindDN

    + + + + + + + +
    Description:Un DN optionnel pour se connecter au serveur +LDAP
    Syntaxe:AuthLDAPBindDN dn
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    +

    Cette directive permet de définir un DN optionnel pour se + connecter au serveur afin d'y rechercher des entrées. Si aucun DN + n'est spécifié, mod_authnz_ldap tentera une + connexion anonyme.

    - - +
    +
    top
    +

    Directive AuthLDAPBindPassword

    + + + + + + + + +
    Description:Mot de passe à utiliser en conjonction avec le DN de +connexion
    Syntaxe:AuthLDAPBindPassword mot-de-passe
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:exec: est disponible depuis la version 2.4.5 du +serveur HTTP Apache.
    +

    Cette directive permet de spécifier un mot de passe à utiliser en + conjonction avec le DN de connexion. Notez que ce mot de passe + constitue en général une donnée sensible, et doit donc être protégé + de manière appropriée. Vous ne devez utiliser les directives + AuthLDAPBindDN et AuthLDAPBindPassword que si + vous en avez vraiment besoin pour effectuer une recherche dans + l'annuaire.

    -
  • Exemples
    • -
  • Utilisation de TLS
    • -
  • Utilisation de SSL
    • -
  • Mise à disposition des informations de - connexion
    • -
  • Utilisation d'Active Directory
    • -
  • - Utilisation de Microsoft FrontPage avec - mod_authnz_ldap +

    Si la valeur spécifiée débute par "exec:", la commande qui suit sera + exécutée, et la première ligne renvoyée par la commande sur la + sortie standard sera utilisée comme mot de passe.

    +
    # Mot de passe spécifié directement
+AuthLDAPBindPassword secret
 
-        
-
    • - -
    top
    -
    -

    Mode opératoire

    +# Exécution de /path/to/program pour obtenir le mot de passe +AuthLDAPBindPassword exec:/path/to/program -

    L'utilisateur se voit accorder l'accès selon un processus en deux - phases. La première phase est l'authentification, au cours de - laquelle le fournisseur d'authentification - mod_authnz_ldap vérifie que les informations de - connexion de l'utilisateur sont valides. Elle est aussi connue sous - le nom de phase de recherche/connexion (NdT : en anglais ou - dans le code source : search/bind). La deuxième - phase est l'autorisation, au cours de laquelle - mod_authnz_ldap détermine si l'utilisateur - authentifié a la permission d'accéder à la ressource considérée. - Elle est aussi connue sous le nom de phase de - comparaison (compare).

    +# Exécution de /path/to/otherProgram avec un argument pour obtenir le mot de passe +AuthLDAPBindPassword "exec:/path/to/otherProgram argument1" -

    mod_authnz_ldap comporte un fournisseur - d'authentification authn_ldap et un gestionnaire d'autorisation - authz_ldap. Le fournisseur d'authentification authn_ldap peut être - invoqué en affectant la valeur ldap à la directive - AuthBasicProvider. Le - gestionnaire d'autorisation authz_ldap enrichit la liste des types - d'autorisations de la directive Require en y ajoutant les - valeurs ldap-user, ldap-dn et - ldap-group.

    -

    La phase d'authentification

    -

    Au cours de la phase d'authentification, - mod_authnz_ldap recherche une entrée de l'annuaire - LDAP qui correspond au nom d'utilisateur fourni par le client HTTP. - Si une correspondance unique est trouvée, - mod_authnz_ldap tente de se connecter au serveur - hébergeant l'annuaire LDAP en utilisant le DN de l'entrée et le mot - de passe fourni par le client HTTP. Comme ce processus effectue tout - d'abord une recherche, puis une connexion, il est aussi connu sous - le nom de phase de recherche/connexion. Voici le détail des étapes - constituant la phase de recherche/connexion :

    +
    +
    top
    +

    Directive AuthLDAPCharsetConfig

    + + + + + + +
    Description:Chemin du fichier de configuration de la correspondance +langage/jeu de caractères
    Syntaxe:AuthLDAPCharsetConfig chemin-fichier
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_authnz_ldap
    +

    La directive AuthLDAPCharsetConfig permet + de définir le chemin du fichier de configuration de la + correspondance langage/jeu de caractères. chemin-fichier + est un chemin relatif au répertoire défini par la directive + ServerRoot. Ce fichier contient une liste + de correspondances extension de langage/jeu de caractères. La + plupart des administrateurs utilisent le fichier + charset.conv fourni qui associe les extensions de + langage courantes à leurs jeux de caractères.

    -
      -
    1. Confection d'un filtre de recherche en combinant les attribut - et filtre définis par la directive AuthLDAPURL avec le nom d'utilisateur et le mot de - passe fournis par le client HTTP.
      2. +

      Le fichier contient des lignes au format suivant :

      -
    2. Recherche dans l'annuaire LDAP en utilisant le filtre - confectionné précédemment. Si le résultat de la recherche est - négatif ou comporte plusieurs entrées, refus ou restriction de - l'accès.
      3. +

      + extension de langage jeu de caractères + [Nom du langage] ... +

      -
    3. Extraction du DN (distinguished name) de l'entrée issue du - résultat de la recherche, et tentative de connexion au serveur - LDAP en utilisant ce DN et le mot de passe fournis par le client - HTTP. Si la connexion échoue, refus ou restriction de - l'accès.
      4. -
    +

    L'extension est insensible à la casse. Les lignes vides et les + lignes commençant par un dièse (#) sont ignorées.

    -

    Les directives utilisées durant la phase de recherche/connexion - sont les suivantes :

    +
    +
    top
    +

    Directive AuthLDAPCompareAsUser

    + + + + + + + + + +
    Description:Utilisation des données d'authentification de l'utilisateur +pour effectuer les comparaisons pour l'attribution des autorisations
    Syntaxe:AuthLDAPCompareAsUser on|off
    Défaut:AuthLDAPCompareAsUser off
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible depuis la version version 2.3.6
    +

    Lorsque cette directive est définie, et si + mod_authnz_ldap a authentifié l'utilisateur, les + recherches LDAP pour les autorisations utilisent le nom distinctif + trouvé (DN) et le mot de passe d'authentification basique HTTP de + l'utilisateur authentifié au lieu des données d'authentification + configurées au niveau du serveur.

    - - - - +

    Les vérifications d'autorisation ldap-attribute, + ldap-user, et ldap-group (niveau simple seulement) + utilisent des comparaisons.

    - - +

    Cette directive n'a d'effet sur les comparaisons effectuées au + cours des traitements de groupe imbriqués, et lorsque la directive + AuthLDAPSearchAsUser + est aussi activée.

    - - - - - - - - - - - -
    AuthLDAPURLSpécifie le serveur LDAP, le DN de base, l'attribut à - utiliser pour la recherche, ainsi que les filtres de recherche - supplémentaires.
    AuthLDAPBindDNUn DN optionnel pour se connecter durant la phase de - recherche.
    AuthLDAPBindPasswordUn mot de passe optionnel pour se connecter durant la phase - de recherche.
    - - -

    La phase d'autorisation

    - -

    Au cours de la phase d'autorisation, - mod_authnz_ldap tente de déterminer si - l'utilisateur est autorisé à accéder à la ressource considérée. Une - grande partie de cette vérification consiste pour - mod_authnz_ldap en des opérations de comparaison au - niveau du serveur LDAP. C'est pourquoi cette phase est aussi connue - sous le nom de phase de comparaison. - mod_authnz_ldap accepte les directives Require suivantes pour - déterminer si les informations de connexion permettent d'accorder - l'accès à l'utilisateur :

    - -
      -
    • Avec la directive Require ldap-user, - l'autorisation d'accès est accordée si le nom d'utilisateur - spécifié par la directive correspond au nom d'utilisateur fourni - par le client.
      • - -
    • Avec la directive Require - ldap-dn, l'autorisation d'accès est accordée si le DN - spécifié par la directive correspond au DN extrait du résultat de - la recherche dans l'annuaire LDAP.
      • - -
    • Avec la directive Require ldap-group, - l'autorisation d'accès est accordée si le DN extrait du résultat de - la recherche dans l'annuaire LDAP (ou le nom d'utilisateur fourni - par le client) appartient au groupe LDAP spécifié par la - directive, ou éventuellement à un de ses sous-groupes.
      • +

      Cette directive ne doit être utilisée que si votre serveur LDAP + n'autorise pas les recherches anonymes, ou si vous ne pouvez pas + utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN. +

      -
    • Avec la directive - Require ldap-attribute, l'autorisation d'accès - est accordée si la valeur de l'attribut extraite de la recherche - dans l'annuaire LDAP correspond à la valeur spécifiée par la - directive.
      • +

      Voir aussi

      + +
    +
    top
    +

    Directive AuthLDAPCompareDNOnServer

    + + + + + + + + +
    Description:Utilise le serveur LDAP pour comparer les DNs
    Syntaxe:AuthLDAPCompareDNOnServer on|off
    Défaut:AuthLDAPCompareDNOnServer on
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    +

    Lorsque cette directive est définie à on, + mod_authnz_ldap utilise le serveur LDAP pour + comparer les DNs. Il s'agit de la seule méthode infaillible pour + comparer les DNs. mod_authnz_ldap va rechercher + dans l'annuaire le DN spécifié par la directive Require dn, puis extraire ce DN et le + comparer avec le DN extrait de l'entrée de l'utilisateur. Si cette + directive est à off, mod_authnz_ldap effectue une + simple comparaison de chaînes. Cette dernière approche peut produire + des faux négatifs, mais elle est beaucoup plus rapide. Notez + cependant que le cache de mod_ldap peut accélérer + la comparaison de DNs dans la plupart des situations.

    -
  • Avec la directive - Require ldap-filter, l'autorisation d'accès - est accordée si le filtre de recherche renvoie un objet - utilisateur unique qui corresponde au DN de l'utilisateur - authentifié.
    • +
    +
    top
    +

    Directive AuthLDAPDereferenceAliases

    + + + + + + + + +
    Description:À quel moment le module va déréférencer les +alias
    Syntaxe:AuthLDAPDereferenceAliases never|searching|finding|always
    Défaut:AuthLDAPDereferenceAliases always
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    +

    Cette directive permet de spécifier à quel moment + mod_authnz_ldap va déréférencer les alias au cours + des opérations liées à LDAP. La valeur par défaut est + always.

    -
  • dans tous les autres cas, refus ou restriction de - l'accès.
    • - +
    +
    top
    +

    Directive AuthLDAPGroupAttribute

    + + + + + + + + +
    Description:L'attribut LDAP utilisé pour vérifier l'appartenance d'un +utilisateur à un groupe.
    Syntaxe:AuthLDAPGroupAttribute attribut
    Défaut:AuthLDAPGroupAttribute member uniquemember
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    +

    Cette directive permet de spécifier quel attribut LDAP est + utilisé pour vérifier l'appartenance d'un utilisateur à un + groupe. On peut spécifier plusieurs attributs en répétant cette + directive plusieurs fois. Si la directive n'est pas définie, + mod_authnz_ldap utilise les attributs + member et uniquemember.

    -

    Sous réserve du chargement de modules d'autorisation - supplémentaires, d'autres valeurs de la directive Require peuvent être - spécifiées.

    +
    +
    top
    +

    Directive AuthLDAPGroupAttributeIsDN

    + + + + + + + + +
    Description:Utilise le DN de l'utilisateur pour vérifier son +appartenance à un groupe
    Syntaxe:AuthLDAPGroupAttributeIsDN on|off
    Défaut:AuthLDAPGroupAttributeIsDN on
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    +

    Lorsqu'elle est définie à on, cette directive + indique que c'est le DN de l'utilisateur qui doit être utilisé pour + vérifier son appartenance à un groupe. Dans le cas contraire, c'est + le nom de l'utilisateur qui sera utilisé. Par exemple, supposons que + le client envoie le nom d'utilisateur bjenson, qui + correspond au DN LDAP cn=Babs Jenson,o=Example. Si la + directive est à on, mod_authnz_ldap va + vérifier si cn=Babs Jenson, o=Example est un membre du + groupe. Dans le cas contraire, mod_authnz_ldap + vérifiera si bjenson est un membre du groupe.

    -
    +
    top
    +

    Directive AuthLDAPInitialBindAsUser

    + + + + + + + + + +
    Description:Détermine si le serveur effectue la recherche initiale du +DN en utilisant le nom propre de l'utilisateur pour l'authentification +de base +et non de manière anonyme, ou en utilisant des données d'authentification +codées en dur pour le serveur
    Syntaxe:AuthLDAPInitialBindAsUser off|on
    Défaut:AuthLDAPInitialBindAsUser off
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible depuis la version 2.3.6
    +

    Par défaut, le serveur convertit le nom d'utilisateur pour + l'authentification de base en nom distinctif LDAP (DN) soit de + manière anonyme, soit avec un couple nom/mot de passe dédié. Cette + directive permet de forcer le serveur à utiliser les véritables nom + d'utilisateur et mot de passe fournis par l'utilisateur pour + effectuer la recherche initiale du DN.

    -
  • Avec la directive Require group, l'autorisation - d'accès est accordée si le module - mod_authz_groupfile a été chargé et si la - directive AuthGroupFile a été - définie.
    • +

    Si le nom d'utilisateur ne peut pas s'authentifier directement + et nécessite de légères modifications, voir la directive AuthLDAPInitialBindPattern.

    -
  • etc...
    • - +

    Cette directive ne doit être utilisée que si votre serveur LDAP + n'autorise pas les recherches anonymes, ou si vous ne pouvez pas + utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN. +

    +

    Non disponible dans la cas d'une autorisation seule

    + On ne peut utiliser cette directive que si ce module + effectue une authentification, et n'a aucun effet si ce module + n'est utilisé que pour les processus d'autorisation. +
    -

    Durant la phase de comparaison, mod_authnz_ldap - utilise les directives suivantes :

    +

    Voir aussi

    + +
    +
    top
    +

    Directive AuthLDAPInitialBindPattern

    + + + + + + + + + +
    Description:Spécifie la modification a apporter au nom d'utilisateur +pour l'authentification de base lors de l'authentification auprès du +serveur LDAP pour effectuer une recherche de DN
    Syntaxe:AuthLDAPInitialBindPatternregex substitution
    Défaut:AuthLDAPInitialBindPattern (.*) $1 (nom de l'utilisateur +distant utilisé tel quel)
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible depuis la version 2.3.6
    +

    Si la directive AuthLDAPInitialBindAsUser est + définie à ON, le nom utilisateur pour l'authentification de + base sera transformé selon l'expression rationnelle + regex et l'argument substitution spécifiés.

    - - - - +

    L'expression rationnelle est comparée au nom d'utilisateur pour + l'authentification de base courant. L'argument + substitution peut contenir des références arrières, mais + n'effectue aucune autre interpolation de variable.

    - - +

    Cette directive ne doit être utilisée que si votre serveur LDAP + n'autorise pas les recherches anonymes, ou si vous ne pouvez pas + utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN. +

    - - + 
    AuthLDAPInitialBindPattern (.+) $1@example.com
    - - + 
    AuthLDAPInitialBindPattern (.+) cn=$1,dc=example,dc=com
    - - - - +

    Non disponible dans la cas d'une autorisation seule

    + On ne peut utiliser cette directive que si ce module + effectue une authentification, et n'a aucun effet si ce module + n'est utilisé que pour les processus d'autorisation. +
    +

    Débogage

    + Le DN de substitution est enregistré dans la variable + d'environnement LDAP_BINDASUSER. Si l'expression + rationnelle ne convient pas, le nom d'utilisateur est utilisé + tel quel. +
    - - +

    Voir aussi

    + + +
    top
    +

    Directive AuthLDAPMaxSubGroupDepth

    +
    AuthLDAPURL - On utilise l'attribut spécifié dans l'URL pour les - opérations de comparaison initiées par la directive - Require ldap-user.
    AuthLDAPCompareDNOnServerDétermine le comportement de la directive Require - ldap-dn.
    AuthLDAPGroupAttributeDétermine l'attribut utilisé pour les opérations de - comparaison initiées par la directive Require - ldap-group.
    AuthLDAPGroupAttributeIsDN
    + + + + + + + + +
    Description:Spécifie la profondeur d'imbrication des sous-groupes +maximale prise en compte avant l'abandon de la recherche de +l'utilisateur.
    Syntaxe:AuthLDAPMaxSubGroupDepth Nombre
    Défaut:AuthLDAPMaxSubGroupDepth 10
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible à partir de la version 2.3.0 du serveur HTTP +Apache
    +

    Lorsque cette directive est définie à une valeur X + non nulle, en combinaison avec l'utilisation de la directive + Require ldap-group DN-groupe, les données de connexion + fournies seront utilisées pour vérifier l'appartenance de + l'utilisateur à l'objet de l'annuaire DN-groupe ou à + tout sous-groupe du groupe courant en tenant compte de la profondeur + d'imbrication maximale X spécifiée par la directive.

    +

    Se référer à la section Require + ldap-group pour un exemple plus détaillé.

    -
    		Spécifie si l'on doit utiliser le DN ou le nom de - l'utilisateur lors des opérations de comparaison initiées par la - directive Require ldap-group.
    AuthLDAPMaxSubGroupDepthDétermine la profondeur maximale de l'arborescence des - sous-groupes qui seront évalués au cours des opérations de - comparaisons initiées par la directive Require - ldap-group.
    + + + + + + + +
    Description:Spécifie l'attribut dont la valeur renvoyée au cours de la +requête de l'utilisateur sera utilisée pour définir la variable +d'environnement REMOTE_USER
    Syntaxe:AuthLDAPRemoteUserAttribute uid
    Défaut:none
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    +

    Lorsque cette directive est définie, la variable d'environnement + REMOTE_USER sera définie à la valeur de l'attribut + spécifié. Assurez-vous que cet attribut soit bien inclus dans la + liste d'attributs spécifiés dans la définition de AuthLDAPUrl ; dans + le cas contraire, cette directive n'aurait aucun effet. Si elle est + présente, cette directive l'emporte sur AuthLDAPRemoteUserIsDN. Elle + peut s'avérer utile par exemple, si vous souhaitez que les + utilisateurs se connectent à un site web en utilisant leur adresse + email, alors qu'une application sous-jacente nécessite un nom + d'utilisateur comme identifiant.

    - - AuthLDAPSubGroupAttribute +
    +
    top
    +

    Directive AuthLDAPRemoteUserIsDN

    + + + + + + + + +
    Description:Utilise le DN de l'utilisateur pour définir la variable +d'environnement REMOTE_USER
    Syntaxe:AuthLDAPRemoteUserIsDN on|off
    Défaut:AuthLDAPRemoteUserIsDN off
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    +

    Lorsque cette directive est à on, la variable d'environnement + REMOTE_USER sera définie avec la valeur du DN complet + de l'utilisateur authentifié, et non plus avec simplement le nom + d'utilisateur fourni par le client. Elle est définie à off par + défaut.

    - Détermine l'attribut à utiliser lors de l'extraction de - membres de sous-groupes du groupe courant au cours des - opérations de comparaison initiées par la directive - Require ldap-group. - +
    +
    top
    +

    Directive AuthLDAPSearchAsUser

    + + + + + + + + + +
    Description:Utilise les données d'authentification de l'utilisateur +pour la recherche des autorisations
    Syntaxe:AuthLDAPSearchAsUser on|off
    Défaut:AuthLDAPSearchAsUser off
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible depuis la version 2.3.6
    +

    Lorsque cette directive est définie, et si + mod_authnz_ldap a authentifié l'utilisateur, les + recherches LDAP pour définir les autorisations utilisent le nom + distinctif (DN) trouvé et le mot de passe pour l'authentification de + base HTTP de l'utilisateur authentifié, au lieu des données + d'authentification configurées au niveau du serveur.

    - - AuthLDAPSubGroupClass +

    Les vérifications d'autorisation ldap-filter et + ldap-dn utilisent des recherches.

    - Spécifie les valeurs de classe d'objet LDAP à utiliser pour - déterminer si les objets extraits de l'annuaire sont bien des - objets de type groupe (et non des objets de type utilisateur), - au cours du traitement des sous-groupes initié par la directive - Require ldap-group. - - +

    Cette directive n'a d'effet sur les comparaisons effectuées au + cours des traitements de groupe imbriqués, et lorsque la directive + AuthLDAPCompareAsUser + est aussi activée.

    -
    top
    -
    -

    Les directives requises

    +

    Cette directive ne doit être utilisée que si votre serveur LDAP + n'autorise pas les recherches anonymes, ou si vous ne pouvez pas + utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN. +

    -

    Les directives Require d'Apache sont utilisées - au cours de la phase d'autorisation afin de s'assurer que - l'utilisateur est autorisé à accéder à une ressource. - mod_authnz_ldap enrichit la liste des types d'autorisations avec les - valeurs ldap-user, ldap-dn, - ldap-group, ldap-attribute et - ldap-filter. D'autres types d'autorisations sont - disponibles, sous réserve du chargement de modules d'autorisation - supplémentaires.

    -

    Depuis la version 2.4.8, les directives require LDAP supportent - les expressions.

    +

    Voir aussi

    + +
    +
    top
    +

    Directive AuthLDAPSubGroupAttribute

    + + + + + + + + + +
    Description:Spécifie les noms d'attribut, un par directive, utilisés +pour différencier les membres du groupe courant qui sont eux-mêmes des +groupes.
    Syntaxe:AuthLDAPSubGroupAttribute attribut
    Défaut:AuthLDAPSubgroupAttribute member uniquemember
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible à partir de la version 2.3.0 du serveur HTTP +Apache
    +

    Un objet groupe LDAP peut contenir des membres qui sont des + utilisateurs et des membres qui sont eux-mêmes des groupes (appelés + sous-groupes ou groupes imbriqués). La directive + AuthLDAPSubGroupAttribute spécifie l'attribut utilisé + pour identifier les groupes, alors que la directive + AuthLDAPGroupAttribute spécifie l'attribut utilisé + pour identifier les utilisateurs. On peut spécifier plusieurs + attributs en répétant la directive plusieurs fois. Si elle n'est pas + définie, mod_authnz_ldap utilise les attributs + member et uniqueMember.

    -

    Require ldap-user

    +
    +
    top
    +

    Directive AuthLDAPSubGroupClass

    + + + + + + + + + +
    Description:Spécifie quelles valeurs d'objectClass LDAP identifient les +objets de l'annuaire qui sont des groupes au cours du traitement des +sous-groupes.
    Syntaxe:AuthLDAPSubGroupClass ObjectClass-LDAP
    Défaut:AuthLDAPSubGroupClass groupOfNames groupOfUniqueNames
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible à partir de la version 2.3.0 du serveur HTTP +Apache
    +

    Un objet groupe LDAP peut contenir des membres qui sont des + utilisateurs et des membres qui sont eux-mêmes des groupes (appelés + sous-groupes ou groupes imbriqués). La directive + AuthLDAPSubGroupAttribute permet d'identifier les + membres qui sont des sous-groupes du groupe courant (à l'opposé des + membres utilisateurs). La directive + AuthLDAPSubGroupClass permet de spécifier les valeurs + d'objectClass LDAP utilisées pour vérifier que certains membres sont + en fait des objets groupe. Les sous-groupes ainsi identifiés peuvent + alors faire l'objet d'une recherche d'autres membres utilisateurs ou + sous-groupes. On peut spécifier plusieurs attributs en répétant + cette directive plusieurs fois. Si cette directive n'est pas + définie, mod_authnz_ldap utilise les attributs + groupOfNames et groupOfUniqueNames.

    -

    La directive Require ldap-user permet de spécifier - les noms des utilisateurs autorisés à accéder à la ressource. - Lorsque mod_authnz_ldap a extrait un DN unique de - l'annuaire LDAP, il effectue une opération de comparaison LDAP en - utilisant le nom d'utilisateur spécifié par la directive - Require ldap-user, pour vérifier si ce nom - d'utilisateur correspond à l'entrée LDAP extraite. On peut accorder - l'accès à plusieurs utilisateurs en plaçant plusieurs nom - d'utilisateurs sur la même ligne séparés par des espaces. Si un nom - d'utilisateur contient des espaces, il doit être entouré de - guillemets. On peut aussi accorder l'accès à plusieurs utilisateurs - en utilisant une directive Require ldap-user par - utilisateur. Par exemple, avec la directive AuthLDAPURL définie à - ldap://ldap/o=Example?cn (spécifiant donc que l'attribut - cn sera utilisé pour les recherches), on pourra - utiliser les directives Require suivantes pour restreindre l'accès - :

    -
    Require ldap-user "Barbara Jenson"
-Require ldap-user "Fred User"
-Require ldap-user "Joe Manager"
    +
    +
    top
    +

    Directive AuthLDAPUrl

    + + + + + + + +
    Description:L'URL permettant de spécifier les paramètres de la +recherche LDAP
    Syntaxe:AuthLDAPUrl url [NONE|SSL|TLS|STARTTLS]
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    +

    Une URL conforme à la RFC 2255 qui permet de spécifier les + paramètres à utiliser pour la recherche dans l'annuaire LDAP. La + syntaxe de l'URL est :

    +

    ldap://hôte:port/DN-de-base?attribut?portée?filtre

    +

    Si vous souhaitez mettre à la disposition d'Apache plusieurs URLs + LDAP, la syntaxe sera :

    +
    AuthLDAPUrl "ldap://ldap1.example.com ldap2.example.com/dc=..."
    +

    Mise en garde : Si vous spécifiez plusieurs +serveurs, vous devez en entourer la liste avec des guillemets ; dans le +cas contraire, vous générerez une erreur : "AuthLDAPURL takes one +argument, URL to define LDAP connection..". Vous pouvez bien +entendu ajouter des paramètres de recherche à chacun des serveurs +spécifiés.

    -

    De par la manière dont mod_authnz_ldap traite - cette directive, Barbara Jenson peut s'authentifier comme - Barbara Jenson, Babs Jenson ou tout autre - cn sous lequel elle est enregistrée dans l'annuaire - LDAP. Une seule ligne Require ldap-user suffit pour - toutes les valeurs de l'attribut dans l'entrée LDAP de - l'utilisateur.

    +
    +
    ldap
    -

    Si l'attribut uid avait été spécifié à la place de - l'attribut cn dans l'URL précédente, les trois lignes - ci-dessus auraient pû être condensées en une seule ligne :

    -
    Require ldap-user bjenson fuser jmanager
    +
    Pour ldap non sécurisé, utilisez la chaîne + ldap. Pour ldap sécurisé, utilisez à la place la + chaîne ldaps. LDAP sécurisé n'est disponible que si + Apache a été lié avec une bibliothèque LDAP supportant SSL.
    +
    hôte:port
    +
    +

    Il s'agit du nom/port du serveur ldap + (dont la valeur par défaut est + localhost:389 pour ldap, et + localhost:636 pour ldaps). Pour + spécifier plusieurs serveurs LDAP redondants, indiquez + simplement leur liste en les séparant par des espaces. + mod_authnz_ldap tentera alors de se connecter + à chacun des serveurs jusqu'à ce qu'il parvienne à se + connecter avec succès. Notez qu'en cas de multiples serveurs + LDAP, l'ensemble de l'URL LDAP doit être entourée de + guillemets.

    -

    Require ldap-group

    +

    lorsqu'une connection a été établie avec un serveur, elle + reste active pendant toute la durée de vie du processus + httpd, ou jusqu'à ce que le serveur LDAP + cesse de fonctionner.

    -

    Cette directive permet de spécifier un groupe LDAP dont les - membres auront l'autorisation d'accès. Elle prend comme argument le - DN du groupe LDAP. Note : n'entourez pas le nom du groupe avec des - guillemets. Par exemple, supposons que l'entrée suivante existe dans - l'annuaire LDAP :

    -
    dn: cn=Administrators, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Barbara Jenson, o=Example
-uniqueMember: cn=Fred User, o=Example
    +

    Si le serveur LDAP cesse de fonctionner, et ainsi + interrompt une + connexion existante, mod_authnz_ldap tentera + de se reconnecter en commençant par le premier serveur de la + liste, et ainsi de suite avec les serveurs redondants + suivants. Notez que ce processus n'a rien à voir avec une + véritable recherche de type round-robin.

    +
    -

    La directive suivante autoriserait alors l'accès à Fred et - Barbara :

    -
    Require ldap-group cn=Administrators, o=Example
    +
    DN-de-base
    +
    Le DN de la branche de l'annuaire à partir de laquelle + toutes les recherches seront lancées. Il doit au moins + correspondre à la racine de votre annuaire, mais vous pouvez + aussi indiquer une branche plus spécifique.
    +
    attribut
    -

    Les membres peuvent aussi se trouver dans les sous-groupes du - groupe LDAP spécifié si la directive AuthLDAPMaxSubGroupDepth a été - définie à une valeur supérieure à 0. Par exemple, supposons que les - entrées suivantes existent dans l'annuaire LDAP :

    -
    dn: cn=Employees, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Managers, o=Example
-uniqueMember: cn=Administrators, o=Example
-uniqueMember: cn=Users, o=Example
+        
    Il s'agit de l'attribut à utiliser pour la recherche.
+	Bien que la RFC
+	2255 autorise une liste d'attributs séparés par des virgules,
+	seul le premier sera retenu, sans tenir compte des autres
+	attributs fournis. Si aucun attribut n'est fourni, l'attribut
+	par défaut est uid. Il est judicieux de choisir un
+	attribut dont la valeur sera unique parmi toutes les entrées de
+	la branche de l'annuaire que vous aurez définie. Tous les
+	attributs spécifiés seront enregistrés dans des variables
+	d'environnement avec le préfixe AUTHENTICATE_, afin de pouvoir
+	être utilisés par d'autres modules.
    
 
-dn: cn=Managers, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Bob Ellis, o=Example
-uniqueMember: cn=Tom Jackson, o=Example
+
    portée
    
 
-dn: cn=Administrators, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Barbara Jenson, o=Example
-uniqueMember: cn=Fred User, o=Example
+        
    Il s'agit de la portée de la recherche. Elle peut prendre
+	les valeurs one ou sub. Notez que la
+	RFC 2255 supporte aussi une portée de valeur base,
+	mais cette dernière n'est pas supportée par le module. Si la
+	portée n'est pas définie, ou si elle est définie à
+	base, c'est la valeur de portée par défaut
+	sub qui sera utilisée.
    
 
-dn: cn=Users, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Allan Jefferson, o=Example
-uniqueMember: cn=Paul Tilley, o=Example
-uniqueMember: cn=Temporary Employees, o=Example
+
    filtre
    
 
-dn: cn=Temporary Employees, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Jim Swenson, o=Example
-uniqueMember: cn=Elliot Rhodes, o=Example
    +
    Il s'agit d'un filtre de recherche LDAP valide. Si aucun + filtre n'est spécifié, le filtre par défaut + (objectClass=*) sera utilisé, ce qui corrspond à + une recherche de tous les types d'objets de l'arborescence. La + taille des filtres est limitée à environ 8000 caractères (valeur + de la macro MAX_STRING_LEN dans le code source + d'Apache), ce qui s'avère plus que suffisant pour la plupart des + applications. Depuis la version 2.4.10, il est possible + d'utiliser le paramètre "none" pour spécifier qu'aucun filtre + n'est activé ; ce paramètre est obligatoire avec certains + serveurs LDAP primitifs.
    +
    -

    Les directives suivantes autoriseraient alors l'accès à Bob - Ellis, Tom Jackson, Barbara Jenson, Fred User, Allan Jefferson, et - Paul Tilley, mais l'interdiraient à Jim Swenson, ou Elliot Rhodes - (car ils sont situés dans un sous-groupe de niveau de profondeur 2) - :

    -
    Require ldap-group cn=Employees, o=Example
-AuthLDAPMaxSubGroupDepth 1
    +

    Pour une recherche, les attribut, filtre et nom d'utilisateur + fournis par le client HTTP sont combinés pour créer un filtre de + recherche du style : + (&(filtre)(attribut + =nom-utilisateur)).

    +

    Par exemple, considérons l'URL + ldap://ldap.example.com/o=Example?cn?sub?(posixid=*). + Lorsqu'un client tentera de se connecter en utilisant le nom + d'utilisateur Babs Jenson, le filtre de recherche sera + : (&(posixid=*)(cn=Babs Jenson)).

    -

    Le comportement de cette directive est modifié par les directives - AuthLDAPGroupAttribute, - AuthLDAPGroupAttributeIsDN, - AuthLDAPMaxSubGroupDepth, - AuthLDAPSubGroupAttribute, et - AuthLDAPSubGroupClass.

    +

    On peut encore ajouter un paramètre optionnel pour permettre à + l'URL LDAP de surcharger le type de connexion. Ce paramètre peut + prendre l'une des valeurs suivantes :

    +
    +
    NONE
    +
    Établit une connexion non sécurisée sur le port LDAP par + défaut, ce qui est équivalent à ldap:// sur le port + 389.
    +
    SSL
    +
    Établit une connexion sécurisée sur le port LDAP sécurisé + par défaut, ce qui est équivalent à ldaps://.
    +
    TLS | STARTTLS
    +
    Établit une connexion sécurisée par élévation de niveau sur + le port LDAP par défaut. Cette connexion sera initialisée sur le + port 389 par défaut, puis élevée à un niveau de connexion + sécurisée sur le même port.
    +
    -

    Require ldap-dn

    +

    Voir plus haut pour des exemples d'URLs définies par la directive + AuthLDAPURL.

    -

    La directive Require ldap-dn permet à - l'administrateur d'accorder l'utorisation d'accès en fonction du DN. - Elle permet de spécifier un DN pour lequel l'accès est autorisé. Si - le DN extrait de - l'annuaire correspond au DN spécifié par la directive Require - ldap-dn, l'autorisation d'accès est accordée. Note : - n'entourez pas Le DN de guillemets.

    +
    +
    top
    +
    +

    Sommaire

    -

    La directive suivante accorderait l'accès à un DN spécifique - :

    -
    Require ldap-dn cn=Barbara Jenson, o=Example
    + +
    top
    +
    +

    Mode opératoire

    - 
    Require ldap-attribute employeeType=active
    +

    L'utilisateur se voit accorder l'accès selon un processus en deux + phases. La première phase est l'authentification, au cours de + laquelle le fournisseur d'authentification + mod_authnz_ldap vérifie que les informations de + connexion de l'utilisateur sont valides. Elle est aussi connue sous + le nom de phase de recherche/connexion (NdT : en anglais ou + dans le code source : search/bind). La deuxième + phase est l'autorisation, au cours de laquelle + mod_authnz_ldap détermine si l'utilisateur + authentifié a la permission d'accéder à la ressource considérée. + Elle est aussi connue sous le nom de phase de + comparaison (compare).

    +

    mod_authnz_ldap comporte un fournisseur + d'authentification authn_ldap et un gestionnaire d'autorisation + authz_ldap. Le fournisseur d'authentification authn_ldap peut être + invoqué en affectant la valeur ldap à la directive + AuthBasicProvider. Le + gestionnaire d'autorisation authz_ldap enrichit la liste des types + d'autorisations de la directive Require en y ajoutant les + valeurs ldap-user, ldap-dn et + ldap-group.

    -

    Plusieurs paires attribut/valeur peuvent être spécifiées par une - même directive en les séparant par des espaces, ou en définissant - plusieurs directives Require ldap-attribute. La logique - sous-jacente à une liste de paires attribut/valeur est une opération - OU. L'autorisation d'accès sera accordée si au moins une paire - attribut/valeur de la liste spécifiée correspond à la paire - attribut/valeur de l'utilisateur authentifié. Si elle contient des - espaces, la valeur, et seulement la valeur, doit être entourée de - guillemets.

    +

    La phase d'authentification

    -

    La directive suivante accorderait l'autorisation d'accès à tout - utilisateur dont l'attribut city aurait pour valeur "San Jose", ou - donc l'attribut status aurait pour valeur "actif" :

    +

    Au cours de la phase d'authentification, + mod_authnz_ldap recherche une entrée de l'annuaire + LDAP qui correspond au nom d'utilisateur fourni par le client HTTP. + Si une correspondance unique est trouvée, + mod_authnz_ldap tente de se connecter au serveur + hébergeant l'annuaire LDAP en utilisant le DN de l'entrée et le mot + de passe fourni par le client HTTP. Comme ce processus effectue tout + d'abord une recherche, puis une connexion, il est aussi connu sous + le nom de phase de recherche/connexion. Voici le détail des étapes + constituant la phase de recherche/connexion :

    - 
    Require ldap-attribute city="San Jose" status=active
    +
      +
    1. Confection d'un filtre de recherche en combinant les attribut + et filtre définis par la directive AuthLDAPURL avec le nom d'utilisateur et le mot de + passe fournis par le client HTTP.
      2. +
    2. Recherche dans l'annuaire LDAP en utilisant le filtre + confectionné précédemment. Si le résultat de la recherche est + négatif ou comporte plusieurs entrées, refus ou restriction de + l'accès.
      3. +
    3. Extraction du DN (distinguished name) de l'entrée issue du + résultat de la recherche, et tentative de connexion au serveur + LDAP en utilisant ce DN et le mot de passe fournis par le client + HTTP. Si la connexion échoue, refus ou restriction de + l'accès.
      4. +
    +

    Les directives utilisées durant la phase de recherche/connexion + sont les suivantes :

    -

    Require ldap-filter

    + + + + -

    La directive Require ldap-filter permet à - l'administrateur d'accorder l'autorisation d'accès en fonction d'un - filtre de recherche LDAP complexe. L'autorisation d'accès est - accordée si le DN renvoyé par le filtre de recherche correspond au - DN de l'utilisateur authentifié.

    + + -

    La directive suivante accorderait l'autorisation d'accès à tout - utilisateur possédant un téléphone cellulaire et faisant partie du - département "marketing" :

    + + - 
    Require ldap-filter &(cell=*)(department=marketing)
    + + + + -

    Alors que la directive Require ldap-attribute se - contente d'une simple comparaison d'attributs, la directive - Require ldap-filter effectue une opération de recherche - dans l'annuaire LDAP en utilisant le filtre de recherche spécifié. - Si une simple comparaison d'attributs suffit, l'opération de - comparaison effectuée par ldap-attribute sera plus - rapide que l'opération de recherche effectuée par - ldap-filter, en particulier dans le cas d'un annuaire - LDAP de grande taille.

    + + +
    AuthLDAPURLSpécifie le serveur LDAP, le DN de base, l'attribut à + utiliser pour la recherche, ainsi que les filtres de recherche + supplémentaires.
    AuthLDAPBindDNUn DN optionnel pour se connecter durant la phase de + recherche.
    AuthLDAPBindPasswordUn mot de passe optionnel pour se connecter durant la phase + de recherche.
    +

    La phase d'autorisation

    -
    top
    -
    -

    Exemples

    +

    Au cours de la phase d'autorisation, + mod_authnz_ldap tente de déterminer si + l'utilisateur est autorisé à accéder à la ressource considérée. Une + grande partie de cette vérification consiste pour + mod_authnz_ldap en des opérations de comparaison au + niveau du serveur LDAP. C'est pourquoi cette phase est aussi connue + sous le nom de phase de comparaison. + mod_authnz_ldap accepte les directives Require suivantes pour + déterminer si les informations de connexion permettent d'accorder + l'accès à l'utilisateur :

    - +

    Sous réserve du chargement de modules d'autorisation + supplémentaires, d'autres valeurs de la directive Require peuvent être + spécifiées.

    -
  • - Accorde l'accès à tout utilisateur appartenant au groupe dont le - nom correspond au nom d'hôte du serveur virtuel. Dans cet exemple, - on utilise une expression pour - construire le filtre. -
    AuthLDAPURL ldap://ldap.example.com/o=Example?uid
-Require ldap-group cn=%{SERVER_NAME}, o=Example
    +
      +
    • L'accès est accordé à tous les utilisateurs authentifiés si + une directive Require + valid-user est présente (nécessite le module + mod_authz_user).
      • - +
    • Avec la directive Require group, l'autorisation + d'accès est accordée si le module + mod_authz_groupfile a été chargé et si la + directive AuthGroupFile a été + définie.
      • -
    • - Pour l'exemple suivant, on suppose que tout utilisateur de chez - Example qui dispose d'un bippeur alphanumérique possèdera un - attribut LDAP qpagePagerID. Seuls ces utilisateurs - (authentifiés via leur UID) se verront accorder l'autorisation - d'accès : -
      AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(qpagePagerID=*)
-Require valid-user
      +
    • etc...
      • +
    -
    • -
  • -

    L'exemple suivant illustre la puissance des filtres pour - effectuer des requêtes complexes. Sans les filtres, il aurait - été nécessaire de créer un nouveau groupe LDAP et de s'assurer - de la synchronisation des membres du groupe avec les - utilisateurs possédant un bippeur. Tout devient limpide avec les - filtres. Nous avons pour but d'accorder l'autorisation d'accès à - tout utilisateur disposant d'un bippeur ainsi qu'à Joe Manager - qui ne possède pas de bippeur, mais doit tout de même pouvoir - accéder à la ressource :

    -
    AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(|(qpagePagerID=*)(uid=jmanager))
-Require valid-user
    +

    Durant la phase de comparaison, mod_authnz_ldap + utilise les directives suivantes :

    + + + + -

    Ce dernier exemple peut sembler confus au premier abord ; en - fait, il permet de mieux comprendre à quoi doit ressembler le - filtre en fonction de l'utilisateur qui se connecte. Si Fred - User se connecte en tant que fuser, le filtre devra - ressembler à :

    + + -

    (&(|(qpagePagerID=*)(uid=jmanager))(uid=fuser))

    + + -

    Un recherche avec le filtre ci-dessus ne retournera un - résultat positif que si fuser dispose d'un bippeur. Si - Joe Manager se connecte en tant que jmanager, le filtre - devra ressembler à :

    + + -

    (&(|(qpagePagerID=*)(uid=jmanager))(uid=jmanager))

    + + -

    Un recherche avec le filtre ci-dessus retournera un - résultat positif que jmanager dispose d'un - bippeur ou non

    - - -
    top
    -
    -

    Utilisation de TLS

    +
    + -

    Pour l'utilisation de TLS, voir les directives du module - mod_ldap LDAPTrustedClientCert, LDAPTrustedGlobalCert et LDAPTrustedMode.

    + + -

    Un second paramètre optionnel peut être ajouté à la directive - AuthLDAPURL pour - remplacer le type de connexion par défaut défini par la directive - LDAPTrustedMode. Ceci - permettra de promouvoir la connexion établie via une URL du type - ldap:// au statut de connection sécurisée sur le même - port.

    -
    top
    -
    -

    Utilisation de SSL

    +
    + -

    Pour l'utilisation de SSL, voir les directives du module - mod_ldap LDAPTrustedClientCert, LDAPTrustedGlobalCert et LDAPTrustedMode.

    + + -

    Pour spécifier un serveur LDAP sécurisé, utilisez - ldaps:// au lieu de - ldap:// dans la directive AuthLDAPURL.

    -
    top
    -
    -

    Mise à disposition des informations de -connexion

    +
    + -

    Au cours du processus d'authentification, les attributs LDAP - spécifiés par la directive authldapurl sont enregistrés - dans des variables d'environnement préfixées par la chaîne - "AUTHENTICATE_".

    + + -

    Au cours du processus d'autorisation, les attributs LDAP - spécifiés par la directive authldapurl sont enregistrés - dans des variables d'environnement préfixées par la chaîne - "AUTHORIZE_".

    + + -

    Si les champs attribut contiennent le nom, le CN et le numéro de - téléphone d'un utilisateur, un programme CGI pourra accéder à ces - informations sans devoir effectuer une autre requête LDAP pour - les extraire de l'annuaire.

    + + -

    Ceci a pour effet de simplifier considérablement le code et la - configuration nécessaire de certaines applications web.

    + + +
    AuthLDAPURL + On utilise l'attribut spécifié dans l'URL pour les + opérations de comparaison initiées par la directive + Require ldap-user.
    AuthLDAPCompareDNOnServerDétermine le comportement de la directive Require + ldap-dn.
    AuthLDAPGroupAttributeDétermine l'attribut utilisé pour les opérations de + comparaison initiées par la directive Require + ldap-group.
    AuthLDAPGroupAttributeIsDNSpécifie si l'on doit utiliser le DN ou le nom de + l'utilisateur lors des opérations de comparaison initiées par la + directive Require ldap-group.
    AuthLDAPMaxSubGroupDepthDétermine la profondeur maximale de l'arborescence des + sous-groupes qui seront évalués au cours des opérations de + comparaisons initiées par la directive Require + ldap-group.
    AuthLDAPSubGroupAttributeDétermine l'attribut à utiliser lors de l'extraction de + membres de sous-groupes du groupe courant au cours des + opérations de comparaison initiées par la directive + Require ldap-group.
    AuthLDAPSubGroupClassSpécifie les valeurs de classe d'objet LDAP à utiliser pour + déterminer si les objets extraits de l'annuaire sont bien des + objets de type groupe (et non des objets de type utilisateur), + au cours du traitement des sous-groupes initié par la directive + Require ldap-group.
    • top
    -

    Utilisation d'Active -Directory

    +

    Les directives requises

    -

    Active Directory peut supporter plusieurs domaines à la fois. - Pour faire la distinction entre les utilisateurs de plusieurs - domaines, on peut ajouter à l'entrée de l'utilisateur dans - l'annuaire un identifiant appelé Nom - Principal d'Utilisateur (User Principle Name ou UPN). Cet UPN se - compose en général du nom de compte de l'utilisateur, suivi du nom - du domaine considéré, par exemple untel@nz.example.com.

    +

    Les directives Require d'Apache sont utilisées + au cours de la phase d'autorisation afin de s'assurer que + l'utilisateur est autorisé à accéder à une ressource. + mod_authnz_ldap enrichit la liste des types d'autorisations avec les + valeurs ldap-user, ldap-dn, + ldap-group, ldap-attribute et + ldap-filter. D'autres types d'autorisations sont + disponibles, sous réserve du chargement de modules d'autorisation + supplémentaires.

    -

    Vous voudrez probablement configurer le module - mod_authnz_ldap afin de pouvoir authentifier les - utilisateurs de n'importe quel domaine de la forêt Active Directory. - Ainsi, untel@nz.example.com et - untel@au.example.com pourront être authentifiés en une - seule fois par la même requête.

    +

    Depuis la version 2.4.8, les directives require LDAP supportent + les expressions.

    -

    Pour y parvenir, on utilise le concept de Catalogue Global - d'Active Directory. Ce Catalogue Global est une copie en lecture - seule des attributs sélectionnés de tous les serveurs de la forêt - Active Directory. Une requête vers le - Catalogue Global permet donc d'atteindre tous les domaines en une - seule fois, sans avoir à se connecter aux différents serveurs, via - des liaisons dont certaines peuvent être lentes.

    +

    Require ldap-user

    -

    Lorsqu'il est activé, la Catalogue Global est un serveur - d'annuaire indépendant accessible sur le port 3268 (3269 pour SSL). - Pour rechercher un utilisateur, effectuez une recherche sur - l'attribut userPrincipalName, avec une base de recherche - vide, comme suit :

    +

    La directive Require ldap-user permet de spécifier + les noms des utilisateurs autorisés à accéder à la ressource. + Lorsque mod_authnz_ldap a extrait un DN unique de + l'annuaire LDAP, il effectue une opération de comparaison LDAP en + utilisant le nom d'utilisateur spécifié par la directive + Require ldap-user, pour vérifier si ce nom + d'utilisateur correspond à l'entrée LDAP extraite. On peut accorder + l'accès à plusieurs utilisateurs en plaçant plusieurs nom + d'utilisateurs sur la même ligne séparés par des espaces. Si un nom + d'utilisateur contient des espaces, il doit être entouré de + guillemets. On peut aussi accorder l'accès à plusieurs utilisateurs + en utilisant une directive Require ldap-user par + utilisateur. Par exemple, avec la directive AuthLDAPURL définie à + ldap://ldap/o=Example?cn (spécifiant donc que l'attribut + cn sera utilisé pour les recherches), on pourra + utiliser les directives Require suivantes pour restreindre l'accès + :

    +
    Require ldap-user "Barbara Jenson"
+Require ldap-user "Fred User"
+Require ldap-user "Joe Manager"
    -
    AuthLDAPBindDN apache@example.com
-AuthLDAPBindPassword password
-AuthLDAPURL ldap://10.0.0.1:3268/?userPrincipalName?sub
    +

    De par la manière dont mod_authnz_ldap traite + cette directive, Barbara Jenson peut s'authentifier comme + Barbara Jenson, Babs Jenson ou tout autre + cn sous lequel elle est enregistrée dans l'annuaire + LDAP. Une seule ligne Require ldap-user suffit pour + toutes les valeurs de l'attribut dans l'entrée LDAP de + l'utilisateur.

    + +

    Si l'attribut uid avait été spécifié à la place de + l'attribut cn dans l'URL précédente, les trois lignes + ci-dessus auraient pû être condensées en une seule ligne :

    +
    Require ldap-user bjenson fuser jmanager
    -

    Les utilisateurs devront s'authentifier en entrant leur UPN, de - la formeuntel@nz.example.com.

    -
    top
    -
    -

    Utilisation de Microsoft - FrontPage avec mod_authnz_ldap

    -

    Normalement, FrontPage utilise des fichiers utilisateur/groupe - spécifiques à FrontPage-web (c'est à dire les modules - mod_authn_file et - mod_authz_groupfile) pour effectuer toute - l'authentification. Malheureusement, il ne suffit pas de modifier - l'authentification LDAP en ajoutant les directives appropriées, car - ceci corromprait les formulaires de Permissions dans le - client FrontPage, qui sont censés modifier les fichiers - d'autorisation standards au format texte.

    +

    Require ldap-group

    + +

    Cette directive permet de spécifier un groupe LDAP dont les + membres auront l'autorisation d'accès. Elle prend comme argument le + DN du groupe LDAP. Note : n'entourez pas le nom du groupe avec des + guillemets. Par exemple, supposons que l'entrée suivante existe dans + l'annuaire LDAP :

    +
    dn: cn=Administrators, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Barbara Jenson, o=Example
+uniqueMember: cn=Fred User, o=Example
    -

    Lorsqu'un site web FrontPage a été créé, lui adjoindre - l'authentification LDAP consiste à ajouter les directives suivantes - à chaque fichier .htaccess qui sera créé dans - le site web :

    -
    AuthLDAPURL       "the url"
-AuthGroupFile     mygroupfile
-Require group     mygroupfile
    +

    La directive suivante autoriserait alors l'accès à Fred et + Barbara :

    +
    Require ldap-group cn=Administrators, o=Example
    -

    Comment ça marche

    +

    Les membres peuvent aussi se trouver dans les sous-groupes du + groupe LDAP spécifié si la directive AuthLDAPMaxSubGroupDepth a été + définie à une valeur supérieure à 0. Par exemple, supposons que les + entrées suivantes existent dans l'annuaire LDAP :

    +
    dn: cn=Employees, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Managers, o=Example
+uniqueMember: cn=Administrators, o=Example
+uniqueMember: cn=Users, o=Example
 
-    
    FrontPage restreint l'accès à un site web en ajoutant la
-    directive Require valid-user aux fichiers
-    .htaccess. La directive Require valid-user
-    permettra l'accès à tout utilisateur valide du point de vue
-    LDAP. Cela signifie que tout utilisateur possédant une entrée
-    dans l'annuaire LDAP sera considéré comme valide, alors que
-    FrontPage ne considère comme valides que les utilisateurs
-    enregistrés dans le fichier des utilisateurs local. En remplaçant
-    l'autorisation par groupe LDAP par une autorisation par fichier de
-    groupe, Apache sera en mesure de consulter le fichier des
-    utilisateurs local (géré par FrontPage) - au lieu de l'annuaire LDAP
-    - lors du processus d'autorisation des utilisateurs.
    
+dn: cn=Managers, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Bob Ellis, o=Example
+uniqueMember: cn=Tom Jackson, o=Example
 
-    
    Une fois les directives ajoutées selon ce qui précède, les
-    utilisateurs FrontPage pourront effectuer toutes les opérations de
-    gestion à partir du client FrontPage.
    
+dn: cn=Administrators, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Barbara Jenson, o=Example
+uniqueMember: cn=Fred User, o=Example
 
+dn: cn=Users, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Allan Jefferson, o=Example
+uniqueMember: cn=Paul Tilley, o=Example
+uniqueMember: cn=Temporary Employees, o=Example
 
-
    Avertissements
    
+dn: cn=Temporary Employees, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Jim Swenson, o=Example
+uniqueMember: cn=Elliot Rhodes, o=Example
    - -
    -
    top
    -

    Directive AuthLDAPAuthorizePrefix

    - - - - - - - - - -
    Description:Spécifie le préfixe ajouté aux variables d'environnement -durant la phase d'autorisation
    Syntaxe:AuthLDAPAuthorizePrefix préfixe
    Défaut:AuthLDAPAuthorizePrefix AUTHORIZE_
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible depuis la version 2.3.6
    -

    Cette directive permet de spécifier le préfixe ajouté aux - variables d'environnement durant la phase d'autorisation. Si la - valeur spécifiée est AUTHENTICATE_, les utilisateurs de ces - variables d'environnement verront les mêmes informations, que le - serveur effectue une authentification, une autorisation, ou les - deux.

    +

    Require ldap-dn

    -

    Note

    - Aucune variable d'autorisation n'est définie lorsqu'un utilisateur - s'est vu autoriser l'accès via la directive Require - valid-user. -
    +

    La directive Require ldap-dn permet à + l'administrateur d'accorder l'utorisation d'accès en fonction du DN. + Elle permet de spécifier un DN pour lequel l'accès est autorisé. Si + le DN extrait de + l'annuaire correspond au DN spécifié par la directive Require + ldap-dn, l'autorisation d'accès est accordée. Note : + n'entourez pas Le DN de guillemets.

    -
    -
    top
    -

    Directive AuthLDAPBindAuthoritative

    - - - - - - - - -
    Description:Détermine si l'on doit utiliser d'autres fournisseurs -d'authentification lorsque le serveur ne peut pas valider les données -d'authentification de l'utilisateur, alors que ce dernier possède un -DN.
    Syntaxe:AuthLDAPBindAuthoritativeoff|on
    Défaut:AuthLDAPBindAuthoritative on
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    -

    Par défaut, des fournisseurs d'authentification sont appelés - si un utilisateur ne possède pas de DN, mais ne le sont pas si - l'utilisateur possède un DN et si son mot de passe ne peut pas être - vérifié lors d'une connexion au serveur LDAP. Si la directive - AuthLDAPBindAuthoritative est - définie à off, d'autres modules d'authentification - configurés auront une chance de valider le mot de passe de - l'utilisateur si la tentative de connexion au serveur LDAP échoue - pour une raison quelconque (avec les données d'authentification - fournies).

    -

    Ceci permet aux utilisateurs présent à la fois dans l'annuaire - LDAP et dans un fichier AuthUserFile de s'authentifier - lorsque le serveur LDAP est disponible, alors que le compte de - l'utilisateur est verrouillé ou que son mot de passe est - inutilisable pour une raison quelconque.

    +

    La directive suivante accorderait l'accès à un DN spécifique + :

    +
    Require ldap-dn cn=Barbara Jenson, o=Example
    -

    Voir aussi

    - -
    -
    top
    -

    Directive AuthLDAPBindDN

    - - - - - - - -
    Description:Un DN optionnel pour se connecter au serveur -LDAP
    Syntaxe:AuthLDAPBindDN dn
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    -

    Cette directive permet de définir un DN optionnel pour se - connecter au serveur afin d'y rechercher des entrées. Si aucun DN - n'est spécifié, mod_authnz_ldap tentera une - connexion anonyme.

    -
    -
    top
    -

    Directive AuthLDAPBindPassword

    - - - - - - - - -
    Description:Mot de passe à utiliser en conjonction avec le DN de -connexion
    Syntaxe:AuthLDAPBindPassword mot-de-passe
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:exec: est disponible depuis la version 2.4.5 du -serveur HTTP Apache.
    -

    Cette directive permet de spécifier un mot de passe à utiliser en - conjonction avec le DN de connexion. Notez que ce mot de passe - constitue en général une donnée sensible, et doit donc être protégé - de manière appropriée. Vous ne devez utiliser les directives - AuthLDAPBindDN et AuthLDAPBindPassword que si - vous en avez vraiment besoin pour effectuer une recherche dans - l'annuaire.

    +

    Le comportement ce cette directive est modifié par la directive + AuthLDAPCompareDNOnServer.

    -

    Si la valeur spécifiée débute par "exec:", la commande qui suit sera - exécutée, et la première ligne renvoyée par la commande sur la - sortie standard sera utilisée comme mot de passe.

    -
    # Mot de passe spécifié directement
-AuthLDAPBindPassword secret
 
-# Exécution de /path/to/program pour obtenir le mot de passe
-AuthLDAPBindPassword exec:/path/to/program
+
    Require ldap-attribute
    
 
-# Exécution de /path/to/otherProgram avec un argument pour obtenir le mot de passe
-AuthLDAPBindPassword "exec:/path/to/otherProgram argument1"
    +

    La directive Require ldap-attribute permet à + l'administrateur d'accorder l'autorisation d'accès en fonction des + attributs de l'utilisateur authentifié dans l'annuaire LDAP. Si la + valeur de l'attribut dans l'annuaire correspond à la valeur + spécifiée par la directive, l'autorisation d'accès est accordée.

    +

    La directive suivante accorderait l'autorisation d'accès à tout + utilisateur dont l'attribut employeeType a pour valeur "actif" :

    + 
    Require ldap-attribute employeeType=active
    -
    -
    top
    -

    Directive AuthLDAPCharsetConfig

    - - - - - - -
    Description:Chemin du fichier de configuration de la correspondance -langage/jeu de caractères
    Syntaxe:AuthLDAPCharsetConfig chemin-fichier
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_authnz_ldap
    -

    La directive AuthLDAPCharsetConfig permet - de définir le chemin du fichier de configuration de la - correspondance langage/jeu de caractères. chemin-fichier - est un chemin relatif au répertoire défini par la directive - ServerRoot. Ce fichier contient une liste - de correspondances extension de langage/jeu de caractères. La - plupart des administrateurs utilisent le fichier - charset.conv fourni qui associe les extensions de - langage courantes à leurs jeux de caractères.

    -

    Le fichier contient des lignes au format suivant :

    +

    Plusieurs paires attribut/valeur peuvent être spécifiées par une + même directive en les séparant par des espaces, ou en définissant + plusieurs directives Require ldap-attribute. La logique + sous-jacente à une liste de paires attribut/valeur est une opération + OU. L'autorisation d'accès sera accordée si au moins une paire + attribut/valeur de la liste spécifiée correspond à la paire + attribut/valeur de l'utilisateur authentifié. Si elle contient des + espaces, la valeur, et seulement la valeur, doit être entourée de + guillemets.

    + +

    La directive suivante accorderait l'autorisation d'accès à tout + utilisateur dont l'attribut city aurait pour valeur "San Jose", ou + donc l'attribut status aurait pour valeur "actif" :

    -

    - extension de langage jeu de caractères - [Nom du langage] ... -

    + 
    Require ldap-attribute city="San Jose" status=active
    -

    L'extension est insensible à la casse. Les lignes vides et les - lignes commençant par un dièse (#) sont ignorées.

    -
    -
    top
    -

    Directive AuthLDAPCompareAsUser

    - - - - - - - - - -
    Description:Utilisation des données d'authentification de l'utilisateur -pour effectuer les comparaisons pour l'attribution des autorisations
    Syntaxe:AuthLDAPCompareAsUser on|off
    Défaut:AuthLDAPCompareAsUser off
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible depuis la version version 2.3.6
    -

    Lorsque cette directive est définie, et si - mod_authnz_ldap a authentifié l'utilisateur, les - recherches LDAP pour les autorisations utilisent le nom distinctif - trouvé (DN) et le mot de passe d'authentification basique HTTP de - l'utilisateur authentifié au lieu des données d'authentification - configurées au niveau du serveur.

    -

    Les vérifications d'autorisation ldap-attribute, - ldap-user, et ldap-group (niveau simple seulement) - utilisent des comparaisons.

    -

    Cette directive n'a d'effet sur les comparaisons effectuées au - cours des traitements de groupe imbriqués, et lorsque la directive - AuthLDAPSearchAsUser - est aussi activée.

    +

    Require ldap-filter

    -

    Cette directive ne doit être utilisée que si votre serveur LDAP - n'autorise pas les recherches anonymes, ou si vous ne pouvez pas - utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN. -

    +

    La directive Require ldap-filter permet à + l'administrateur d'accorder l'autorisation d'accès en fonction d'un + filtre de recherche LDAP complexe. L'autorisation d'accès est + accordée si le DN renvoyé par le filtre de recherche correspond au + DN de l'utilisateur authentifié.

    -

    Voir aussi

    - -
    -
    top
    -

    Directive AuthLDAPCompareDNOnServer

    - - - - - - - - -
    Description:Utilise le serveur LDAP pour comparer les DNs
    Syntaxe:AuthLDAPCompareDNOnServer on|off
    Défaut:AuthLDAPCompareDNOnServer on
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    -

    Lorsque cette directive est définie à on, - mod_authnz_ldap utilise le serveur LDAP pour - comparer les DNs. Il s'agit de la seule méthode infaillible pour - comparer les DNs. mod_authnz_ldap va rechercher - dans l'annuaire le DN spécifié par la directive Require dn, puis extraire ce DN et le - comparer avec le DN extrait de l'entrée de l'utilisateur. Si cette - directive est à off, mod_authnz_ldap effectue une - simple comparaison de chaînes. Cette dernière approche peut produire - des faux négatifs, mais elle est beaucoup plus rapide. Notez - cependant que le cache de mod_ldap peut accélérer - la comparaison de DNs dans la plupart des situations.

    +

    La directive suivante accorderait l'autorisation d'accès à tout + utilisateur possédant un téléphone cellulaire et faisant partie du + département "marketing" :

    -
    -
    top
    -

    Directive AuthLDAPDereferenceAliases

    - - - - - - - - -
    Description:À quel moment le module va déréférencer les -alias
    Syntaxe:AuthLDAPDereferenceAliases never|searching|finding|always
    Défaut:AuthLDAPDereferenceAliases always
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    -

    Cette directive permet de spécifier à quel moment - mod_authnz_ldap va déréférencer les alias au cours - des opérations liées à LDAP. La valeur par défaut est - always.

    + 
    Require ldap-filter &(cell=*)(department=marketing)
    -
    -
    top
    -

    Directive AuthLDAPGroupAttribute

    - - - - - - - - -
    Description:L'attribut LDAP utilisé pour vérifier l'appartenance d'un -utilisateur à un groupe.
    Syntaxe:AuthLDAPGroupAttribute attribut
    Défaut:AuthLDAPGroupAttribute member uniquemember
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    -

    Cette directive permet de spécifier quel attribut LDAP est - utilisé pour vérifier l'appartenance d'un utilisateur à un - groupe. On peut spécifier plusieurs attributs en répétant cette - directive plusieurs fois. Si la directive n'est pas définie, - mod_authnz_ldap utilise les attributs - member et uniquemember.

    -
    -
    top
    -

    Directive AuthLDAPGroupAttributeIsDN

    - - - - - - - - -
    Description:Utilise le DN de l'utilisateur pour vérifier son -appartenance à un groupe
    Syntaxe:AuthLDAPGroupAttributeIsDN on|off
    Défaut:AuthLDAPGroupAttributeIsDN on
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    -

    Lorsqu'elle est définie à on, cette directive - indique que c'est le DN de l'utilisateur qui doit être utilisé pour - vérifier son appartenance à un groupe. Dans le cas contraire, c'est - le nom de l'utilisateur qui sera utilisé. Par exemple, supposons que - le client envoie le nom d'utilisateur bjenson, qui - correspond au DN LDAP cn=Babs Jenson,o=Example. Si la - directive est à on, mod_authnz_ldap va - vérifier si cn=Babs Jenson, o=Example est un membre du - groupe. Dans le cas contraire, mod_authnz_ldap - vérifiera si bjenson est un membre du groupe.

    +

    Alors que la directive Require ldap-attribute se + contente d'une simple comparaison d'attributs, la directive + Require ldap-filter effectue une opération de recherche + dans l'annuaire LDAP en utilisant le filtre de recherche spécifié. + Si une simple comparaison d'attributs suffit, l'opération de + comparaison effectuée par ldap-attribute sera plus + rapide que l'opération de recherche effectuée par + ldap-filter, en particulier dans le cas d'un annuaire + LDAP de grande taille.

    -
    -
    top
    -

    Directive AuthLDAPInitialBindAsUser

    - - - - - - - - - -
    Description:Détermine si le serveur effectue la recherche initiale du -DN en utilisant le nom propre de l'utilisateur pour l'authentification -de base -et non de manière anonyme, ou en utilisant des données d'authentification -codées en dur pour le serveur
    Syntaxe:AuthLDAPInitialBindAsUser off|on
    Défaut:AuthLDAPInitialBindAsUser off
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible depuis la version 2.3.6
    -

    Par défaut, le serveur convertit le nom d'utilisateur pour - l'authentification de base en nom distinctif LDAP (DN) soit de - manière anonyme, soit avec un couple nom/mot de passe dédié. Cette - directive permet de forcer le serveur à utiliser les véritables nom - d'utilisateur et mot de passe fournis par l'utilisateur pour - effectuer la recherche initiale du DN.

    -

    Si le nom d'utilisateur ne peut pas s'authentifier directement - et nécessite de légères modifications, voir la directive AuthLDAPInitialBindPattern.

    -

    Cette directive ne doit être utilisée que si votre serveur LDAP - n'autorise pas les recherches anonymes, ou si vous ne pouvez pas - utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN. -

    +
    top
    +
    +

    Exemples

    -

    Non disponible dans la cas d'une autorisation seule

    - On ne peut utiliser cette directive que si ce module - effectue une authentification, et n'a aucun effet si ce module - n'est utilisé que pour les processus d'autorisation. -
    +
    -
    top
    -

    Directive AuthLDAPInitialBindPattern

    - - - - - - - - - -
    Description:Spécifie la modification a apporter au nom d'utilisateur -pour l'authentification de base lors de l'authentification auprès du -serveur LDAP pour effectuer une recherche de DN
    Syntaxe:AuthLDAPInitialBindPatternregex substitution
    Défaut:AuthLDAPInitialBindPattern (.*) $1 (nom de l'utilisateur -distant utilisé tel quel)
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible depuis la version 2.3.6
    -

    Si la directive AuthLDAPInitialBindAsUser est - définie à ON, le nom utilisateur pour l'authentification de - base sera transformé selon l'expression rationnelle - regex et l'argument substitution spécifiés.

    + -

    L'expression rationnelle est comparée au nom d'utilisateur pour - l'authentification de base courant. L'argument - substitution peut contenir des références arrières, mais - n'effectue aucune autre interpolation de variable.

    +
  • + L'exemple suivant est similaire au précédent, mais les champs + dont les valeurs par défaut conviennent sont omis. Notez aussi + la présence d'un annuaire LDAP redondant : +
    AuthLDAPURL "ldap://ldap1.example.com ldap2.example.com/ou=People, o=Example"
+Require valid-user
    -

    Cette directive ne doit être utilisée que si votre serveur LDAP - n'autorise pas les recherches anonymes, ou si vous ne pouvez pas - utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN. -

    +
    • + +
  • + Encore un exemple similaire aux précédents, mais cette fois, + c'est l'attribut cn qui est utilisé pour la recherche à la place + de l'UID. Notez que ceci peut poser problème si plusieurs + utilisateurs de l'annuaire partagent le même cn, + car une recherche sur le cn doit + retourner une entrée et une seule. C'est pourquoi cette + approche n'est pas recommandée : il est préférable de choisir un + attribut de votre annuaire dont l'unicité soit garantie, comme + uid. +
    AuthLDAPURL "ldap://ldap.example.com/ou=People, o=Example?cn"
+Require valid-user
    - 
    AuthLDAPInitialBindPattern (.+) $1@example.com
    +
    • - 
    AuthLDAPInitialBindPattern (.+) cn=$1,dc=example,dc=com
    +
  • + Accorde l'autorisation d'accès à tout utilisateur appartenant au + groupe Administrateurs. Les utilisateurs doivent s'authentifier + en utilisant leur UID : +
    AuthLDAPURL ldap://ldap.example.com/o=Example?uid
+Require ldap-group cn=Administrators, o=Example
    +
    • -

    Non disponible dans la cas d'une autorisation seule

    - On ne peut utiliser cette directive que si ce module - effectue une authentification, et n'a aucun effet si ce module - n'est utilisé que pour les processus d'autorisation. -
    -

    Débogage

    - Le DN de substitution est enregistré dans la variable - d'environnement LDAP_BINDASUSER. Si l'expression - rationnelle ne convient pas, le nom d'utilisateur est utilisé - tel quel. -
    +
  • + Accorde l'accès à tout utilisateur appartenant au groupe dont le + nom correspond au nom d'hôte du serveur virtuel. Dans cet exemple, + on utilise une expression pour + construire le filtre. +
    AuthLDAPURL ldap://ldap.example.com/o=Example?uid
+Require ldap-group cn=%{SERVER_NAME}, o=Example
    -

    Voir aussi

    - -
    • -
    top
    -

    Directive AuthLDAPMaxSubGroupDepth

    - - - - - - - - - -
    Description:Spécifie la profondeur d'imbrication des sous-groupes -maximale prise en compte avant l'abandon de la recherche de -l'utilisateur.
    Syntaxe:AuthLDAPMaxSubGroupDepth Nombre
    Défaut:AuthLDAPMaxSubGroupDepth 10
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible à partir de la version 2.3.0 du serveur HTTP -Apache
    -

    Lorsque cette directive est définie à une valeur X - non nulle, en combinaison avec l'utilisation de la directive - Require ldap-group DN-groupe, les données de connexion - fournies seront utilisées pour vérifier l'appartenance de - l'utilisateur à l'objet de l'annuaire DN-groupe ou à - tout sous-groupe du groupe courant en tenant compte de la profondeur - d'imbrication maximale X spécifiée par la directive.

    -

    Se référer à la section Require - ldap-group pour un exemple plus détaillé.

    + -

    Performances dans le cas des groupes imbriqués

    -

    Lorsque les directives - AuthLDAPSubGroupAttribute et - AuthLDAPGroupAttribute se recouvrent (comme - c'est le cas par défaut et requis par les schémas LDAP courants), la - recherche de sous-groupes au sein de grands groupes peut être très - longue. Si vos groupes sont très grands et non imbriqués, définissez - la directive AuthLDAPMaxSubGroupDepth à 0.

    -
    +
  • + Pour l'exemple suivant, on suppose que tout utilisateur de chez + Example qui dispose d'un bippeur alphanumérique possèdera un + attribut LDAP qpagePagerID. Seuls ces utilisateurs + (authentifiés via leur UID) se verront accorder l'autorisation + d'accès : +
    AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(qpagePagerID=*)
+Require valid-user
    +
    • -
    -
    top
    -

    Directive AuthLDAPRemoteUserAttribute

    - - - - - - - - -
    Description:Spécifie l'attribut dont la valeur renvoyée au cours de la -requête de l'utilisateur sera utilisée pour définir la variable -d'environnement REMOTE_USER
    Syntaxe:AuthLDAPRemoteUserAttribute uid
    Défaut:none
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    -

    Lorsque cette directive est définie, la variable d'environnement - REMOTE_USER sera définie à la valeur de l'attribut - spécifié. Assurez-vous que cet attribut soit bien inclus dans la - liste d'attributs spécifiés dans la définition de AuthLDAPUrl ; dans - le cas contraire, cette directive n'aurait aucun effet. Si elle est - présente, cette directive l'emporte sur AuthLDAPRemoteUserIsDN. Elle - peut s'avérer utile par exemple, si vous souhaitez que les - utilisateurs se connectent à un site web en utilisant leur adresse - email, alors qu'une application sous-jacente nécessite un nom - d'utilisateur comme identifiant.

    +
  • +

    L'exemple suivant illustre la puissance des filtres pour + effectuer des requêtes complexes. Sans les filtres, il aurait + été nécessaire de créer un nouveau groupe LDAP et de s'assurer + de la synchronisation des membres du groupe avec les + utilisateurs possédant un bippeur. Tout devient limpide avec les + filtres. Nous avons pour but d'accorder l'autorisation d'accès à + tout utilisateur disposant d'un bippeur ainsi qu'à Joe Manager + qui ne possède pas de bippeur, mais doit tout de même pouvoir + accéder à la ressource :

    +
    AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(|(qpagePagerID=*)(uid=jmanager))
+Require valid-user
    -
    • -
    top
    -

    Directive AuthLDAPRemoteUserIsDN

    - - - - - - - - -
    Description:Utilise le DN de l'utilisateur pour définir la variable -d'environnement REMOTE_USER
    Syntaxe:AuthLDAPRemoteUserIsDN on|off
    Défaut:AuthLDAPRemoteUserIsDN off
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    -

    Lorsque cette directive est à on, la variable d'environnement - REMOTE_USER sera définie avec la valeur du DN complet - de l'utilisateur authentifié, et non plus avec simplement le nom - d'utilisateur fourni par le client. Elle est définie à off par - défaut.

    -
    -
    top
    -

    Directive AuthLDAPSearchAsUser

    - - - - - - - - - -
    Description:Utilise les données d'authentification de l'utilisateur -pour la recherche des autorisations
    Syntaxe:AuthLDAPSearchAsUser on|off
    Défaut:AuthLDAPSearchAsUser off
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible depuis la version 2.3.6
    -

    Lorsque cette directive est définie, et si - mod_authnz_ldap a authentifié l'utilisateur, les - recherches LDAP pour définir les autorisations utilisent le nom - distinctif (DN) trouvé et le mot de passe pour l'authentification de - base HTTP de l'utilisateur authentifié, au lieu des données - d'authentification configurées au niveau du serveur.

    +

    Ce dernier exemple peut sembler confus au premier abord ; en + fait, il permet de mieux comprendre à quoi doit ressembler le + filtre en fonction de l'utilisateur qui se connecte. Si Fred + User se connecte en tant que fuser, le filtre devra + ressembler à :

    -

    Les vérifications d'autorisation ldap-filter et - ldap-dn utilisent des recherches.

    +

    (&(|(qpagePagerID=*)(uid=jmanager))(uid=fuser))

    -

    Cette directive n'a d'effet sur les comparaisons effectuées au - cours des traitements de groupe imbriqués, et lorsque la directive - AuthLDAPCompareAsUser - est aussi activée.

    +

    Un recherche avec le filtre ci-dessus ne retournera un + résultat positif que si fuser dispose d'un bippeur. Si + Joe Manager se connecte en tant que jmanager, le filtre + devra ressembler à :

    -

    Cette directive ne doit être utilisée que si votre serveur LDAP - n'autorise pas les recherches anonymes, ou si vous ne pouvez pas - utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN. -

    +

    (&(|(qpagePagerID=*)(uid=jmanager))(uid=jmanager))

    +

    Un recherche avec le filtre ci-dessus retournera un + résultat positif que jmanager dispose d'un + bippeur ou non

    + + +
    top
    +
    +

    Utilisation de TLS

    -

    Voir aussi

    - -
    -
    top
    -

    Directive AuthLDAPSubGroupAttribute

    - - - - - - - - - -
    Description:Spécifie les noms d'attribut, un par directive, utilisés -pour différencier les membres du groupe courant qui sont eux-mêmes des -groupes.
    Syntaxe:AuthLDAPSubGroupAttribute attribut
    Défaut:AuthLDAPSubgroupAttribute member uniquemember
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible à partir de la version 2.3.0 du serveur HTTP -Apache
    -

    Un objet groupe LDAP peut contenir des membres qui sont des - utilisateurs et des membres qui sont eux-mêmes des groupes (appelés - sous-groupes ou groupes imbriqués). La directive - AuthLDAPSubGroupAttribute spécifie l'attribut utilisé - pour identifier les groupes, alors que la directive - AuthLDAPGroupAttribute spécifie l'attribut utilisé - pour identifier les utilisateurs. On peut spécifier plusieurs - attributs en répétant la directive plusieurs fois. Si elle n'est pas - définie, mod_authnz_ldap utilise les attributs - member et uniqueMember.

    +

    Pour l'utilisation de TLS, voir les directives du module + mod_ldap LDAPTrustedClientCert, LDAPTrustedGlobalCert et LDAPTrustedMode.

    -
    -
    top
    -

    Directive AuthLDAPSubGroupClass

    - - - - - - - - - -
    Description:Spécifie quelles valeurs d'objectClass LDAP identifient les -objets de l'annuaire qui sont des groupes au cours du traitement des -sous-groupes.
    Syntaxe:AuthLDAPSubGroupClass ObjectClass-LDAP
    Défaut:AuthLDAPSubGroupClass groupOfNames groupOfUniqueNames
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    Compatibilité:Disponible à partir de la version 2.3.0 du serveur HTTP -Apache
    -

    Un objet groupe LDAP peut contenir des membres qui sont des - utilisateurs et des membres qui sont eux-mêmes des groupes (appelés - sous-groupes ou groupes imbriqués). La directive - AuthLDAPSubGroupAttribute permet d'identifier les - membres qui sont des sous-groupes du groupe courant (à l'opposé des - membres utilisateurs). La directive - AuthLDAPSubGroupClass permet de spécifier les valeurs - d'objectClass LDAP utilisées pour vérifier que certains membres sont - en fait des objets groupe. Les sous-groupes ainsi identifiés peuvent - alors faire l'objet d'une recherche d'autres membres utilisateurs ou - sous-groupes. On peut spécifier plusieurs attributs en répétant - cette directive plusieurs fois. Si cette directive n'est pas - définie, mod_authnz_ldap utilise les attributs - groupOfNames et groupOfUniqueNames.

    +

    Un second paramètre optionnel peut être ajouté à la directive + AuthLDAPURL pour + remplacer le type de connexion par défaut défini par la directive + LDAPTrustedMode. Ceci + permettra de promouvoir la connexion établie via une URL du type + ldap:// au statut de connection sécurisée sur le même + port.

    +
    top
    +
    +

    Utilisation de SSL

    + +

    Pour l'utilisation de SSL, voir les directives du module + mod_ldap LDAPTrustedClientCert, LDAPTrustedGlobalCert et LDAPTrustedMode.

    -
    -
    top
    -

    Directive AuthLDAPUrl

    - - - - - - - -
    Description:L'URL permettant de spécifier les paramètres de la -recherche LDAP
    Syntaxe:AuthLDAPUrl url [NONE|SSL|TLS|STARTTLS]
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_authnz_ldap
    -

    Une URL conforme à la RFC 2255 qui permet de spécifier les - paramètres à utiliser pour la recherche dans l'annuaire LDAP. La - syntaxe de l'URL est :

    -

    ldap://hôte:port/DN-de-base?attribut?portée?filtre

    -

    Si vous souhaitez mettre à la disposition d'Apache plusieurs URLs - LDAP, la syntaxe sera :

    -
    AuthLDAPUrl "ldap://ldap1.example.com ldap2.example.com/dc=..."
    +

    Pour spécifier un serveur LDAP sécurisé, utilisez + ldaps:// au lieu de + ldap:// dans la directive AuthLDAPURL.

    +
    top
    +
    +

    Mise à disposition des informations de +connexion

    -

    Mise en garde : Si vous spécifiez plusieurs -serveurs, vous devez en entourer la liste avec des guillemets ; dans le -cas contraire, vous générerez une erreur : "AuthLDAPURL takes one -argument, URL to define LDAP connection..". Vous pouvez bien -entendu ajouter des paramètres de recherche à chacun des serveurs -spécifiés.

    +

    Au cours du processus d'authentification, les attributs LDAP + spécifiés par la directive authldapurl sont enregistrés + dans des variables d'environnement préfixées par la chaîne + "AUTHENTICATE_".

    -
    -
    ldap
    +

    Au cours du processus d'autorisation, les attributs LDAP + spécifiés par la directive authldapurl sont enregistrés + dans des variables d'environnement préfixées par la chaîne + "AUTHORIZE_".

    -
    Pour ldap non sécurisé, utilisez la chaîne - ldap. Pour ldap sécurisé, utilisez à la place la - chaîne ldaps. LDAP sécurisé n'est disponible que si - Apache a été lié avec une bibliothèque LDAP supportant SSL.
    +

    Si les champs attribut contiennent le nom, le CN et le numéro de + téléphone d'un utilisateur, un programme CGI pourra accéder à ces + informations sans devoir effectuer une autre requête LDAP pour + les extraire de l'annuaire.

    -
    hôte:port
    +

    Ceci a pour effet de simplifier considérablement le code et la + configuration nécessaire de certaines applications web.

    -
    -

    Il s'agit du nom/port du serveur ldap - (dont la valeur par défaut est - localhost:389 pour ldap, et - localhost:636 pour ldaps). Pour - spécifier plusieurs serveurs LDAP redondants, indiquez - simplement leur liste en les séparant par des espaces. - mod_authnz_ldap tentera alors de se connecter - à chacun des serveurs jusqu'à ce qu'il parvienne à se - connecter avec succès. Notez qu'en cas de multiples serveurs - LDAP, l'ensemble de l'URL LDAP doit être entourée de - guillemets.

    +
    top
    +
    +

    Utilisation d'Active +Directory

    -

    lorsqu'une connection a été établie avec un serveur, elle - reste active pendant toute la durée de vie du processus - httpd, ou jusqu'à ce que le serveur LDAP - cesse de fonctionner.

    +

    Active Directory peut supporter plusieurs domaines à la fois. + Pour faire la distinction entre les utilisateurs de plusieurs + domaines, on peut ajouter à l'entrée de l'utilisateur dans + l'annuaire un identifiant appelé Nom + Principal d'Utilisateur (User Principle Name ou UPN). Cet UPN se + compose en général du nom de compte de l'utilisateur, suivi du nom + du domaine considéré, par exemple untel@nz.example.com.

    -

    Si le serveur LDAP cesse de fonctionner, et ainsi - interrompt une - connexion existante, mod_authnz_ldap tentera - de se reconnecter en commençant par le premier serveur de la - liste, et ainsi de suite avec les serveurs redondants - suivants. Notez que ce processus n'a rien à voir avec une - véritable recherche de type round-robin.

    - +

    Vous voudrez probablement configurer le module + mod_authnz_ldap afin de pouvoir authentifier les + utilisateurs de n'importe quel domaine de la forêt Active Directory. + Ainsi, untel@nz.example.com et + untel@au.example.com pourront être authentifiés en une + seule fois par la même requête.

    -
    DN-de-base
    -
    Le DN de la branche de l'annuaire à partir de laquelle - toutes les recherches seront lancées. Il doit au moins - correspondre à la racine de votre annuaire, mais vous pouvez - aussi indiquer une branche plus spécifique.
    +

    Pour y parvenir, on utilise le concept de Catalogue Global + d'Active Directory. Ce Catalogue Global est une copie en lecture + seule des attributs sélectionnés de tous les serveurs de la forêt + Active Directory. Une requête vers le + Catalogue Global permet donc d'atteindre tous les domaines en une + seule fois, sans avoir à se connecter aux différents serveurs, via + des liaisons dont certaines peuvent être lentes.

    -
    attribut
    +

    Lorsqu'il est activé, la Catalogue Global est un serveur + d'annuaire indépendant accessible sur le port 3268 (3269 pour SSL). + Pour rechercher un utilisateur, effectuez une recherche sur + l'attribut userPrincipalName, avec une base de recherche + vide, comme suit :

    -
    Il s'agit de l'attribut à utiliser pour la recherche. - Bien que la RFC - 2255 autorise une liste d'attributs séparés par des virgules, - seul le premier sera retenu, sans tenir compte des autres - attributs fournis. Si aucun attribut n'est fourni, l'attribut - par défaut est uid. Il est judicieux de choisir un - attribut dont la valeur sera unique parmi toutes les entrées de - la branche de l'annuaire que vous aurez définie. Tous les - attributs spécifiés seront enregistrés dans des variables - d'environnement avec le préfixe AUTHENTICATE_, afin de pouvoir - être utilisés par d'autres modules.
    +
    AuthLDAPBindDN apache@example.com
+AuthLDAPBindPassword password
+AuthLDAPURL ldap://10.0.0.1:3268/?userPrincipalName?sub
    -
    portée
    -
    Il s'agit de la portée de la recherche. Elle peut prendre - les valeurs one ou sub. Notez que la - RFC 2255 supporte aussi une portée de valeur base, - mais cette dernière n'est pas supportée par le module. Si la - portée n'est pas définie, ou si elle est définie à - base, c'est la valeur de portée par défaut - sub qui sera utilisée.
    +

    Les utilisateurs devront s'authentifier en entrant leur UPN, de + la formeuntel@nz.example.com.

    -
    filtre
    +
    top
    +
    +

    Utilisation de Microsoft + FrontPage avec mod_authnz_ldap

    -
    Il s'agit d'un filtre de recherche LDAP valide. Si aucun - filtre n'est spécifié, le filtre par défaut - (objectClass=*) sera utilisé, ce qui corrspond à - une recherche de tous les types d'objets de l'arborescence. La - taille des filtres est limitée à environ 8000 caractères (valeur - de la macro MAX_STRING_LEN dans le code source - d'Apache), ce qui s'avère plus que suffisant pour la plupart des - applications. Depuis la version 2.4.10, il est possible - d'utiliser le paramètre "none" pour spécifier qu'aucun filtre - n'est activé ; ce paramètre est obligatoire avec certains - serveurs LDAP primitifs.
    - +

    Normalement, FrontPage utilise des fichiers utilisateur/groupe + spécifiques à FrontPage-web (c'est à dire les modules + mod_authn_file et + mod_authz_groupfile) pour effectuer toute + l'authentification. Malheureusement, il ne suffit pas de modifier + l'authentification LDAP en ajoutant les directives appropriées, car + ceci corromprait les formulaires de Permissions dans le + client FrontPage, qui sont censés modifier les fichiers + d'autorisation standards au format texte.

    -

    Pour une recherche, les attribut, filtre et nom d'utilisateur - fournis par le client HTTP sont combinés pour créer un filtre de - recherche du style : - (&(filtre)(attribut - =nom-utilisateur)).

    +

    Lorsqu'un site web FrontPage a été créé, lui adjoindre + l'authentification LDAP consiste à ajouter les directives suivantes + à chaque fichier .htaccess qui sera créé dans + le site web :

    +
    AuthLDAPURL       "the url"
+AuthGroupFile     mygroupfile
+Require group     mygroupfile
    -

    Par exemple, considérons l'URL - ldap://ldap.example.com/o=Example?cn?sub?(posixid=*). - Lorsqu'un client tentera de se connecter en utilisant le nom - d'utilisateur Babs Jenson, le filtre de recherche sera - : (&(posixid=*)(cn=Babs Jenson)).

    -

    On peut encore ajouter un paramètre optionnel pour permettre à - l'URL LDAP de surcharger le type de connexion. Ce paramètre peut - prendre l'une des valeurs suivantes :

    +

    Comment ça marche

    -
    -
    NONE
    -
    Établit une connexion non sécurisée sur le port LDAP par - défaut, ce qui est équivalent à ldap:// sur le port - 389.
    -
    SSL
    -
    Établit une connexion sécurisée sur le port LDAP sécurisé - par défaut, ce qui est équivalent à ldaps://.
    -
    TLS | STARTTLS
    -
    Établit une connexion sécurisée par élévation de niveau sur - le port LDAP par défaut. Cette connexion sera initialisée sur le - port 389 par défaut, puis élevée à un niveau de connexion - sécurisée sur le même port.
    -
    +

    FrontPage restreint l'accès à un site web en ajoutant la + directive Require valid-user aux fichiers + .htaccess. La directive Require valid-user + permettra l'accès à tout utilisateur valide du point de vue + LDAP. Cela signifie que tout utilisateur possédant une entrée + dans l'annuaire LDAP sera considéré comme valide, alors que + FrontPage ne considère comme valides que les utilisateurs + enregistrés dans le fichier des utilisateurs local. En remplaçant + l'autorisation par groupe LDAP par une autorisation par fichier de + groupe, Apache sera en mesure de consulter le fichier des + utilisateurs local (géré par FrontPage) - au lieu de l'annuaire LDAP + - lors du processus d'autorisation des utilisateurs.

    -

    Voir plus haut pour des exemples d'URLs définies par la directive - AuthLDAPURL.

    +

    Une fois les directives ajoutées selon ce qui précède, les + utilisateurs FrontPage pourront effectuer toutes les opérations de + gestion à partir du client FrontPage.

    + + +

    Avertissements

    + +
    diff --git a/docs/manual/mod/mod_authz_core.html.en b/docs/manual/mod/mod_authz_core.html.en index 69f6fcfe2f7..3f06a422083 100644 --- a/docs/manual/mod/mod_authz_core.html.en +++ b/docs/manual/mod/mod_authz_core.html.en @@ -61,210 +61,6 @@
  • The Require Directives
    • top
    -
    -

    Creating Authorization Provider Aliases

    - -

    Extended authorization providers can be created within the configuration - file and assigned an alias name. The alias providers can then be referenced - through the Require directive - in the same way as a base authorization provider. Besides the ability to - create and alias an extended provider, it also allows the same extended - authorization provider to be referenced by multiple locations. -

    - -

    Example

    -

    The example below creates two different ldap authorization provider - aliases based on the ldap-group authorization provider. This example - allows a single authorization location to check group membership within - multiple ldap hosts: -

    - - 
    <AuthzProviderAlias ldap-group ldap-group-alias1 cn=my-group,o=ctx>
-    AuthLDAPBindDN cn=youruser,o=ctx
-    AuthLDAPBindPassword yourpassword
-    AuthLDAPURL ldap://ldap.host/o=ctx
-</AuthzProviderAlias>
-
-<AuthzProviderAlias ldap-group ldap-group-alias2 cn=my-other-group,o=dev>
-    AuthLDAPBindDN cn=yourotheruser,o=dev
-    AuthLDAPBindPassword yourotherpassword
-    AuthLDAPURL ldap://other.ldap.host/o=dev?cn
-</AuthzProviderAlias>
-
-Alias "/secure" "/webpages/secure"
-<Directory "/webpages/secure">
-    Require all granted
-    
-    AuthBasicProvider file
-    
-    AuthType Basic
-    AuthName LDAP_Protected_Place
-    
-    #implied OR operation
-    Require ldap-group-alias1
-    Require ldap-group-alias2
-</Directory>
    - - - -
    top
    -
    -

    Authorization Containers

    - -

    The authorization container directives - <RequireAll>, - <RequireAny> - and - <RequireNone> - may be combined with each other and with the - Require - directive to express complex authorization logic.

    - -

    The example below expresses the following authorization logic. - In order to access the resource, the user must either be the - superadmin user, or belong to both the - admins group and the Administrators LDAP - group and either belong to the sales group or - have the LDAP dept attribute sales. - Furthermore, in order to access the resource, the user must - not belong to either the temps group or the - LDAP group Temporary Employees.

    - - 
    <Directory "/www/mydocs">
-    <RequireAll>
-        <RequireAny>
-            Require user superadmin
-            <RequireAll>
-                Require group admins
-                Require ldap-group cn=Administrators,o=Airius
-                <RequireAny>
-                    Require group sales
-                    Require ldap-attribute dept="sales"
-                </RequireAny>
-            </RequireAll>
-        </RequireAny>
-        <RequireNone>
-            Require group temps
-            Require ldap-group cn=Temporary Employees,o=Airius
-        </RequireNone>
-    </RequireAll>
-</Directory>
    - -
    top
    -
    -

    The Require Directives

    - -

    mod_authz_core provides some generic authorization - providers which can be used with the - Require directive.

    - -

    Require env

    - -

    The env provider allows access to the server - to be controlled based on the existence of an environment variable. When Require - env env-variable is specified, then the request is - allowed access if the environment variable env-variable - exists. The server provides the ability to set environment - variables in a flexible way based on characteristics of the client - request using the directives provided by - mod_setenvif. Therefore, this directive can be - used to allow access based on such factors as the clients - User-Agent (browser type), Referer, or - other HTTP request header fields.

    - - 
    SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in
-<Directory "/docroot">
-    Require env let_me_in
-</Directory>
    - - -

    In this case, browsers with a user-agent string beginning - with KnockKnock/2.0 will be allowed access, and all - others will be denied.

    - -

    When the server looks up a path via an internal - subrequest such as looking - for a DirectoryIndex - or generating a directory listing with mod_autoindex, - per-request environment variables are not inherited in the - subrequest. Additionally, - SetEnvIf directives - are not separately evaluated in the subrequest due to the API phases - mod_setenvif takes action in.

    - - - -

    Require all

    - -

    The all provider mimics the functionality that - was previously provided by the 'Allow from all' and 'Deny from all' - directives. This provider can take one of two arguments which are - 'granted' or 'denied'. The following examples will grant or deny - access to all requests.

    - - 
    Require all granted
    - - - 
    Require all denied
    - - - - -

    Require method

    - -

    The method provider allows using the HTTP method in - authorization decisions. The GET and HEAD methods are treated as - equivalent. The TRACE method is not available to this provider, - use TraceEnable instead.

    - -

    The following example will only allow GET, HEAD, POST, and OPTIONS - requests:

    - - 
    Require method GET POST OPTIONS
    - - -

    The following example will allow GET, HEAD, POST, and OPTIONS - requests without authentication, and require a valid user for all other - methods:

    - - 
    <RequireAny>
-     Require method GET POST OPTIONS
-     Require valid-user
-</RequireAny>
    - - - - -

    Require expr

    - -

    The expr provider allows basing authorization - decisions on arbitrary expressions.

    - - 
    Require expr "%{TIME_HOUR} -ge 9 && %{TIME_HOUR} -le 17"
    - - - 
    <RequireAll>
-    Require expr "!(%{QUERY_STRING} =~ /secret/)"
-    Require expr "%{REQUEST_URI} in { '/example.cgi', '/other.cgi' }" 
-</RequireAll>
    - - - 
    Require expr "!(%{QUERY_STRING} =~ /secret/) && %{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"
    - - -

    The syntax is described in the ap_expr - documentation.

    - -

    Normally, the expression is evaluated before authentication. However, if - the expression returns false and references the variable - %{REMOTE_USER}, authentication will be performed and - the expression will be re-evaluated.

    - - - - -
    -
    top

    AuthMerging Directive

  • Authentication, Authorization, and Access Control
    • + +
    top
    +
    +

    Creating Authorization Provider Aliases

    + +

    Extended authorization providers can be created within the configuration + file and assigned an alias name. The alias providers can then be referenced + through the Require directive + in the same way as a base authorization provider. Besides the ability to + create and alias an extended provider, it also allows the same extended + authorization provider to be referenced by multiple locations. +

    + +

    Example

    +

    The example below creates two different ldap authorization provider + aliases based on the ldap-group authorization provider. This example + allows a single authorization location to check group membership within + multiple ldap hosts: +

    + + 
    <AuthzProviderAlias ldap-group ldap-group-alias1 cn=my-group,o=ctx>
+    AuthLDAPBindDN cn=youruser,o=ctx
+    AuthLDAPBindPassword yourpassword
+    AuthLDAPURL ldap://ldap.host/o=ctx
+</AuthzProviderAlias>
+
+<AuthzProviderAlias ldap-group ldap-group-alias2 cn=my-other-group,o=dev>
+    AuthLDAPBindDN cn=yourotheruser,o=dev
+    AuthLDAPBindPassword yourotherpassword
+    AuthLDAPURL ldap://other.ldap.host/o=dev?cn
+</AuthzProviderAlias>
+
+Alias "/secure" "/webpages/secure"
+<Directory "/webpages/secure">
+    Require all granted
+    
+    AuthBasicProvider file
+    
+    AuthType Basic
+    AuthName LDAP_Protected_Place
+    
+    #implied OR operation
+    Require ldap-group-alias1
+    Require ldap-group-alias2
+</Directory>
    + + + +
    top
    +
    +

    Authorization Containers

    + +

    The authorization container directives + <RequireAll>, + <RequireAny> + and + <RequireNone> + may be combined with each other and with the + Require + directive to express complex authorization logic.

    + +

    The example below expresses the following authorization logic. + In order to access the resource, the user must either be the + superadmin user, or belong to both the + admins group and the Administrators LDAP + group and either belong to the sales group or + have the LDAP dept attribute sales. + Furthermore, in order to access the resource, the user must + not belong to either the temps group or the + LDAP group Temporary Employees.

    + + 
    <Directory "/www/mydocs">
+    <RequireAll>
+        <RequireAny>
+            Require user superadmin
+            <RequireAll>
+                Require group admins
+                Require ldap-group cn=Administrators,o=Airius
+                <RequireAny>
+                    Require group sales
+                    Require ldap-attribute dept="sales"
+                </RequireAny>
+            </RequireAll>
+        </RequireAny>
+        <RequireNone>
+            Require group temps
+            Require ldap-group cn=Temporary Employees,o=Airius
+        </RequireNone>
+    </RequireAll>
+</Directory>
    + +
    top
    +
    +

    The Require Directives

    + +

    mod_authz_core provides some generic authorization + providers which can be used with the + Require directive.

    + +

    Require env

    + +

    The env provider allows access to the server + to be controlled based on the existence of an environment variable. When Require + env env-variable is specified, then the request is + allowed access if the environment variable env-variable + exists. The server provides the ability to set environment + variables in a flexible way based on characteristics of the client + request using the directives provided by + mod_setenvif. Therefore, this directive can be + used to allow access based on such factors as the clients + User-Agent (browser type), Referer, or + other HTTP request header fields.

    + + 
    SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in
+<Directory "/docroot">
+    Require env let_me_in
+</Directory>
    + + +

    In this case, browsers with a user-agent string beginning + with KnockKnock/2.0 will be allowed access, and all + others will be denied.

    + +

    When the server looks up a path via an internal + subrequest such as looking + for a DirectoryIndex + or generating a directory listing with mod_autoindex, + per-request environment variables are not inherited in the + subrequest. Additionally, + SetEnvIf directives + are not separately evaluated in the subrequest due to the API phases + mod_setenvif takes action in.

    + + + +

    Require all

    + +

    The all provider mimics the functionality that + was previously provided by the 'Allow from all' and 'Deny from all' + directives. This provider can take one of two arguments which are + 'granted' or 'denied'. The following examples will grant or deny + access to all requests.

    + + 
    Require all granted
    + + + 
    Require all denied
    + + + + +

    Require method

    + +

    The method provider allows using the HTTP method in + authorization decisions. The GET and HEAD methods are treated as + equivalent. The TRACE method is not available to this provider, + use TraceEnable instead.

    + +

    The following example will only allow GET, HEAD, POST, and OPTIONS + requests:

    + + 
    Require method GET POST OPTIONS
    + + +

    The following example will allow GET, HEAD, POST, and OPTIONS + requests without authentication, and require a valid user for all other + methods:

    + + 
    <RequireAny>
+     Require method GET POST OPTIONS
+     Require valid-user
+</RequireAny>
    + + + + +

    Require expr

    + +

    The expr provider allows basing authorization + decisions on arbitrary expressions.

    + + 
    Require expr "%{TIME_HOUR} -ge 9 && %{TIME_HOUR} -le 17"
    + + + 
    <RequireAll>
+    Require expr "!(%{QUERY_STRING} =~ /secret/)"
+    Require expr "%{REQUEST_URI} in { '/example.cgi', '/other.cgi' }" 
+</RequireAll>
    + + + 
    Require expr "!(%{QUERY_STRING} =~ /secret/) && %{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"
    + + +

    The syntax is described in the ap_expr + documentation.

    + +

    Normally, the expression is evaluated before authentication. However, if + the expression returns false and references the variable + %{REMOTE_USER}, authentication will be performed and + the expression will be re-evaluated.

    + + + +
    diff --git a/docs/manual/mod/mod_authz_core.html.fr b/docs/manual/mod/mod_authz_core.html.fr index a7fb4aa85be..0b040c26b9b 100644 --- a/docs/manual/mod/mod_authz_core.html.fr +++ b/docs/manual/mod/mod_authz_core.html.fr @@ -65,208 +65,6 @@ d'autorisation
  • Les directives Require
    • top
    -
    -

    Création des alias du fournisseur -d'autorisation

    - -

    Il est possible de créer des fournisseurs d'autorisation étendus - dans le fichier de configuration et de leur assigner un nom d'alias. - On peut ensuite utiliser ces fournisseurs aliasés dans une - directive Require de - la même manière qu'on le ferait pour des fournisseurs d'autorisation - de base. En plus de la possibilité de créer et d'aliaser un - fournisseur étendu, le même fournisseur d'autorisation étendu peut - être référencé par plusieurs localisations. -

    - -

    Exemple

    -

    Dans l'exemple suivant, on crée deux alias de fournisseur - d'autorisation ldap différents basés sur le fournisseur - d'autorisation ldap-group. Il est ainsi possible pour un seul - répertoire de vérifier l'appartenance à un groupe dans plusieurs - serveurs ldap : -

    - - 
    <AuthzProviderAlias ldap-group ldap-group-alias1 cn=my-group,o=ctx>
-    AuthLDAPBindDN cn=youruser,o=ctx
-    AuthLDAPBindPassword yourpassword
-    AuthLDAPURL ldap://ldap.host/o=ctx
-</AuthzProviderAlias>
-
-<AuthzProviderAlias ldap-group ldap-group-alias2 cn=my-other-group,o=dev>
-    AuthLDAPBindDN cn=yourotheruser,o=dev
-    AuthLDAPBindPassword yourotherpassword
-    AuthLDAPURL ldap://other.ldap.host/o=dev?cn
-</AuthzProviderAlias>
-
-Alias /secure /webpages/secure
-<Directory /webpages/secure>
-    Require all granted
-    
-    AuthBasicProvider file
-    
-    AuthType Basic
-    AuthName LDAP_Protected_Place
-    
-    #implied OR operation
-    Require ldap-group-alias1
-    Require ldap-group-alias2
-</Directory>
    - - - -
    top
    -
    -

    Conteneurs d'autorisation

    - -

    Les directives de conteneur d'autorisation <RequireAll>, - <RequireAny> et <RequireNone> - peuvent être combinées entre elles et avec la directive Require pour confectionner une - logique d'autorisation complexe.

    - -

    L'exemple ci-dessous illustre la logique d'autorisation suivante. - Pour pouvoir accéder à la ressource, l'utilisateur doit être - l'utilisateur superadmin, ou appartenir aux deux - groupes LDAP admins et Administrateurs et - soit appartenir au groupe ventes ou avoir - ventes comme valeur de l'attribut LDAP - dept. De plus, pour pouvoir accéder à la ressource, - l'utilisateur ne doit appartenir ni au groupe temps, ni - au groupe LDAP Employés temporaires.

    - - 
    <Directory /www/mydocs>
-    <RequireAll>
-        <RequireAny>
-            Require user superadmin
-            <RequireAll>
-            Require group admins
-            Require ldap-group cn=Administrators,o=Airius
-                <RequireAny>
-                Require group sales
-                Require ldap-attribute dept="sales"
-                </RequireAny>
-            </RequireAll>
-        </RequireAny>
-        <RequireNone>
-            Require group temps
-            Require ldap-group cn=Temporary Employees,o=Airius
-        </RequireNone>
-    </RequireAll>
-</Directory>
    - -
    top
    -
    -

    Les directives Require

    - -

    Le module mod_authz_core met à disposition des - fournisseurs d'autorisation génériques utilisables avec la directive - Require.

    - -

    Require env

    - -

    Le fournisseur env permet de contrôler l'accès au - serveur en fonction de l'existence d'une variable d'environnement. Lorsque Require - env env-variable est spécifié, la requête se voit - autoriser l'accès si la variable d'environnement - env-variable existe. Le serveur permet de définir - facilement des variables d'environnement en fonction des - caractéristiques de la requête du client via les directives fournies - par le module mod_setenvif. Cette directive Require - env permet donc de contrôler l'accès en fonction des - valeurs des en-têtes de la requête HTTP tels que - User-Agent (type de navigateur), Referer, - entre autres.

    - - 
    SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in
-<Directory /docroot>
-    Require env let_me_in
-</Directory>
    - - -

    Avec cet exemple, les navigateurs dont la chaîne user-agent - commence par KnockKnock/2.0 se verront autoriser - l'accès, alors que tous les autres seront rejetés.

    - -

    Lorsque le serveur cherche un chemin via une sous-requête interne (par exemple la - recherche d'un DirectoryIndex), ou lorsqu'il génère un - listing du contenu d'un répertoire via le module - mod_autoindex, la sous-requête n'hérite pas des - variables d'environnement spécifiques à la requête. En outre, à cause - des phases de l'API auxquelles mod_setenvif prend - part, les directives SetEnvIf ne sont pas évaluées - séparément dans la sous-requête.

    - - - -

    Require all

    - -

    Le fournisseur all reproduit la fonctionnalité - précédemment fournie par les directives 'Allow from all' et 'Deny - from all'. Il accepte un argument dont les deux valeurs possibles - sont : 'granted' ou 'denied'. Les exemples suivants autorisent ou - interdisent l'accès à toutes les requêtes.

    - - 
    Require all granted
    - - - 
    Require all denied
    - - - - -

    Require method

    - -

    Le fournisseur method permet d'utiliser la méthode - HTTP dans le processus d'autorisation. Les méthodes GET et HEAD sont - ici considérées comme équivalentes. La méthode TRACE n'est pas - supportée par ce fournisseur ; utilisez à la place la directive - TraceEnable.

    - -

    Dans l'exemple suivant, seules les méthodes GET, HEAD, POST, et - OPTIONS sont autorisées :

    - - 
    Require method GET POST OPTIONS
    - - -

    Dans l'exemple suivant, les méthodes GET, HEAD, POST, et OPTIONS - sont autorisées sans authentification, alors que toutes les autres - méthodes nécessitent un utilisateur valide :

    - - 
    <RequireAny>
-     Require method GET POST OPTIONS
-     Require valid-user
-</RequireAny>
    - - - -

    Require expr

    - -

    Le fournisseur expr permet d'accorder l'autorisation - d'accès de base en fonction d'expressions arbitraires.

    - - 
    Require expr "%{TIME_HOUR} -ge 9 && %{TIME_HOUR} -le 17"
    - - - 
    <RequireAll>
-    Require expr "!(%{QUERY_STRING} =~ /secret/)"
-    Require expr "%{REQUEST_URI} in { '/example.cgi', '/other.cgi' }" 
-</RequireAll>
    - - - 
    Require expr "!(%{QUERY_STRING} =~ /secret/) && %{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"
    - - -

    La syntaxe de l'expression est décrite dans la documentation de ap_expr.

    - -

    Normalement, l'expression est évaluée avant l'authentification. - Cependant, si l'expression renvoie false et se réfère à la variable - %{REMOTE_USER}, le processus d'authentification sera - engagé et l'expression réévaluée.

    - - - -
    -
    top

    Directive AuthMerging

    Description:Controls the manner in which each configuration section's @@ -631,6 +427,210 @@ must succeed for the enclosing directive to not fail.
  • Authentification, autorisation et contrôle d'accès
    • + +
    top
    +
    +

    Création des alias du fournisseur +d'autorisation

    + +

    Il est possible de créer des fournisseurs d'autorisation étendus + dans le fichier de configuration et de leur assigner un nom d'alias. + On peut ensuite utiliser ces fournisseurs aliasés dans une + directive Require de + la même manière qu'on le ferait pour des fournisseurs d'autorisation + de base. En plus de la possibilité de créer et d'aliaser un + fournisseur étendu, le même fournisseur d'autorisation étendu peut + être référencé par plusieurs localisations. +

    + +

    Exemple

    +

    Dans l'exemple suivant, on crée deux alias de fournisseur + d'autorisation ldap différents basés sur le fournisseur + d'autorisation ldap-group. Il est ainsi possible pour un seul + répertoire de vérifier l'appartenance à un groupe dans plusieurs + serveurs ldap : +

    + + 
    <AuthzProviderAlias ldap-group ldap-group-alias1 cn=my-group,o=ctx>
+    AuthLDAPBindDN cn=youruser,o=ctx
+    AuthLDAPBindPassword yourpassword
+    AuthLDAPURL ldap://ldap.host/o=ctx
+</AuthzProviderAlias>
+
+<AuthzProviderAlias ldap-group ldap-group-alias2 cn=my-other-group,o=dev>
+    AuthLDAPBindDN cn=yourotheruser,o=dev
+    AuthLDAPBindPassword yourotherpassword
+    AuthLDAPURL ldap://other.ldap.host/o=dev?cn
+</AuthzProviderAlias>
+
+Alias /secure /webpages/secure
+<Directory /webpages/secure>
+    Require all granted
+    
+    AuthBasicProvider file
+    
+    AuthType Basic
+    AuthName LDAP_Protected_Place
+    
+    #implied OR operation
+    Require ldap-group-alias1
+    Require ldap-group-alias2
+</Directory>
    + + + +
    top
    +
    +

    Conteneurs d'autorisation

    + +

    Les directives de conteneur d'autorisation <RequireAll>, + <RequireAny> et <RequireNone> + peuvent être combinées entre elles et avec la directive Require pour confectionner une + logique d'autorisation complexe.

    + +

    L'exemple ci-dessous illustre la logique d'autorisation suivante. + Pour pouvoir accéder à la ressource, l'utilisateur doit être + l'utilisateur superadmin, ou appartenir aux deux + groupes LDAP admins et Administrateurs et + soit appartenir au groupe ventes ou avoir + ventes comme valeur de l'attribut LDAP + dept. De plus, pour pouvoir accéder à la ressource, + l'utilisateur ne doit appartenir ni au groupe temps, ni + au groupe LDAP Employés temporaires.

    + + 
    <Directory /www/mydocs>
+    <RequireAll>
+        <RequireAny>
+            Require user superadmin
+            <RequireAll>
+            Require group admins
+            Require ldap-group cn=Administrators,o=Airius
+                <RequireAny>
+                Require group sales
+                Require ldap-attribute dept="sales"
+                </RequireAny>
+            </RequireAll>
+        </RequireAny>
+        <RequireNone>
+            Require group temps
+            Require ldap-group cn=Temporary Employees,o=Airius
+        </RequireNone>
+    </RequireAll>
+</Directory>
    + +
    top
    +
    +

    Les directives Require

    + +

    Le module mod_authz_core met à disposition des + fournisseurs d'autorisation génériques utilisables avec la directive + Require.

    + +

    Require env

    + +

    Le fournisseur env permet de contrôler l'accès au + serveur en fonction de l'existence d'une variable d'environnement. Lorsque Require + env env-variable est spécifié, la requête se voit + autoriser l'accès si la variable d'environnement + env-variable existe. Le serveur permet de définir + facilement des variables d'environnement en fonction des + caractéristiques de la requête du client via les directives fournies + par le module mod_setenvif. Cette directive Require + env permet donc de contrôler l'accès en fonction des + valeurs des en-têtes de la requête HTTP tels que + User-Agent (type de navigateur), Referer, + entre autres.

    + + 
    SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in
+<Directory /docroot>
+    Require env let_me_in
+</Directory>
    + + +

    Avec cet exemple, les navigateurs dont la chaîne user-agent + commence par KnockKnock/2.0 se verront autoriser + l'accès, alors que tous les autres seront rejetés.

    + +

    Lorsque le serveur cherche un chemin via une sous-requête interne (par exemple la + recherche d'un DirectoryIndex), ou lorsqu'il génère un + listing du contenu d'un répertoire via le module + mod_autoindex, la sous-requête n'hérite pas des + variables d'environnement spécifiques à la requête. En outre, à cause + des phases de l'API auxquelles mod_setenvif prend + part, les directives SetEnvIf ne sont pas évaluées + séparément dans la sous-requête.

    + + + +

    Require all

    + +

    Le fournisseur all reproduit la fonctionnalité + précédemment fournie par les directives 'Allow from all' et 'Deny + from all'. Il accepte un argument dont les deux valeurs possibles + sont : 'granted' ou 'denied'. Les exemples suivants autorisent ou + interdisent l'accès à toutes les requêtes.

    + + 
    Require all granted
    + + + 
    Require all denied
    + + + + +

    Require method

    + +

    Le fournisseur method permet d'utiliser la méthode + HTTP dans le processus d'autorisation. Les méthodes GET et HEAD sont + ici considérées comme équivalentes. La méthode TRACE n'est pas + supportée par ce fournisseur ; utilisez à la place la directive + TraceEnable.

    + +

    Dans l'exemple suivant, seules les méthodes GET, HEAD, POST, et + OPTIONS sont autorisées :

    + + 
    Require method GET POST OPTIONS
    + + +

    Dans l'exemple suivant, les méthodes GET, HEAD, POST, et OPTIONS + sont autorisées sans authentification, alors que toutes les autres + méthodes nécessitent un utilisateur valide :

    + + 
    <RequireAny>
+     Require method GET POST OPTIONS
+     Require valid-user
+</RequireAny>
    + + + +

    Require expr

    + +

    Le fournisseur expr permet d'accorder l'autorisation + d'accès de base en fonction d'expressions arbitraires.

    + + 
    Require expr "%{TIME_HOUR} -ge 9 && %{TIME_HOUR} -le 17"
    + + + 
    <RequireAll>
+    Require expr "!(%{QUERY_STRING} =~ /secret/)"
+    Require expr "%{REQUEST_URI} in { '/example.cgi', '/other.cgi' }" 
+</RequireAll>
    + + + 
    Require expr "!(%{QUERY_STRING} =~ /secret/) && %{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"
    + + +

    La syntaxe de l'expression est décrite dans la documentation de ap_expr.

    + +

    Normalement, l'expression est évaluée avant l'authentification. + Cependant, si l'expression renvoie false et se réfère à la variable + %{REMOTE_USER}, le processus d'authentification sera + engagé et l'expression réévaluée.

    + + +
    diff --git a/docs/manual/mod/mod_authz_dbd.html.en b/docs/manual/mod/mod_authz_dbd.html.en index 2710cb6ed6b..a3f016e33f4 100644 --- a/docs/manual/mod/mod_authz_dbd.html.en +++ b/docs/manual/mod/mod_authz_dbd.html.en @@ -70,6 +70,90 @@
  • DBDParams
    • top
    +

    AuthzDBDLoginToReferer Directive

    +
    Description:Définit la manière dont chaque logique d'autorisation des @@ -640,6 +438,208 @@ pas.
    + + + + + + +
    Description:Determines whether to redirect the Client to the Referring +page on successful login or logout if a Referer request +header is present
    Syntax:AuthzDBDLoginToReferer On|Off
    Default:AuthzDBDLoginToReferer Off
    Context:directory
    Status:Extension
    Module:mod_authz_dbd
    +

    In conjunction with Require dbd-login or + Require dbd-logout, this provides the option to + redirect the client back to the Referring page (the URL in + the Referer HTTP request header, if present). + When there is no Referer header, + AuthzDBDLoginToReferer On will be ignored.

    + +
    +
    top
    +

    AuthzDBDQuery Directive

    + + + + + + +
    Description:Specify the SQL Query for the required operation
    Syntax:AuthzDBDQuery query
    Context:directory
    Status:Extension
    Module:mod_authz_dbd
    +

    The AuthzDBDQuery specifies an SQL + query to run. The purpose of the query depends on the + Require directive in + effect.

    + +

    In all cases, the user's ID will be passed as a single string + parameter when the SQL query is executed. It may be referenced within + the query statement using a %s format specifier.

    + +
    +
    top
    +

    AuthzDBDRedirectQuery Directive

    + + + + + + +
    Description:Specify a query to look up a login page for the user
    Syntax:AuthzDBDRedirectQuery query
    Context:directory
    Status:Extension
    Module:mod_authz_dbd
    +

    Specifies an optional SQL query to use after successful login + (or logout) to redirect the user to a URL, which may be + specific to the user. The user's ID will be passed as a single string + parameter when the SQL query is executed. It may be referenced within + the query statement using a %s format specifier.

    + 
    AuthzDBDRedirectQuery "SELECT userpage FROM userpages WHERE user = %s"
    + +

    The first column value of the first row returned by the query + statement should be a string containing a URL to which to redirect + the client. Subsequent rows will be ignored. If no rows are returned, + the client will not be redirected.

    +

    Note that AuthzDBDLoginToReferer takes + precedence if both are set.

    + +
    +
    top

    The Require Directives

    @@ -197,90 +281,6 @@ DBDExptime 300 </Files> </Directory> -
    -
    top
    -

    AuthzDBDLoginToReferer Directive

    - - - - - - - -
    Description:Determines whether to redirect the Client to the Referring -page on successful login or logout if a Referer request -header is present
    Syntax:AuthzDBDLoginToReferer On|Off
    Default:AuthzDBDLoginToReferer Off
    Context:directory
    Status:Extension
    Module:mod_authz_dbd
    -

    In conjunction with Require dbd-login or - Require dbd-logout, this provides the option to - redirect the client back to the Referring page (the URL in - the Referer HTTP request header, if present). - When there is no Referer header, - AuthzDBDLoginToReferer On will be ignored.

    - -
    -
    top
    -

    AuthzDBDQuery Directive

    - - - - - - -
    Description:Specify the SQL Query for the required operation
    Syntax:AuthzDBDQuery query
    Context:directory
    Status:Extension
    Module:mod_authz_dbd
    -

    The AuthzDBDQuery specifies an SQL - query to run. The purpose of the query depends on the - Require directive in - effect.

    - -

    In all cases, the user's ID will be passed as a single string - parameter when the SQL query is executed. It may be referenced within - the query statement using a %s format specifier.

    - -
    -
    top
    -

    AuthzDBDRedirectQuery Directive

    - - - - - - -
    Description:Specify a query to look up a login page for the user
    Syntax:AuthzDBDRedirectQuery query
    Context:directory
    Status:Extension
    Module:mod_authz_dbd
    -

    Specifies an optional SQL query to use after successful login - (or logout) to redirect the user to a URL, which may be - specific to the user. The user's ID will be passed as a single string - parameter when the SQL query is executed. It may be referenced within - the query statement using a %s format specifier.

    - 
    AuthzDBDRedirectQuery "SELECT userpage FROM userpages WHERE user = %s"
    - -

    The first column value of the first row returned by the query - statement should be a string containing a URL to which to redirect - the client. Subsequent rows will be ignored. If no rows are returned, - the client will not be redirected.

    -

    Note that AuthzDBDLoginToReferer takes - precedence if both are set.

    -
    diff --git a/docs/manual/mod/mod_authz_dbd.html.fr b/docs/manual/mod/mod_authz_dbd.html.fr index dcea399ff43..85d75f7a98d 100644 --- a/docs/manual/mod/mod_authz_dbd.html.fr +++ b/docs/manual/mod/mod_authz_dbd.html.fr @@ -75,6 +75,99 @@ d'Apache
  • DBDParams
    • top
    +

    Directive AuthzDBDLoginToReferer

    + + + + + + + +
    Description:Définit si le client doit être redirigé vers la page +d'origine en cas de connexion ou de déconnexion réussie si un en-tête +de requête Referer est présent
    Syntaxe:AuthzDBDLoginToReferer On|Off
    Défaut:AuthzDBDLoginToReferer Off
    Contexte:répertoire
    Statut:Extension
    Module:mod_authz_dbd
    +

    Utilisée en conjonction avec Require dbd-login ou + Require dbd-logout, cette directive permet de rediriger + le client vers la page d'origine (l'URL contenue dans l'en-tête + de requête HTTP Referer, s'il est présent). En + l'absence d'en-tête Referer, la définition + AuthzDBDLoginToReferer On sera ignorée.

    + +
    +
    top
    +

    Directive AuthzDBDQuery

    + + + + + + +
    Description:Définit la requête SQL pour l'opération +requise
    Syntaxe:AuthzDBDQuery requête
    Contexte:répertoire
    Statut:Extension
    Module:mod_authz_dbd
    +

    La directive AuthzDBDQuery permet de + spécifier une requête SQL à exécuter. Le but de cette requête dépend + de la directive Require en cours de + traitement.

    + +

    Dans tous les cas, l'identifiant utilisateur sera transmis comme + paramètre sous la forme d'une simple chaîne lorsque la requête SQL + sera exécutée. Il y sera fait référence dans la requête en utilisant + le spécificateur de format %s.

    + +
    +
    top
    +

    Directive AuthzDBDRedirectQuery

    + + + + + + +
    Description:Définit une requête pour rechercher une page vers laquelle +rediriger l'utilisateur après une connexion réussie
    Syntaxe:AuthzDBDRedirectQuery requête
    Contexte:répertoire
    Statut:Extension
    Module:mod_authz_dbd
    +

    Spécifie une requête SQL optionnelle à utiliser après une + connexion (ou une déconnexion) réussie pour rediriger l'utilisateur + vers une URL, qui peut être spécifique à l'utilisateur. + L'identifiant utilisateur sera transmis comme paramètre sous la + forme d'une simple chaîne lorsque la requête SQL sera exécutée. Il y + sera fait référence dans la requête en utilisant le spécificateur de + format %s.

    + 
    AuthzDBDRedirectQuery "SELECT userpage FROM userpages WHERE user = %s"
    + +

    La première colonne du premier enregistrement renvoyé par la + requête doit contenir une chaîne de caractères correspondant à une + URL vers laquelle rediriger le client. Les enregistrements suivants + sont ignorés. Si aucun enregistrement n'est renvoyé, le client ne + sera pas redirigé.

    +

    Notez que AuthzDBDLoginToReferer l'emporte + sur cette directive si les deux sont définies.

    + +
    +
    top

    Les directives Require

    @@ -210,99 +303,6 @@ DBDExptime 300 </Files> </Directory> -
    -
    top
    -

    Directive AuthzDBDLoginToReferer

    - - - - - - - -
    Description:Définit si le client doit être redirigé vers la page -d'origine en cas de connexion ou de déconnexion réussie si un en-tête -de requête Referer est présent
    Syntaxe:AuthzDBDLoginToReferer On|Off
    Défaut:AuthzDBDLoginToReferer Off
    Contexte:répertoire
    Statut:Extension
    Module:mod_authz_dbd
    -

    Utilisée en conjonction avec Require dbd-login ou - Require dbd-logout, cette directive permet de rediriger - le client vers la page d'origine (l'URL contenue dans l'en-tête - de requête HTTP Referer, s'il est présent). En - l'absence d'en-tête Referer, la définition - AuthzDBDLoginToReferer On sera ignorée.

    - -
    -
    top
    -

    Directive AuthzDBDQuery

    - - - - - - -
    Description:Définit la requête SQL pour l'opération -requise
    Syntaxe:AuthzDBDQuery requête
    Contexte:répertoire
    Statut:Extension
    Module:mod_authz_dbd
    -

    La directive AuthzDBDQuery permet de - spécifier une requête SQL à exécuter. Le but de cette requête dépend - de la directive Require en cours de - traitement.

    - -

    Dans tous les cas, l'identifiant utilisateur sera transmis comme - paramètre sous la forme d'une simple chaîne lorsque la requête SQL - sera exécutée. Il y sera fait référence dans la requête en utilisant - le spécificateur de format %s.

    - -
    -
    top
    -

    Directive AuthzDBDRedirectQuery

    - - - - - - -
    Description:Définit une requête pour rechercher une page vers laquelle -rediriger l'utilisateur après une connexion réussie
    Syntaxe:AuthzDBDRedirectQuery requête
    Contexte:répertoire
    Statut:Extension
    Module:mod_authz_dbd
    -

    Spécifie une requête SQL optionnelle à utiliser après une - connexion (ou une déconnexion) réussie pour rediriger l'utilisateur - vers une URL, qui peut être spécifique à l'utilisateur. - L'identifiant utilisateur sera transmis comme paramètre sous la - forme d'une simple chaîne lorsque la requête SQL sera exécutée. Il y - sera fait référence dans la requête en utilisant le spécificateur de - format %s.

    - 
    AuthzDBDRedirectQuery "SELECT userpage FROM userpages WHERE user = %s"
    - -

    La première colonne du premier enregistrement renvoyé par la - requête doit contenir une chaîne de caractères correspondant à une - URL vers laquelle rediriger le client. Les enregistrements suivants - sont ignorés. Si aucun enregistrement n'est renvoyé, le client ne - sera pas redirigé.

    -

    Notez que AuthzDBDLoginToReferer l'emporte - sur cette directive si les deux sont définies.

    -
    diff --git a/docs/manual/mod/mod_authz_dbm.html.en b/docs/manual/mod/mod_authz_dbm.html.en index 0b56e30d82e..481d330afe7 100644 --- a/docs/manual/mod/mod_authz_dbm.html.en +++ b/docs/manual/mod/mod_authz_dbm.html.en @@ -54,55 +54,6 @@
  • Require
    • top
    -
    -

    The Require Directives

    - -

    Apache's Require - directives are used during the authorization phase to ensure that - a user is allowed to access a resource. mod_authz_dbm extends the - authorization types with dbm-group.

    - -

    Since v2.4.8, expressions are supported - within the DBM require directives.

    - -

    Require dbm-group

    - -

    This directive specifies group membership that is required for the - user to gain access.

    - - 
    Require dbm-group admin
    - - - - -

    Require dbm-file-group

    - -

    When this directive is specified, the user must be a member of the group - assigned to the file being accessed.

    - - 
    Require dbm-file-group
    - - - - -
    top
    -
    -

    Example usage

    - -

    Note that using mod_authz_dbm requires you to require dbm-group -instead of group: -

    -
    <Directory "/foo/bar">
-  AuthType Basic
-  AuthName "Secure Area"
-  AuthBasicProvider dbm
-  AuthDBMUserFile "site/data/users"
-  AuthDBMGroupFile "site/data/users"
-  Require dbm-group admin
-</Directory>
    - -
    -
    top

    AuthDBMGroupFile Directive

    It is crucial that whatever program you use to create your group files is configured to use the same type of database.

    + +
    top
    +
    +

    The Require Directives

    + +

    Apache's Require + directives are used during the authorization phase to ensure that + a user is allowed to access a resource. mod_authz_dbm extends the + authorization types with dbm-group.

    + +

    Since v2.4.8, expressions are supported + within the DBM require directives.

    + +

    Require dbm-group

    + +

    This directive specifies group membership that is required for the + user to gain access.

    + + 
    Require dbm-group admin
    + + + + +

    Require dbm-file-group

    + +

    When this directive is specified, the user must be a member of the group + assigned to the file being accessed.

    + + 
    Require dbm-file-group
    + + + + +
    top
    +
    +

    Example usage

    + +

    Note that using mod_authz_dbm requires you to require dbm-group +instead of group: +

    +
    <Directory "/foo/bar">
+  AuthType Basic
+  AuthName "Secure Area"
+  AuthBasicProvider dbm
+  AuthDBMUserFile "site/data/users"
+  AuthDBMGroupFile "site/data/users"
+  Require dbm-group admin
+</Directory>
    +
    diff --git a/docs/manual/mod/mod_authz_dbm.html.fr b/docs/manual/mod/mod_authz_dbm.html.fr index e8972f711f6..05746eb0788 100644 --- a/docs/manual/mod/mod_authz_dbm.html.fr +++ b/docs/manual/mod/mod_authz_dbm.html.fr @@ -59,56 +59,6 @@ d'Apache
    Description:Sets the name of the database file containing the list @@ -180,6 +131,55 @@ store list of user groups
  • Require
    • top
    -
    -

    The Require Directives

    - -

    Les directives Require d'Apache permettent, - au cours de la phase d'autorisation, de s'assurer qu'un utilisateur - est bien autorisé à accéder à une ressource. mod_authz_dbm ajoute - les types d'autorisation dbm-group et dbm-file-group.

    - -

    A partir de la version 2.4.8, les directives require DBM - supportent les expressions.

    - -

    Require dbm-group

    - -

    Cette directive permet de spécifier à quel groupe un utilisateur - doit appartenir pour obtenir l'autorisation d'accès.

    - - 
    Require dbm-group admin
    - - - - -

    Require dbm-file-group

    - -

    Lorsque cette directive est définie, l'utilisateur doit - appartenir au groupe du fichier pour pouvoir y accéder.

    - - 
    Require dbm-file-group
    - - - - -
    top
    -
    -

    Exemple d'utilisation

    - -

    Notez que si vous utilisez mod_authz_dbm, le mot-clé pour les -groupes d'authentification qui était auparavant group est -maintenant dbm-group : -

    -
    <Directory "/foo/bar">
-  AuthType Basic 
-  AuthName "Secure Area"
-  AuthBasicProvider dbm 
-  AuthDBMUserFile site/data/users 
-  AuthDBMGroupFile site/data/users 
-  Require dbm-group admin 
-</Directory>
    - -
    -
    top

    Directive AuthDBMGroupFile

    fichier de groupes, il est impératif que celui-ci soit configuré pour utiliser le même type de base de données.

    + +
    top
    +
    +

    The Require Directives

    + +

    Les directives Require d'Apache permettent, + au cours de la phase d'autorisation, de s'assurer qu'un utilisateur + est bien autorisé à accéder à une ressource. mod_authz_dbm ajoute + les types d'autorisation dbm-group et dbm-file-group.

    + +

    A partir de la version 2.4.8, les directives require DBM + supportent les expressions.

    + +

    Require dbm-group

    + +

    Cette directive permet de spécifier à quel groupe un utilisateur + doit appartenir pour obtenir l'autorisation d'accès.

    + + 
    Require dbm-group admin
    + + + + +

    Require dbm-file-group

    + +

    Lorsque cette directive est définie, l'utilisateur doit + appartenir au groupe du fichier pour pouvoir y accéder.

    + + 
    Require dbm-file-group
    + + + + +
    top
    +
    +

    Exemple d'utilisation

    + +

    Notez que si vous utilisez mod_authz_dbm, le mot-clé pour les +groupes d'authentification qui était auparavant group est +maintenant dbm-group : +

    +
    <Directory "/foo/bar">
+  AuthType Basic 
+  AuthName "Secure Area"
+  AuthBasicProvider dbm 
+  AuthDBMUserFile site/data/users 
+  AuthDBMGroupFile site/data/users 
+  Require dbm-group admin 
+</Directory>
    +
    diff --git a/docs/manual/mod/mod_authz_dbm.html.ko.euc-kr b/docs/manual/mod/mod_authz_dbm.html.ko.euc-kr index 28ed80a6a23..ad838512637 100644 --- a/docs/manual/mod/mod_authz_dbm.html.ko.euc-kr +++ b/docs/manual/mod/mod_authz_dbm.html.ko.euc-kr @@ -51,7 +51,6 @@
  • Require
  • Satisfy
    • -
    top

    AuthDBMGroupFile Áö½Ã¾î

    Description:Définit le nom du fichier de base de données contenant la @@ -192,6 +142,56 @@ la liste des groupes d'utilisateurs
    @@ -122,6 +121,7 @@ »ç¿ëÇϵµ·Ï ¼³Á¤ÇØ¾ß ÇÑ´Ù.

    +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_authz_groupfile.html.en b/docs/manual/mod/mod_authz_groupfile.html.en index b421614b1f6..fc7388a760f 100644 --- a/docs/manual/mod/mod_authz_groupfile.html.en +++ b/docs/manual/mod/mod_authz_groupfile.html.en @@ -53,40 +53,6 @@

  • Require
    • top
    -
    -

    The Require Directives

    - -

    Apache's Require - directives are used during the authorization phase to ensure that - a user is allowed to access a resource. mod_authz_groupfile extends the - authorization types with group and group-file. -

    - -

    Since v2.4.8, expressions are supported - within the groupfile require directives.

    - -

    Require group

    - -

    This directive specifies group membership that is required for the - user to gain access.

    - - 
    Require group admin
    - - - - -

    Require file-group

    - -

    When this directive is specified, the user must be a member of the group - assigned to the file being accessed.

    - - 
    Require file-group
    - - - - -
    -
    top

    AuthGroupFile Directive

    be able to download the AuthGroupFile.

    + +
    top
    +
    +

    The Require Directives

    + +

    Apache's Require + directives are used during the authorization phase to ensure that + a user is allowed to access a resource. mod_authz_groupfile extends the + authorization types with group and group-file. +

    + +

    Since v2.4.8, expressions are supported + within the groupfile require directives.

    + +

    Require group

    + +

    This directive specifies group membership that is required for the + user to gain access.

    + + 
    Require group admin
    + + + + +

    Require file-group

    + +

    When this directive is specified, the user must be a member of the group + assigned to the file being accessed.

    + + 
    Require file-group
    + + + +
    diff --git a/docs/manual/mod/mod_authz_groupfile.html.fr b/docs/manual/mod/mod_authz_groupfile.html.fr index 7b333a84618..8adbcfbeea0 100644 --- a/docs/manual/mod/mod_authz_groupfile.html.fr +++ b/docs/manual/mod/mod_authz_groupfile.html.fr @@ -55,40 +55,6 @@ fonction de leur appartenance
  • Require
    • top
    -
    -

    The Require Directives

    - -

    Les directives Require d'Apache permettent, - au cours de la phase d'autorisation, de s'assurer qu'un utilisateur - est bien autorisé à accéder à une ressource. mod_authz_groupfile ajoute - les types d'autorisation group et file-group. -

    - -

    A partir de la version 2.4.8, les directives require groupfile - supportent les expressions.

    - -

    Require group

    - -

    Cette directive permet de spécifier à quel groupe un utilisateur - doit appartenir pour obtenir l'autorisation d'accès.

    - - 
    Require group admin
    - - - - -

    Require file-group

    - -

    Lorsque cette directive est définie, l'utilisateur doit - appartenir au groupe du fichier pour pouvoir y accéder.

    - - 
    Require file-group
    - - - - -
    -
    top

    Directive AuthGroupFile

    Description:Sets the name of a text file containing the list @@ -119,6 +85,40 @@ of user groups for authorization
    Description:Définit le nom d'un fichier texte contenant la liste des @@ -127,6 +93,40 @@ s clients pourraient le télécharger.

    + +
    top
    +
    +

    The Require Directives

    + +

    Les directives Require d'Apache permettent, + au cours de la phase d'autorisation, de s'assurer qu'un utilisateur + est bien autorisé à accéder à une ressource. mod_authz_groupfile ajoute + les types d'autorisation group et file-group. +

    + +

    A partir de la version 2.4.8, les directives require groupfile + supportent les expressions.

    + +

    Require group

    + +

    Cette directive permet de spécifier à quel groupe un utilisateur + doit appartenir pour obtenir l'autorisation d'accès.

    + + 
    Require group admin
    + + + + +

    Require file-group

    + +

    Lorsque cette directive est définie, l'utilisateur doit + appartenir au groupe du fichier pour pouvoir y accéder.

    + + 
    Require file-group
    + + + +
    diff --git a/docs/manual/mod/mod_authz_groupfile.html.ja.utf8 b/docs/manual/mod/mod_authz_groupfile.html.ja.utf8 index 26425dd2abe..27a3313e348 100644 --- a/docs/manual/mod/mod_authz_groupfile.html.ja.utf8 +++ b/docs/manual/mod/mod_authz_groupfile.html.ja.utf8 @@ -53,7 +53,6 @@
    -
    top

    AuthGroupFile ディレクティブ

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

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_authz_groupfile.html.ko.euc-kr b/docs/manual/mod/mod_authz_groupfile.html.ko.euc-kr index 0aa3ce2494d..bffb3c7511d 100644 --- a/docs/manual/mod/mod_authz_groupfile.html.ko.euc-kr +++ b/docs/manual/mod/mod_authz_groupfile.html.ko.euc-kr @@ -51,7 +51,6 @@

  • Require
  • Satisfy
    • -
    top

    AuthGroupFile Áö½Ã¾î

    @@ -86,6 +85,7 @@ +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_autoindex.html.en b/docs/manual/mod/mod_autoindex.html.en index 529ffdf0276..9864dce3c3b 100644 --- a/docs/manual/mod/mod_autoindex.html.en +++ b/docs/manual/mod/mod_autoindex.html.en @@ -104,108 +104,6 @@

  • Autoindex Request Query Arguments
    • top
    -
    -

    Autoindex Request Query Arguments

    - - -

    Various query string arguments are available to give the client - some control over the ordering of the directory listing, as well as - what files are listed. If you do not wish to give the client this - control, the IndexOptions - IgnoreClient option disables that functionality.

    - -

    The column sorting headers themselves are self-referencing - hyperlinks that add the sort query options shown below. Any - option below may be added to any request for the directory - resource.

    - -
      -
    • C=N sorts the directory by file name
      • - -
    • C=M sorts the directory by last-modified - date, then file name
      • - -
    • C=S sorts the directory by size, then file - name
      • - -
    • C=D sorts the directory by description, then - file name
      • - -
    • O=A sorts the listing in Ascending - Order
      • - -
    • O=D sorts the listing in Descending - Order
      • - -
    • F=0 formats the listing as a simple list - (not FancyIndexed)
      • - -
    • F=1 formats the listing as a FancyIndexed - list
      • - -
    • F=2 formats the listing as an - HTMLTable FancyIndexed list
      • - -
    • V=0 disables version sorting
      • - -
    • V=1 enables version sorting
      • - -
    • P=pattern lists only files matching - the given pattern
      • -
    - -

    Note that the 'P'attern query argument is tested - after the usual IndexIgnore directives are processed, - and all file names are still subjected to the same criteria as - any other autoindex listing. The Query Arguments parser in - mod_autoindex will stop abruptly when an unrecognized - option is encountered. The Query Arguments must be well formed, - according to the table above.

    - -

    The simple example below, which can be clipped and saved in - a header.html file, illustrates these query options. Note that - the unknown "X" argument, for the submit button, is listed last - to assure the arguments are all parsed before mod_autoindex - encounters the X=Go input.

    - -

    - <form action="" method="get">
    - - Show me a <select name="F">
    - - <option value="0"> Plain list</option>
    - <option value="1" selected="selected"> Fancy list</option>
    - <option value="2"> Table list</option>
    -     - </select>
    - Sorted by <select name="C">
    - - <option value="N" selected="selected"> Name</option>
    - <option value="M"> Date Modified</option>
    - <option value="S"> Size</option>
    - <option value="D"> Description</option>
    -     - </select>
    - <select name="O">
    - - <option value="A" selected="selected"> Ascending</option>
    - <option value="D"> Descending</option>
    -     - </select>
    - <select name="V">
    - - <option value="0" selected="selected"> in Normal order</option>
    - <option value="1"> in Version order</option>
    -     - </select>
    - Matching <input type="text" name="P" value="*" />
    - <input type="submit" name="X" value="Go" />
    -     - </form> -

    - -
    -
    top

    AddAlt Directive

  • Arguments de la requête d'autoindexation
    • top
    -
    -

    Arguments de la requête d'autoindexation

    - - -

    La chaîne de paramètres de la requête peut contenir de nombreux - arguments permettant dans une certaine mesure au client de contrôler - l'ordre de l'index du répertoire, ainsi que la liste des fichiers à - afficher. Si vous souhaitez désactiver cette fonctionnalité, - utilisez l'option IndexOptions - IgnoreClient.

    - -

    Les en-têtes de tri des colonnes eux-mêmes sont des hyper-liens - auto-référant qui ajoutent les options de tri à la requête énumérées - ci-dessous qui peuvent être ajoutées à toute requête concernant la - ressource répertoire.

    - -
      -
    • C=N trie l'affichage en fonction du nom de - fichier
      • - -
    • C=M trie l'affichage en fonction de la date de - dernière modification, puis du nom de fichier
      • - -
    • C=S trie l'affichage en fonction de la taille, - puis du nom de fichier
      • - -
    • C=D trie l'affichage en fonction - de la description, puis du nom de fichier
      • - -
    • O=A trie l'affichage selon l'ordre croissant
      • - -
    • O=D trie l'affichage selon - l'ordre décroissant
      • - -
    • F=0 affiche le listing sous la forme d'une simple - liste (sans FancyIndex)
      • - -
    • F=1 affiche le listing avec en-têtes de colonnes - sous forme de liens hyper-textes (FancyIndexed)
      • - -
    • F=2 affiche le listing sous - forme de table HTML avec en-têtes de colonnes contenant des liens - hyper-textes (FancyIndexed)
      • - -
    • V=0 désactive le tri en fonction de la - version
      • - -
    • V=1 active le tri en fonction de - la version
      • - -
    • P=modèle n'affiche que les fichiers - correspondant au modèle spécifié
      • -
    - -

    Notez que l'argument 'P' (pour Pattern) n'est testé - qu'après que les directives habituelles IndexIgnore ont été traitées, - et que tous les noms de fichiers sont encore assujettis aux mêmes - critères que pour tout autre listing auto-indexé. L'interpréteur - d'arguments de requête de mod_autoindex s'arrête - immédiatement s'il rencontre une option non reconnue. Les arguments - de requête doivent être bien formés, selon la table ci-dessus.

    - -

    Les options de requêtes sont illustrées par l'exemple ci-dessous, - qui peut être copié et collé dans un fichier header.html. Notez que - l'argument inconnu "X", pour le bouton submit, est introduit en - dernier afin de s'assurer que tous les arguments ont été - interprétés avant que mod_autoindex ne rencontre l'entrée X=Go.

    - -

    - <form action="" method="get">
    - - Montre moi une <select name="F">
    - - <option value="0"> liste simple</option>
    - <option value="1" selected="selected"> liste avec - en-têtes</option>
    - <option value="2"> liste avec en-tête sous forme de - table</option>
    -     - </select>
    - triée par <select name="C">
    - - <option value="N" selected="selected"> nom</option>
    - <option value="M"> date de modification</option>
    - <option value="S"> taille</option>
    - <option value="D"> description</option>
    -     - </select>
    - <select name="O">
    - - <option value="A" selected="selected"> croissant</option>
    - <option value="D"> décroissant</option>
    -     - </select>
    - <select name="V">
    - - <option value="0" selected="selected"> dans l'ordre - normal</option>
    - <option value="1"> en fonction de la version</option>
    -     - </select>
    - correspondant à <input type="text" name="P" value="*" />
    - <input type="submit" name="X" value="Go" />
    -     - </form> -

    - -
    -
    top

    Directive AddAlt

    Description:Alternate text to display for a file, instead of an @@ -1012,6 +910,108 @@ ReadmeName /include/FOOTER.html

    See also HeaderName, where this behavior is described in greater detail.

    + +
    top
    +
    +

    Autoindex Request Query Arguments

    + + +

    Various query string arguments are available to give the client + some control over the ordering of the directory listing, as well as + what files are listed. If you do not wish to give the client this + control, the IndexOptions + IgnoreClient option disables that functionality.

    + +

    The column sorting headers themselves are self-referencing + hyperlinks that add the sort query options shown below. Any + option below may be added to any request for the directory + resource.

    + +
      +
    • C=N sorts the directory by file name
      • + +
    • C=M sorts the directory by last-modified + date, then file name
      • + +
    • C=S sorts the directory by size, then file + name
      • + +
    • C=D sorts the directory by description, then + file name
      • + +
    • O=A sorts the listing in Ascending + Order
      • + +
    • O=D sorts the listing in Descending + Order
      • + +
    • F=0 formats the listing as a simple list + (not FancyIndexed)
      • + +
    • F=1 formats the listing as a FancyIndexed + list
      • + +
    • F=2 formats the listing as an + HTMLTable FancyIndexed list
      • + +
    • V=0 disables version sorting
      • + +
    • V=1 enables version sorting
      • + +
    • P=pattern lists only files matching + the given pattern
      • +
    + +

    Note that the 'P'attern query argument is tested + after the usual IndexIgnore directives are processed, + and all file names are still subjected to the same criteria as + any other autoindex listing. The Query Arguments parser in + mod_autoindex will stop abruptly when an unrecognized + option is encountered. The Query Arguments must be well formed, + according to the table above.

    + +

    The simple example below, which can be clipped and saved in + a header.html file, illustrates these query options. Note that + the unknown "X" argument, for the submit button, is listed last + to assure the arguments are all parsed before mod_autoindex + encounters the X=Go input.

    + +

    + <form action="" method="get">
    + + Show me a <select name="F">
    + + <option value="0"> Plain list</option>
    + <option value="1" selected="selected"> Fancy list</option>
    + <option value="2"> Table list</option>
    +     + </select>
    + Sorted by <select name="C">
    + + <option value="N" selected="selected"> Name</option>
    + <option value="M"> Date Modified</option>
    + <option value="S"> Size</option>
    + <option value="D"> Description</option>
    +     + </select>
    + <select name="O">
    + + <option value="A" selected="selected"> Ascending</option>
    + <option value="D"> Descending</option>
    +     + </select>
    + <select name="V">
    + + <option value="0" selected="selected"> in Normal order</option>
    + <option value="1"> in Version order</option>
    +     + </select>
    + Matching <input type="text" name="P" value="*" />
    + <input type="submit" name="X" value="Go" />
    +     + </form> +

    +
    diff --git a/docs/manual/mod/mod_autoindex.html.fr b/docs/manual/mod/mod_autoindex.html.fr index f9e725043b7..3d299631571 100644 --- a/docs/manual/mod/mod_autoindex.html.fr +++ b/docs/manual/mod/mod_autoindex.html.fr @@ -103,115 +103,6 @@ shell Win32 dir
    | sed -e 's/.*/mmapfile &/' > /www/conf/mmap.conf

    - -
    top
    -

    Directive CacheFile

    -
    Description:Texte optionnel à afficher à la place d'un icône pour un @@ -1099,6 +990,115 @@ ReadmeName /include/FOOTER.html

    Voir aussi la directive HeaderName, où cette fonctionnalité est décrite plus en détails.

    + +
    top
    +
    +

    Arguments de la requête d'autoindexation

    + + +

    La chaîne de paramètres de la requête peut contenir de nombreux + arguments permettant dans une certaine mesure au client de contrôler + l'ordre de l'index du répertoire, ainsi que la liste des fichiers à + afficher. Si vous souhaitez désactiver cette fonctionnalité, + utilisez l'option IndexOptions + IgnoreClient.

    + +

    Les en-têtes de tri des colonnes eux-mêmes sont des hyper-liens + auto-référant qui ajoutent les options de tri à la requête énumérées + ci-dessous qui peuvent être ajoutées à toute requête concernant la + ressource répertoire.

    + +
      +
    • C=N trie l'affichage en fonction du nom de + fichier
      • + +
    • C=M trie l'affichage en fonction de la date de + dernière modification, puis du nom de fichier
      • + +
    • C=S trie l'affichage en fonction de la taille, + puis du nom de fichier
      • + +
    • C=D trie l'affichage en fonction + de la description, puis du nom de fichier
      • + +
    • O=A trie l'affichage selon l'ordre croissant
      • + +
    • O=D trie l'affichage selon + l'ordre décroissant
      • + +
    • F=0 affiche le listing sous la forme d'une simple + liste (sans FancyIndex)
      • + +
    • F=1 affiche le listing avec en-têtes de colonnes + sous forme de liens hyper-textes (FancyIndexed)
      • + +
    • F=2 affiche le listing sous + forme de table HTML avec en-têtes de colonnes contenant des liens + hyper-textes (FancyIndexed)
      • + +
    • V=0 désactive le tri en fonction de la + version
      • + +
    • V=1 active le tri en fonction de + la version
      • + +
    • P=modèle n'affiche que les fichiers + correspondant au modèle spécifié
      • +
    + +

    Notez que l'argument 'P' (pour Pattern) n'est testé + qu'après que les directives habituelles IndexIgnore ont été traitées, + et que tous les noms de fichiers sont encore assujettis aux mêmes + critères que pour tout autre listing auto-indexé. L'interpréteur + d'arguments de requête de mod_autoindex s'arrête + immédiatement s'il rencontre une option non reconnue. Les arguments + de requête doivent être bien formés, selon la table ci-dessus.

    + +

    Les options de requêtes sont illustrées par l'exemple ci-dessous, + qui peut être copié et collé dans un fichier header.html. Notez que + l'argument inconnu "X", pour le bouton submit, est introduit en + dernier afin de s'assurer que tous les arguments ont été + interprétés avant que mod_autoindex ne rencontre l'entrée X=Go.

    + +

    + <form action="" method="get">
    + + Montre moi une <select name="F">
    + + <option value="0"> liste simple</option>
    + <option value="1" selected="selected"> liste avec + en-têtes</option>
    + <option value="2"> liste avec en-tête sous forme de + table</option>
    +     + </select>
    + triée par <select name="C">
    + + <option value="N" selected="selected"> nom</option>
    + <option value="M"> date de modification</option>
    + <option value="S"> taille</option>
    + <option value="D"> description</option>
    +     + </select>
    + <select name="O">
    + + <option value="A" selected="selected"> croissant</option>
    + <option value="D"> décroissant</option>
    +     + </select>
    + <select name="V">
    + + <option value="0" selected="selected"> dans l'ordre + normal</option>
    + <option value="1"> en fonction de la version</option>
    +     + </select>
    + correspondant à <input type="text" name="P" value="*" />
    + <input type="submit" name="X" value="Go" />
    +     + </form> +

    +
    diff --git a/docs/manual/mod/mod_autoindex.html.ja.utf8 b/docs/manual/mod/mod_autoindex.html.ja.utf8 index 54334c68d6c..e0845fe2bcd 100644 --- a/docs/manual/mod/mod_autoindex.html.ja.utf8 +++ b/docs/manual/mod/mod_autoindex.html.ja.utf8 @@ -113,116 +113,6 @@
  • Autoindex リクエストクエリー引数
    • top
    -
    -

    Autoindex リクエストクエリー引数

    - - -

    Apache 2.0.23 で、 - コラムソートのためにクエリー引数を再編成して、 - 新しいクエリーオプションのグループを導入しました。 - 出力に対するクライアントのすべての制御を効率的に抹消 - できるように、 - IndexOptions - IgnoreClient が導入されました。

    - -

    コラムソートのヘッダそれ自体が、 - 下記のソートクエリーオプションを付加する - 自分自身を参照するリンクです。 - 下記のオプションのどれでも、 - ディレクトリリソースへのリクエストに加えることができます。

    - -
      -
    • C=N は、ファイル名でソートします。
      • - -
    • C=M は、更新日時、 - ディレクトリ、ファイル名の順でソートします。
      • - -
    • C=S は、サイズ、 - ディレクトリ、ファイル名の順でソートします。
      • - -
    • C=D は、説明、 - ディレクトリ、ファイル名の順でソートします。
      • - -
    • O=A は、昇順で表をソートします。
      • - -
    • O=D は、降順で表をソートします。
      • - -
    • F=0 は、単純な表の書式にします。 - (FancyIndex ではありません。)
      • - -
    • F=1 は、FancyIndex - 表示の表の書式にします。
      • - -
    • F=2 は、表を HTML - のテーブルを使った FancyIndex の書式にします。
      • - -
    • V=0 - は、バージョンによるソートを無効にします。
      • - -
    • V=1 - は、バージョンによるソートを有効にします。
      • - -
    • P=pattern - は、与えられた pattern - に適合したファイルのみを表示します。
      • -
    - -

    "P (パターンの P)" クエリー引数は、 - 通常の IndexIgnore - ディレクティブが処理された後に検査され、 - ファイル名全てが、他の autoindex - リスト処理と同様の判定基準下に置かれ続ける - ことに注意してください。 - mod_autoindex のクエリー引数パーサ (解析) は、 - 認識不能なオプションにぶつかると即座に停止します。 - クエリー引数は上の表に従って - 正しい形式になっていなければなりません。

    - -

    下の単純な例は、これらのクエリーオプションを - 表します。これをそのまま切り取って HEADER.html - ファイルに保存することもできます。 - mod_autoindex が X=Go 入力にぶつかる前に - 引数が全て解釈されるように、 - 未知の引数 "X" はリストの最後に置かれています。

    - -

    - <form action="" method="get">
    - - Show me a <select name="F">
    - - <option value="0"> Plain list</option>
    - <option value="1" selected="selected"> Fancy list</option>
    - <option value="2"> Table list</option>
    -     - </select>
    - Sorted by <select name="C">
    - - <option value="N" selected="selected"> Name</option>
    - <option value="M"> Date Modified</option>
    - <option value="S"> Size</option>
    - <option value="D"> Description</option>
    -     - </select>
    - <select name="O">
    - - <option value="A" selected="selected"> Ascending</option>
    - <option value="D"> Descending</option>
    -     - </select>
    - <select name="V">
    - - <option value="0" selected="selected"> in Normal order</option>
    - <option value="1"> in Version order</option>
    -     - </select>
    - Matching <input type="text" name="P" value="*" />
    - <input type="submit" name="X" value="Go" />
    -     - </form> -

    - -
    -
    top

    AddAlt ディレクティブ

    より詳細にまでこの挙動について記述している HeaderName もご覧下さい。

    + +
    top
    +
    +

    Autoindex リクエストクエリー引数

    + + +

    Apache 2.0.23 で、 + コラムソートのためにクエリー引数を再編成して、 + 新しいクエリーオプションのグループを導入しました。 + 出力に対するクライアントのすべての制御を効率的に抹消 + できるように、 + IndexOptions + IgnoreClient が導入されました。

    + +

    コラムソートのヘッダそれ自体が、 + 下記のソートクエリーオプションを付加する + 自分自身を参照するリンクです。 + 下記のオプションのどれでも、 + ディレクトリリソースへのリクエストに加えることができます。

    + +
      +
    • C=N は、ファイル名でソートします。
      • + +
    • C=M は、更新日時、 + ディレクトリ、ファイル名の順でソートします。
      • + +
    • C=S は、サイズ、 + ディレクトリ、ファイル名の順でソートします。
      • + +
    • C=D は、説明、 + ディレクトリ、ファイル名の順でソートします。
      • + +
    • O=A は、昇順で表をソートします。
      • + +
    • O=D は、降順で表をソートします。
      • + +
    • F=0 は、単純な表の書式にします。 + (FancyIndex ではありません。)
      • + +
    • F=1 は、FancyIndex + 表示の表の書式にします。
      • + +
    • F=2 は、表を HTML + のテーブルを使った FancyIndex の書式にします。
      • + +
    • V=0 + は、バージョンによるソートを無効にします。
      • + +
    • V=1 + は、バージョンによるソートを有効にします。
      • + +
    • P=pattern + は、与えられた pattern + に適合したファイルのみを表示します。
      • +
    + +

    "P (パターンの P)" クエリー引数は、 + 通常の IndexIgnore + ディレクティブが処理された後に検査され、 + ファイル名全てが、他の autoindex + リスト処理と同様の判定基準下に置かれ続ける + ことに注意してください。 + mod_autoindex のクエリー引数パーサ (解析) は、 + 認識不能なオプションにぶつかると即座に停止します。 + クエリー引数は上の表に従って + 正しい形式になっていなければなりません。

    + +

    下の単純な例は、これらのクエリーオプションを + 表します。これをそのまま切り取って HEADER.html + ファイルに保存することもできます。 + mod_autoindex が X=Go 入力にぶつかる前に + 引数が全て解釈されるように、 + 未知の引数 "X" はリストの最後に置かれています。

    + +

    + <form action="" method="get">
    + + Show me a <select name="F">
    + + <option value="0"> Plain list</option>
    + <option value="1" selected="selected"> Fancy list</option>
    + <option value="2"> Table list</option>
    +     + </select>
    + Sorted by <select name="C">
    + + <option value="N" selected="selected"> Name</option>
    + <option value="M"> Date Modified</option>
    + <option value="S"> Size</option>
    + <option value="D"> Description</option>
    +     + </select>
    + <select name="O">
    + + <option value="A" selected="selected"> Ascending</option>
    + <option value="D"> Descending</option>
    +     + </select>
    + <select name="V">
    + + <option value="0" selected="selected"> in Normal order</option>
    + <option value="1"> in Version order</option>
    +     + </select>
    + Matching <input type="text" name="P" value="*" />
    + <input type="submit" name="X" value="Go" />
    +     + </form> +

    +
    diff --git a/docs/manual/mod/mod_autoindex.html.ko.euc-kr b/docs/manual/mod/mod_autoindex.html.ko.euc-kr index d0bb1709175..151c67cf750 100644 --- a/docs/manual/mod/mod_autoindex.html.ko.euc-kr +++ b/docs/manual/mod/mod_autoindex.html.ko.euc-kr @@ -97,97 +97,6 @@
  • Autoindex ¿äû ¾Æ±Ô¸ÕÆ®
    • top
    -
    -

    Autoindex ¿äû ¾Æ±Ô¸ÕÆ®

    - - -

    ¾ÆÆÄÄ¡ 2.0.23´Â ¿­¼ø¼­¿¡ ´ëÇÑ ¿äû ¾Æ±Ô¸ÕÆ®¸¦ Á¤¸®ÇÏ°í, - »õ·Î¿î ¿É¼ÇµéÀ» Ãß°¡Çß´Ù. Ãâ·ÂÀ» Ŭ¶óÀ̾ðÆ®°¡ Á¶ÀýÇÒ ¼ö - ¾øµµ·Ï ¸¸µå´Â IndexOptions - IgnoreClient ¿É¼ÇÀÌ Ãß°¡µÇ¾ú´Ù.

    - -

    ¿­¼ø¼­ À̸§Àº ¾Æ·¡ ³ª¿Â ¼ø¼­ ¿äû ¿É¼ÇÀ» ´õÇÑ ÀÚ±âÂüÁ¶ - ¸µÅ©´Ù. ¾Æ·¡ ¿É¼ÇÀº µð·ºÅ丮 ÀÚ¿ø¿¡ ´ëÇÑ ¾î¶² ¿äû¿¡µµ - »ç¿ëÇÒ ¼ö ÀÖ´Ù.

    - -
      -
    • C=NÀº ÆÄÀÏ¸í ¼øÀÌ´Ù
      • - -
    • C=MÀº ÃÖ±Ù ¼öÁ¤ÀÏ ¼ø, ±×¸®°í ÆÄÀÏ¸í ¼øÀÌ´Ù
      • - -
    • C=S´Â Å©±â ¼ø, ±×¸®°í ÆÄÀÏ¸í ¼øÀÌ´Ù
      • - -
    • C=D´Â ¼³¸í ¼ø, ±×¸®°í ÆÄÀϸí - ¼øÀÌ´Ù
      • - -
    • O=A´Â ¿À¸§Â÷¼øÀ¸·Î ¸ñ·ÏÀ» Á¤·ÄÇÑ´Ù
      • - -
    • O=D´Â ³»¸²Â÷¼øÀ¸·Î ¸ñ·ÏÀ» Á¤·ÄÇÑ´Ù
      • - -
    • F=0Àº (FancyIndexed°¡ ¾Æ´Ñ) °£´ÜÇÑ ¸ñ·Ï Çü½ÄÀÌ´Ù
      • - -
    • F=1Àº FancyIndexed ¸ñ·Ï Çü½ÄÀÌ´Ù
      • - -
    • F=2´Â HTMLTable FancyIndexed ¸ñ·Ï - Çü½ÄÀÌ´Ù
      • - -
    • V=0Àº ¹öÀü ¼øÀ¸·Î Á¤·ÄÇÏÁö ¾Ê´Â´Ù
      • - -
    • V=1Àº ¹öÀü ¼øÀ¸·Î Á¤·ÄÇÑ´Ù
      • - -
    • P=patternÀº ÁÖ¾îÁø pattern¿¡ - ÇØ´çÇÏ´Â ÆÄÀϸ¸À» ¸ñ·ÏÀ¸·Î ¸¸µç´Ù
      • -
    - -

    'P'attern ¾Æ±Ô¸ÕÆ®´Â ÀϹÝÀûÀÎ IndexIgnore Áö½Ã¾î¸¦ ó¸®ÇÑ ÈÄ¿¡ - °Ë»çÇϱ⶧¹®¿¡, ¸ñ·ÏÀº ´Ù¸¥ autoindex Á¶°ÇÀ» µû¸§À» ÁÖÀÇÇ϶ó. - mod_autoindexÀÇ ¿äû ¾Æ±Ô¸ÕÆ®¸¦ ÀоîµéÀ϶§ - ¾Ë ¼ö ¾ø´Â ¿É¼ÇÀ» ¹ß°ßÇÏ¸é ´õ ÀÌ»ó ÀÐÁö¾Ê´Â´Ù. ¿äû ¾Æ±Ô¸ÕÆ®´Â - À§ÀÇ Ç¥¿¡ µû¶ó ¸¸µé¾î¾ß ÇÑ´Ù.

    - -

    header.html ÆÄÀÏ¿¡ »ç¿ëÇÒ ¼ö ÀÖ´Â ¾Æ·¡ °£´ÜÇÑ ¿¹Á¦´Â - ÀÌ ¿É¼ÇµéÀ» ¼³¸íÇÑ´Ù. submit ¹öÅÏÀÇ ¾Ë ¼ö ¾ø´Â "X" ¾Æ±Ô¸ÕÆ®´Â - mod_autoindex°¡ X=Go Àü±îÁö ¸ðµç ¾Æ±Ô¸ÕÆ®¸¦ ÀоîµéÀÓÀ» - È®ÀÎÇϱâÀ§ÇØ ¸¶Áö¸·¿¡ »ç¿ëÇß´Ù.

    - -

    - <form action="" method="get">
    - - Show me a <select name="F">
    - - <option value="0"> Plain list</option>
    - <option value="1" selected="selected"> Fancy list</option>
    - <option value="2"> Table list</option>
    -     - </select>
    - Sorted by <select name="C">
    - - <option value="N" selected="selected"> Name</option>
    - <option value="M"> Date Modified</option>
    - <option value="S"> Size</option>
    - <option value="D"> Description</option>
    -     - </select>
    - <select name="O">
    - - <option value="A" selected="selected"> Ascending</option>
    - <option value="D"> Descending</option>
    -     - </select>
    - <select name="V">
    - - <option value="0" selected="selected"> in Normal order</option>
    - <option value="1"> in Version order</option>
    -     - </select>
    - Matching <input type="text" name="P" value="*" />
    - <input type="submit" name="X" value="Go" />
    -     - </form> -

    - -
    -
    top

    AddAlt Áö½Ã¾î

    説明:アイコンの代わりに @@ -1042,6 +932,116 @@ Name|Date|Size|Description
    @@ -854,6 +763,97 @@ Name|Date|Size|Description

    ÀÌ µ¿ÀÛÀ» ÀÚ¼¼È÷ ¼³¸íÇÑ HeaderNameµµ Âü°íÇ϶ó.

    + +
    top
    +
    +

    Autoindex ¿äû ¾Æ±Ô¸ÕÆ®

    + + +

    ¾ÆÆÄÄ¡ 2.0.23´Â ¿­¼ø¼­¿¡ ´ëÇÑ ¿äû ¾Æ±Ô¸ÕÆ®¸¦ Á¤¸®ÇÏ°í, + »õ·Î¿î ¿É¼ÇµéÀ» Ãß°¡Çß´Ù. Ãâ·ÂÀ» Ŭ¶óÀ̾ðÆ®°¡ Á¶ÀýÇÒ ¼ö + ¾øµµ·Ï ¸¸µå´Â IndexOptions + IgnoreClient ¿É¼ÇÀÌ Ãß°¡µÇ¾ú´Ù.

    + +

    ¿­¼ø¼­ À̸§Àº ¾Æ·¡ ³ª¿Â ¼ø¼­ ¿äû ¿É¼ÇÀ» ´õÇÑ ÀÚ±âÂüÁ¶ + ¸µÅ©´Ù. ¾Æ·¡ ¿É¼ÇÀº µð·ºÅ丮 ÀÚ¿ø¿¡ ´ëÇÑ ¾î¶² ¿äû¿¡µµ + »ç¿ëÇÒ ¼ö ÀÖ´Ù.

    + +
      +
    • C=NÀº ÆÄÀÏ¸í ¼øÀÌ´Ù
      • + +
    • C=MÀº ÃÖ±Ù ¼öÁ¤ÀÏ ¼ø, ±×¸®°í ÆÄÀÏ¸í ¼øÀÌ´Ù
      • + +
    • C=S´Â Å©±â ¼ø, ±×¸®°í ÆÄÀÏ¸í ¼øÀÌ´Ù
      • + +
    • C=D´Â ¼³¸í ¼ø, ±×¸®°í ÆÄÀϸí + ¼øÀÌ´Ù
      • + +
    • O=A´Â ¿À¸§Â÷¼øÀ¸·Î ¸ñ·ÏÀ» Á¤·ÄÇÑ´Ù
      • + +
    • O=D´Â ³»¸²Â÷¼øÀ¸·Î ¸ñ·ÏÀ» Á¤·ÄÇÑ´Ù
      • + +
    • F=0Àº (FancyIndexed°¡ ¾Æ´Ñ) °£´ÜÇÑ ¸ñ·Ï Çü½ÄÀÌ´Ù
      • + +
    • F=1Àº FancyIndexed ¸ñ·Ï Çü½ÄÀÌ´Ù
      • + +
    • F=2´Â HTMLTable FancyIndexed ¸ñ·Ï + Çü½ÄÀÌ´Ù
      • + +
    • V=0Àº ¹öÀü ¼øÀ¸·Î Á¤·ÄÇÏÁö ¾Ê´Â´Ù
      • + +
    • V=1Àº ¹öÀü ¼øÀ¸·Î Á¤·ÄÇÑ´Ù
      • + +
    • P=patternÀº ÁÖ¾îÁø pattern¿¡ + ÇØ´çÇÏ´Â ÆÄÀϸ¸À» ¸ñ·ÏÀ¸·Î ¸¸µç´Ù
      • +
    + +

    'P'attern ¾Æ±Ô¸ÕÆ®´Â ÀϹÝÀûÀÎ IndexIgnore Áö½Ã¾î¸¦ ó¸®ÇÑ ÈÄ¿¡ + °Ë»çÇϱ⶧¹®¿¡, ¸ñ·ÏÀº ´Ù¸¥ autoindex Á¶°ÇÀ» µû¸§À» ÁÖÀÇÇ϶ó. + mod_autoindexÀÇ ¿äû ¾Æ±Ô¸ÕÆ®¸¦ ÀоîµéÀ϶§ + ¾Ë ¼ö ¾ø´Â ¿É¼ÇÀ» ¹ß°ßÇÏ¸é ´õ ÀÌ»ó ÀÐÁö¾Ê´Â´Ù. ¿äû ¾Æ±Ô¸ÕÆ®´Â + À§ÀÇ Ç¥¿¡ µû¶ó ¸¸µé¾î¾ß ÇÑ´Ù.

    + +

    header.html ÆÄÀÏ¿¡ »ç¿ëÇÒ ¼ö ÀÖ´Â ¾Æ·¡ °£´ÜÇÑ ¿¹Á¦´Â + ÀÌ ¿É¼ÇµéÀ» ¼³¸íÇÑ´Ù. submit ¹öÅÏÀÇ ¾Ë ¼ö ¾ø´Â "X" ¾Æ±Ô¸ÕÆ®´Â + mod_autoindex°¡ X=Go Àü±îÁö ¸ðµç ¾Æ±Ô¸ÕÆ®¸¦ ÀоîµéÀÓÀ» + È®ÀÎÇϱâÀ§ÇØ ¸¶Áö¸·¿¡ »ç¿ëÇß´Ù.

    + +

    + <form action="" method="get">
    + + Show me a <select name="F">
    + + <option value="0"> Plain list</option>
    + <option value="1" selected="selected"> Fancy list</option>
    + <option value="2"> Table list</option>
    +     + </select>
    + Sorted by <select name="C">
    + + <option value="N" selected="selected"> Name</option>
    + <option value="M"> Date Modified</option>
    + <option value="S"> Size</option>
    + <option value="D"> Description</option>
    +     + </select>
    + <select name="O">
    + + <option value="A" selected="selected"> Ascending</option>
    + <option value="D"> Descending</option>
    +     + </select>
    + <select name="V">
    + + <option value="0" selected="selected"> in Normal order</option>
    + <option value="1"> in Version order</option>
    +     + </select>
    + Matching <input type="text" name="P" value="*" />
    + <input type="submit" name="X" value="Go" />
    +     + </form> +

    +
    diff --git a/docs/manual/mod/mod_autoindex.html.tr.utf8 b/docs/manual/mod/mod_autoindex.html.tr.utf8 index c3e265287b5..4248056d50f 100644 --- a/docs/manual/mod/mod_autoindex.html.tr.utf8 +++ b/docs/manual/mod/mod_autoindex.html.tr.utf8 @@ -97,98 +97,6 @@ yaptığı gibi dizin içeriğini listeler.
  • Sütun Sıralamada Sorgu Seçenekleri
    • top
    -
    -

    Sütun Sıralamada Sorgu Seçenekleri

    - - -

    İstemciye, dizin içeriğini listelerken neleri hangi sırada - listeleyeceğini belirleyebilmesi için içerik üzerinde biraz denetim - sağlayabileceği çeşitli sorgu dizgesi bileşenleri sağlanmıştır. - Çıktı üzerinde kullanıcı denetimini tamamen ortadan kaldırmak için - IndexOptions yönergesinin - IgnoreClient - seçeneği kullanılabilir.

    - -

    Sütun sıralama başlıklarının her biri hedefi kendisi olan birer hiper - bağ olup aşağıda sıralanan sorgu seçeneklerini kullanırlar. Bu - seçeneklerin her biri her dizin içerik listesi isteğine eklenebilir.

    - -
      -
    • C=N dizini dosya adına göre sıralar
      • - -
    • C=M dizini son değişiklik zamanına ve ardından dosya - ismine göre sıralar.
      • - -
    • C=S dizini boyuta ve ardından dosya adına göre - sıralar
      • - -
    • C=D dizini açıklamaya ve ardından - dosya adına göre sıralar.
      • - -
    • O=A artan sıralama uygulanır.
      • - -
    • O=D azalan sıralama uygulanır.
      • - -
    • F=0 listeleme basit listeleme biçiminde yapılır - (FancyIndexing seçeneği ile etkinleştirilen biçimde - değil)
      • - -
    • F=1 listeleme FancyIndexing seçeneği ile - etkinleştirilen biçimde yapılır
      • - -
    • F=2 listeleme FancyIndexing ve - HTMLTable seçeneği - ile etkinleştirilen biçimde yapılır.
      • - -
    • V=0 sürüme göre sıralama iptal edilir.
      • - -
    • V=1 sürüme göre sıralama etkin - kılınır.
      • - -
    • P=kalıp sadece belirtilen - kalıp ile eşleşen dosyalar istelenir.
      • -
    - -

    P=kalıp sorgu seçeneğinin normalde IndexIgnore yönergesi işleme - sokulduktan sonra değerlendirildiğine ve dosya isimlerinin diğer - kendiliğinden içerik listeleme koşullarının konusu olmaya devam ettiğine - dikkat ediniz. mod_autoindex modülündeki Sorgu - Seçenekleri çözümleyicisi tanımadığı bir seçeneğe rastlar rastlamaz - işlemi durdurur. Sorgu Seçenekleri yukarıda belirtilene uygun olarak iyi - biçimli olmak zorundadır.

    - -

    Aşağıdaki basit örnekte sorgu seçeneklerinin kullanımı gösterilmiştir. - Son satırda bulunan "submit" düğmesindeki tanınmayan "X" girdisine - dikkat ediniz. "X=Göster" girdisi tüm seçenekler işlendikten sonra - mod_autoindex tarafından son argüman olarak ele - alınacak ve çözümleme işlemi o noktada duracaktır.

    - - 
    <form action="" method="get">
-  <input type="text" name="P" value="*" /> ile eşleşen
-  <select name="C">
-    <option value="N" selected="selected">isme</option>
-    <option value="M"> değişiklik tarihine</option>
-    <option value="S"> boyuta</option>
-    <option value="D"> açıklamaya</option>
-  </select> göre
-  <select name="O">
-    <option value="A" selected="selected"> artan</option>
-    <option value="D"> azalan</option>
-  </select>
-  <select name="V">
-    <option value="0" selected="selected">normal</option>
-    <option value="1"> sürümlü</option>
-  </select> sıralamayla bir
-  <select name="F">
-    <option value="0"> basit liste</option>
-    <option value="1" selected="selected"> süslü liste</option>
-    <option value="2"> tablolu liste</option>
-  </select>
-  <input type="submit" name="X" value="Göster" />
-</form>
    - -
    -
    top

    AddAlt Yönergesi

    ¼³¸í:ÆÄÀϸíÀ¸·Î ¼±ÅÃÇÑ ¾ÆÀÌÄÜ´ë½Å »ç¿ëÇÒ ÆÄÀÏ ¼³¸í±Û
  • Utilisation de mod_file_cache
    • top
    +

    Directive CacheFile

    +
    Açıklama:Dosyaya göre seçilen simgenin yerinde gösterilecek metni belirler. @@ -1014,6 +922,98 @@ ReadmeName /include/FOOTER.html

    Ayrıca bu davranışın daha ayrıntılı ele alındığı HeaderName yönergesine de bakınız.

    + +
    top
    +
    +

    Sütun Sıralamada Sorgu Seçenekleri

    + + +

    İstemciye, dizin içeriğini listelerken neleri hangi sırada + listeleyeceğini belirleyebilmesi için içerik üzerinde biraz denetim + sağlayabileceği çeşitli sorgu dizgesi bileşenleri sağlanmıştır. + Çıktı üzerinde kullanıcı denetimini tamamen ortadan kaldırmak için + IndexOptions yönergesinin + IgnoreClient + seçeneği kullanılabilir.

    + +

    Sütun sıralama başlıklarının her biri hedefi kendisi olan birer hiper + bağ olup aşağıda sıralanan sorgu seçeneklerini kullanırlar. Bu + seçeneklerin her biri her dizin içerik listesi isteğine eklenebilir.

    + +
      +
    • C=N dizini dosya adına göre sıralar
      • + +
    • C=M dizini son değişiklik zamanına ve ardından dosya + ismine göre sıralar.
      • + +
    • C=S dizini boyuta ve ardından dosya adına göre + sıralar
      • + +
    • C=D dizini açıklamaya ve ardından + dosya adına göre sıralar.
      • + +
    • O=A artan sıralama uygulanır.
      • + +
    • O=D azalan sıralama uygulanır.
      • + +
    • F=0 listeleme basit listeleme biçiminde yapılır + (FancyIndexing seçeneği ile etkinleştirilen biçimde + değil)
      • + +
    • F=1 listeleme FancyIndexing seçeneği ile + etkinleştirilen biçimde yapılır
      • + +
    • F=2 listeleme FancyIndexing ve + HTMLTable seçeneği + ile etkinleştirilen biçimde yapılır.
      • + +
    • V=0 sürüme göre sıralama iptal edilir.
      • + +
    • V=1 sürüme göre sıralama etkin + kılınır.
      • + +
    • P=kalıp sadece belirtilen + kalıp ile eşleşen dosyalar istelenir.
      • +
    + +

    P=kalıp sorgu seçeneğinin normalde IndexIgnore yönergesi işleme + sokulduktan sonra değerlendirildiğine ve dosya isimlerinin diğer + kendiliğinden içerik listeleme koşullarının konusu olmaya devam ettiğine + dikkat ediniz. mod_autoindex modülündeki Sorgu + Seçenekleri çözümleyicisi tanımadığı bir seçeneğe rastlar rastlamaz + işlemi durdurur. Sorgu Seçenekleri yukarıda belirtilene uygun olarak iyi + biçimli olmak zorundadır.

    + +

    Aşağıdaki basit örnekte sorgu seçeneklerinin kullanımı gösterilmiştir. + Son satırda bulunan "submit" düğmesindeki tanınmayan "X" girdisine + dikkat ediniz. "X=Göster" girdisi tüm seçenekler işlendikten sonra + mod_autoindex tarafından son argüman olarak ele + alınacak ve çözümleme işlemi o noktada duracaktır.

    + + 
    <form action="" method="get">
+  <input type="text" name="P" value="*" /> ile eşleşen
+  <select name="C">
+    <option value="N" selected="selected">isme</option>
+    <option value="M"> değişiklik tarihine</option>
+    <option value="S"> boyuta</option>
+    <option value="D"> açıklamaya</option>
+  </select> göre
+  <select name="O">
+    <option value="A" selected="selected"> artan</option>
+    <option value="D"> azalan</option>
+  </select>
+  <select name="V">
+    <option value="0" selected="selected">normal</option>
+    <option value="1"> sürümlü</option>
+  </select> sıralamayla bir
+  <select name="F">
+    <option value="0"> basit liste</option>
+    <option value="1" selected="selected"> süslü liste</option>
+    <option value="2"> tablolu liste</option>
+  </select>
+  <input type="submit" name="X" value="Göster" />
+</form>
    +
    diff --git a/docs/manual/mod/mod_buffer.html.en b/docs/manual/mod/mod_buffer.html.en index f696509c85f..04aa79eecd8 100644 --- a/docs/manual/mod/mod_buffer.html.en +++ b/docs/manual/mod/mod_buffer.html.en @@ -78,7 +78,6 @@
    -
    top

    BufferSize Directive

    @@ -95,6 +94,7 @@ The default is 128 kilobytes.

    +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_buffer.html.fr b/docs/manual/mod/mod_buffer.html.fr index 3184b17a9f6..7e49a67f6a8 100644 --- a/docs/manual/mod/mod_buffer.html.fr +++ b/docs/manual/mod/mod_buffer.html.fr @@ -81,7 +81,6 @@ d'Apache

    -
    top

    Directive BufferSize

    @@ -98,6 +97,7 @@ d'Apache
    128 ko.

    +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_cache.html.en b/docs/manual/mod/mod_cache.html.en index 429137e164f..d0a2a6000a1 100644 --- a/docs/manual/mod/mod_cache.html.en +++ b/docs/manual/mod/mod_cache.html.en @@ -163,191 +163,6 @@

  • Caching Guide
    • top
    -
    -

    Related Modules and Directives

    -
    Related ModulesRelated Directives
    -
    top
    -
    -

    Sample Configuration

    -

    Sample httpd.conf

    #
-# Sample Cache Configuration
-#
-LoadModule cache_module modules/mod_cache.so
-<IfModule mod_cache.c>
-    LoadModule cache_disk_module modules/mod_cache_disk.so
-    <IfModule mod_cache_disk.c>
-        CacheRoot "c:/cacheroot"
-        CacheEnable disk  "/"
-        CacheDirLevels 5
-        CacheDirLength 3
-    </IfModule>
-
-    # When acting as a proxy, don't cache the list of security updates
-    CacheDisable "http://security.update.server/update-list/"
-</IfModule>
    -
    -
    top
    -
    -

    Avoiding the Thundering Herd

    -

    When a cached entry becomes stale, mod_cache will submit - a conditional request to the backend, which is expected to confirm whether the - cached entry is still fresh, and send an updated entity if not.

    -

    A small but finite amount of time exists between the time the cached entity - becomes stale, and the time the stale entity is fully refreshed. On a busy - server, a significant number of requests might arrive during this time, and - cause a thundering herd of requests to strike the backend - suddenly and unpredictably.

    -

    To keep the thundering herd at bay, the CacheLock - directive can be used to define a directory in which locks are created for - URLs in flight. The lock is used as a hint - by other requests to either suppress an attempt to cache (someone else has - gone to fetch the entity), or to indicate that a stale entry is being refreshed - (stale content will be returned in the mean time). -

    -

    Initial caching of an entry

    - -

    When an entity is cached for the first time, a lock will be created for the - entity until the response has been fully cached. During the lifetime of the - lock, the cache will suppress the second and subsequent attempt to cache the - same entity. While this doesn't hold back the thundering herd, it does stop - the cache attempting to cache the same entity multiple times simultaneously. -

    - -

    Refreshment of a stale entry

    - -

    When an entity reaches its freshness lifetime and becomes stale, a lock - will be created for the entity until the response has either been confirmed as - still fresh, or replaced by the backend. During the lifetime of the lock, the - second and subsequent incoming request will cause stale data to be returned, - and the thundering herd is kept at bay.

    - -

    Locks and Cache-Control: no-cache

    - -

    Locks are used as a hint only to enable the cache to be - more gentle on backend servers, however the lock can be overridden if necessary. - If the client sends a request with a Cache-Control header forcing a reload, any - lock that may be present will be ignored, and the client's request will be - honored immediately and the cached entry refreshed.

    -

    As a further safety mechanism, locks have a configurable maximum age. - Once this age has been reached, the lock is removed, and a new request is - given the opportunity to create a new lock. This maximum age can be set using - the CacheLockMaxAge directive, and defaults to 5 - seconds. -

    - -

    Example configuration

    - -

    Enabling the cache lock

    #
-# Enable the cache lock
-#
-<IfModule mod_cache.c>
-    CacheLock on
-    CacheLockPath "/tmp/mod_cache-lock"
-    CacheLockMaxAge 5
-</IfModule>
    -
    - -
    top
    -
    -

    Fine Control with the CACHE Filter

    -

    Under the default mode of cache operation, the cache runs as a quick handler, - short circuiting the majority of server processing and offering the highest - cache performance available.

    - -

    In this mode, the cache bolts onto the front of the server, - acting as if a free standing RFC 2616 caching proxy had been placed in front of - the server.

    - -

    While this mode offers the best performance, the administrator may find that - under certain circumstances they may want to perform further processing on the - request after the request is cached, such as to inject personalisation into the - cached page, or to apply authorisation restrictions to the content. Under these - circumstances, an administrator is often forced to place independent reverse - proxy servers either behind or in front of the caching server to achieve this.

    - -

    To solve this problem the CacheQuickHandler - directive can be set to off, and the server will - process all phases normally handled by a non-cached request, including the - authentication and authorisation phases.

    - -

    In addition, the administrator may optionally specify the precise point - within the filter chain where caching is to take place by adding the - CACHE filter to the output filter chain.

    - -

    For example, to cache content before applying compression to the response, - place the CACHE filter before the DEFLATE - filter as in the example below:

    - - 
    # Cache content before optional compression
-CacheQuickHandler off
-AddOutputFilterByType CACHE;DEFLATE text/plain
    - - -

    Another option is to have content cached before personalisation is applied - by mod_include (or another content processing filter). In this - example templates containing tags understood by - mod_include are cached before being parsed:

    - - 
    # Cache content before mod_include and mod_deflate
-CacheQuickHandler off
-AddOutputFilterByType CACHE;INCLUDES;DEFLATE text/html
    - - -

    You may place the CACHE filter anywhere you wish within the - filter chain. In this example, content is cached after being parsed by - mod_include, but before being processed by - mod_deflate:

    - - 
    # Cache content between mod_include and mod_deflate
-CacheQuickHandler off
-AddOutputFilterByType INCLUDES;CACHE;DEFLATE text/html
    - - -

    Warning:

    If the location of the - CACHE filter in the filter chain is changed for any reason, - you may need to flush your cache to ensure that your data - served remains consistent. mod_cache is not in a position - to enforce this for you.
    - -
    top
    -
    -

    Cache Status and Logging

    -

    Once mod_cache has made a decision as to whether or not - an entity is to be served from cache, the detailed reason for the decision - is written to the subprocess environment within the request under the - cache-status key. This reason can be logged by the - LogFormat directive as - follows:

    - - 
    LogFormat "%{cache-status}e ..."
    - - -

    Based on the caching decision made, the reason is also written to the - subprocess environment under one the following four keys, as appropriate:

    - -
    -
    cache-hit
    The response was served from cache.
    -
    cache-revalidate
    The response was stale and was successfully - revalidated, then served from cache.
    -
    cache-miss
    The response was served from the upstream server.
    -
    cache-invalidate
    The cached entity was invalidated by a request - method other than GET or HEAD.
    -
    - -

    This makes it possible to support conditional logging of cached requests - as per the following example:

    - - 
    CustomLog "cached-requests.log" common env=cache-hit
-CustomLog "uncached-requests.log" common env=cache-miss
-CustomLog "revalidated-requests.log" common env=cache-revalidate
-CustomLog "invalidated-requests.log" common env=cache-invalidate
    - - -

    For module authors, a hook called cache_status is available, - allowing modules to respond to the caching outcomes above in customised - ways.

    -
    -
    top

    CacheDefaultExpire Directive

    @@ -1044,6 +859,191 @@ CacheStaleOnError on
  • CacheStoreNoStore
    • +
    top
    +
    +

    Related Modules and Directives

    +
    Description:The default duration to cache a document when no expiry date is specified.
    Related ModulesRelated Directives
    +
    top
    +
    +

    Sample Configuration

    +

    Sample httpd.conf

    #
+# Sample Cache Configuration
+#
+LoadModule cache_module modules/mod_cache.so
+<IfModule mod_cache.c>
+    LoadModule cache_disk_module modules/mod_cache_disk.so
+    <IfModule mod_cache_disk.c>
+        CacheRoot "c:/cacheroot"
+        CacheEnable disk  "/"
+        CacheDirLevels 5
+        CacheDirLength 3
+    </IfModule>
+
+    # When acting as a proxy, don't cache the list of security updates
+    CacheDisable "http://security.update.server/update-list/"
+</IfModule>
    +
    +
    top
    +
    +

    Avoiding the Thundering Herd

    +

    When a cached entry becomes stale, mod_cache will submit + a conditional request to the backend, which is expected to confirm whether the + cached entry is still fresh, and send an updated entity if not.

    +

    A small but finite amount of time exists between the time the cached entity + becomes stale, and the time the stale entity is fully refreshed. On a busy + server, a significant number of requests might arrive during this time, and + cause a thundering herd of requests to strike the backend + suddenly and unpredictably.

    +

    To keep the thundering herd at bay, the CacheLock + directive can be used to define a directory in which locks are created for + URLs in flight. The lock is used as a hint + by other requests to either suppress an attempt to cache (someone else has + gone to fetch the entity), or to indicate that a stale entry is being refreshed + (stale content will be returned in the mean time). +

    +

    Initial caching of an entry

    + +

    When an entity is cached for the first time, a lock will be created for the + entity until the response has been fully cached. During the lifetime of the + lock, the cache will suppress the second and subsequent attempt to cache the + same entity. While this doesn't hold back the thundering herd, it does stop + the cache attempting to cache the same entity multiple times simultaneously. +

    + +

    Refreshment of a stale entry

    + +

    When an entity reaches its freshness lifetime and becomes stale, a lock + will be created for the entity until the response has either been confirmed as + still fresh, or replaced by the backend. During the lifetime of the lock, the + second and subsequent incoming request will cause stale data to be returned, + and the thundering herd is kept at bay.

    + +

    Locks and Cache-Control: no-cache

    + +

    Locks are used as a hint only to enable the cache to be + more gentle on backend servers, however the lock can be overridden if necessary. + If the client sends a request with a Cache-Control header forcing a reload, any + lock that may be present will be ignored, and the client's request will be + honored immediately and the cached entry refreshed.

    +

    As a further safety mechanism, locks have a configurable maximum age. + Once this age has been reached, the lock is removed, and a new request is + given the opportunity to create a new lock. This maximum age can be set using + the CacheLockMaxAge directive, and defaults to 5 + seconds. +

    + +

    Example configuration

    + +

    Enabling the cache lock

    #
+# Enable the cache lock
+#
+<IfModule mod_cache.c>
+    CacheLock on
+    CacheLockPath "/tmp/mod_cache-lock"
+    CacheLockMaxAge 5
+</IfModule>
    +
    + +
    top
    +
    +

    Fine Control with the CACHE Filter

    +

    Under the default mode of cache operation, the cache runs as a quick handler, + short circuiting the majority of server processing and offering the highest + cache performance available.

    + +

    In this mode, the cache bolts onto the front of the server, + acting as if a free standing RFC 2616 caching proxy had been placed in front of + the server.

    + +

    While this mode offers the best performance, the administrator may find that + under certain circumstances they may want to perform further processing on the + request after the request is cached, such as to inject personalisation into the + cached page, or to apply authorisation restrictions to the content. Under these + circumstances, an administrator is often forced to place independent reverse + proxy servers either behind or in front of the caching server to achieve this.

    + +

    To solve this problem the CacheQuickHandler + directive can be set to off, and the server will + process all phases normally handled by a non-cached request, including the + authentication and authorisation phases.

    + +

    In addition, the administrator may optionally specify the precise point + within the filter chain where caching is to take place by adding the + CACHE filter to the output filter chain.

    + +

    For example, to cache content before applying compression to the response, + place the CACHE filter before the DEFLATE + filter as in the example below:

    + + 
    # Cache content before optional compression
+CacheQuickHandler off
+AddOutputFilterByType CACHE;DEFLATE text/plain
    + + +

    Another option is to have content cached before personalisation is applied + by mod_include (or another content processing filter). In this + example templates containing tags understood by + mod_include are cached before being parsed:

    + + 
    # Cache content before mod_include and mod_deflate
+CacheQuickHandler off
+AddOutputFilterByType CACHE;INCLUDES;DEFLATE text/html
    + + +

    You may place the CACHE filter anywhere you wish within the + filter chain. In this example, content is cached after being parsed by + mod_include, but before being processed by + mod_deflate:

    + + 
    # Cache content between mod_include and mod_deflate
+CacheQuickHandler off
+AddOutputFilterByType INCLUDES;CACHE;DEFLATE text/html
    + + +

    Warning:

    If the location of the + CACHE filter in the filter chain is changed for any reason, + you may need to flush your cache to ensure that your data + served remains consistent. mod_cache is not in a position + to enforce this for you.
    + +
    top
    +
    +

    Cache Status and Logging

    +

    Once mod_cache has made a decision as to whether or not + an entity is to be served from cache, the detailed reason for the decision + is written to the subprocess environment within the request under the + cache-status key. This reason can be logged by the + LogFormat directive as + follows:

    + + 
    LogFormat "%{cache-status}e ..."
    + + +

    Based on the caching decision made, the reason is also written to the + subprocess environment under one the following four keys, as appropriate:

    + +
    +
    cache-hit
    The response was served from cache.
    +
    cache-revalidate
    The response was stale and was successfully + revalidated, then served from cache.
    +
    cache-miss
    The response was served from the upstream server.
    +
    cache-invalidate
    The cached entity was invalidated by a request + method other than GET or HEAD.
    +
    + +

    This makes it possible to support conditional logging of cached requests + as per the following example:

    + + 
    CustomLog "cached-requests.log" common env=cache-hit
+CustomLog "uncached-requests.log" common env=cache-miss
+CustomLog "revalidated-requests.log" common env=cache-revalidate
+CustomLog "invalidated-requests.log" common env=cache-invalidate
    + + +

    For module authors, a hook called cache_status is available, + allowing modules to respond to the caching outcomes above in customised + ways.

    +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_cache.html.fr b/docs/manual/mod/mod_cache.html.fr index 106894687c1..7760f19a4c8 100644 --- a/docs/manual/mod/mod_cache.html.fr +++ b/docs/manual/mod/mod_cache.html.fr @@ -174,218 +174,6 @@ cache

    top
    -
    -

    Modules apparentés et directives

    -
    Modules ApparentésDirectives Apparentées
    -
    top
    -
    -

    Exemple de configuration

    -

    Extrait de httpd.conf

    #
-# Exemple de configuration du cache
-#
-LoadModule cache_module modules/mod_cache.so
-<IfModule mod_cache.c>
-    LoadModule cache_disk_module modules/mod_cache_disk.so
-    <IfModule mod_cache_disk.c>
-        CacheRoot c:/cacheroot
-        CacheEnable disk  /
-        CacheDirLevels 5
-        CacheDirLength 3
-    </IfModule>
-    
-    # Lorsqu'on sert de mandataire, on ne met pas en cache la liste
-# des mises à jour de sécurité
-    CacheDisable http://security.update.server/update-list/
-</IfModule>
    -
    -
    top
    -
    -

    Eviter une tempête de requête

    -

    Lorsqu'une entrée du cache est périmée, mod_cache - soumet une requête conditionnelle au processus d'arrière-plan, qui est - censé confirmer la validité de l'entrée du cache, ou dans la négative - envoyer une entrée mise à jour.

    -

    Un court mais non négligeable laps de temps existe entre le moment - où l'entrée du cache est périmée, et le moment où elle est mise à - jour. Sur un serveur fortement chargé, un certain nombre de requêtes - peut arriver pendant ce laps de temps, et provoquer une - tempête de requêtes susceptibles de saturer le - processus d'arrière-plan de manière soudaine et imprédictible.

    -

    Pour contenir cette tempête, on peut utiliser la directive - CacheLock afin de définir un répertoire où - seront créés à la volée des verrous pour les URLs. - Ces verrous sont utilisés comme autant d'indications - par les autres requêtes, soit pour empêcher une tentative de mise en - cache (un autre processus est en train de récupérer l'entité), soit - pour indiquer qu'une entrée périmée est en cours de mise à jour - (pendant ce temps, c'est le contenu périmé qui sera renvoyé). -

    -

    Mise en cache initiale d'une entrée

    - -

    Lorsqu'une entité est mise en cache pour la première fois, un - verrou est créé pour cette entité jusqu'à ce que la réponse ait été - entièrement mise en cache. Pendant la durée de vie du verrou, le - cache va empêcher une seconde tentative de mise en cache de la même - entité. Bien que cela ne suffise pas à contenir la tempête de - requêtes, toute tentative de mettre en cache la même entité - plusieurs fois simultanément est stoppée. -

    - -

    Mise à jour d'une entrée périmée

    - -

    Lorsqu'une entrée atteint la limite de sa durée de vie, et - devient par conséquent périmée, un verrou est créé pour cette entité - jusqu'à ce que la réponse ait été soit confirmée comme encore - valide, soit remplacée par le processus d'arrière-plan. Pendant la - durée de vie du verrou, une seconde requête entrante va provoquer le - renvoi de la donnée périmée, et la tempête de requêtes sera - contenue.

    - -

    Verrous et en-tête Cache-Control: no-cache

    - -

    Les verrous ne sont utilisés qu'à titre - indicatif pour enjoindre le cache à être plus coopératif - avec les serveurs d'arrière-plan, et il est possible de passer outre - si nécessaire. Si le client envoie une requête contenant un en-tête - Cache-Control imposant un nouveau téléchargement de l'entité, tout - verrou éventuel sera ignoré, la requête du client sera honorée - immédiatement, et l'entrée du cache mise à jour.

    - -

    Comme mécanisme de sécurité supplémentaire, la durée de vie - maximale des verrous est configurable. Lorsque cette limite est - atteinte, le verrou est supprimé et une autre requête peut alors en - créer un nouveau. Cette durée de vie peut être définie via la - directive CacheLockMaxAge, et sa valeur par - défaut est de 5 secondes. -

    - -

    Exemple de configuration

    - -

    Activation du verrouillage du cache

    #
-# Active le verrouillage du cache
-#
-<IfModule mod_cache.c>
-    CacheLock on
-    CacheLockPath /tmp/mod_cache-lock
-    CacheLockMaxAge 5
-</IfModule>
    -
    - -
    top
    -
    -

    Contrôle fin via le filtre CACHE

    -

    Dans son mode de fonctionnement par défaut, le cache s'exécute sous - la forme d'un gestionnaire rapide, court-circuitant la majorité des - traitements du serveur et fournissant ainsi une mise en cache - possédant les plus hautes performances disponibles.

    - -

    Dans ce mode, le cache s'incruste devant le - serveur, comme si un mandataire de mise en cache indépendant RFC 2616 - était placé devant ce dernier.

    - -

    Bien que que ce mode offre les meilleures performances, les - administrateurs peuvent souhaiter, dans certaines circonstances, - effectuer des traitements sur la requête après que cette dernière ait - été mise en cache, comme ajouter du contenu personnalisé à la page - mise en cache, ou appliquer des restrictions d'autorisations au - contenu. Pour y parvenir, l'administrateur sera alors souvent forcé de - placer des serveurs mandataires inverses indépendants soit derrière, - soit devant le serveur de mise en cache.

    - -

    Pour résoudre ce problème, la directive CacheQuickHandler peut être définie à - off, afin que le serveur traite toutes les phases - normalement exécutées par une requête non mise en cache, y compris les - phases d'authentification et d'autorisation.

    - -

    En outre, l'administrateur peut éventuellement spécifier le - point précis dans la chaîne de filtrage où devra - intervenir la mise en cache en ajoutant le filtre - CACHE à la chaîne de filtrage en sortie.

    - -

    Par exemple, pour mettre en cache le contenu avant d'appliquer une - compression à la réponse, placez le filtre CACHE - avant le filtre DEFLATE comme dans l'exemple suivant - :

    - - 
    # Mise en cache du contenu avant la compression optionnelle
-CacheQuickHandler off
-AddOutputFilterByType CACHE;DEFLATE text/plain
    - - -

    Une autre possibilité consiste à mettre en cache le contenu avant - l'ajout de contenu personnalisé via mod_include (ou - tout autre filtre de traitement de contenu). Dans l'exemple suivant, - les modèles contenant des balises comprises par - mod_include sont mis en cache avant d'être - interprétés :

    - - 
    # Mise en cache du contenu avant l'intervention de mod_include et
-   # mod_deflate
-CacheQuickHandler off
-AddOutputFilterByType CACHE;INCLUDES;DEFLATE text/html
    - - -

    Vous pouvez insérer le filtre CACHE en tout point - de la chaîne de filtrage. Dans l'exemple suivant, le contenu est mis - en cache après avoir été interprété par mod_include, - mais avant d'être traité par mod_deflate :

    - - 
    # Mise en cache du contenu entre les interventions de mod_include et
-   # mod_deflate
-CacheQuickHandler off
-AddOutputFilterByType INCLUDES;CACHE;DEFLATE text/html
    - - -

    Avertissement :

    Si pour une raison - ou pour une autre, le point d'insertion du filtre - CACHE dans la chaîne de filtrage est modifié, vous - devez vider votre cache pour être sûr que les données - servies soient à jour. En effet, mod_cache n'est pas - en mesure d'effectuer cette opération à votre place.
    - -
    top
    -
    -

    Etat du cache et journalisation

    -

    Lorsque mod_cache a décidé s'il devait ou non - servir une entité depuis le cache, les raisons précises de cette - décision sont enregistrées dans l'environnement du sous-processus - interne à la requête sous la clé cache-status. - Cette information peut être journalisée via la directive LogFormat comme suit :

    - - 
    LogFormat "%{cache-status}e ..."
    - - -

    En fonction de la décision prise, l'information est aussi écrite - dans l'environnement du sous-processus sous une des quatre clés - suivantes :

    - -
    -
    cache-hit
    Le contenu a été servi depuis le cache.
    -
    cache-revalidate
    Le contenu du cache était périmé, a été - mis à jour avec succès, puis servi depuis le cache.
    -
    cache-miss
    Le contenu n'était pas dans le cache et a été - servi directement depuis le serveur demandé.
    -
    cache-invalidate
    L'entité du cache est devenue invalide - suite à une requête d'un type autre que GET ou HEAD.
    -
    - -

    Il est alors possible d'envisager une journalisation conditionnelle - du traitement des requêtes par rapport au cache comme dans l'exemple - suivant :

    - - 
    CustomLog cached-requests.log common env=cache-hit
-CustomLog uncached-requests.log common env=cache-miss
-CustomLog revalidated-requests.log common env=cache-revalidate
-CustomLog invalidated-requests.log common env=cache-invalidate
    - - -

    Pour les concepteurs de modules, une accroche (hook) nommée - cache_status est disponible et permet aux modules de - répondre aux résultats de la vérification du cache ci-dessus de manière - personnalisée.

    - -
    -
    top

    Directive CacheDefaultExpire

  • Alternate Interval Syntax
    • top
    -
    -

    Alternate Interval Syntax

    -

    The ExpiresDefault and - ExpiresByType directives - can also be defined in a more readable syntax of the form:

    - - 
    ExpiresDefault "base  [plus num type] [num type] ..."
-ExpiresByType type/encoding "base  [plus num type] [num type] ..."
    - - -

    where base is one of:

    - -
      -
    • access
      • - -
    • now (equivalent to - 'access')
      • - -
    • modification
      • -
    - -

    The plus keyword is optional. num - should be an integer value [acceptable to atoi()], - and type is one of:

    - -
      -
    • years
      • -
    • months
      • -
    • weeks
      • -
    • days
      • -
    • hours
      • -
    • minutes
      • -
    • seconds
      • -
    - -

    For example, any of the following directives can be used to - make documents expire 1 month after being accessed, by - default:

    - - 
    ExpiresDefault "access plus 1 month"
-ExpiresDefault "access plus 4 weeks"
-ExpiresDefault "access plus 30 days"
    - - -

    The expiry time can be fine-tuned by adding several - 'num type' clauses:

    - - 
    ExpiresByType text/html "access plus 1 month 15 days 2 hours"
-ExpiresByType image/gif "modification plus 5 hours 3 minutes"
    - - -

    Note that if you use a modification date based setting, the - Expires header will not be added to content - that does not come from a file on disk. This is due to the fact - that there is no modification time for such content.

    -
    -
    top

    ExpiresActive Directive

    Description:La durée par défaut de mise en cache d'un document @@ -1159,6 +947,218 @@ marqu
  • CacheIgnoreCacheControl
  • CacheStoreNoStore
    • + +
    top
    +
    +

    Modules apparentés et directives

    +
    Modules ApparentésDirectives Apparentées
    +
    top
    +
    +

    Exemple de configuration

    +

    Extrait de httpd.conf

    #
+# Exemple de configuration du cache
+#
+LoadModule cache_module modules/mod_cache.so
+<IfModule mod_cache.c>
+    LoadModule cache_disk_module modules/mod_cache_disk.so
+    <IfModule mod_cache_disk.c>
+        CacheRoot c:/cacheroot
+        CacheEnable disk  /
+        CacheDirLevels 5
+        CacheDirLength 3
+    </IfModule>
+    
+    # Lorsqu'on sert de mandataire, on ne met pas en cache la liste
+# des mises à jour de sécurité
+    CacheDisable http://security.update.server/update-list/
+</IfModule>
    +
    +
    top
    +
    +

    Eviter une tempête de requête

    +

    Lorsqu'une entrée du cache est périmée, mod_cache + soumet une requête conditionnelle au processus d'arrière-plan, qui est + censé confirmer la validité de l'entrée du cache, ou dans la négative + envoyer une entrée mise à jour.

    +

    Un court mais non négligeable laps de temps existe entre le moment + où l'entrée du cache est périmée, et le moment où elle est mise à + jour. Sur un serveur fortement chargé, un certain nombre de requêtes + peut arriver pendant ce laps de temps, et provoquer une + tempête de requêtes susceptibles de saturer le + processus d'arrière-plan de manière soudaine et imprédictible.

    +

    Pour contenir cette tempête, on peut utiliser la directive + CacheLock afin de définir un répertoire où + seront créés à la volée des verrous pour les URLs. + Ces verrous sont utilisés comme autant d'indications + par les autres requêtes, soit pour empêcher une tentative de mise en + cache (un autre processus est en train de récupérer l'entité), soit + pour indiquer qu'une entrée périmée est en cours de mise à jour + (pendant ce temps, c'est le contenu périmé qui sera renvoyé). +

    +

    Mise en cache initiale d'une entrée

    + +

    Lorsqu'une entité est mise en cache pour la première fois, un + verrou est créé pour cette entité jusqu'à ce que la réponse ait été + entièrement mise en cache. Pendant la durée de vie du verrou, le + cache va empêcher une seconde tentative de mise en cache de la même + entité. Bien que cela ne suffise pas à contenir la tempête de + requêtes, toute tentative de mettre en cache la même entité + plusieurs fois simultanément est stoppée. +

    + +

    Mise à jour d'une entrée périmée

    + +

    Lorsqu'une entrée atteint la limite de sa durée de vie, et + devient par conséquent périmée, un verrou est créé pour cette entité + jusqu'à ce que la réponse ait été soit confirmée comme encore + valide, soit remplacée par le processus d'arrière-plan. Pendant la + durée de vie du verrou, une seconde requête entrante va provoquer le + renvoi de la donnée périmée, et la tempête de requêtes sera + contenue.

    + +

    Verrous et en-tête Cache-Control: no-cache

    + +

    Les verrous ne sont utilisés qu'à titre + indicatif pour enjoindre le cache à être plus coopératif + avec les serveurs d'arrière-plan, et il est possible de passer outre + si nécessaire. Si le client envoie une requête contenant un en-tête + Cache-Control imposant un nouveau téléchargement de l'entité, tout + verrou éventuel sera ignoré, la requête du client sera honorée + immédiatement, et l'entrée du cache mise à jour.

    + +

    Comme mécanisme de sécurité supplémentaire, la durée de vie + maximale des verrous est configurable. Lorsque cette limite est + atteinte, le verrou est supprimé et une autre requête peut alors en + créer un nouveau. Cette durée de vie peut être définie via la + directive CacheLockMaxAge, et sa valeur par + défaut est de 5 secondes. +

    + +

    Exemple de configuration

    + +

    Activation du verrouillage du cache

    #
+# Active le verrouillage du cache
+#
+<IfModule mod_cache.c>
+    CacheLock on
+    CacheLockPath /tmp/mod_cache-lock
+    CacheLockMaxAge 5
+</IfModule>
    +
    + +
    top
    +
    +

    Contrôle fin via le filtre CACHE

    +

    Dans son mode de fonctionnement par défaut, le cache s'exécute sous + la forme d'un gestionnaire rapide, court-circuitant la majorité des + traitements du serveur et fournissant ainsi une mise en cache + possédant les plus hautes performances disponibles.

    + +

    Dans ce mode, le cache s'incruste devant le + serveur, comme si un mandataire de mise en cache indépendant RFC 2616 + était placé devant ce dernier.

    + +

    Bien que que ce mode offre les meilleures performances, les + administrateurs peuvent souhaiter, dans certaines circonstances, + effectuer des traitements sur la requête après que cette dernière ait + été mise en cache, comme ajouter du contenu personnalisé à la page + mise en cache, ou appliquer des restrictions d'autorisations au + contenu. Pour y parvenir, l'administrateur sera alors souvent forcé de + placer des serveurs mandataires inverses indépendants soit derrière, + soit devant le serveur de mise en cache.

    + +

    Pour résoudre ce problème, la directive CacheQuickHandler peut être définie à + off, afin que le serveur traite toutes les phases + normalement exécutées par une requête non mise en cache, y compris les + phases d'authentification et d'autorisation.

    + +

    En outre, l'administrateur peut éventuellement spécifier le + point précis dans la chaîne de filtrage où devra + intervenir la mise en cache en ajoutant le filtre + CACHE à la chaîne de filtrage en sortie.

    + +

    Par exemple, pour mettre en cache le contenu avant d'appliquer une + compression à la réponse, placez le filtre CACHE + avant le filtre DEFLATE comme dans l'exemple suivant + :

    + + 
    # Mise en cache du contenu avant la compression optionnelle
+CacheQuickHandler off
+AddOutputFilterByType CACHE;DEFLATE text/plain
    + + +

    Une autre possibilité consiste à mettre en cache le contenu avant + l'ajout de contenu personnalisé via mod_include (ou + tout autre filtre de traitement de contenu). Dans l'exemple suivant, + les modèles contenant des balises comprises par + mod_include sont mis en cache avant d'être + interprétés :

    + + 
    # Mise en cache du contenu avant l'intervention de mod_include et
+   # mod_deflate
+CacheQuickHandler off
+AddOutputFilterByType CACHE;INCLUDES;DEFLATE text/html
    + + +

    Vous pouvez insérer le filtre CACHE en tout point + de la chaîne de filtrage. Dans l'exemple suivant, le contenu est mis + en cache après avoir été interprété par mod_include, + mais avant d'être traité par mod_deflate :

    + + 
    # Mise en cache du contenu entre les interventions de mod_include et
+   # mod_deflate
+CacheQuickHandler off
+AddOutputFilterByType INCLUDES;CACHE;DEFLATE text/html
    + + +

    Avertissement :

    Si pour une raison + ou pour une autre, le point d'insertion du filtre + CACHE dans la chaîne de filtrage est modifié, vous + devez vider votre cache pour être sûr que les données + servies soient à jour. En effet, mod_cache n'est pas + en mesure d'effectuer cette opération à votre place.
    + +
    top
    +
    +

    Etat du cache et journalisation

    +

    Lorsque mod_cache a décidé s'il devait ou non + servir une entité depuis le cache, les raisons précises de cette + décision sont enregistrées dans l'environnement du sous-processus + interne à la requête sous la clé cache-status. + Cette information peut être journalisée via la directive LogFormat comme suit :

    + + 
    LogFormat "%{cache-status}e ..."
    + + +

    En fonction de la décision prise, l'information est aussi écrite + dans l'environnement du sous-processus sous une des quatre clés + suivantes :

    + +
    +
    cache-hit
    Le contenu a été servi depuis le cache.
    +
    cache-revalidate
    Le contenu du cache était périmé, a été + mis à jour avec succès, puis servi depuis le cache.
    +
    cache-miss
    Le contenu n'était pas dans le cache et a été + servi directement depuis le serveur demandé.
    +
    cache-invalidate
    L'entité du cache est devenue invalide + suite à une requête d'un type autre que GET ou HEAD.
    +
    + +

    Il est alors possible d'envisager une journalisation conditionnelle + du traitement des requêtes par rapport au cache comme dans l'exemple + suivant :

    + + 
    CustomLog cached-requests.log common env=cache-hit
+CustomLog uncached-requests.log common env=cache-miss
+CustomLog revalidated-requests.log common env=cache-revalidate
+CustomLog invalidated-requests.log common env=cache-invalidate
    + + +

    Pour les concepteurs de modules, une accroche (hook) nommée + cache_status est disponible et permet aux modules de + répondre aux résultats de la vérification du cache ci-dessus de manière + personnalisée.

    +
    diff --git a/docs/manual/mod/mod_cache.html.ja.utf8 b/docs/manual/mod/mod_cache.html.ja.utf8 index 42c2ae8139c..3338ee183a6 100644 --- a/docs/manual/mod/mod_cache.html.ja.utf8 +++ b/docs/manual/mod/mod_cache.html.ja.utf8 @@ -105,50 +105,6 @@
  • キャッシュ機能
    • top
    -
    -

    関連モジュールとディレクティブ

    -
    関連モジュール関連ディレクティブ
    -
    top
    -
    -

    サンプル設定

    -

    Sample httpd.conf

    - #
    - # Sample Cache Configuration
    - #
    - LoadModule cache_module modules/mod_cache.so
    -
    - <IfModule mod_cache.c>
    - - #LoadModule cache_disk_module modules/mod_cache_disk.so
    - # If you want to use mod_cache_disk instead of mod_mem_cache,
    - # uncomment the line above and comment out the LoadModule line below.
    - <IfModule mod_cache_disk.c>
    - - CacheRoot c:/cacheroot
    - CacheEnable disk /
    - CacheDirLevels 5
    - CacheDirLength 3
    -     - </IfModule>
    -
    - LoadModule mem_cache_module modules/mod_mem_cache.so
    - <IfModule mod_mem_cache.c>
    - - CacheEnable mem /
    - MCacheSize 4096
    - MCacheMaxObjectCount 100
    - MCacheMinObjectSize 1
    - MCacheMaxObjectSize 2048
    -     - </IfModule>
    -
    - # When acting as a proxy, don't cache the list of security updates
    - CacheDisable http://security.update.server/update-list/
    -     - </IfModule> -

    -
    -
    top

    CacheDefaultExpire ディレクティブ

    @@ -646,6 +602,50 @@
  • CacheStoreNoStore
    • +
    top
    +
    +

    関連モジュールとディレクティブ

    +
    説明:期日が指定されていないときにドキュメントをキャッシュするデフォルトの期間
    関連モジュール関連ディレクティブ
    +
    top
    +
    +

    サンプル設定

    +

    Sample httpd.conf

    + #
    + # Sample Cache Configuration
    + #
    + LoadModule cache_module modules/mod_cache.so
    +
    + <IfModule mod_cache.c>
    + + #LoadModule cache_disk_module modules/mod_cache_disk.so
    + # If you want to use mod_cache_disk instead of mod_mem_cache,
    + # uncomment the line above and comment out the LoadModule line below.
    + <IfModule mod_cache_disk.c>
    + + CacheRoot c:/cacheroot
    + CacheEnable disk /
    + CacheDirLevels 5
    + CacheDirLength 3
    +     + </IfModule>
    +
    + LoadModule mem_cache_module modules/mod_mem_cache.so
    + <IfModule mod_mem_cache.c>
    + + CacheEnable mem /
    + MCacheSize 4096
    + MCacheMaxObjectCount 100
    + MCacheMinObjectSize 1
    + MCacheMaxObjectSize 2048
    +     + </IfModule>
    +
    + # When acting as a proxy, don't cache the list of security updates
    + CacheDisable http://security.update.server/update-list/
    +     + </IfModule> +

    +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_cache.html.ko.euc-kr b/docs/manual/mod/mod_cache.html.ko.euc-kr index 3c557de164e..99d77ddea3b 100644 --- a/docs/manual/mod/mod_cache.html.ko.euc-kr +++ b/docs/manual/mod/mod_cache.html.ko.euc-kr @@ -95,46 +95,6 @@

  • ¼³Á¤¿¹
    • top
    -
    -

    °ü·ÃµÈ ¸ðµâ°ú Áö½Ã¾î

    -
    °ü·ÃµÈ ¸ðµâ°ü·ÃµÈ Áö½Ã¾î
    -
    top
    -
    -

    ¼³Á¤¿¹

    -

    Sample httpd.conf

    - #
    - # ¿¹Á¦ ij½¬ ¼³Á¤
    - #
    - LoadModule cache_module modules/mod_cache.so
    -
    - <IfModule mod_cache.c>
    - - #LoadModule cache_disk_module modules/mod_cache_disk.so
    - <IfModule mod_cache_disk.c>
    - - CacheRoot c:/cacheroot
    - CacheSize 256
    - CacheEnable disk /
    - CacheDirLevels 5
    - CacheDirLength 3
    -     - </IfModule>
    -
    - LoadModule mem_cache_module modules/mod_mem_cache.so
    - <IfModule mod_mem_cache.c>
    - - CacheEnable mem /
    - MCacheSize 4096
    - MCacheMaxObjectCount 100
    - MCacheMinObjectSize 1
    - MCacheMaxObjectSize 2048
    -     - </IfModule>
    -     - </IfModule> -

    -
    -
    top

    CacheDefaultExpire Áö½Ã¾î

    @@ -495,6 +455,46 @@
    ¼³¸í:¸¸±â½Ã°£À» ÁöÁ¤ÇÏÁö¾ÊÀº ¹®¼­¸¦ ij½¬ÇÒ ±âº» ±â°£.
    ¸ðµâ:mod_cache

    Documentation not yet translated. Please see English version of document.

    +
    top
    +
    +

    °ü·ÃµÈ ¸ðµâ°ú Áö½Ã¾î

    +
    °ü·ÃµÈ ¸ðµâ°ü·ÃµÈ Áö½Ã¾î
    +
    top
    +
    +

    ¼³Á¤¿¹

    +

    Sample httpd.conf

    + #
    + # ¿¹Á¦ ij½¬ ¼³Á¤
    + #
    + LoadModule cache_module modules/mod_cache.so
    +
    + <IfModule mod_cache.c>
    + + #LoadModule cache_disk_module modules/mod_cache_disk.so
    + <IfModule mod_cache_disk.c>
    + + CacheRoot c:/cacheroot
    + CacheSize 256
    + CacheEnable disk /
    + CacheDirLevels 5
    + CacheDirLength 3
    +     + </IfModule>
    +
    + LoadModule mem_cache_module modules/mod_mem_cache.so
    + <IfModule mod_mem_cache.c>
    + + CacheEnable mem /
    + MCacheSize 4096
    + MCacheMaxObjectCount 100
    + MCacheMinObjectSize 1
    + MCacheMaxObjectSize 2048
    +     + </IfModule>
    +     + </IfModule> +

    +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_cache_disk.html.en b/docs/manual/mod/mod_cache_disk.html.en index f5741bdf18d..1c9d640ee94 100644 --- a/docs/manual/mod/mod_cache_disk.html.en +++ b/docs/manual/mod/mod_cache_disk.html.en @@ -88,7 +88,6 @@

  • mod_cache_socache
  • Caching Guide
    • -
    top

    CacheDirLength Directive

    @@ -257,6 +256,7 @@ stored +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_cache_disk.html.fr b/docs/manual/mod/mod_cache_disk.html.fr index 3dbd9d71101..e9de7ee2b72 100644 --- a/docs/manual/mod/mod_cache_disk.html.fr +++ b/docs/manual/mod/mod_cache_disk.html.fr @@ -92,7 +92,6 @@ cache HTTP.

  • mod_cache_socache
  • Guide de la mise en cache
    • -
    top

    Directive CacheDirLength

    @@ -275,6 +274,7 @@ seront stock +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_cache_disk.html.ja.utf8 b/docs/manual/mod/mod_cache_disk.html.ja.utf8 index d3b934db84f..330ccdedded 100644 --- a/docs/manual/mod/mod_cache_disk.html.ja.utf8 +++ b/docs/manual/mod/mod_cache_disk.html.ja.utf8 @@ -65,7 +65,6 @@

  • CacheRoot
    • -
    top

    CacheDirLength ディレクティブ

    @@ -197,6 +196,7 @@

    +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_cache_disk.html.ko.euc-kr b/docs/manual/mod/mod_cache_disk.html.ko.euc-kr index 1288ec29495..11eac3a2929 100644 --- a/docs/manual/mod/mod_cache_disk.html.ko.euc-kr +++ b/docs/manual/mod/mod_cache_disk.html.ko.euc-kr @@ -64,7 +64,6 @@

  • CacheRoot
    • -
    top

    CacheDirLength Áö½Ã¾î

    @@ -191,6 +190,7 @@

    +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_cache_socache.html.en b/docs/manual/mod/mod_cache_socache.html.en index e4840e36ee0..f9a39416983 100644 --- a/docs/manual/mod/mod_cache_socache.html.en +++ b/docs/manual/mod/mod_cache_socache.html.en @@ -83,7 +83,6 @@ CacheSocacheMaxSize 102400

  • mod_cache_disk
  • Caching Guide
    • -
    top

    CacheSocache Directive

    @@ -233,6 +232,7 @@ cache +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_cache_socache.html.fr b/docs/manual/mod/mod_cache_socache.html.fr index 501ccf70be5..68177ebaa2c 100644 --- a/docs/manual/mod/mod_cache_socache.html.fr +++ b/docs/manual/mod/mod_cache_socache.html.fr @@ -84,7 +84,6 @@ CacheSocacheMaxSize 102400

  • mod_cache_disk
  • Guide de la mise en cache
    • -
    top

    Directive CacheSocache

    @@ -246,6 +245,7 @@ Apache +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_cern_meta.html.en b/docs/manual/mod/mod_cern_meta.html.en index 255ac6322e9..779c61e7f67 100644 --- a/docs/manual/mod/mod_cern_meta.html.en +++ b/docs/manual/mod/mod_cern_meta.html.en @@ -56,7 +56,6 @@

  • mod_headers
  • mod_asis
    • -
    top

    MetaDir Directive

    @@ -123,6 +122,7 @@ meta information +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_cern_meta.html.fr b/docs/manual/mod/mod_cern_meta.html.fr index fedaebb27c3..1aea5c6d177 100644 --- a/docs/manual/mod/mod_cern_meta.html.fr +++ b/docs/manual/mod/mod_cern_meta.html.fr @@ -58,7 +58,6 @@ CERN

  • mod_headers
  • mod_asis
    • -
    top

    Directive MetaDir

    @@ -128,6 +127,7 @@ style du CERN +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_cern_meta.html.ko.euc-kr b/docs/manual/mod/mod_cern_meta.html.ko.euc-kr index 15ac58049c9..feb49a1ce3b 100644 --- a/docs/manual/mod/mod_cern_meta.html.ko.euc-kr +++ b/docs/manual/mod/mod_cern_meta.html.ko.euc-kr @@ -56,7 +56,6 @@

  • mod_headers
  • mod_asis
    • -
    top

    MetaDir Áö½Ã¾î

    @@ -116,6 +115,7 @@

    +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_cgi.html.en b/docs/manual/mod/mod_cgi.html.en index 10f8548cf59..b7e88eec750 100644 --- a/docs/manual/mod/mod_cgi.html.en +++ b/docs/manual/mod/mod_cgi.html.en @@ -78,6 +78,78 @@

  • CGI Specification
    • top
    +

    ScriptLog Directive

    +
    + + + + + +
    Description:Location of the CGI script error logfile
    Syntax:ScriptLog file-path
    Context:server config, virtual host
    Status:Base
    Module:mod_cgi, mod_cgid
    +

    The ScriptLog directive sets the CGI + script error logfile. If no ScriptLog is given, + no error log is created. If given, any CGI errors are logged into the + filename given as argument. If this is a relative file or path it is + taken relative to the ServerRoot. +

    + +

    Example

    ScriptLog logs/cgi_log
    +
    + +

    This log will be opened as the user the child processes run + as, i.e. the user specified in the main User directive. This means that + either the directory the script log is in needs to be writable + by that user or the file needs to be manually created and set + to be writable by that user. If you place the script log in + your main logs directory, do NOT change the + directory permissions to make it writable by the user the child + processes run as.

    + +

    Note that script logging is meant to be a debugging feature + when writing CGI scripts, and is not meant to be activated + continuously on running servers. It is not optimized for speed + or efficiency, and may have security problems if used in a + manner other than that for which it was designed.

    + +
    +
    top
    +

    ScriptLogBuffer Directive

    + + + + + + + +
    Description:Maximum amount of PUT or POST requests that will be recorded +in the scriptlog
    Syntax:ScriptLogBuffer bytes
    Default:ScriptLogBuffer 1024
    Context:server config, virtual host
    Status:Base
    Module:mod_cgi, mod_cgid
    +

    The size of any PUT or POST entity body that is logged to + the file is limited, to prevent the log file growing too big + too quickly if large bodies are being received. By default, up + to 1024 bytes are logged, but this can be changed with this + directive.

    + +
    +
    top
    +

    ScriptLogLength Directive

    + + + + + + + +
    Description:Size limit of the CGI script logfile
    Syntax:ScriptLogLength bytes
    Default:ScriptLogLength 10385760
    Context:server config, virtual host
    Status:Base
    Module:mod_cgi, mod_cgid
    +

    ScriptLogLength can be used to limit the + size of the CGI script logfile. Since the logfile logs a lot of + information per CGI error (all request headers, all script output) + it can grow to be a big file. To prevent problems due to unbounded + growth, this directive can be used to set an maximum file-size for + the CGI logfile. If the file exceeds this size, no more + information will be written to it.

    + +
    +
    top

    CGI Environment variables

    The server will set the CGI environment variables as described @@ -161,78 +233,6 @@

    (The %stdout and %stderr parts may be missing if the script did not output anything on standard output or standard error).

    -
    -
    top
    -

    ScriptLog Directive

    - - - - - - -
    Description:Location of the CGI script error logfile
    Syntax:ScriptLog file-path
    Context:server config, virtual host
    Status:Base
    Module:mod_cgi, mod_cgid
    -

    The ScriptLog directive sets the CGI - script error logfile. If no ScriptLog is given, - no error log is created. If given, any CGI errors are logged into the - filename given as argument. If this is a relative file or path it is - taken relative to the ServerRoot. -

    - -

    Example

    ScriptLog logs/cgi_log
    -
    - -

    This log will be opened as the user the child processes run - as, i.e. the user specified in the main User directive. This means that - either the directory the script log is in needs to be writable - by that user or the file needs to be manually created and set - to be writable by that user. If you place the script log in - your main logs directory, do NOT change the - directory permissions to make it writable by the user the child - processes run as.

    - -

    Note that script logging is meant to be a debugging feature - when writing CGI scripts, and is not meant to be activated - continuously on running servers. It is not optimized for speed - or efficiency, and may have security problems if used in a - manner other than that for which it was designed.

    - -
    -
    top
    -

    ScriptLogBuffer Directive

    - - - - - - - -
    Description:Maximum amount of PUT or POST requests that will be recorded -in the scriptlog
    Syntax:ScriptLogBuffer bytes
    Default:ScriptLogBuffer 1024
    Context:server config, virtual host
    Status:Base
    Module:mod_cgi, mod_cgid
    -

    The size of any PUT or POST entity body that is logged to - the file is limited, to prevent the log file growing too big - too quickly if large bodies are being received. By default, up - to 1024 bytes are logged, but this can be changed with this - directive.

    - -
    -
    top
    -

    ScriptLogLength Directive

    - - - - - - - -
    Description:Size limit of the CGI script logfile
    Syntax:ScriptLogLength bytes
    Default:ScriptLogLength 10385760
    Context:server config, virtual host
    Status:Base
    Module:mod_cgi, mod_cgid
    -

    ScriptLogLength can be used to limit the - size of the CGI script logfile. Since the logfile logs a lot of - information per CGI error (all request headers, all script output) - it can grow to be a big file. To prevent problems due to unbounded - growth, this directive can be used to set an maximum file-size for - the CGI logfile. If the file exceeds this size, no more - information will be written to it.

    -
    diff --git a/docs/manual/mod/mod_cgi.html.fr b/docs/manual/mod/mod_cgi.html.fr index af193e82265..8fbeb925f99 100644 --- a/docs/manual/mod/mod_cgi.html.fr +++ b/docs/manual/mod/mod_cgi.html.fr @@ -78,6 +78,88 @@ utilisateurs diff CGI
    top
    +

    Directive ScriptLog

    + + + + + + +
    Description:Chemin du fichier journal des erreurs du script +CGI
    Syntaxe:ScriptLog chemin fichier
    Contexte:configuration du serveur, serveur virtuel
    Statut:Base
    Module:mod_cgi, mod_cgid
    +

    La directive ScriptLog permet de définir + le chemin du fichier journal des erreurs du script CGI. Si cette + directive n'est pas définie, aucune journalisation des erreurs n'est + effectuée. Si elle est définie, toute erreur CGI sera enregistrée + dans le fichier dont le nom est fourni en argument. S'il s'agit d'un + chemin de fichier relatif, il est considéré par rapport au + répertoire défini par la directive ServerRoot. +

    + +

    Exemple

    ScriptLog logs/cgi_log
    +
    + +

    Ce journal sera ouvert par l'utilisateur sous lequel les + processus enfants s'exécutent, c'est à dire l'utilisateur spécifié + par la directive du serveur User. Ceci implique que le + répertoire dans lequel se trouve le journal doit être accessible en + écriture pour cet utilisateur, ou bien que le fichier est créé + manuellement et accessible en écriture pour cet utilisateur. Si vous + placez le journal du script dans votre répertoire principal des + journaux, ne modifiez JAMAIS les permissions de ce + dernier afin de le le rendre accessible en écriture par + l'utilisateur sous lequel les processus enfants s'exécutent.

    + +

    Notez que l'on ne doit activer la journalisation des scripts + qu'à des fins de débogage lors de l'écriture de scripts CGI, et non + de manière permanente sur un serveur en production. Elle n'est pas + optimisée en terme de performances et d'efficacité, et peut + présenter des problèmes de sécurité si on l'utilise dans un cadre + autre que celui pour lequel elle a été conçue.

    + +
    +
    top
    +

    Directive ScriptLogBuffer

    + + + + + + + +
    Description:Taille maximale des requêtes PUT ou POST qui seront +enregistrées dans le journal du script
    Syntaxe:ScriptLogBuffer octets
    Défaut:ScriptLogBuffer 1024
    Contexte:configuration du serveur, serveur virtuel
    Statut:Base
    Module:mod_cgi, mod_cgid
    +

    Cette directive permet de limiter la taille du corps de toute + entité PUT ou POST qui sera enregistrée dans le journal, afin + de prévenir une croissance trop importante et trop rapide du fichier + journal due à la réception de corps de requête de grandes tailles. + Cette directive permet de modifier cette taille maximale, dont la + valeur par défaut est de 1024 octets.

    + +
    +
    top
    +

    Directive ScriptLogLength

    + + + + + + + +
    Description:Taille maximale du fichier journal des scripts +CGI
    Syntaxe:ScriptLogLength octets
    Défaut:ScriptLogLength 10385760
    Contexte:configuration du serveur, serveur virtuel
    Statut:Base
    Module:mod_cgi, mod_cgid
    +

    La directive ScriptLogLength permet de + définir la taille maximale du fichier journal des scripts CGI. Comme + le fichier journal accumule une grande quantité d'informations par + erreur CGI (tous les en-têtes de la requête, toutes les sorties du + script), il peut vite atteindre une grande taille. En limitant la + taille du fichier, cette directive permet d'éviter les problèmes que + causerait sa croissance sans limites. Lorsque le fichier a atteint + cette taille maximale, plus aucune information n'y est + enregistrée.

    + +
    +
    top

    Les variables d'environnement CGI

    Le serveur va définir les variables d'environnement CGI comme @@ -170,88 +252,6 @@ CGI n'a rien envoyé sur la sortie standard ou la sortie d'erreurs).

    -
    -
    top
    -

    Directive ScriptLog

    - - - - - - -
    Description:Chemin du fichier journal des erreurs du script -CGI
    Syntaxe:ScriptLog chemin fichier
    Contexte:configuration du serveur, serveur virtuel
    Statut:Base
    Module:mod_cgi, mod_cgid
    -

    La directive ScriptLog permet de définir - le chemin du fichier journal des erreurs du script CGI. Si cette - directive n'est pas définie, aucune journalisation des erreurs n'est - effectuée. Si elle est définie, toute erreur CGI sera enregistrée - dans le fichier dont le nom est fourni en argument. S'il s'agit d'un - chemin de fichier relatif, il est considéré par rapport au - répertoire défini par la directive ServerRoot. -

    - -

    Exemple

    ScriptLog logs/cgi_log
    -
    - -

    Ce journal sera ouvert par l'utilisateur sous lequel les - processus enfants s'exécutent, c'est à dire l'utilisateur spécifié - par la directive du serveur User. Ceci implique que le - répertoire dans lequel se trouve le journal doit être accessible en - écriture pour cet utilisateur, ou bien que le fichier est créé - manuellement et accessible en écriture pour cet utilisateur. Si vous - placez le journal du script dans votre répertoire principal des - journaux, ne modifiez JAMAIS les permissions de ce - dernier afin de le le rendre accessible en écriture par - l'utilisateur sous lequel les processus enfants s'exécutent.

    - -

    Notez que l'on ne doit activer la journalisation des scripts - qu'à des fins de débogage lors de l'écriture de scripts CGI, et non - de manière permanente sur un serveur en production. Elle n'est pas - optimisée en terme de performances et d'efficacité, et peut - présenter des problèmes de sécurité si on l'utilise dans un cadre - autre que celui pour lequel elle a été conçue.

    - -
    -
    top
    -

    Directive ScriptLogBuffer

    - - - - - - - -
    Description:Taille maximale des requêtes PUT ou POST qui seront -enregistrées dans le journal du script
    Syntaxe:ScriptLogBuffer octets
    Défaut:ScriptLogBuffer 1024
    Contexte:configuration du serveur, serveur virtuel
    Statut:Base
    Module:mod_cgi, mod_cgid
    -

    Cette directive permet de limiter la taille du corps de toute - entité PUT ou POST qui sera enregistrée dans le journal, afin - de prévenir une croissance trop importante et trop rapide du fichier - journal due à la réception de corps de requête de grandes tailles. - Cette directive permet de modifier cette taille maximale, dont la - valeur par défaut est de 1024 octets.

    - -
    -
    top
    -

    Directive ScriptLogLength

    - - - - - - - -
    Description:Taille maximale du fichier journal des scripts -CGI
    Syntaxe:ScriptLogLength octets
    Défaut:ScriptLogLength 10385760
    Contexte:configuration du serveur, serveur virtuel
    Statut:Base
    Module:mod_cgi, mod_cgid
    -

    La directive ScriptLogLength permet de - définir la taille maximale du fichier journal des scripts CGI. Comme - le fichier journal accumule une grande quantité d'informations par - erreur CGI (tous les en-têtes de la requête, toutes les sorties du - script), il peut vite atteindre une grande taille. En limitant la - taille du fichier, cette directive permet d'éviter les problèmes que - causerait sa croissance sans limites. Lorsque le fichier a atteint - cette taille maximale, plus aucune information n'y est - enregistrée.

    -
    diff --git a/docs/manual/mod/mod_cgi.html.ja.utf8 b/docs/manual/mod/mod_cgi.html.ja.utf8 index b5b26e07cc1..65b41c3b1b6 100644 --- a/docs/manual/mod/mod_cgi.html.ja.utf8 +++ b/docs/manual/mod/mod_cgi.html.ja.utf8 @@ -75,6 +75,81 @@
  • CGI 規格書
    • top
    +

    ScriptLog ディレクティブ

    + + + + + + +
    説明:CGI スクリプトのエラーログファイルの場所
    構文:ScriptLog file-path
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Base
    モジュール:mod_cgi, mod_cgid
    +

    ScriptLog ディレクティブは CGI スクリプトの + エラーログファイルを設定します。ScriptLog が + 設定されていないときは、 + エラーログは作成されません。設定されているときは、CGI + のエラーはすべて引数として与えられているファイル名にログされます。 + 相対パスで指定されているときは、 + ServerRootからの相対パスとして + 扱われます。

    + +

    例

    ScriptLog logs/cgi_log
    +
    + +

    このログは子プロセスが実行されているユーザとしてオープンされます。 + すなわち、User ディレクティブで指定された + ユーザです。これは、スクリプトログが書かれるディレクトリがそのユーザで + 書き込み可能か、スクリプトファイルが手動で作成され、そのユーザで + 書き込み可能になっている必要があるということです。スクリプトログを + アクセスログなどのためのログディレクトリに書かれるようにしたときは、 + そのディレクトリを子プロセスを実行しているユーザの権限で + 書き込み可能にはしないようにしてください。

    + +

    スクリプトのログ収集は CGI スクリプトを書くときの + デバッグ用の機能として意図されていて、通常のサーバで + 常に使用されるようには意図されていないということに注意してください。 + 速度や効率は最適化されておらず、設計された以外の方法で使用されると + セキュリティの問題があるかもしれません。

    + +
    +
    top
    +

    ScriptLogBuffer ディレクティブ

    + + + + + + + +
    説明:スクリプトログに記録される PUT や POST リクエストの内容の上限
    構文:ScriptLogBuffer bytes
    デフォルト:ScriptLogBuffer 1024
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Base
    モジュール:mod_cgi, mod_cgid
    +

    大きな本体を受け取ったときにログファイルがすぐに大きくなりすぎる + 問題を避けるために、ファイルにログ収集される PUT と POST + の本体の大きさは制限されています。デフォルトでは、1024 + バイトまでがログ収集されますが、 + このディレクティブはそれを変更することができます。 +

    + +
    +
    top
    +

    ScriptLogLength ディレクティブ

    + + + + + + + +
    説明:CGI スクリプトのログファイルの大きさの上限
    構文:ScriptLogLength bytes
    デフォルト:ScriptLogLength 10385760
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Base
    モジュール:mod_cgi, mod_cgid
    +

    ScriptLogLength は CGI スクリプトのログファイル + の大きさを制限するために使用することができます。ログファイルは + CGI のエラー毎に大量の情報 (リクエストのすべてのヘッダ、 + すべての出力)をログしますので、すぐに大きなファイルになります。 + この大きさの制限がないことによる問題を防ぐために、 + このディレクティブを使って CGI のログファイルの + 最大のファイルサイズを設定することができます。 + ファイルがこの大きさを超えた場合は、それ以上は書き込まれません。

    + +
    +
    top

    CGI 環境変数

    サーバは CGI @@ -164,81 +239,6 @@

    (スクリプトが標準出力や標準エラーに何も出力しなかった場合は、 %stdout や %stderr はありません)。

    -
    -
    top
    -

    ScriptLog ディレクティブ

    - - - - - - -
    説明:CGI スクリプトのエラーログファイルの場所
    構文:ScriptLog file-path
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Base
    モジュール:mod_cgi, mod_cgid
    -

    ScriptLog ディレクティブは CGI スクリプトの - エラーログファイルを設定します。ScriptLog が - 設定されていないときは、 - エラーログは作成されません。設定されているときは、CGI - のエラーはすべて引数として与えられているファイル名にログされます。 - 相対パスで指定されているときは、 - ServerRootからの相対パスとして - 扱われます。

    - -

    例

    ScriptLog logs/cgi_log
    -
    - -

    このログは子プロセスが実行されているユーザとしてオープンされます。 - すなわち、User ディレクティブで指定された - ユーザです。これは、スクリプトログが書かれるディレクトリがそのユーザで - 書き込み可能か、スクリプトファイルが手動で作成され、そのユーザで - 書き込み可能になっている必要があるということです。スクリプトログを - アクセスログなどのためのログディレクトリに書かれるようにしたときは、 - そのディレクトリを子プロセスを実行しているユーザの権限で - 書き込み可能にはしないようにしてください。

    - -

    スクリプトのログ収集は CGI スクリプトを書くときの - デバッグ用の機能として意図されていて、通常のサーバで - 常に使用されるようには意図されていないということに注意してください。 - 速度や効率は最適化されておらず、設計された以外の方法で使用されると - セキュリティの問題があるかもしれません。

    - -
    -
    top
    -

    ScriptLogBuffer ディレクティブ

    - - - - - - - -
    説明:スクリプトログに記録される PUT や POST リクエストの内容の上限
    構文:ScriptLogBuffer bytes
    デフォルト:ScriptLogBuffer 1024
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Base
    モジュール:mod_cgi, mod_cgid
    -

    大きな本体を受け取ったときにログファイルがすぐに大きくなりすぎる - 問題を避けるために、ファイルにログ収集される PUT と POST - の本体の大きさは制限されています。デフォルトでは、1024 - バイトまでがログ収集されますが、 - このディレクティブはそれを変更することができます。 -

    - -
    -
    top
    -

    ScriptLogLength ディレクティブ

    - - - - - - - -
    説明:CGI スクリプトのログファイルの大きさの上限
    構文:ScriptLogLength bytes
    デフォルト:ScriptLogLength 10385760
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Base
    モジュール:mod_cgi, mod_cgid
    -

    ScriptLogLength は CGI スクリプトのログファイル - の大きさを制限するために使用することができます。ログファイルは - CGI のエラー毎に大量の情報 (リクエストのすべてのヘッダ、 - すべての出力)をログしますので、すぐに大きなファイルになります。 - この大きさの制限がないことによる問題を防ぐために、 - このディレクティブを使って CGI のログファイルの - 最大のファイルサイズを設定することができます。 - ファイルがこの大きさを超えた場合は、それ以上は書き込まれません。

    -
    diff --git a/docs/manual/mod/mod_cgi.html.ko.euc-kr b/docs/manual/mod/mod_cgi.html.ko.euc-kr index f1283ef7b5c..a274ebfaadf 100644 --- a/docs/manual/mod/mod_cgi.html.ko.euc-kr +++ b/docs/manual/mod/mod_cgi.html.ko.euc-kr @@ -78,6 +78,75 @@
  • CGI Ç¥ÁØ
    • top
    +

    ScriptLog Áö½Ã¾î

    + + + + + + +
    ¼³¸í:CGI ½ºÅ©¸³Æ® ¿À·ù·Î±×ÆÄÀÏÀÇ À§Ä¡
    ¹®¹ý:ScriptLog file-path
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Base
    ¸ðµâ:mod_cgi, mod_cgid
    +

    ScriptLog Áö½Ã¾î´Â CGI ½ºÅ©¸³Æ® + ¿À·ù·Î±×ÆÄÀÏÀ» ÁöÁ¤ÇÑ´Ù. ScriptLog¸¦ + »ç¿ëÇÏÁö¾ÊÀ¸¸é ¿À·ù·Î±×¸¦ ¸¸µéÁö ¾Ê´Â´Ù. »ç¿ëÇÏ¸é ¾Æ±Ô¸ÕÆ®·Î + ÁöÁ¤ÇÑ ÆÄÀÏ¿¡ CGI ¿À·ù¸¦ ±â·ÏÇÑ´Ù. »ó´ë°æ·Î¸¦ ÁöÁ¤Çϸé + ServerRoot¿¡ »ó´ë°æ·Î·Î + ¹Þ¾ÆµéÀδÙ. +

    + +

    ¿¹Á¦

    + ScriptLog logs/cgi_log +

    + +

    ÀÚ½Ä ÇÁ·Î¼¼½º¸¦ ½ÇÇàÇÏ´Â »ç¿ëÀÚ, Áï User Áö½Ã¾î·Î ÁöÁ¤ÇÑ »ç¿ëÀÚ + ±ÇÇÑÀ¸·Î ·Î±×¸¦ ¿¬´Ù. ±×·¡¼­ ±× »ç¿ëÀÚ°¡ ½ºÅ©¸³Æ® ·Î±×°¡ + ÀÖ´Â µð·ºÅ丮¿¡ ¾²±â±ÇÇÑÀÌ ÀÖ´øÁö, Á÷Á¢ ¹Ì¸® ÆÄÀÏÀ» ¸¸µé¾î¼­ + ±× »ç¿ëÀÚ¿¡°Ô ¾²±â±ÇÇÑÀ» Áà¾ß ÇÑ´Ù. ½ºÅ©¸³Æ® ·Î±×¸¦ ÁÖ ·Î±× + µð·ºÅ丮¿¡ µÐ´Ù¸é ÀÚ½Ä ÇÁ·Î¼¼½º¸¦ ½ÇÇàÇÏ´Â »ç¿ëÀÚ¿¡°Ô ¾²±â±ÇÇÑÀ» + ÁÖ±âÀ§ÇØ µð·ºÅ丮 ±ÇÇÑÀ» º¯°æÇÏÁö ¸¶¶ó.

    + +

    ½ºÅ©¸³Æ® ·Î±×´Â CGI ½ºÅ©¸³Æ®¸¦ ÀÛ¼ºÇÒ¶§ µð¹ö±ëÀ» À§ÇÑ + ¿ëµµÀÌÁö ¼­¹ö¸¦ ½ÇÇàÇÏ´Â µ¿¾È °è¼Ó »ç¿ëÇϱâÀ§ÇÔÀÌ ¾Æ´ÔÀ» + ÁÖÀÇÇ϶ó. ¼Óµµ¿Í È¿À²¼º¸é¿¡¼­ ÃÖÀûÈ­°¡ ¾ÈµÇÀÖ°í, ¼³°èÇÑ + ¸ñÀûÀÌ¿ÜÀÇ ¹æ¹ýÀ¸·Î »ç¿ëÇÏ¸é º¸¾È»ó ¹®Á¦°¡ µÉ ¼ö ÀÖ´Ù.

    + +
    +
    top
    +

    ScriptLogBuffer Áö½Ã¾î

    + + + + + + + +
    ¼³¸í:½ºÅ©¸³Æ® ·Î±×¿¡ ±â·ÏÇÒ PUT ȤÀº POST ¿äûÀÇ ÃÖ´ë·®
    ¹®¹ý:ScriptLogBuffer bytes
    ±âº»°ª:ScriptLogBuffer 1024
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Base
    ¸ðµâ:mod_cgi, mod_cgid
    +

    Å« ³»¿ëÀ» ¹Þ¾Æ¼­ ·Î±×ÆÄÀÏÀÌ ³Ê¹« »¡¸® Ä¿Áö´Â Çö»óÀ» ¸·±âÀ§ÇØ + ÆÄÀÏ¿¡ ±â·ÏÇÒ PUT ȤÀº POST ³»¿ëÀÇ Å©±â¸¦ Á¦ÇÑÇÑ´Ù. ±âº»ÀûÀ¸·Î + 1024 ¹ÙÀÌÆ®±îÁö ·Î±×¿¡ ±â·ÏÇÏÁö¸¸, ÀÌ Áö½Ã¾î¸¦ »ç¿ëÇÏ¿© + ¼öÁ¤ÇÒ ¼ö ÀÖ´Ù.

    + +
    +
    top
    +

    ScriptLogLength Áö½Ã¾î

    + + + + + + + +
    ¼³¸í:CGI ½ºÅ©¸³Æ® ·Î±×ÆÄÀÏÀÇ Å©±â Á¦ÇÑ
    ¹®¹ý:ScriptLogLength bytes
    ±âº»°ª:ScriptLogLength 10385760
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Base
    ¸ðµâ:mod_cgi, mod_cgid
    +

    ScriptLogLength´Â CGI ½ºÅ©¸³Æ® + ·Î±×ÆÄÀÏÀÇ Å©±â¸¦ Á¦ÇÑÇÑ´Ù. CGI ¿À·ù°¡ ¹ß»ýÇÒ¶§¸¶´Ù (¸ðµç + ¿äû Çì´õ, ¸ðµç ½ºÅ©¸³Æ® Ãâ·Â µî) ¸¹Àº Á¤º¸°¡ ·Î±×¿¡ + ±â·ÏµÇ±â¶§¹®¿¡ ÆÄÀÏÀÌ ¸Å¿ì Ä¿Áú ¼ö ÀÖ´Ù. ÆÄÀÏÀÌ ¹«ÇÑÈ÷ Ä¿Áö´Â + ¹®Á¦¸¦ ¸·±âÀ§ÇØ ÀÌ Áö½Ã¾î¸¦ »ç¿ëÇÏ¿© CGI ·Î±×ÆÄÀÏÀÇ ÃÖ´ë + ÆÄÀÏÅ©±â¸¦ ¼³Á¤ÇÑ´Ù. ÆÄÀÏÀÇ Å©±â°¡ ¼³Á¤ÇÑ °ªÀ» ³ÑÀ¸¸é ´õ + ÀÌ»ó Á¤º¸¸¦ ±â·ÏÇÏÁö¾Ê´Â´Ù.

    + +
    +
    top

    CGI ȯ°æº¯¼ö

    ¼­¹ö´Â ´ÙÀ½°ú °°Àº ¹æ¹ýÀ¸·Î CGI Ç¥ÁØÀÌ ¼³¸íÇÏ´Â @@ -157,75 +226,6 @@

    (½ºÅ©¸³Æ®°¡ Ç¥ÁØÃâ·ÂÀ̳ª Ç¥ÁØ¿À·ù¿¡ ¾Æ¹« ³»¿ëµµ Ãâ·ÂÇÏÁö ¾Ê¾Ò´Ù¸é %stdout°ú %stderr ºÎºÐÀº »ý·«µÉ ¼ö ÀÖ´Ù).

    -
    -
    top
    -

    ScriptLog Áö½Ã¾î

    - - - - - - -
    ¼³¸í:CGI ½ºÅ©¸³Æ® ¿À·ù·Î±×ÆÄÀÏÀÇ À§Ä¡
    ¹®¹ý:ScriptLog file-path
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Base
    ¸ðµâ:mod_cgi, mod_cgid
    -

    ScriptLog Áö½Ã¾î´Â CGI ½ºÅ©¸³Æ® - ¿À·ù·Î±×ÆÄÀÏÀ» ÁöÁ¤ÇÑ´Ù. ScriptLog¸¦ - »ç¿ëÇÏÁö¾ÊÀ¸¸é ¿À·ù·Î±×¸¦ ¸¸µéÁö ¾Ê´Â´Ù. »ç¿ëÇÏ¸é ¾Æ±Ô¸ÕÆ®·Î - ÁöÁ¤ÇÑ ÆÄÀÏ¿¡ CGI ¿À·ù¸¦ ±â·ÏÇÑ´Ù. »ó´ë°æ·Î¸¦ ÁöÁ¤Çϸé - ServerRoot¿¡ »ó´ë°æ·Î·Î - ¹Þ¾ÆµéÀδÙ. -

    - -

    ¿¹Á¦

    - ScriptLog logs/cgi_log -

    - -

    ÀÚ½Ä ÇÁ·Î¼¼½º¸¦ ½ÇÇàÇÏ´Â »ç¿ëÀÚ, Áï User Áö½Ã¾î·Î ÁöÁ¤ÇÑ »ç¿ëÀÚ - ±ÇÇÑÀ¸·Î ·Î±×¸¦ ¿¬´Ù. ±×·¡¼­ ±× »ç¿ëÀÚ°¡ ½ºÅ©¸³Æ® ·Î±×°¡ - ÀÖ´Â µð·ºÅ丮¿¡ ¾²±â±ÇÇÑÀÌ ÀÖ´øÁö, Á÷Á¢ ¹Ì¸® ÆÄÀÏÀ» ¸¸µé¾î¼­ - ±× »ç¿ëÀÚ¿¡°Ô ¾²±â±ÇÇÑÀ» Áà¾ß ÇÑ´Ù. ½ºÅ©¸³Æ® ·Î±×¸¦ ÁÖ ·Î±× - µð·ºÅ丮¿¡ µÐ´Ù¸é ÀÚ½Ä ÇÁ·Î¼¼½º¸¦ ½ÇÇàÇÏ´Â »ç¿ëÀÚ¿¡°Ô ¾²±â±ÇÇÑÀ» - ÁÖ±âÀ§ÇØ µð·ºÅ丮 ±ÇÇÑÀ» º¯°æÇÏÁö ¸¶¶ó.

    - -

    ½ºÅ©¸³Æ® ·Î±×´Â CGI ½ºÅ©¸³Æ®¸¦ ÀÛ¼ºÇÒ¶§ µð¹ö±ëÀ» À§ÇÑ - ¿ëµµÀÌÁö ¼­¹ö¸¦ ½ÇÇàÇÏ´Â µ¿¾È °è¼Ó »ç¿ëÇϱâÀ§ÇÔÀÌ ¾Æ´ÔÀ» - ÁÖÀÇÇ϶ó. ¼Óµµ¿Í È¿À²¼º¸é¿¡¼­ ÃÖÀûÈ­°¡ ¾ÈµÇÀÖ°í, ¼³°èÇÑ - ¸ñÀûÀÌ¿ÜÀÇ ¹æ¹ýÀ¸·Î »ç¿ëÇÏ¸é º¸¾È»ó ¹®Á¦°¡ µÉ ¼ö ÀÖ´Ù.

    - -
    -
    top
    -

    ScriptLogBuffer Áö½Ã¾î

    - - - - - - - -
    ¼³¸í:½ºÅ©¸³Æ® ·Î±×¿¡ ±â·ÏÇÒ PUT ȤÀº POST ¿äûÀÇ ÃÖ´ë·®
    ¹®¹ý:ScriptLogBuffer bytes
    ±âº»°ª:ScriptLogBuffer 1024
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Base
    ¸ðµâ:mod_cgi, mod_cgid
    -

    Å« ³»¿ëÀ» ¹Þ¾Æ¼­ ·Î±×ÆÄÀÏÀÌ ³Ê¹« »¡¸® Ä¿Áö´Â Çö»óÀ» ¸·±âÀ§ÇØ - ÆÄÀÏ¿¡ ±â·ÏÇÒ PUT ȤÀº POST ³»¿ëÀÇ Å©±â¸¦ Á¦ÇÑÇÑ´Ù. ±âº»ÀûÀ¸·Î - 1024 ¹ÙÀÌÆ®±îÁö ·Î±×¿¡ ±â·ÏÇÏÁö¸¸, ÀÌ Áö½Ã¾î¸¦ »ç¿ëÇÏ¿© - ¼öÁ¤ÇÒ ¼ö ÀÖ´Ù.

    - -
    -
    top
    -

    ScriptLogLength Áö½Ã¾î

    - - - - - - - -
    ¼³¸í:CGI ½ºÅ©¸³Æ® ·Î±×ÆÄÀÏÀÇ Å©±â Á¦ÇÑ
    ¹®¹ý:ScriptLogLength bytes
    ±âº»°ª:ScriptLogLength 10385760
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Base
    ¸ðµâ:mod_cgi, mod_cgid
    -

    ScriptLogLength´Â CGI ½ºÅ©¸³Æ® - ·Î±×ÆÄÀÏÀÇ Å©±â¸¦ Á¦ÇÑÇÑ´Ù. CGI ¿À·ù°¡ ¹ß»ýÇÒ¶§¸¶´Ù (¸ðµç - ¿äû Çì´õ, ¸ðµç ½ºÅ©¸³Æ® Ãâ·Â µî) ¸¹Àº Á¤º¸°¡ ·Î±×¿¡ - ±â·ÏµÇ±â¶§¹®¿¡ ÆÄÀÏÀÌ ¸Å¿ì Ä¿Áú ¼ö ÀÖ´Ù. ÆÄÀÏÀÌ ¹«ÇÑÈ÷ Ä¿Áö´Â - ¹®Á¦¸¦ ¸·±âÀ§ÇØ ÀÌ Áö½Ã¾î¸¦ »ç¿ëÇÏ¿© CGI ·Î±×ÆÄÀÏÀÇ ÃÖ´ë - ÆÄÀÏÅ©±â¸¦ ¼³Á¤ÇÑ´Ù. ÆÄÀÏÀÇ Å©±â°¡ ¼³Á¤ÇÑ °ªÀ» ³ÑÀ¸¸é ´õ - ÀÌ»ó Á¤º¸¸¦ ±â·ÏÇÏÁö¾Ê´Â´Ù.

    -
    diff --git a/docs/manual/mod/mod_cgid.html.en b/docs/manual/mod/mod_cgid.html.en index 7d683ebf39f..134d4b70e18 100644 --- a/docs/manual/mod/mod_cgid.html.en +++ b/docs/manual/mod/mod_cgid.html.en @@ -74,7 +74,6 @@
  • Running CGI programs under different user IDs
    • -
    top

    CGIDScriptTimeout Directive

    @@ -126,6 +125,7 @@ the cgi daemon +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_cgid.html.fr b/docs/manual/mod/mod_cgid.html.fr index 177297b3966..97b5674935d 100644 --- a/docs/manual/mod/mod_cgid.html.fr +++ b/docs/manual/mod/mod_cgid.html.fr @@ -78,7 +78,6 @@ thread

  • Exécution de programmes CGI sous des utilisateurs différents
    • -
    top

    Directive CGIDScriptTimeout

    @@ -130,6 +129,7 @@ communiquer avec le d +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_cgid.html.ja.utf8 b/docs/manual/mod/mod_cgid.html.ja.utf8 index f989689d95a..ad143a50b6e 100644 --- a/docs/manual/mod/mod_cgid.html.ja.utf8 +++ b/docs/manual/mod/mod_cgid.html.ja.utf8 @@ -73,7 +73,6 @@

  • mod_cgi
  • CGI プログラムを違うユーザ ID で実行する
    • -
    top

    CGIDScriptTimeout ディレクティブ

    @@ -113,6 +112,7 @@ unset +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_cgid.html.ko.euc-kr b/docs/manual/mod/mod_cgid.html.ko.euc-kr index 189bda11435..2eaed876d0b 100644 --- a/docs/manual/mod/mod_cgid.html.ko.euc-kr +++ b/docs/manual/mod/mod_cgid.html.ko.euc-kr @@ -71,7 +71,6 @@

  • ´Ù¸¥ »ç¿ëÀÚ ID·Î CGI ÇÁ·Î±×·¥ ½ÇÇàÇϱâ
    • -
    top

    CGIDScriptTimeout Áö½Ã¾î

    @@ -109,6 +108,7 @@ unset +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_charset_lite.html.en b/docs/manual/mod/mod_charset_lite.html.en index 3d2b75eb4f8..cf88e52c6ef 100644 --- a/docs/manual/mod/mod_charset_lite.html.en +++ b/docs/manual/mod/mod_charset_lite.html.en @@ -60,43 +60,6 @@

  • Common Problems
    • top
    -
    -

    Common Problems

    - -

    Invalid character set names

    - -

    The character set name parameters of CharsetSourceEnc and - CharsetDefault - must be acceptable to the translation mechanism used by - APR on the system where - mod_charset_lite is deployed. These character - set names are not standardized and are usually not the same as - the corresponding values used in http headers. Currently, APR - can only use iconv(3), so you can easily test your character set - names using the iconv(1) program, as follows:

    - -

    - iconv -f charsetsourceenc-value -t charsetdefault-value -

    - - -

    Mismatch between character set of content and translation - rules

    - -

    If the translation rules don't make sense for the content, - translation can fail in various ways, including:

    - -
      -
    • The translation mechanism may return a bad return code, - and the connection will be aborted.
      • - -
    • The translation mechanism may silently place special - characters (e.g., question marks) in the output buffer when - it cannot translate the input buffer.
      • -
    - -
    -
    top

    CharsetDefault Directive

    @@ -199,6 +162,43 @@ + +
    top
    +
    +

    Common Problems

    + +

    Invalid character set names

    + +

    The character set name parameters of CharsetSourceEnc and + CharsetDefault + must be acceptable to the translation mechanism used by + APR on the system where + mod_charset_lite is deployed. These character + set names are not standardized and are usually not the same as + the corresponding values used in http headers. Currently, APR + can only use iconv(3), so you can easily test your character set + names using the iconv(1) program, as follows:

    + +

    + iconv -f charsetsourceenc-value -t charsetdefault-value +

    + + +

    Mismatch between character set of content and translation + rules

    + +

    If the translation rules don't make sense for the content, + translation can fail in various ways, including:

    + +
      +
    • The translation mechanism may return a bad return code, + and the connection will be aborted.
      • + +
    • The translation mechanism may silently place special + characters (e.g., question marks) in the output buffer when + it cannot translate the input buffer.
      • +
    +
    diff --git a/docs/manual/mod/mod_charset_lite.html.fr b/docs/manual/mod/mod_charset_lite.html.fr index 9ff6662532d..709f162c61e 100644 --- a/docs/manual/mod/mod_charset_lite.html.fr +++ b/docs/manual/mod/mod_charset_lite.html.fr @@ -64,47 +64,6 @@ traductions ou les r
  • Problèmes courants
    • top
    -
    -

    Problèmes courants

    - -

    Noms de jeux de caractères non valides

    - -

    Les noms des jeux de caractères passés en paramètres aux - directives CharsetSourceEnc et - CharsetDefault - doivent être reconnus par le mécanisme de traduction utilisé par - APR sur le système où - mod_charset_lite est utilisé. Ces noms de jeux de - caractères ne sont pas standardisés, et sont en général différents - des valeurs qui leur correspondent dans les en-têtes HTTP. - Actuellement, APR ne peut utiliser que iconv(3) ; vous pouvez donc - tester facilement vos noms de jeux de caractères en utilisant le - programme iconv(1), de la manière suivante :

    - -

    - iconv -f valeur-charsetsourceenc -t valeur-charsetdefault -

    - - -

    Incompatibilité entre le jeu de caractères du - contenu et les règles de traduction

    - -

    Si les règles de traduction ne peuvent s'appliquer au contenu, - la traduction peut échouer avec des conséquences diverses, comme - :

    - -
      -
    • Le mécanisme de traduction peut renvoyer un mauvais code de - retour, et la connexion sera interrompue.
      • - -
    • Le mécanisme de traduction peut insérer silencieusement des - caractères spéciaux (par exemple des points d'interrogation) dans - le tampon de sortie lorsqu'il n'est pas en mesure de traduire le - tampon d'entrée.
      • -
    - -
    -
    top

    Directive CharsetDefault

    Description:Charset to translate into
  • Ressources WebDAV
    • top
    +

    Directive Dav

    +
    Description:Jeu de caractère vers lequel la traduction doit @@ -217,6 +176,47 @@ caract valide du point de vue du système. + +
    top
    +
    +

    Problèmes courants

    + +

    Noms de jeux de caractères non valides

    + +

    Les noms des jeux de caractères passés en paramètres aux + directives CharsetSourceEnc et + CharsetDefault + doivent être reconnus par le mécanisme de traduction utilisé par + APR sur le système où + mod_charset_lite est utilisé. Ces noms de jeux de + caractères ne sont pas standardisés, et sont en général différents + des valeurs qui leur correspondent dans les en-têtes HTTP. + Actuellement, APR ne peut utiliser que iconv(3) ; vous pouvez donc + tester facilement vos noms de jeux de caractères en utilisant le + programme iconv(1), de la manière suivante :

    + +

    + iconv -f valeur-charsetsourceenc -t valeur-charsetdefault +

    + + +

    Incompatibilité entre le jeu de caractères du + contenu et les règles de traduction

    + +

    Si les règles de traduction ne peuvent s'appliquer au contenu, + la traduction peut échouer avec des conséquences diverses, comme + :

    + +
      +
    • Le mécanisme de traduction peut renvoyer un mauvais code de + retour, et la connexion sera interrompue.
      • + +
    • Le mécanisme de traduction peut insérer silencieusement des + caractères spéciaux (par exemple des points d'interrogation) dans + le tampon de sortie lorsqu'il n'est pas en mesure de traduire le + tampon d'entrée.
      • +
    +
    diff --git a/docs/manual/mod/mod_charset_lite.html.ko.euc-kr b/docs/manual/mod/mod_charset_lite.html.ko.euc-kr index 30a8064eeee..554accd2e11 100644 --- a/docs/manual/mod/mod_charset_lite.html.ko.euc-kr +++ b/docs/manual/mod/mod_charset_lite.html.ko.euc-kr @@ -66,40 +66,6 @@
  • ÀϹÝÀûÀÎ ¹®Á¦Á¡
    • top
    -
    -

    ÀϹÝÀûÀÎ ¹®Á¦Á¡

    - -

    À߸øµÈ ¹®ÀÚÁýÇÕ À̸§

    - -

    mod_charset_lite¸¦ »ç¿ëÇÏ´Â ½Ã½ºÅÛÀÇ - ARP ¹ø¿ª±â´ÉÀÌ CharsetSourceEnc¿Í - CharsetDefaultÀÇ - ÆĶó¹ÌÅÍÀÎ ¹®ÀÚÁýÇÕ À̸§À» ó¸®ÇÒ ¼ö ÀÖ¾î¾ß ÇÑ´Ù. ¹®ÀÚÁýÇÕ - À̸§Àº Ç¥ÁØÈ­µÇÁö ¾Ê¾Ò°í, http Çì´õ¿¡ »ç¿ëÇÏ´Â °ª°ú Ç×»ó - °°Áö´Â ¾Ê´Ù. ÇöÀç APRÀº iconv(3)¸¸À» »ç¿ëÇϱ⶧¹®¿¡, - ´ÙÀ½°ú °°ÀÌ iconv(1) ÇÁ·Î±×·¥À» »ç¿ëÇÏ¿© ƯÁ¤ ¹®ÀÚÁýÇÕ - À̸§À» »ç¿ëÇÒ ¼ö ÀÖ´ÂÁö ½±°Ô ¾Ë ¼ö ÀÖ´Ù:

    - -

    - iconv -f charsetsourceenc-value -t charsetdefault-value -

    - - -

    ³»¿ë°ú º¯È¯±ÔÄ¢ÀÇ ¹®ÀÚÁýÇÕÀÌ ¼­·Î ´Ù¸§

    - -

    º¯È¯±ÔÄ¢ÀÌ »óȲ¿¡ ¸ÂÁö¾ÊÀ¸¸é ´ÙÀ½°ú °°Àº ¿©·¯ ¹æ½ÄÀ¸·Î - º¯È¯ÀÌ ½ÇÆÐÇÒ ¼ö ÀÖ´Ù:

    - -
      -
    • º¯È¯±â´ÉÀÌ ½ÇÆÐ ¹ÝȯÄڵ带 ¹ÝȯÇÏ°í ¿¬°áÀÌ ²÷¾îÁú - ¼ö ÀÖ´Ù.
      • - -
    • ÀԷ¹öÆÛ¸¦ º¯È¯ÇÏÁö ¸øÇÒ¶§ Ãâ·Â¹öÆÛ¿¡ ´ë½Å Ưº°ÇÑ - ¹®ÀÚ¸¦ (¿¹, ¹°À½Ç¥) ÀûÀ» ¼ö ÀÖ´Ù.
      • -
    - -
    -
    top

    CharsetDefault Áö½Ã¾î

    @@ -191,6 +157,40 @@

    Solaris 8ÀÇ iconv°¡ ÀÌ ¿¹Á¦ÀÇ ¹®ÀÚÁýÇÕÀ» Áö¿øÇÑ´Ù.

    + +
    top
    +
    +

    ÀϹÝÀûÀÎ ¹®Á¦Á¡

    + +

    À߸øµÈ ¹®ÀÚÁýÇÕ À̸§

    + +

    mod_charset_lite¸¦ »ç¿ëÇÏ´Â ½Ã½ºÅÛÀÇ + ARP ¹ø¿ª±â´ÉÀÌ CharsetSourceEnc¿Í + CharsetDefaultÀÇ + ÆĶó¹ÌÅÍÀÎ ¹®ÀÚÁýÇÕ À̸§À» ó¸®ÇÒ ¼ö ÀÖ¾î¾ß ÇÑ´Ù. ¹®ÀÚÁýÇÕ + À̸§Àº Ç¥ÁØÈ­µÇÁö ¾Ê¾Ò°í, http Çì´õ¿¡ »ç¿ëÇÏ´Â °ª°ú Ç×»ó + °°Áö´Â ¾Ê´Ù. ÇöÀç APRÀº iconv(3)¸¸À» »ç¿ëÇϱ⶧¹®¿¡, + ´ÙÀ½°ú °°ÀÌ iconv(1) ÇÁ·Î±×·¥À» »ç¿ëÇÏ¿© ƯÁ¤ ¹®ÀÚÁýÇÕ + À̸§À» »ç¿ëÇÒ ¼ö ÀÖ´ÂÁö ½±°Ô ¾Ë ¼ö ÀÖ´Ù:

    + +

    + iconv -f charsetsourceenc-value -t charsetdefault-value +

    + + +

    ³»¿ë°ú º¯È¯±ÔÄ¢ÀÇ ¹®ÀÚÁýÇÕÀÌ ¼­·Î ´Ù¸§

    + +

    º¯È¯±ÔÄ¢ÀÌ »óȲ¿¡ ¸ÂÁö¾ÊÀ¸¸é ´ÙÀ½°ú °°Àº ¿©·¯ ¹æ½ÄÀ¸·Î + º¯È¯ÀÌ ½ÇÆÐÇÒ ¼ö ÀÖ´Ù:

    + +
      +
    • º¯È¯±â´ÉÀÌ ½ÇÆÐ ¹ÝȯÄڵ带 ¹ÝȯÇÏ°í ¿¬°áÀÌ ²÷¾îÁú + ¼ö ÀÖ´Ù.
      • + +
    • ÀԷ¹öÆÛ¸¦ º¯È¯ÇÏÁö ¸øÇÒ¶§ Ãâ·Â¹öÆÛ¿¡ ´ë½Å Ưº°ÇÑ + ¹®ÀÚ¸¦ (¿¹, ¹°À½Ç¥) ÀûÀ» ¼ö ÀÖ´Ù.
      • +
    +
    diff --git a/docs/manual/mod/mod_dav.html.en b/docs/manual/mod/mod_dav.html.en index abbe7c859c8..8a464b2819e 100644 --- a/docs/manual/mod/mod_dav.html.en +++ b/docs/manual/mod/mod_dav.html.en @@ -60,6 +60,80 @@
  • WebDAV Resources
    • top
    +

    Dav Directive

    +
    ¼³¸í:º¯È¯ÇÒ ¹®ÀÚÁýÇÕ
    + + + + + + +
    Description:Enable WebDAV HTTP methods
    Syntax:Dav On|Off|provider-name
    Default:Dav Off
    Context:directory
    Status:Extension
    Module:mod_dav
    +

    Use the Dav directive to enable the + WebDAV HTTP methods for the given container:

    + + 
    <Location "/foo">
+    Dav On
+</Location>
    + + +

    The value On is actually an alias for the default + provider filesystem which is served by the mod_dav_fs module. Note, that once you have DAV enabled + for some location, it cannot be disabled for sublocations. + For a complete configuration example have a look at the section above.

    + +
    + Do not enable WebDAV until you have secured your server. Otherwise + everyone will be able to distribute files on your system. +
    + +
    +
    top
    +

    DavDepthInfinity Directive

    + + + + + + + +
    Description:Allow PROPFIND, Depth: Infinity requests
    Syntax:DavDepthInfinity on|off
    Default:DavDepthInfinity off
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_dav
    +

    Use the DavDepthInfinity directive to + allow the processing of PROPFIND requests containing the + header 'Depth: Infinity'. Because this type of request could constitute + a denial-of-service attack, by default it is not allowed.

    + +
    +
    top
    +

    DavMinTimeout Directive

    + + + + + + + +
    Description:Minimum amount of time the server holds a lock on +a DAV resource
    Syntax:DavMinTimeout seconds
    Default:DavMinTimeout 0
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_dav
    +

    When a client requests a DAV resource lock, it can also + specify a time when the lock will be automatically removed by + the server. This value is only a request, and the server can + ignore it or inform the client of an arbitrary value.

    + +

    Use the DavMinTimeout directive to specify, in + seconds, the minimum lock timeout to return to a client. + Microsoft Web Folders defaults to a timeout of 120 seconds; the + DavMinTimeout can override this to a higher value + (like 600 seconds) to reduce the chance of the client losing + the lock due to network latency.

    + +

    Example

    <Location "/MSWord">
+    DavMinTimeout 600
+</Location>
    +
    + +
    +
    top

    Enabling WebDAV

    To enable mod_dav, add the following to a @@ -171,80 +245,6 @@ Alias "/php-source" "/home/gstein/php_files" used to access the output of the PHP scripts, and http://example.com/php-source can be used with a DAV client to manipulate them.

    -
    -
    top
    -

    Dav Directive

    - - - - - - - -
    Description:Enable WebDAV HTTP methods
    Syntax:Dav On|Off|provider-name
    Default:Dav Off
    Context:directory
    Status:Extension
    Module:mod_dav
    -

    Use the Dav directive to enable the - WebDAV HTTP methods for the given container:

    - - 
    <Location "/foo">
-    Dav On
-</Location>
    - - -

    The value On is actually an alias for the default - provider filesystem which is served by the mod_dav_fs module. Note, that once you have DAV enabled - for some location, it cannot be disabled for sublocations. - For a complete configuration example have a look at the section above.

    - -
    - Do not enable WebDAV until you have secured your server. Otherwise - everyone will be able to distribute files on your system. -
    - -
    -
    top
    -

    DavDepthInfinity Directive

    - - - - - - - -
    Description:Allow PROPFIND, Depth: Infinity requests
    Syntax:DavDepthInfinity on|off
    Default:DavDepthInfinity off
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_dav
    -

    Use the DavDepthInfinity directive to - allow the processing of PROPFIND requests containing the - header 'Depth: Infinity'. Because this type of request could constitute - a denial-of-service attack, by default it is not allowed.

    - -
    -
    top
    -

    DavMinTimeout Directive

    - - - - - - - -
    Description:Minimum amount of time the server holds a lock on -a DAV resource
    Syntax:DavMinTimeout seconds
    Default:DavMinTimeout 0
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_dav
    -

    When a client requests a DAV resource lock, it can also - specify a time when the lock will be automatically removed by - the server. This value is only a request, and the server can - ignore it or inform the client of an arbitrary value.

    - -

    Use the DavMinTimeout directive to specify, in - seconds, the minimum lock timeout to return to a client. - Microsoft Web Folders defaults to a timeout of 120 seconds; the - DavMinTimeout can override this to a higher value - (like 600 seconds) to reduce the chance of the client losing - the lock due to network latency.

    - -

    Example

    <Location "/MSWord">
-    DavMinTimeout 600
-</Location>
    -
    -
    diff --git a/docs/manual/mod/mod_dav.html.fr b/docs/manual/mod/mod_dav.html.fr index 5c8888b7071..d274d67908f 100644 --- a/docs/manual/mod/mod_dav.html.fr +++ b/docs/manual/mod/mod_dav.html.fr @@ -63,6 +63,88 @@ documents via le web (WebDAV)
    + + + + + + +
    Description:Active les méthodes HTTP WebDAV
    Syntaxe:Dav On|Off|nom fournisseur
    Défaut:Dav Off
    Contexte:répertoire
    Statut:Extension
    Module:mod_dav
    +

    La directive Dav permet d'activer les + méthodes HTTP WebDAV pour le conteneur condidéré :

    + + 
    <Location /foo>
+    Dav On
+</Location>
    + + +

    La valeur On est en fait un alias vers le + fournisseur par défaut filesystem implémenté par le + module mod_dav_fs. Notez que lorsque DAV est activé + pour un conteneur, on ne peut pas le désactiver pour ses + sous-conteneurs. Pour un exemple de configuration complet, + reportez-vous à la section précédente.

    + +
    + N'activez pas WebDAV tant que votre serveur n'est pas sécurisé. Si + vous passez outre cette recommandation, tout le monde pourra + enregistrer des fichiers sur votre système. +
    + +
    +
    top
    +

    Directive DavDepthInfinity

    + + + + + + + +
    Description:Autorise les requêtes PROPFIND avec en-tête Depth: +Infinity
    Syntaxe:DavDepthInfinity on|off
    Défaut:DavDepthInfinity off
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_dav
    +

    La directive DavDepthInfinity permet + d'autoriser le traitement des requêtes PROPFIND + contenant l'en-tête Depth: Infinity. Par défaut, ce type de requête + n'est pas autorisé, car il peut favoriser les attaques de type Déni + de service.

    + +
    +
    top
    +

    Directive DavMinTimeout

    + + + + + + + +
    Description:Durée minimale pendant laquelle le serveur maintient un +verrou sur une ressource DAV
    Syntaxe:DavMinTimeout secondes
    Défaut:DavMinTimeout 0
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_dav
    +

    Lorsqu'un client demande le verrouillage d'une ressource DAV, il + peut aussi spécifier une durée au bout de laquelle le verrou sera + automatiquement supprimé par le serveur. Cette valeur ne constitue + qu'une demande, et le serveur peut l'ignorer ou informer le client + qu'il va utiliser une valeur arbitraire.

    + +

    La directive DavMinTimeout permet de + spécifier, en secondes, la durée minimale de verrouillage à renvoyer + au client. Les Répertoires Web de Microsoft présentent une durée par + défaut de 120 secondes ; la directive + DavMinTimeout permet de définir une valeur + supérieure (par exemple 600 secondes), afin de réduire les risques + de perte du verrou par le client suite à une surcharge du + réseau.

    + +

    Exemple

    <Location /MSWord>
+    DavMinTimeout 600
+</Location>
    +
    + +
    +
    top

    Activation de WebDAV

    Pour activer le module mod_dav, ajoutez la ligne @@ -186,88 +268,6 @@ ForceType text/plain l'exécution des scripts PHP, et http://example.com/php-source pour les manipuler avec DAV.

    -
    -
    top
    -

    Directive Dav

    - - - - - - - -
    Description:Active les méthodes HTTP WebDAV
    Syntaxe:Dav On|Off|nom fournisseur
    Défaut:Dav Off
    Contexte:répertoire
    Statut:Extension
    Module:mod_dav
    -

    La directive Dav permet d'activer les - méthodes HTTP WebDAV pour le conteneur condidéré :

    - - 
    <Location /foo>
-    Dav On
-</Location>
    - - -

    La valeur On est en fait un alias vers le - fournisseur par défaut filesystem implémenté par le - module mod_dav_fs. Notez que lorsque DAV est activé - pour un conteneur, on ne peut pas le désactiver pour ses - sous-conteneurs. Pour un exemple de configuration complet, - reportez-vous à la section précédente.

    - -
    - N'activez pas WebDAV tant que votre serveur n'est pas sécurisé. Si - vous passez outre cette recommandation, tout le monde pourra - enregistrer des fichiers sur votre système. -
    - -
    -
    top
    -

    Directive DavDepthInfinity

    - - - - - - - -
    Description:Autorise les requêtes PROPFIND avec en-tête Depth: -Infinity
    Syntaxe:DavDepthInfinity on|off
    Défaut:DavDepthInfinity off
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_dav
    -

    La directive DavDepthInfinity permet - d'autoriser le traitement des requêtes PROPFIND - contenant l'en-tête Depth: Infinity. Par défaut, ce type de requête - n'est pas autorisé, car il peut favoriser les attaques de type Déni - de service.

    - -
    -
    top
    -

    Directive DavMinTimeout

    - - - - - - - -
    Description:Durée minimale pendant laquelle le serveur maintient un -verrou sur une ressource DAV
    Syntaxe:DavMinTimeout secondes
    Défaut:DavMinTimeout 0
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_dav
    -

    Lorsqu'un client demande le verrouillage d'une ressource DAV, il - peut aussi spécifier une durée au bout de laquelle le verrou sera - automatiquement supprimé par le serveur. Cette valeur ne constitue - qu'une demande, et le serveur peut l'ignorer ou informer le client - qu'il va utiliser une valeur arbitraire.

    - -

    La directive DavMinTimeout permet de - spécifier, en secondes, la durée minimale de verrouillage à renvoyer - au client. Les Répertoires Web de Microsoft présentent une durée par - défaut de 120 secondes ; la directive - DavMinTimeout permet de définir une valeur - supérieure (par exemple 600 secondes), afin de réduire les risques - de perte du verrou par le client suite à une surcharge du - réseau.

    - -

    Exemple

    <Location /MSWord>
-    DavMinTimeout 600
-</Location>
    -
    -
    diff --git a/docs/manual/mod/mod_dav.html.ja.utf8 b/docs/manual/mod/mod_dav.html.ja.utf8 index 174fdba6ae3..ac9c002ae5c 100644 --- a/docs/manual/mod/mod_dav.html.ja.utf8 +++ b/docs/manual/mod/mod_dav.html.ja.utf8 @@ -66,6 +66,86 @@
  • WebDAV Resources
    • top
    +

    Dav ディレクティブ

    + + + + + + + +
    説明:WebDAV HTTP メソッドを有効にします
    構文:Dav On|Off|provider-name
    デフォルト:Dav Off
    コンテキスト:ディレクトリ
    ステータス:Extension
    モジュール:mod_dav
    +

    与えられたコンテナで WebDAV HTTP メソッドが使えるようにするには + 次のようにします。

    + + 
    <Location /foo>
+    Dav On
+</Location>
    + + +

    On という指定は実際には mod_dav_fs + で提供されているデフォルトのプロバイダ、filesystem + へのエイリアスになっています。一度あるロケーションで DAV + を有効にした後は、そのサブロケーションで無効化することはできない + ということに注意してください。完全な設定例は上記のセクション をご覧下さい。

    + +
    + サーバのセキュリティが確保できるまで WebDAV を有効にしないでください。 + そうしなければ誰でもそのサーバでファイルを配布することができるように + なってしまいます。 +
    + +
    +
    top
    +

    DavDepthInfinity ディレクティブ

    + + + + + + + +
    説明:PROPFIND, Depth: Infinity リクエストを許可します
    構文:DavDepthInfinity on|off
    デフォルト:DavDepthInfinity off
    コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ
    ステータス:Extension
    モジュール:mod_dav
    +

    'Depth: Infinity' を含んでいる + PROPFIND リクエストを処理できるようにするには、 + DavDepthInfinity + ディレクティブを使います。このタイプのリクエストは + denial-of-service アタックとなりうるので、 + デフォルトでは許可されていません。

    + +
    +
    top
    +

    DavMinTimeout ディレクティブ

    + + + + + + + +
    説明:サーバが DAV リソースのロックを維持する最小時間です。 +
    構文:DavMinTimeout seconds
    デフォルト:DavMinTimeout 0
    コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ
    ステータス:Extension
    モジュール:mod_dav
    +

    クライアントが DAV リソースロックを要求した場合、 + ロックがサーバによって自動的に解除されるまでの時間を + 同時に指定することができます。この値は単なるリクエストであって、 + サーバはこれを無視することもできますし、 + 任意の値をクライアントに通知することもできます。

    + +

    クライアントに戻すロックタイムアウトの最小時間を、 + 秒で、指定するために DavMinTimeout + ディレクティブを使います。 + マイクロソフトのウェブフォルダのデフォルトでは 120 秒ですが； + ネットワークの遅延のせいでクライアントがロックを失うのを減らすために、 + DavMinTimeout を使って + これをもっと大きな値 (例えば 600 秒) に上書きできます。

    + +

    例

    <Location /MSWord>
+    DavMinTimeout 600
+</Location>
    +
    + +
    +
    top

    Enabling WebDAV

    mod_dav を有効にするには、httpd.conf @@ -175,86 +255,6 @@ Alias /php-source /home/gstein/php_files 出力をアクセスするために使うことができ、 http://example.com/php-source を DAV クライアントによる が操作のために使うことができます。

    -
    -
    top
    -

    Dav ディレクティブ

    - - - - - - - -
    説明:WebDAV HTTP メソッドを有効にします
    構文:Dav On|Off|provider-name
    デフォルト:Dav Off
    コンテキスト:ディレクトリ
    ステータス:Extension
    モジュール:mod_dav
    -

    与えられたコンテナで WebDAV HTTP メソッドが使えるようにするには - 次のようにします。

    - - 
    <Location /foo>
-    Dav On
-</Location>
    - - -

    On という指定は実際には mod_dav_fs - で提供されているデフォルトのプロバイダ、filesystem - へのエイリアスになっています。一度あるロケーションで DAV - を有効にした後は、そのサブロケーションで無効化することはできない - ということに注意してください。完全な設定例は上記のセクション をご覧下さい。

    - -
    - サーバのセキュリティが確保できるまで WebDAV を有効にしないでください。 - そうしなければ誰でもそのサーバでファイルを配布することができるように - なってしまいます。 -
    - -
    -
    top
    -

    DavDepthInfinity ディレクティブ

    - - - - - - - -
    説明:PROPFIND, Depth: Infinity リクエストを許可します
    構文:DavDepthInfinity on|off
    デフォルト:DavDepthInfinity off
    コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ
    ステータス:Extension
    モジュール:mod_dav
    -

    'Depth: Infinity' を含んでいる - PROPFIND リクエストを処理できるようにするには、 - DavDepthInfinity - ディレクティブを使います。このタイプのリクエストは - denial-of-service アタックとなりうるので、 - デフォルトでは許可されていません。

    - -
    -
    top
    -

    DavMinTimeout ディレクティブ

    - - - - - - - -
    説明:サーバが DAV リソースのロックを維持する最小時間です。 -
    構文:DavMinTimeout seconds
    デフォルト:DavMinTimeout 0
    コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ
    ステータス:Extension
    モジュール:mod_dav
    -

    クライアントが DAV リソースロックを要求した場合、 - ロックがサーバによって自動的に解除されるまでの時間を - 同時に指定することができます。この値は単なるリクエストであって、 - サーバはこれを無視することもできますし、 - 任意の値をクライアントに通知することもできます。

    - -

    クライアントに戻すロックタイムアウトの最小時間を、 - 秒で、指定するために DavMinTimeout - ディレクティブを使います。 - マイクロソフトのウェブフォルダのデフォルトでは 120 秒ですが； - ネットワークの遅延のせいでクライアントがロックを失うのを減らすために、 - DavMinTimeout を使って - これをもっと大きな値 (例えば 600 秒) に上書きできます。

    - -

    例

    <Location /MSWord>
-    DavMinTimeout 600
-</Location>
    -
    -
    diff --git a/docs/manual/mod/mod_dav.html.ko.euc-kr b/docs/manual/mod/mod_dav.html.ko.euc-kr index 1e7d0fa4b22..ea2171e8479 100644 --- a/docs/manual/mod/mod_dav.html.ko.euc-kr +++ b/docs/manual/mod/mod_dav.html.ko.euc-kr @@ -63,6 +63,85 @@
  • WebDAV Á¤º¸
    • top
    +

    Dav Áö½Ã¾î

    + + + + + + + +
    ¼³¸í:WebDAV HTTP ¸Þ½áµå¸¦ ½ÃÀÛÇÑ´Ù
    ¹®¹ý:Dav On|Off|provider-name
    ±âº»°ª:Dav Off
    »ç¿ëÀå¼Ò:directory
    »óÅÂ:Extension
    ¸ðµâ:mod_dav
    +

    ÁöÁ¤ÇÑ À§Ä¡¿¡¼­ WebDAV HTTP ¸Þ½áµå¸¦ »ç¿ëÇÏ·Á¸é + Dav Áö½Ã¾î¸¦ »ç¿ëÇÑ´Ù:

    + +

    + <Location /foo>
    + + Dav On
    +     + </Location> +

    + +

    On °ªÀº ½ÇÁ¦·Î mod_dav_fs + ¸ðµâÀÌ Á¦°øÇÏ´Â ±âº» Á¦°øÀÚÀÎ filesystemÀÇ + º°ÄªÀÌ´Ù. ¾î¶² À§Ä¡¿¡¼­ DAV¸¦ ½ÃÀÛÇϸé ÇÏÀ§°ø°£¿¡¼­ DAV¸¦ + »ç¿ë¾ÈÇϵµ·Ï ¼³Á¤ÇÒ ¼ö ¾øÀ½À» ÁÖÀÇÇ϶ó. ¿ÏÀüÇÑ + ¼³Á¤¿¹´Â À§ÀÇ ÀýÀ» Âü°íÇ϶ó.

    + +
    + ¼­¹ö¸¦ ¾ÈÀüÇÏ°Ô ±¸¼ºÇÒ¶§±îÁö WebDAVÀ» »ç¿ëÇÏÁö ¸¶¶ó. ±×·¸Áö + ¾ÊÀ¸¸é ´©±¸¶óµµ ¼­¹ö¸¦ ÅëÇØ ÆÄÀÏÀ» ºÐ¹èÇÒ ¼ö ÀÖ°Ô µÈ´Ù. +
    + +
    +
    top
    +

    DavDepthInfinity Áö½Ã¾î

    + + + + + + + +
    ¼³¸í:PROPFINDÀÇ Depth: Infinity ¿äûÀ» Çã°¡ÇÑ´Ù
    ¹®¹ý:DavDepthInfinity on|off
    ±âº»°ª:DavDepthInfinity off
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory
    »óÅÂ:Extension
    ¸ðµâ:mod_dav
    +

    DavDepthInfinity Áö½Ã¾î¸¦ »ç¿ëÇϸé + 'Depth: Infinity' Çì´õ¸¦ °¡Áø PROPFIND ¿äûÀ» + Çã°¡ÇÑ´Ù. ÀÌ·± ¿äûÀ» »ç¿ëÇÏ¿© ¼­ºñ½º°ÅºÎ °ø°ÝÀÌ °¡´ÉÇϱâ + ¶§¹®¿¡ ±âº»ÀûÀ¸·Î Çã¿ëÇÏÁö ¾Ê´Â´Ù.

    + +
    +
    top
    +

    DavMinTimeout Áö½Ã¾î

    + + + + + + + +
    ¼³¸í:¼­¹ö°¡ DAV ÀÚ¿ø¿¡ ´ëÇØ À¯ÁöÇÒ Àá±ÝÀÇ Ãּҽð£
    ¹®¹ý:DavMinTimeout seconds
    ±âº»°ª:DavMinTimeout 0
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory
    »óÅÂ:Extension
    ¸ðµâ:mod_dav
    +

    Ŭ¶óÀ̾ðÆ®°¡ DAV ÀÚ¿ø¿¡ Àá±Ý(lock)À» ¿äûÇÒ¶§ ¼­¹ö°¡ + ¾Ë¾Æ¼­ Àá±ÝÀ» Á¦°ÅÇÒ ¼ö ÀÖ´Â ½Ã°£À» °°ÀÌ ¾Ë·ÁÁÙ ¼ö ÀÖ´Ù. ÀÌ °ªÀº + ´ÜÁö ¿äûÀÏ»ÓÀ̸ç, ¼­¹ö´Â Ŭ¶óÀ̾ðÆ®°¡ ¿äûÇÑ °ªÀ» ¹«½ÃÇÏ°í + Ŭ¶óÀ̾ðÆ®¿¡°Ô ÀÓÀÇÀÇ ½Ã°£À» ¾Ë·ÁÁÙ ¼ö ÀÖ´Ù.

    + +

    DavMinTimeout Áö½Ã¾î´Â Ŭ¶óÀ̾ðÆ®¿¡°Ô + º¸³¾ ÃÖ¼Ò Àá±Ý ½Ã°£À» (ÃÊ´ÜÀ§) ÁöÁ¤ÇÑ´Ù. Microsoft Web Folders´Â + ±âº»°ªÀ¸·Î 120 Ãʸ¦ »ç¿ëÇÑ´Ù. DavMinTimeout¿¡ + (600 ÃÊ¿Í °°ÀÌ) ´õ ³ôÀº °ªÀ» »ç¿ëÇϸé Ŭ¶óÀ̾ðÆ®°¡ ³×Æ®¿÷ + Áö¿¬¶§¹®¿¡ Àá±ÝÀ» ÀҰԵǴ °æ¿ì¸¦ ÁÙÀÏ ¼ö ÀÖ´Ù.

    + +

    ¿¹Á¦

    + <Location /MSWord>
    + + DavMinTimeout 600
    +     + </Location> +

    + +
    +
    top

    WebDAV »ç¿ëÇϱâ

    mod_dav¸¦ »ç¿ëÇÏ·Á¸é httpd.conf @@ -179,85 +258,6 @@ Alias /php-source /home/gstein/php_files
    http://example.com/php-source·Î´Â DAV Ŭ¶óÀ̾ðÆ®¿¡¼­ ½ºÅ©¸³Æ®¸¦ ¼öÁ¤ÇÒ ¼ö ÀÖ´Ù.

    -
    top
    -

    Dav Áö½Ã¾î

    - - - - - - - -
    ¼³¸í:WebDAV HTTP ¸Þ½áµå¸¦ ½ÃÀÛÇÑ´Ù
    ¹®¹ý:Dav On|Off|provider-name
    ±âº»°ª:Dav Off
    »ç¿ëÀå¼Ò:directory
    »óÅÂ:Extension
    ¸ðµâ:mod_dav
    -

    ÁöÁ¤ÇÑ À§Ä¡¿¡¼­ WebDAV HTTP ¸Þ½áµå¸¦ »ç¿ëÇÏ·Á¸é - Dav Áö½Ã¾î¸¦ »ç¿ëÇÑ´Ù:

    - -

    - <Location /foo>
    - - Dav On
    -     - </Location> -

    - -

    On °ªÀº ½ÇÁ¦·Î mod_dav_fs - ¸ðµâÀÌ Á¦°øÇÏ´Â ±âº» Á¦°øÀÚÀÎ filesystemÀÇ - º°ÄªÀÌ´Ù. ¾î¶² À§Ä¡¿¡¼­ DAV¸¦ ½ÃÀÛÇϸé ÇÏÀ§°ø°£¿¡¼­ DAV¸¦ - »ç¿ë¾ÈÇϵµ·Ï ¼³Á¤ÇÒ ¼ö ¾øÀ½À» ÁÖÀÇÇ϶ó. ¿ÏÀüÇÑ - ¼³Á¤¿¹´Â À§ÀÇ ÀýÀ» Âü°íÇ϶ó.

    - -
    - ¼­¹ö¸¦ ¾ÈÀüÇÏ°Ô ±¸¼ºÇÒ¶§±îÁö WebDAVÀ» »ç¿ëÇÏÁö ¸¶¶ó. ±×·¸Áö - ¾ÊÀ¸¸é ´©±¸¶óµµ ¼­¹ö¸¦ ÅëÇØ ÆÄÀÏÀ» ºÐ¹èÇÒ ¼ö ÀÖ°Ô µÈ´Ù. -
    - -
    -
    top
    -

    DavDepthInfinity Áö½Ã¾î

    - - - - - - - -
    ¼³¸í:PROPFINDÀÇ Depth: Infinity ¿äûÀ» Çã°¡ÇÑ´Ù
    ¹®¹ý:DavDepthInfinity on|off
    ±âº»°ª:DavDepthInfinity off
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory
    »óÅÂ:Extension
    ¸ðµâ:mod_dav
    -

    DavDepthInfinity Áö½Ã¾î¸¦ »ç¿ëÇϸé - 'Depth: Infinity' Çì´õ¸¦ °¡Áø PROPFIND ¿äûÀ» - Çã°¡ÇÑ´Ù. ÀÌ·± ¿äûÀ» »ç¿ëÇÏ¿© ¼­ºñ½º°ÅºÎ °ø°ÝÀÌ °¡´ÉÇϱâ - ¶§¹®¿¡ ±âº»ÀûÀ¸·Î Çã¿ëÇÏÁö ¾Ê´Â´Ù.

    - -
    -
    top
    -

    DavMinTimeout Áö½Ã¾î

    - - - - - - - -
    ¼³¸í:¼­¹ö°¡ DAV ÀÚ¿ø¿¡ ´ëÇØ À¯ÁöÇÒ Àá±ÝÀÇ Ãּҽð£
    ¹®¹ý:DavMinTimeout seconds
    ±âº»°ª:DavMinTimeout 0
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory
    »óÅÂ:Extension
    ¸ðµâ:mod_dav
    -

    Ŭ¶óÀ̾ðÆ®°¡ DAV ÀÚ¿ø¿¡ Àá±Ý(lock)À» ¿äûÇÒ¶§ ¼­¹ö°¡ - ¾Ë¾Æ¼­ Àá±ÝÀ» Á¦°ÅÇÒ ¼ö ÀÖ´Â ½Ã°£À» °°ÀÌ ¾Ë·ÁÁÙ ¼ö ÀÖ´Ù. ÀÌ °ªÀº - ´ÜÁö ¿äûÀÏ»ÓÀ̸ç, ¼­¹ö´Â Ŭ¶óÀ̾ðÆ®°¡ ¿äûÇÑ °ªÀ» ¹«½ÃÇÏ°í - Ŭ¶óÀ̾ðÆ®¿¡°Ô ÀÓÀÇÀÇ ½Ã°£À» ¾Ë·ÁÁÙ ¼ö ÀÖ´Ù.

    - -

    DavMinTimeout Áö½Ã¾î´Â Ŭ¶óÀ̾ðÆ®¿¡°Ô - º¸³¾ ÃÖ¼Ò Àá±Ý ½Ã°£À» (ÃÊ´ÜÀ§) ÁöÁ¤ÇÑ´Ù. Microsoft Web Folders´Â - ±âº»°ªÀ¸·Î 120 Ãʸ¦ »ç¿ëÇÑ´Ù. DavMinTimeout¿¡ - (600 ÃÊ¿Í °°ÀÌ) ´õ ³ôÀº °ªÀ» »ç¿ëÇϸé Ŭ¶óÀ̾ðÆ®°¡ ³×Æ®¿÷ - Áö¿¬¶§¹®¿¡ Àá±ÝÀ» ÀҰԵǴ °æ¿ì¸¦ ÁÙÀÏ ¼ö ÀÖ´Ù.

    - -

    ¿¹Á¦

    - <Location /MSWord>
    - - DavMinTimeout 600
    -     - </Location> -

    - -

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_dav_fs.html.en b/docs/manual/mod/mod_dav_fs.html.en index 4e0e0280bc7..4f252369c2f 100644 --- a/docs/manual/mod/mod_dav_fs.html.en +++ b/docs/manual/mod/mod_dav_fs.html.en @@ -56,7 +56,6 @@

    -
    top

    DavLockDB Directive

    @@ -88,6 +87,7 @@ +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_dav_fs.html.fr b/docs/manual/mod/mod_dav_fs.html.fr index f538ffff062..339370cd7d6 100644 --- a/docs/manual/mod/mod_dav_fs.html.fr +++ b/docs/manual/mod/mod_dav_fs.html.fr @@ -60,7 +60,6 @@

    -
    top

    Directive DavLockDB

    @@ -96,6 +95,7 @@ +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_dav_fs.html.ja.utf8 b/docs/manual/mod/mod_dav_fs.html.ja.utf8 index 30094c040c6..6eaae0b1440 100644 --- a/docs/manual/mod/mod_dav_fs.html.ja.utf8 +++ b/docs/manual/mod/mod_dav_fs.html.ja.utf8 @@ -63,7 +63,6 @@

    -
    top

    DavLockDB ディレクティブ

    @@ -86,6 +85,7 @@

    +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_dav_fs.html.ko.euc-kr b/docs/manual/mod/mod_dav_fs.html.ko.euc-kr index 7b04d47b9c4..babdf635bda 100644 --- a/docs/manual/mod/mod_dav_fs.html.ko.euc-kr +++ b/docs/manual/mod/mod_dav_fs.html.ko.euc-kr @@ -58,7 +58,6 @@

    -
    top

    DavLockDB Áö½Ã¾î

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

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_dav_lock.html.en b/docs/manual/mod/mod_dav_lock.html.en index a0a99db81b1..7014c28ae4f 100644 --- a/docs/manual/mod/mod_dav_lock.html.en +++ b/docs/manual/mod/mod_dav_lock.html.en @@ -64,7 +64,6 @@

    -
    top

    DavGenericLockDB Directive

    @@ -94,6 +93,7 @@ +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_dav_lock.html.fr b/docs/manual/mod/mod_dav_lock.html.fr index bfa2192d71c..08a554cae05 100644 --- a/docs/manual/mod/mod_dav_lock.html.fr +++ b/docs/manual/mod/mod_dav_lock.html.fr @@ -69,7 +69,6 @@

    -
    top

    Directive DavGenericLockDB

    @@ -103,6 +102,7 @@ +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_dav_lock.html.ja.utf8 b/docs/manual/mod/mod_dav_lock.html.ja.utf8 index f6775347ce6..bf07de0d9d3 100644 --- a/docs/manual/mod/mod_dav_lock.html.ja.utf8 +++ b/docs/manual/mod/mod_dav_lock.html.ja.utf8 @@ -67,7 +67,6 @@

    -
    top

    DavGenericLockDB ディレクティブ

    @@ -98,6 +97,7 @@ +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_dbd.html.en b/docs/manual/mod/mod_dbd.html.en index 158a00038f9..edd3585bb06 100644 --- a/docs/manual/mod/mod_dbd.html.en +++ b/docs/manual/mod/mod_dbd.html.en @@ -67,120 +67,6 @@

  • Password Formats
    • top
    -
    -

    Connection Pooling

    -

    This module manages database connections, in a manner - optimised for the platform. On non-threaded platforms, - it provides a persistent connection in the manner of - classic LAMP (Linux, Apache, Mysql, Perl/PHP/Python). - On threaded platform, it provides an altogether more - scalable and efficient connection pool, as - described in this - article at ApacheTutor. Note that mod_dbd - supersedes the modules presented in that article.

    -
    top
    -
    -

    Apache DBD API

    -

    mod_dbd exports five functions for other modules - to use. The API is as follows:

    - -
    typedef struct {
-    apr_dbd_t *handle;
-    apr_dbd_driver_t *driver;
-    apr_hash_t *prepared;
-} ap_dbd_t;
-
-/* Export functions to access the database */
-
-/* acquire a connection that MUST be explicitly closed.
- * Returns NULL on error
- */
-AP_DECLARE(ap_dbd_t*) ap_dbd_open(apr_pool_t*, server_rec*);
-
-/* release a connection acquired with ap_dbd_open */
-AP_DECLARE(void) ap_dbd_close(server_rec*, ap_dbd_t*);
-
-/* acquire a connection that will have the lifetime of a request
- * and MUST NOT be explicitly closed.  Return NULL on error.
- * This is the preferred function for most applications.
- */
-AP_DECLARE(ap_dbd_t*) ap_dbd_acquire(request_rec*);
-
-/* acquire a connection that will have the lifetime of a connection
- * and MUST NOT be explicitly closed.  Return NULL on error.
- */
-AP_DECLARE(ap_dbd_t*) ap_dbd_cacquire(conn_rec*);
-
-/* Prepare a statement for use by a client module */
-AP_DECLARE(void) ap_dbd_prepare(server_rec*, const char*, const char*);
-
-/* Also export them as optional functions for modules that prefer it */
-APR_DECLARE_OPTIONAL_FN(ap_dbd_t*, ap_dbd_open, (apr_pool_t*, server_rec*));
-APR_DECLARE_OPTIONAL_FN(void, ap_dbd_close, (server_rec*, ap_dbd_t*));
-APR_DECLARE_OPTIONAL_FN(ap_dbd_t*, ap_dbd_acquire, (request_rec*));
-APR_DECLARE_OPTIONAL_FN(ap_dbd_t*, ap_dbd_cacquire, (conn_rec*));
-APR_DECLARE_OPTIONAL_FN(void, ap_dbd_prepare, (server_rec*, const char*, const char*));
    - -
    top
    -
    -

    SQL Prepared Statements

    -

    mod_dbd supports SQL prepared statements on behalf - of modules that may wish to use them. Each prepared statement - must be assigned a name (label), and they are stored in a hash: - the prepared field of an ap_dbd_t. - Hash entries are of type apr_dbd_prepared_t - and can be used in any of the apr_dbd prepared statement - SQL query or select commands.

    - -

    It is up to dbd user modules to use the prepared statements - and document what statements can be specified in httpd.conf, - or to provide their own directives and use ap_dbd_prepare.

    - -

    Caveat

    - When using prepared statements with a MySQL database, it is preferred to set - reconnect to 0 in the connection string as to avoid errors that - arise from the MySQL client reconnecting without properly resetting the - prepared statements. If set to 1, any broken connections will be attempted - fixed, but as mod_dbd is not informed, the prepared statements will be invalidated. -
    -
    top
    -
    -

    SECURITY WARNING

    - -

    Any web/database application needs to secure itself against SQL - injection attacks. In most cases, Apache DBD is safe, because - applications use prepared statements, and untrusted inputs are - only ever used as data. Of course, if you use it via third-party - modules, you should ascertain what precautions they may require.

    -

    However, the FreeTDS driver is inherently - unsafe. The underlying library doesn't support - prepared statements, so the driver emulates them, and the - untrusted input is merged into the SQL statement.

    -

    It can be made safe by untainting all inputs: - a process inspired by Perl's taint checking. Each input - is matched against a regexp, and only the match is used, - according to the Perl idiom:

    - 
      $untrusted =~ /([a-z]+)/;
-  $trusted = $1;
    -

    To use this, the untainting regexps must be included in the - prepared statements configured. The regexp follows immediately - after the % in the prepared statement, and is enclosed in - curly brackets {}. For example, if your application expects - alphanumeric input, you can use:

    -

    - "SELECT foo FROM bar WHERE input = %s" -

    -

    with other drivers, and suffer nothing worse than a failed query. - But with FreeTDS you'd need:

    -

    - "SELECT foo FROM bar WHERE input = %{([A-Za-z0-9]+)}s" -

    -

    Now anything that doesn't match the regexp's $1 match is - discarded, so the statement is safe.

    -

    An alternative to this may be the third-party ODBC driver, - which offers the security of genuine prepared statements.

    -
    -
    top

    DBDExptime Directive

    @@ -338,6 +224,120 @@ APR_DECLARE_OPTIONAL_FN(void, ap_dbd_prepare, (server_rec*, const char*, const c driver in apr_dbd_mysql.so.

    +
    top
    +
    +

    Connection Pooling

    +

    This module manages database connections, in a manner + optimised for the platform. On non-threaded platforms, + it provides a persistent connection in the manner of + classic LAMP (Linux, Apache, Mysql, Perl/PHP/Python). + On threaded platform, it provides an altogether more + scalable and efficient connection pool, as + described in this + article at ApacheTutor. Note that mod_dbd + supersedes the modules presented in that article.

    +
    top
    +
    +

    Apache DBD API

    +

    mod_dbd exports five functions for other modules + to use. The API is as follows:

    + +
    typedef struct {
+    apr_dbd_t *handle;
+    apr_dbd_driver_t *driver;
+    apr_hash_t *prepared;
+} ap_dbd_t;
+
+/* Export functions to access the database */
+
+/* acquire a connection that MUST be explicitly closed.
+ * Returns NULL on error
+ */
+AP_DECLARE(ap_dbd_t*) ap_dbd_open(apr_pool_t*, server_rec*);
+
+/* release a connection acquired with ap_dbd_open */
+AP_DECLARE(void) ap_dbd_close(server_rec*, ap_dbd_t*);
+
+/* acquire a connection that will have the lifetime of a request
+ * and MUST NOT be explicitly closed.  Return NULL on error.
+ * This is the preferred function for most applications.
+ */
+AP_DECLARE(ap_dbd_t*) ap_dbd_acquire(request_rec*);
+
+/* acquire a connection that will have the lifetime of a connection
+ * and MUST NOT be explicitly closed.  Return NULL on error.
+ */
+AP_DECLARE(ap_dbd_t*) ap_dbd_cacquire(conn_rec*);
+
+/* Prepare a statement for use by a client module */
+AP_DECLARE(void) ap_dbd_prepare(server_rec*, const char*, const char*);
+
+/* Also export them as optional functions for modules that prefer it */
+APR_DECLARE_OPTIONAL_FN(ap_dbd_t*, ap_dbd_open, (apr_pool_t*, server_rec*));
+APR_DECLARE_OPTIONAL_FN(void, ap_dbd_close, (server_rec*, ap_dbd_t*));
+APR_DECLARE_OPTIONAL_FN(ap_dbd_t*, ap_dbd_acquire, (request_rec*));
+APR_DECLARE_OPTIONAL_FN(ap_dbd_t*, ap_dbd_cacquire, (conn_rec*));
+APR_DECLARE_OPTIONAL_FN(void, ap_dbd_prepare, (server_rec*, const char*, const char*));
    + +
    top
    +
    +

    SQL Prepared Statements

    +

    mod_dbd supports SQL prepared statements on behalf + of modules that may wish to use them. Each prepared statement + must be assigned a name (label), and they are stored in a hash: + the prepared field of an ap_dbd_t. + Hash entries are of type apr_dbd_prepared_t + and can be used in any of the apr_dbd prepared statement + SQL query or select commands.

    + +

    It is up to dbd user modules to use the prepared statements + and document what statements can be specified in httpd.conf, + or to provide their own directives and use ap_dbd_prepare.

    + +

    Caveat

    + When using prepared statements with a MySQL database, it is preferred to set + reconnect to 0 in the connection string as to avoid errors that + arise from the MySQL client reconnecting without properly resetting the + prepared statements. If set to 1, any broken connections will be attempted + fixed, but as mod_dbd is not informed, the prepared statements will be invalidated. +
    +
    top
    +
    +

    SECURITY WARNING

    + +

    Any web/database application needs to secure itself against SQL + injection attacks. In most cases, Apache DBD is safe, because + applications use prepared statements, and untrusted inputs are + only ever used as data. Of course, if you use it via third-party + modules, you should ascertain what precautions they may require.

    +

    However, the FreeTDS driver is inherently + unsafe. The underlying library doesn't support + prepared statements, so the driver emulates them, and the + untrusted input is merged into the SQL statement.

    +

    It can be made safe by untainting all inputs: + a process inspired by Perl's taint checking. Each input + is matched against a regexp, and only the match is used, + according to the Perl idiom:

    + 
      $untrusted =~ /([a-z]+)/;
+  $trusted = $1;
    +

    To use this, the untainting regexps must be included in the + prepared statements configured. The regexp follows immediately + after the % in the prepared statement, and is enclosed in + curly brackets {}. For example, if your application expects + alphanumeric input, you can use:

    +

    + "SELECT foo FROM bar WHERE input = %s" +

    +

    with other drivers, and suffer nothing worse than a failed query. + But with FreeTDS you'd need:

    +

    + "SELECT foo FROM bar WHERE input = %{([A-Za-z0-9]+)}s" +

    +

    Now anything that doesn't match the regexp's $1 match is + discarded, so the statement is safe.

    +

    An alternative to this may be the third-party ODBC driver, + which offers the security of genuine prepared statements.

    +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_dbd.html.fr b/docs/manual/mod/mod_dbd.html.fr index cdc08466d2c..584370f6da8 100644 --- a/docs/manual/mod/mod_dbd.html.fr +++ b/docs/manual/mod/mod_dbd.html.fr @@ -69,133 +69,6 @@ passe

    top
    -
    -

    Regroupement des connexions

    -

    Ce module gère de manière optimisée en fonction de la plate-forme - les connexions aux bases de données. Sur les plates-formes non - threadées, il maintient une connexion persistente à la manière d'un - LAMP classique (Linux, Apache, Mysql, Perl/PHP/Python). Sur les - plates-formes threadées, il maintient un groupe de - connexions à la fois plus évolutif et plus efficace, comme - décrit dans cet - article d'ApacheTutor. Notez que mod_dbd - remplace les modules présentés dans cet article.

    -
    top
    -
    -

    API DBD d'Apache

    -

    mod_dbd exporte cinq fonctions que d'autres - modules pourront utiliser. L'API se présente comme suit :

    - - 
    typedef struct {
-    apr_dbd_t *handle;
-    apr_dbd_driver_t *driver;
-    apr_hash_t *prepared;
-} ap_dbd_t;
-
-/* Fonctions exportées pour accéder à la base de données */
-
-/* ouvre une connexion qui DOIT avoir été explicitement fermée.
- * Renvoie NULL en cas d'erreur
- */
-AP_DECLARE(ap_dbd_t*) ap_dbd_open(apr_pool_t*, server_rec*);
-
-/* ferme une connexion ouverte avec ap_dbd_open */
-AP_DECLARE(void) ap_dbd_close(server_rec*, ap_dbd_t*);
-
-/* acquiert une connexion qui aura la durée de vie de la requête et qui
- * NE DOIT PAS avoir été explicitement fermée. Renvoie NULL en cas
- * d'erreur. C'est la fonction recommandée pour la plupart des
- * applications.
- */
-AP_DECLARE(ap_dbd_t*) ap_dbd_acquire(request_rec*);
-
-/* acquiert une connexion qui aura la durée de vie d'une connexion et
- * qui NE DOIT PAS avoir été explicitement fermée. Renvoie NULL en cas
- * d'erreur.
- */
-AP_DECLARE(ap_dbd_t*) ap_dbd_cacquire(conn_rec*);
-
-/* Prépare une requête qu'un module client pourra utiliser */
-AP_DECLARE(void) ap_dbd_prepare(server_rec*, const char*, const char*);
-
-/* Exporte aussi ces fonctions à titre optionnel mour les modules qui
- * péfèreraient les utiliser */
-APR_DECLARE_OPTIONAL_FN(ap_dbd_t*, ap_dbd_open, (apr_pool_t*, server_rec*));
-APR_DECLARE_OPTIONAL_FN(void, ap_dbd_close, (server_rec*, ap_dbd_t*));
-APR_DECLARE_OPTIONAL_FN(ap_dbd_t*, ap_dbd_acquire, (request_rec*));
-APR_DECLARE_OPTIONAL_FN(ap_dbd_t*, ap_dbd_cacquire, (conn_rec*));
-APR_DECLARE_OPTIONAL_FN(void, ap_dbd_prepare, (server_rec*, const char*, const char*));
    - -
    top
    -
    -

    Requêtes SQL préparées

    -

    mod_dbd supporte les requêtes SQL préparées à - destination des modules qui pourraient les utiliser. Chaque requête - préparée doit posséder un nom (étiquette), et est stockée dans un - condensé (hash) : les condensés sont du type - apr_dbd_prepared_t et s'utilisent dans toute requête - SQL ou commande select préparée par apr_dbd.

    - -

    Il est du ressort des modules utilisateurs de dbd d'utiliser les - requêtes préparées et de préciser quelles requêtes doivent être - spécifiées dans httpd.conf, ou de fournir leurs propres directives - et d'utiliser ap_dbd_prepare.

    - -

    Avertissement

    - Lorsqu'on utilise des requêtes préparées avec des bases de - données MySQL, il est préférable de définir - reconnect à 0 dans la chaîne de connexion, afin - d'éviter des erreurs provoquées par un client MySQL qui se - reconnecterait sans réinitialiser correctement les requêtes - préparées. Si reconnect est défini à 1, toute - connexion défectueuse sera sensée être réparée, mais comme - mod_dbd n'en est pas informé, les requêtes préparées seront - invalidées. -
    -
    top
    -
    -

    AVERTISSEMENT DE SECURITE

    - -

    Toute application web impliquant une base de données doit se - protéger elle-même contre les attaques de type injection SQL. Dans - la plupart des cas Apache DBD est sûr, car les applications - utilisent des requêtes préparées, et les entrées non sures ne seront - utilisées qu'à titre de données. Bien entendu, si vous l'utilisez - via un module tiers, vous devez être au fait des précautions à - prendre.

    -

    Cependant, le pilote FreeTDS est non - sûr de par sa nature-même. Comme la bibliothèque - sous-jacente ne supporte pas les requêtes préparées, le pilote en - effectue une émulation, et les entrées non sûres sont fusionnées - avec la requête SQL.

    -

    Il peut être sécurisé en décontaminant toutes les - entrées : un processus inspiré de la recherche de contaminations - (taint mode) de - Perl. Chaque entrée est comparée à une expression rationnelle, et - seules les entrées qui correspondent sont utilisées, en accord avec - le langage Perl :

    - 
      $untrusted =~ /([a-z]+)/;
-  $trusted = $1;
    -

    Pour utiliser ceci, les expressions rationnelles de - décontamination doivent être incluses dans les requêtes préparées. - L'expression rationnelle doit se situer immédiatement après le - caractère % dans la requête préparée, et doit être entourée - d'accolades {}. Par exemple, si votre application attend une entrée - alphanumérique, vous pouvez utiliser :

    -

    - "SELECT foo FROM bar WHERE input = %s" -

    -

    avec d'autres pilotes, et ne risquer au pire qu'une requête - échouée. Mais avec FreeTDS, vous devez utiliser :

    -

    - "SELECT foo FROM bar WHERE input = %{([A-Za-z0-9]+)}s" -

    -

    tout ce qui ne correspond pas à l'expression rationnelle est - alors rejeté, et la requête est maintenant sûre.

    -

    Alternativement, vous pouvez utiliser le pilote ODBC tiers, qui - offre la sécurité des requêtes préparées authentiques.

    -
    -
    top

    Directive DBDExptime

    Description:Keepalive time for idle connections
    @@ -365,6 +238,133 @@ donn dans la bibliothèque apr_dbd_mysql.so.

    +
    top
    +
    +

    Regroupement des connexions

    +

    Ce module gère de manière optimisée en fonction de la plate-forme + les connexions aux bases de données. Sur les plates-formes non + threadées, il maintient une connexion persistente à la manière d'un + LAMP classique (Linux, Apache, Mysql, Perl/PHP/Python). Sur les + plates-formes threadées, il maintient un groupe de + connexions à la fois plus évolutif et plus efficace, comme + décrit dans cet + article d'ApacheTutor. Notez que mod_dbd + remplace les modules présentés dans cet article.

    +
    top
    +
    +

    API DBD d'Apache

    +

    mod_dbd exporte cinq fonctions que d'autres + modules pourront utiliser. L'API se présente comme suit :

    + + 
    typedef struct {
+    apr_dbd_t *handle;
+    apr_dbd_driver_t *driver;
+    apr_hash_t *prepared;
+} ap_dbd_t;
+
+/* Fonctions exportées pour accéder à la base de données */
+
+/* ouvre une connexion qui DOIT avoir été explicitement fermée.
+ * Renvoie NULL en cas d'erreur
+ */
+AP_DECLARE(ap_dbd_t*) ap_dbd_open(apr_pool_t*, server_rec*);
+
+/* ferme une connexion ouverte avec ap_dbd_open */
+AP_DECLARE(void) ap_dbd_close(server_rec*, ap_dbd_t*);
+
+/* acquiert une connexion qui aura la durée de vie de la requête et qui
+ * NE DOIT PAS avoir été explicitement fermée. Renvoie NULL en cas
+ * d'erreur. C'est la fonction recommandée pour la plupart des
+ * applications.
+ */
+AP_DECLARE(ap_dbd_t*) ap_dbd_acquire(request_rec*);
+
+/* acquiert une connexion qui aura la durée de vie d'une connexion et
+ * qui NE DOIT PAS avoir été explicitement fermée. Renvoie NULL en cas
+ * d'erreur.
+ */
+AP_DECLARE(ap_dbd_t*) ap_dbd_cacquire(conn_rec*);
+
+/* Prépare une requête qu'un module client pourra utiliser */
+AP_DECLARE(void) ap_dbd_prepare(server_rec*, const char*, const char*);
+
+/* Exporte aussi ces fonctions à titre optionnel mour les modules qui
+ * péfèreraient les utiliser */
+APR_DECLARE_OPTIONAL_FN(ap_dbd_t*, ap_dbd_open, (apr_pool_t*, server_rec*));
+APR_DECLARE_OPTIONAL_FN(void, ap_dbd_close, (server_rec*, ap_dbd_t*));
+APR_DECLARE_OPTIONAL_FN(ap_dbd_t*, ap_dbd_acquire, (request_rec*));
+APR_DECLARE_OPTIONAL_FN(ap_dbd_t*, ap_dbd_cacquire, (conn_rec*));
+APR_DECLARE_OPTIONAL_FN(void, ap_dbd_prepare, (server_rec*, const char*, const char*));
    + +
    top
    +
    +

    Requêtes SQL préparées

    +

    mod_dbd supporte les requêtes SQL préparées à + destination des modules qui pourraient les utiliser. Chaque requête + préparée doit posséder un nom (étiquette), et est stockée dans un + condensé (hash) : les condensés sont du type + apr_dbd_prepared_t et s'utilisent dans toute requête + SQL ou commande select préparée par apr_dbd.

    + +

    Il est du ressort des modules utilisateurs de dbd d'utiliser les + requêtes préparées et de préciser quelles requêtes doivent être + spécifiées dans httpd.conf, ou de fournir leurs propres directives + et d'utiliser ap_dbd_prepare.

    + +

    Avertissement

    + Lorsqu'on utilise des requêtes préparées avec des bases de + données MySQL, il est préférable de définir + reconnect à 0 dans la chaîne de connexion, afin + d'éviter des erreurs provoquées par un client MySQL qui se + reconnecterait sans réinitialiser correctement les requêtes + préparées. Si reconnect est défini à 1, toute + connexion défectueuse sera sensée être réparée, mais comme + mod_dbd n'en est pas informé, les requêtes préparées seront + invalidées. +
    +
    top
    +
    +

    AVERTISSEMENT DE SECURITE

    + +

    Toute application web impliquant une base de données doit se + protéger elle-même contre les attaques de type injection SQL. Dans + la plupart des cas Apache DBD est sûr, car les applications + utilisent des requêtes préparées, et les entrées non sures ne seront + utilisées qu'à titre de données. Bien entendu, si vous l'utilisez + via un module tiers, vous devez être au fait des précautions à + prendre.

    +

    Cependant, le pilote FreeTDS est non + sûr de par sa nature-même. Comme la bibliothèque + sous-jacente ne supporte pas les requêtes préparées, le pilote en + effectue une émulation, et les entrées non sûres sont fusionnées + avec la requête SQL.

    +

    Il peut être sécurisé en décontaminant toutes les + entrées : un processus inspiré de la recherche de contaminations + (taint mode) de + Perl. Chaque entrée est comparée à une expression rationnelle, et + seules les entrées qui correspondent sont utilisées, en accord avec + le langage Perl :

    + 
      $untrusted =~ /([a-z]+)/;
+  $trusted = $1;
    +

    Pour utiliser ceci, les expressions rationnelles de + décontamination doivent être incluses dans les requêtes préparées. + L'expression rationnelle doit se situer immédiatement après le + caractère % dans la requête préparée, et doit être entourée + d'accolades {}. Par exemple, si votre application attend une entrée + alphanumérique, vous pouvez utiliser :

    +

    + "SELECT foo FROM bar WHERE input = %s" +

    +

    avec d'autres pilotes, et ne risquer au pire qu'une requête + échouée. Mais avec FreeTDS, vous devez utiliser :

    +

    + "SELECT foo FROM bar WHERE input = %{([A-Za-z0-9]+)}s" +

    +

    tout ce qui ne correspond pas à l'expression rationnelle est + alors rejeté, et la requête est maintenant sûre.

    +

    Alternativement, vous pouvez utiliser le pilote ODBC tiers, qui + offre la sécurité des requêtes préparées authentiques.

    +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_deflate.html.en b/docs/manual/mod/mod_deflate.html.en index ec74a5f2aca..41852d194be 100644 --- a/docs/manual/mod/mod_deflate.html.en +++ b/docs/manual/mod/mod_deflate.html.en @@ -64,172 +64,6 @@ content

  • Filters
    • top
    -
    -

    Sample Configurations

    -

    Compression and TLS

    -

    Some web applications are vulnerable to an information disclosure - attack when a TLS connection carries deflate compressed data. For more - information, review the details of the "BREACH" family of attacks.

    -
    -

    This is a simple configuration that compresses common text-based content types.

    - -

    Compress only a few types

    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript
    -
    - -
    top
    -
    -

    Enabling Compression

    -

    Compression and TLS

    -

    Some web applications are vulnerable to an information disclosure - attack when a TLS connection carries deflate compressed data. For more - information, review the details of the "BREACH" family of attacks.

    -
    - -

    Output Compression

    -

    Compression is implemented by the DEFLATE - filter. The following directive - will enable compression for documents in the container where it - is placed:

    - - 
    SetOutputFilter DEFLATE
-SetEnvIfNoCase Request_URI "\.(?:gif|jpe?g|png)$" no-gzip
    - - -

    If you want to restrict the compression to particular MIME types - in general, you may use the AddOutputFilterByType directive. Here is an example of - enabling compression only for the html files of the Apache - documentation:

    - - 
    <Directory "/your-server-root/manual">
-    AddOutputFilterByType DEFLATE text/html
-</Directory>
    - - -

    Note

    - The DEFLATE filter is always inserted after RESOURCE - filters like PHP or SSI. It never touches internal subrequests. -
    -

    Note

    - There is an environment variable force-gzip, - set via SetEnv, which - will ignore the accept-encoding setting of your browser and will - send compressed output. -
    - - -

    Output Decompression

    -

    The mod_deflate module also provides a filter for - inflating/uncompressing a gzip compressed response body. In order to activate - this feature you have to insert the INFLATE filter into - the output filter chain using SetOutputFilter or AddOutputFilter, for example:

    - - 
    <Location "/dav-area">
-    ProxyPass "http://example.com/"
-    SetOutputFilter INFLATE
-</Location>
    - - -

    This Example will uncompress gzip'ed output from example.com, so other - filters can do further processing with it. -

    - - -

    Input Decompression

    -

    The mod_deflate module also provides a filter for - decompressing a gzip compressed request body . In order to activate - this feature you have to insert the DEFLATE filter into - the input filter chain using SetInputFilter or AddInputFilter, for example:

    - - 
    <Location "/dav-area">
-    SetInputFilter DEFLATE
-</Location>
    - - -

    Now if a request contains a Content-Encoding: - gzip header, the body will be automatically decompressed. - Few browsers have the ability to gzip request bodies. However, - some special applications actually do support request - compression, for instance some WebDAV clients.

    - -

    Note on Content-Length

    -

    If you evaluate the request body yourself, don't trust - the Content-Length header! - The Content-Length header reflects the length of the - incoming data from the client and not the byte count of - the decompressed data stream.

    -
    - -
    top
    -
    -

    Dealing with proxy servers

    - -

    The mod_deflate module sends a Vary: - Accept-Encoding HTTP response header to alert proxies that - a cached response should be sent only to clients that send the - appropriate Accept-Encoding request header. This - prevents compressed content from being sent to a client that will - not understand it.

    - -

    If you use some special exclusions dependent - on, for example, the User-Agent header, you must - manually configure an addition to the Vary header - to alert proxies of the additional restrictions. For example, - in a typical configuration where the addition of the DEFLATE - filter depends on the User-Agent, you should add:

    - - 
    Header append Vary User-Agent
    - - -

    If your decision about compression depends on other information - than request headers (e.g. HTTP version), you have to set the - Vary header to the value *. This prevents - compliant proxies from caching entirely.

    - -

    Example

    Header set Vary *
    -
    -
    top
    -
    -

    Serving pre-compressed -content

    - -

    Since mod_deflate re-compresses content each - time a request is made, some performance benefit can be derived by - pre-compressing the content and telling mod_deflate to serve them - without re-compressing them. This may be accomplished using a - configuration like the following:

    - - 
    <IfModule mod_headers.c>
-    # Serve gzip compressed CSS files if they exist 
-    # and the client accepts gzip.
-    RewriteCond "%{HTTP:Accept-encoding}" "gzip"
-    RewriteCond "%{REQUEST_FILENAME}\.gz" -s
-    RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]
-
-    # Serve gzip compressed JS files if they exist 
-    # and the client accepts gzip.
-    RewriteCond "%{HTTP:Accept-encoding}" "gzip"
-    RewriteCond "%{REQUEST_FILENAME}\.gz" -s
-    RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]
-
-
-    # Serve correct content types, and prevent mod_deflate double gzip.
-    RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1]
-    RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1]
-
-
-    <FilesMatch "(\.js\.gz|\.css\.gz)$">
-      # Serve correct encoding type.
-      Header append Content-Encoding gzip
-
-      # Force proxies to cache gzipped & 
-      # non-gzipped css/js files separately.
-      Header append Vary Accept-Encoding
-    </FilesMatch>
-</IfModule>
    - - -
    -
    top

    DeflateBufferSize Directive

    Description:Durée de vie des connexions inactives
    @@ -397,6 +231,172 @@ CustomLog "logs/deflate_log" deflate zlib compression window size (a value between 1 and 15). Generally, the higher the window size, the higher can the compression ratio be expected.

    + +
    top
    +
    +

    Sample Configurations

    +

    Compression and TLS

    +

    Some web applications are vulnerable to an information disclosure + attack when a TLS connection carries deflate compressed data. For more + information, review the details of the "BREACH" family of attacks.

    +
    +

    This is a simple configuration that compresses common text-based content types.

    + +

    Compress only a few types

    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript
    +
    + +
    top
    +
    +

    Enabling Compression

    +

    Compression and TLS

    +

    Some web applications are vulnerable to an information disclosure + attack when a TLS connection carries deflate compressed data. For more + information, review the details of the "BREACH" family of attacks.

    +
    + +

    Output Compression

    +

    Compression is implemented by the DEFLATE + filter. The following directive + will enable compression for documents in the container where it + is placed:

    + + 
    SetOutputFilter DEFLATE
+SetEnvIfNoCase Request_URI "\.(?:gif|jpe?g|png)$" no-gzip
    + + +

    If you want to restrict the compression to particular MIME types + in general, you may use the AddOutputFilterByType directive. Here is an example of + enabling compression only for the html files of the Apache + documentation:

    + + 
    <Directory "/your-server-root/manual">
+    AddOutputFilterByType DEFLATE text/html
+</Directory>
    + + +

    Note

    + The DEFLATE filter is always inserted after RESOURCE + filters like PHP or SSI. It never touches internal subrequests. +
    +

    Note

    + There is an environment variable force-gzip, + set via SetEnv, which + will ignore the accept-encoding setting of your browser and will + send compressed output. +
    + + +

    Output Decompression

    +

    The mod_deflate module also provides a filter for + inflating/uncompressing a gzip compressed response body. In order to activate + this feature you have to insert the INFLATE filter into + the output filter chain using SetOutputFilter or AddOutputFilter, for example:

    + + 
    <Location "/dav-area">
+    ProxyPass "http://example.com/"
+    SetOutputFilter INFLATE
+</Location>
    + + +

    This Example will uncompress gzip'ed output from example.com, so other + filters can do further processing with it. +

    + + +

    Input Decompression

    +

    The mod_deflate module also provides a filter for + decompressing a gzip compressed request body . In order to activate + this feature you have to insert the DEFLATE filter into + the input filter chain using SetInputFilter or AddInputFilter, for example:

    + + 
    <Location "/dav-area">
+    SetInputFilter DEFLATE
+</Location>
    + + +

    Now if a request contains a Content-Encoding: + gzip header, the body will be automatically decompressed. + Few browsers have the ability to gzip request bodies. However, + some special applications actually do support request + compression, for instance some WebDAV clients.

    + +

    Note on Content-Length

    +

    If you evaluate the request body yourself, don't trust + the Content-Length header! + The Content-Length header reflects the length of the + incoming data from the client and not the byte count of + the decompressed data stream.

    +
    + +
    top
    +
    +

    Dealing with proxy servers

    + +

    The mod_deflate module sends a Vary: + Accept-Encoding HTTP response header to alert proxies that + a cached response should be sent only to clients that send the + appropriate Accept-Encoding request header. This + prevents compressed content from being sent to a client that will + not understand it.

    + +

    If you use some special exclusions dependent + on, for example, the User-Agent header, you must + manually configure an addition to the Vary header + to alert proxies of the additional restrictions. For example, + in a typical configuration where the addition of the DEFLATE + filter depends on the User-Agent, you should add:

    + + 
    Header append Vary User-Agent
    + + +

    If your decision about compression depends on other information + than request headers (e.g. HTTP version), you have to set the + Vary header to the value *. This prevents + compliant proxies from caching entirely.

    + +

    Example

    Header set Vary *
    +
    +
    top
    +
    +

    Serving pre-compressed +content

    + +

    Since mod_deflate re-compresses content each + time a request is made, some performance benefit can be derived by + pre-compressing the content and telling mod_deflate to serve them + without re-compressing them. This may be accomplished using a + configuration like the following:

    + + 
    <IfModule mod_headers.c>
+    # Serve gzip compressed CSS files if they exist 
+    # and the client accepts gzip.
+    RewriteCond "%{HTTP:Accept-encoding}" "gzip"
+    RewriteCond "%{REQUEST_FILENAME}\.gz" -s
+    RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]
+
+    # Serve gzip compressed JS files if they exist 
+    # and the client accepts gzip.
+    RewriteCond "%{HTTP:Accept-encoding}" "gzip"
+    RewriteCond "%{REQUEST_FILENAME}\.gz" -s
+    RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]
+
+
+    # Serve correct content types, and prevent mod_deflate double gzip.
+    RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1]
+    RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1]
+
+
+    <FilesMatch "(\.js\.gz|\.css\.gz)$">
+      # Serve correct encoding type.
+      Header append Content-Encoding gzip
+
+      # Force proxies to cache gzipped & 
+      # non-gzipped css/js files separately.
+      Header append Vary Accept-Encoding
+    </FilesMatch>
+</IfModule>
    + +
    diff --git a/docs/manual/mod/mod_deflate.html.fr b/docs/manual/mod/mod_deflate.html.fr index 1397ca481d4..7e543341115 100644 --- a/docs/manual/mod/mod_deflate.html.fr +++ b/docs/manual/mod/mod_deflate.html.fr @@ -63,148 +63,6 @@ client
  • Les filtres
    • top
    -
    -

    Exemples de configurations

    -

    Compression et TLS

    -

    Certaines applications web sont vulnérables aux attaques - visant le vol d'information lorsqu'une connexion TLS transmet - des données compressées par deflate. Pour plus de détails, - étudiez les attaques de la famille "BREACH".

    -
    -

    Voici une configuration simple qui comprime les contenus à base - de texte courants.

    - -

    Ne comprime que certains types de documents

    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript
    -
    - -
    top
    -
    -

    Activation de la compression

    - -

    Compression et TLS

    -

    Certaines applications web sont vulnérables aux attaques pour - vol d'information lorsque la connexion TLS transmet des données - compressées par deflate. Pour plus d'informations, voir en - détails la famille d'attaques de type "BREACH".

    -
    - -

    Compression de la sortie

    -

    La compression est implémentée par le filtre DEFLATE. La - directive suivante active la compression des documents dans le - conteneur où elle est placée :

    - - 
    SetOutputFilter DEFLATE
-SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip
    - - -

    Si vous voulez limiter la compression à certains types MIME - particuliers, vous pouvez utiliser la directive AddOutputFilterByType. Voici un exemple - où la compression n'est activée que pour les fichiers html de la - documentation d'Apache :

    - - 
    <Directory "/your-server-root/manual">
-    AddOutputFilterByType DEFLATE text/html
-</Directory>
    - - -

    Note

    - Le filtre DEFLATE est toujours inséré après les - filtres RESOURCE comme PHP ou SSI. Il n'affecte jamais les - sous-requêtes internes. -
    -

    Note

    - La variable d'environnement force-gzip, définie à - l'aide de la directive SetEnv, permet d'ignorer la - configuration de votre navigateur quant aux codages acceptés, et - d'envoyer sans condition une sortie comprimée. -
    - - -

    Décompression de la sortie

    -

    Le module mod_deflate fournit aussi un filtre - permettant de décomprimer un corps de réponse comprimé par gzip. - Pour activer cette fonctionnalité, vous devez insérer le filtre - INFLATE dans la chaîne de filtrage en sortie via la - directive SetOutputFilter ou - AddOutputFilter, comme - dans l'exemple suivant :

    - - 
    <Location /dav-area>
-    ProxyPass http://example.com/
-    SetOutputFilter INFLATE
-</Location>
    - - -

    Dans cet exemple, les sorties comprimées par gzip en - provenance de example.com seront décomprimées afin de pouvoir - être éventuellement traitées par d'autres filtres. -

    - - -

    Décompression de l'entrée

    -

    Le module mod_deflate fournit également un filtre - permettant de décomprimer un corps de requête comprimé par gzip. - Pour activer cette fonctionnalité, vous devez insérer le filtre - DEFLATE dans la chaîne de filtrage en entrée via la - directive SetInputFilter ou - AddInputFilter, comme - dans l'exemple suivant :

    - - 
    <Location /dav-area>
-    SetInputFilter DEFLATE
-</Location>
    - - -

    Désormais, si une requête contient un en-tête - Content-Encoding: gzip, son corps sera - automatiquement décomprimé. Peu de navigateurs sont actuellement - en mesure de comprimer les corps de requêtes. Cependant, - certaines applications spécialisées supportent les requêtes - comprimées, comme par exemple certains clients WebDAV.

    - -

    Note à propos de l'en-tête - Content-Length

    -

    Si vous évaluez vous-même la taille du corps de requête, - ne faites pas confiance à l'en-tête - Content-Length! L'en-tête - Content-Length indique la longueur des données en provenance du - client, et non la quantité d'octets que représente le - flux de données décompressé.

    -
    - -
    top
    -
    -

    Prise en compte des serveurs mandataires

    - -

    Le module mod_deflate envoie un en-tête de - réponse HTTP Vary: Accept-Encoding pour avertir les - mandataires qu'une réponse enregistrée dans le cache ne doit être - envoyée qu'aux clients qui ont envoyé l'en-tête de requête - Accept-Encoding approprié. Ceci permet d'éviter l'envoi - d'un contenu comprimé à un client qui ne sera pas en mesure - de l'interpréter.

    - -

    Si vous avez défini des exclusions spécifiques dépendant, par - exemple, de l'en-tête User-Agent, vous devez - ajouter manuellement des données à l'en-tête Vary afin - d'informer les mandataires des restrictions supplémentaires. Par - exemple, dans la configuration classique où l'addition du filtre - DEFLATE dépend du contenu de l'en-tête - User-Agent, vous devez spécifier :

    - - 
    Header append Vary User-Agent
    - - -

    Si votre décision de comprimer le contenu dépend d'autres - informations que celles contenues dans les en-têtes de la requête - (par exemple la version HTTP), vous devez attribuer à l'en-tête - Vary la valeur *, ce qui permet d'empêcher - les mandataires compatibles de tout mettre en cache.

    - -

    Exemple

    Header set Vary *
    -
    -
    -
    top

    Directive DeflateBufferSize

    Description:Fragment size to be compressed at one time by zlib
    1 et 15). En général, plus grande sera la taille de la fenêtre, plus grand sera le taux de compression auquel on pourra s'attendre.

    + +
    top
    +
    +

    Exemples de configurations

    +

    Compression et TLS

    +

    Certaines applications web sont vulnérables aux attaques + visant le vol d'information lorsqu'une connexion TLS transmet + des données compressées par deflate. Pour plus de détails, + étudiez les attaques de la famille "BREACH".

    +
    +

    Voici une configuration simple qui comprime les contenus à base + de texte courants.

    + +

    Ne comprime que certains types de documents

    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript
    +
    + +
    top
    +
    +

    Activation de la compression

    + +

    Compression et TLS

    +

    Certaines applications web sont vulnérables aux attaques pour + vol d'information lorsque la connexion TLS transmet des données + compressées par deflate. Pour plus d'informations, voir en + détails la famille d'attaques de type "BREACH".

    +
    + +

    Compression de la sortie

    +

    La compression est implémentée par le filtre DEFLATE. La + directive suivante active la compression des documents dans le + conteneur où elle est placée :

    + + 
    SetOutputFilter DEFLATE
+SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip
    + + +

    Si vous voulez limiter la compression à certains types MIME + particuliers, vous pouvez utiliser la directive AddOutputFilterByType. Voici un exemple + où la compression n'est activée que pour les fichiers html de la + documentation d'Apache :

    + + 
    <Directory "/your-server-root/manual">
+    AddOutputFilterByType DEFLATE text/html
+</Directory>
    + + +

    Note

    + Le filtre DEFLATE est toujours inséré après les + filtres RESOURCE comme PHP ou SSI. Il n'affecte jamais les + sous-requêtes internes. +
    +

    Note

    + La variable d'environnement force-gzip, définie à + l'aide de la directive SetEnv, permet d'ignorer la + configuration de votre navigateur quant aux codages acceptés, et + d'envoyer sans condition une sortie comprimée. +
    + + +

    Décompression de la sortie

    +

    Le module mod_deflate fournit aussi un filtre + permettant de décomprimer un corps de réponse comprimé par gzip. + Pour activer cette fonctionnalité, vous devez insérer le filtre + INFLATE dans la chaîne de filtrage en sortie via la + directive SetOutputFilter ou + AddOutputFilter, comme + dans l'exemple suivant :

    + + 
    <Location /dav-area>
+    ProxyPass http://example.com/
+    SetOutputFilter INFLATE
+</Location>
    + + +

    Dans cet exemple, les sorties comprimées par gzip en + provenance de example.com seront décomprimées afin de pouvoir + être éventuellement traitées par d'autres filtres. +

    + + +

    Décompression de l'entrée

    +

    Le module mod_deflate fournit également un filtre + permettant de décomprimer un corps de requête comprimé par gzip. + Pour activer cette fonctionnalité, vous devez insérer le filtre + DEFLATE dans la chaîne de filtrage en entrée via la + directive SetInputFilter ou + AddInputFilter, comme + dans l'exemple suivant :

    + + 
    <Location /dav-area>
+    SetInputFilter DEFLATE
+</Location>
    + + +

    Désormais, si une requête contient un en-tête + Content-Encoding: gzip, son corps sera + automatiquement décomprimé. Peu de navigateurs sont actuellement + en mesure de comprimer les corps de requêtes. Cependant, + certaines applications spécialisées supportent les requêtes + comprimées, comme par exemple certains clients WebDAV.

    + +

    Note à propos de l'en-tête + Content-Length

    +

    Si vous évaluez vous-même la taille du corps de requête, + ne faites pas confiance à l'en-tête + Content-Length! L'en-tête + Content-Length indique la longueur des données en provenance du + client, et non la quantité d'octets que représente le + flux de données décompressé.

    +
    + +
    top
    +
    +

    Prise en compte des serveurs mandataires

    + +

    Le module mod_deflate envoie un en-tête de + réponse HTTP Vary: Accept-Encoding pour avertir les + mandataires qu'une réponse enregistrée dans le cache ne doit être + envoyée qu'aux clients qui ont envoyé l'en-tête de requête + Accept-Encoding approprié. Ceci permet d'éviter l'envoi + d'un contenu comprimé à un client qui ne sera pas en mesure + de l'interpréter.

    + +

    Si vous avez défini des exclusions spécifiques dépendant, par + exemple, de l'en-tête User-Agent, vous devez + ajouter manuellement des données à l'en-tête Vary afin + d'informer les mandataires des restrictions supplémentaires. Par + exemple, dans la configuration classique où l'addition du filtre + DEFLATE dépend du contenu de l'en-tête + User-Agent, vous devez spécifier :

    + + 
    Header append Vary User-Agent
    + + +

    Si votre décision de comprimer le contenu dépend d'autres + informations que celles contenues dans les en-têtes de la requête + (par exemple la version HTTP), vous devez attribuer à l'en-tête + Vary la valeur *, ce qui permet d'empêcher + les mandataires compatibles de tout mettre en cache.

    + +

    Exemple

    Header set Vary *
    +
    diff --git a/docs/manual/mod/mod_deflate.html.ja.utf8 b/docs/manual/mod/mod_deflate.html.ja.utf8 index 481f8350150..ef35210b7af 100644 --- a/docs/manual/mod/mod_deflate.html.ja.utf8 +++ b/docs/manual/mod/mod_deflate.html.ja.utf8 @@ -64,6 +64,166 @@
  • Filters
    • top
    +

    DeflateBufferSize ディレクティブ

    +
    Description:Taille du fragment que zlib devra comprimer en une seule @@ -389,6 +247,148 @@ compression
    + + + + + + +
    説明:zlib が一度に圧縮する塊の大きさ
    構文:DeflateBufferSize value
    デフォルト:DeflateBufferSize 8096
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Extension
    モジュール:mod_deflate
    +

    DeflateBufferSize ディレクティブは + zlib が一度に圧縮する塊の大きさをバイト単位で指定します。

    + +
    +
    top
    +

    DeflateCompressionLevel ディレクティブ

    + + + + + + + + +
    説明:出力に対して行なう圧縮の程度
    構文:DeflateCompressionLevel value
    デフォルト:Zlib のデフォルト
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Extension
    モジュール:mod_deflate
    互換性:This directive is available since Apache 2.0.45
    +

    DeflateCompressionLevel ディレクティブは + 圧縮の程度を設定します。大きな値では、より圧縮が行なわれますが、 + CPU 資源を消費します。

    +

    値は 1 (低圧縮) から 9 (高圧縮) です。

    + +
    +
    top
    +

    DeflateFilterNote ディレクティブ

    + + + + + + + +
    説明:ロギング用に圧縮比をメモに追加
    構文:DeflateFilterNote [type] notename
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Extension
    モジュール:mod_deflate
    互換性:type is available since Apache 2.0.45
    +

    DeflateFilterNote ディレクティブは + 圧縮比に関するメモがリクエストに付加されることを指定します。 + メモ (note) の名前はディレクティブに指定された値です。 + メモはアクセスログに + 値を記録し、統計を取る目的にも使えます。

    + +

    例

    + DeflateFilterNote ratio
    +
    + LogFormat '"%r" %b (%{ratio}n) "%{User-agent}i"' deflate
    + CustomLog logs/deflate_log deflate +

    + +

    ログからもっと精密な値を抽出したい場合は、type + 引数を使用して、データタイプをログのメモとして残すように指定できます。 + type は次のうちの一つです。

    + +
    +
    Input
    +
    フィルタの入力ストリームのバイトカウントをメモに保存する。
    + +
    Output
    +
    フィルタの出力ストリームのバイトカウントをメモに保存する。
    + +
    Ratio
    +
    圧縮率 (出力 / 入力 * 100) をメモに保存する。 + type 引数を省略した場合は、これがデフォルトとなります。
    +
    + +

    まとめると、次のようにログを取ることになるでしょう。

    + +

    精密なログ採取

    + DeflateFilterNote Input instream
    + DeflateFilterNote Output outstream
    + DeflateFilterNote Ratio ratio
    +
    + LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
    + CustomLog logs/deflate_log deflate +

    + +

    参照

    + +
    +
    top
    +

    DeflateInflateLimitRequestBody ディレクティブ

    + + + + + + + + +
    説明:Maximum size of inflated request bodies
    構文:DeflateInflateLimitRequestBodyvalue
    デフォルト:None, but LimitRequestBody applies after deflation
    コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
    ステータス:Extension
    モジュール:mod_deflate
    互換性:2.4.10 and later

    このディレクティブの解説文書は + まだ翻訳されていません。英語版をご覧ください。 +

    +
    top
    +

    DeflateInflateRatioBurst ディレクティブ

    + + + + + + + + +
    説明:Maximum number of times the inflation ratio for request bodies + can be crossed
    構文:DeflateInflateRatioBurst value
    デフォルト:3
    コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
    ステータス:Extension
    モジュール:mod_deflate
    互換性:2.4.10 and later

    このディレクティブの解説文書は + まだ翻訳されていません。英語版をご覧ください。 +

    +
    top
    +

    DeflateInflateRatioLimit ディレクティブ

    + + + + + + + + +
    説明:Maximum inflation ratio for request bodies
    構文:DeflateInflateRatioLimit value
    デフォルト:200
    コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
    ステータス:Extension
    モジュール:mod_deflate
    互換性:2.4.10 and later

    このディレクティブの解説文書は + まだ翻訳されていません。英語版をご覧ください。 +

    +
    top
    +

    DeflateMemLevel ディレクティブ

    + + + + + + + +
    説明:zlib が圧縮に使うメモリのレベルを指定
    構文:DeflateMemLevel value
    デフォルト:DeflateMemLevel 9
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Extension
    モジュール:mod_deflate
    +

    DeflateMemLevel ディレクティブは + zlib が圧縮に使うメモリのレベルを設定します (1 から 9 の間の値)。 + (訳注: 2 を底とする対数の値になります。 + 8 程度が良いでしょう。)

    + +
    +
    top
    +

    DeflateWindowSize ディレクティブ

    + + + + + + + +
    説明:Zlib の圧縮用ウィンドウの大きさ
    構文:DeflateWindowSize value
    デフォルト:DeflateWindowSize 15
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Extension
    モジュール:mod_deflate
    +

    DeflateWindowSize ディレクティブは + zlib の圧縮用ウィンドウ (訳注: zlib で使用される履歴バッファ) + の大きさを指定します (1 から 15 の間の値)。 + 一般的に大きなウィンドウサイズを使用すると圧縮率が向上します。 + (訳注: 2 を底とする対数の値になります。 + 8 から 15 にするのが良いでしょう。)

    + +
    +
    top

    サンプル設定

    下にせっかちな人向けの簡単な設定例を示します。

    @@ -258,166 +418,6 @@ Header set Vary *

    -
    top
    -

    DeflateBufferSize ディレクティブ

    - - - - - - - -
    説明:zlib が一度に圧縮する塊の大きさ
    構文:DeflateBufferSize value
    デフォルト:DeflateBufferSize 8096
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Extension
    モジュール:mod_deflate
    -

    DeflateBufferSize ディレクティブは - zlib が一度に圧縮する塊の大きさをバイト単位で指定します。

    - -
    -
    top
    -

    DeflateCompressionLevel ディレクティブ

    - - - - - - - - -
    説明:出力に対して行なう圧縮の程度
    構文:DeflateCompressionLevel value
    デフォルト:Zlib のデフォルト
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Extension
    モジュール:mod_deflate
    互換性:This directive is available since Apache 2.0.45
    -

    DeflateCompressionLevel ディレクティブは - 圧縮の程度を設定します。大きな値では、より圧縮が行なわれますが、 - CPU 資源を消費します。

    -

    値は 1 (低圧縮) から 9 (高圧縮) です。

    - -
    -
    top
    -

    DeflateFilterNote ディレクティブ

    - - - - - - - -
    説明:ロギング用に圧縮比をメモに追加
    構文:DeflateFilterNote [type] notename
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Extension
    モジュール:mod_deflate
    互換性:type is available since Apache 2.0.45
    -

    DeflateFilterNote ディレクティブは - 圧縮比に関するメモがリクエストに付加されることを指定します。 - メモ (note) の名前はディレクティブに指定された値です。 - メモはアクセスログに - 値を記録し、統計を取る目的にも使えます。

    - -

    例

    - DeflateFilterNote ratio
    -
    - LogFormat '"%r" %b (%{ratio}n) "%{User-agent}i"' deflate
    - CustomLog logs/deflate_log deflate -

    - -

    ログからもっと精密な値を抽出したい場合は、type - 引数を使用して、データタイプをログのメモとして残すように指定できます。 - type は次のうちの一つです。

    - -
    -
    Input
    -
    フィルタの入力ストリームのバイトカウントをメモに保存する。
    - -
    Output
    -
    フィルタの出力ストリームのバイトカウントをメモに保存する。
    - -
    Ratio
    -
    圧縮率 (出力 / 入力 * 100) をメモに保存する。 - type 引数を省略した場合は、これがデフォルトとなります。
    -
    - -

    まとめると、次のようにログを取ることになるでしょう。

    - -

    精密なログ採取

    - DeflateFilterNote Input instream
    - DeflateFilterNote Output outstream
    - DeflateFilterNote Ratio ratio
    -
    - LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
    - CustomLog logs/deflate_log deflate -

    - -

    参照

    - -
    -
    top
    -

    DeflateInflateLimitRequestBody ディレクティブ

    - - - - - - - - -
    説明:Maximum size of inflated request bodies
    構文:DeflateInflateLimitRequestBodyvalue
    デフォルト:None, but LimitRequestBody applies after deflation
    コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
    ステータス:Extension
    モジュール:mod_deflate
    互換性:2.4.10 and later

    このディレクティブの解説文書は - まだ翻訳されていません。英語版をご覧ください。 -

    -
    top
    -

    DeflateInflateRatioBurst ディレクティブ

    - - - - - - - - -
    説明:Maximum number of times the inflation ratio for request bodies - can be crossed
    構文:DeflateInflateRatioBurst value
    デフォルト:3
    コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
    ステータス:Extension
    モジュール:mod_deflate
    互換性:2.4.10 and later

    このディレクティブの解説文書は - まだ翻訳されていません。英語版をご覧ください。 -

    -
    top
    -

    DeflateInflateRatioLimit ディレクティブ

    - - - - - - - - -
    説明:Maximum inflation ratio for request bodies
    構文:DeflateInflateRatioLimit value
    デフォルト:200
    コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
    ステータス:Extension
    モジュール:mod_deflate
    互換性:2.4.10 and later

    このディレクティブの解説文書は - まだ翻訳されていません。英語版をご覧ください。 -

    -
    top
    -

    DeflateMemLevel ディレクティブ

    - - - - - - - -
    説明:zlib が圧縮に使うメモリのレベルを指定
    構文:DeflateMemLevel value
    デフォルト:DeflateMemLevel 9
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Extension
    モジュール:mod_deflate
    -

    DeflateMemLevel ディレクティブは - zlib が圧縮に使うメモリのレベルを設定します (1 から 9 の間の値)。 - (訳注: 2 を底とする対数の値になります。 - 8 程度が良いでしょう。)

    - -
    -
    top
    -

    DeflateWindowSize ディレクティブ

    - - - - - - - -
    説明:Zlib の圧縮用ウィンドウの大きさ
    構文:DeflateWindowSize value
    デフォルト:DeflateWindowSize 15
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Extension
    モジュール:mod_deflate
    -

    DeflateWindowSize ディレクティブは - zlib の圧縮用ウィンドウ (訳注: zlib で使用される履歴バッファ) - の大きさを指定します (1 から 15 の間の値)。 - 一般的に大きなウィンドウサイズを使用すると圧縮率が向上します。 - (訳注: 2 を底とする対数の値になります。 - 8 から 15 にするのが良いでしょう。)

    - -

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_deflate.html.ko.euc-kr b/docs/manual/mod/mod_deflate.html.ko.euc-kr index bcf266f318a..5529f23fe0f 100644 --- a/docs/manual/mod/mod_deflate.html.ko.euc-kr +++ b/docs/manual/mod/mod_deflate.html.ko.euc-kr @@ -62,6 +62,160 @@

  • ÇÊÅÍ
    • top
    +

    DeflateBufferSize Áö½Ã¾î

    + + + + + + + +
    ¼³¸í:zlibÀÌ Çѹø¿¡ ¾ÐÃàÇÒ Å©±â
    ¹®¹ý:DeflateBufferSize value
    ±âº»°ª:DeflateBufferSize 8096
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Extension
    ¸ðµâ:mod_deflate
    +

    DeflateBufferSize Áö½Ã¾î´Â zlibÀÌ + Çѹø¿¡ ¾ÐÃàÇÒ ¹ÙÀÌÆ®¼ö¸¦ ÁöÁ¤ÇÑ´Ù.

    + +
    +
    top
    +

    DeflateCompressionLevel Áö½Ã¾î

    + + + + + + + + +
    ¼³¸í:Ãâ·ÂÀ» ¾î´ÀÁ¤µµ ¾ÐÃàÇϴ°¡
    ¹®¹ý:DeflateCompressionLevel value
    ±âº»°ª:Zlib's default
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Extension
    ¸ðµâ:mod_deflate
    Áö¿ø:¾ÆÆÄÄ¡ 2.0.45 ºÎÅÍ
    +

    DeflateCompressionLevel Áö½Ã¾î´Â + »ç¿ëÇÒ ¾ÐÃà¼öÁØÀ» ¼±ÅÃÇÑ´Ù. °ªÀÌ Å¬¼ö·Ï ¾ÐÃà·üÀÌ Áõ°¡ÇÏÁö¸¸, + CPU¸¦ ´õ ¸¹ÀÌ »ç¿ëÇÑ´Ù.

    +

    (°¡Àå ´ú ¾ÐÃà) 1°ú (°¡Àå ¸¹ÀÌ ¾ÐÃà) 9 »çÀÌÀÇ °ªÀ» ÁöÁ¤ÇÑ´Ù.

    + +
    +
    top
    +

    DeflateFilterNote Áö½Ã¾î

    + + + + + + + +
    ¼³¸í:¾ÐÃà·üÀ» ·Î±×¿¡ ±â·ÏÇÑ´Ù
    ¹®¹ý:DeflateFilterNote [type] notename
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Extension
    ¸ðµâ:mod_deflate
    Áö¿ø:typeÀº ¾ÆÆÄÄ¡ 2.0.4 ºÎÅÍ
    +

    DeflateFilterNote Áö½Ã¾î´Â ¿äûÀÇ + ¾ÐÃà·üÀ» ·Î±×¿¡ ±â·ÏÇÏ´Â ±âÈ£¸¦ ÁöÁ¤ÇÑ´Ù. ±âÈ£ À̸§Àº Áö½Ã¾î·Î + ÁöÁ¤ÇÑ °ªÀÌ´Ù. Åë°è¸¦ À§ÇØ Á¢±Ù + ·Î±×¿¡¼­ ±âÈ£¸¦ »ç¿ëÇÒ ¼ö ÀÖ´Ù.

    + +

    ¿¹Á¦

    + DeflateFilterNote ratio
    +
    + LogFormat '"%r" %b (%{ratio}n) "%{User-agent}i"' deflate
    + CustomLog logs/deflate_log deflate +

    + +

    ·Î±×¿¡¼­ ´õ Á¤È®ÇÑ °ªÀ» ÃßÃâÇÏ·Á¸é type ¾Æ±Ô¸ÕÆ®·Î + ±â·ÏÇÒ ÀڷḦ ¼±ÅÃÇÑ´Ù. type´Â ´ÙÀ½Áß ÇϳªÀÌ´Ù:

    + +
    +
    Input
    +
    ÇÊÅÍ ÀԷ½ºÆ®¸²ÀÇ ¹ÙÀÌÆ®¼ö¸¦ ÀúÀåÇÑ´Ù.
    + +
    Output
    +
    ÇÊÅÍ Ãâ·Â½ºÆ®¸²ÀÇ ¹ÙÀÌÆ®¼ö¸¦ ÀúÀåÇÑ´Ù..
    + +
    Ratio
    +
    ¾ÐÃà·üÀ» (output/input * 100) ÀúÀåÇÑ´Ù. + type ¾Æ±Ô¸ÕÆ®¸¦ »ý·«ÇÏ¸é »ç¿ëÇÏ´Â ±âº»°ªÀÌ´Ù.
    +
    + +

    ±×·¡¼­ ÀÌ·¸°Ô ·Î±×¿¡ ±â·ÏÇÒ ¼ö ÀÖ´Ù:

    + +

    Á¤¹ÐÇÑ ·Î±×

    + DeflateFilterNote Input instream
    + DeflateFilterNote Output outstream
    + DeflateFilterNote Ratio ratio
    +
    + LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
    + CustomLog logs/deflate_log deflate +

    + +

    Âü°í

    + +
    +
    top
    +

    DeflateInflateLimitRequestBody Áö½Ã¾î

    + + + + + + + + +
    ¼³¸í:Maximum size of inflated request bodies
    ¹®¹ý:DeflateInflateLimitRequestBodyvalue
    ±âº»°ª:None, but LimitRequestBody applies after deflation
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    »óÅÂ:Extension
    ¸ðµâ:mod_deflate
    Áö¿ø:2.4.10 and later

    The documentation for this directive has + not been translated yet. Please have a look at the English + version.

    +
    top
    +

    DeflateInflateRatioBurst Áö½Ã¾î

    + + + + + + + + +
    ¼³¸í:Maximum number of times the inflation ratio for request bodies + can be crossed
    ¹®¹ý:DeflateInflateRatioBurst value
    ±âº»°ª:3
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    »óÅÂ:Extension
    ¸ðµâ:mod_deflate
    Áö¿ø:2.4.10 and later

    The documentation for this directive has + not been translated yet. Please have a look at the English + version.

    +
    top
    +

    DeflateInflateRatioLimit Áö½Ã¾î

    + + + + + + + + +
    ¼³¸í:Maximum inflation ratio for request bodies
    ¹®¹ý:DeflateInflateRatioLimit value
    ±âº»°ª:200
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    »óÅÂ:Extension
    ¸ðµâ:mod_deflate
    Áö¿ø:2.4.10 and later

    The documentation for this directive has + not been translated yet. Please have a look at the English + version.

    +
    top
    +

    DeflateMemLevel Áö½Ã¾î

    + + + + + + + +
    ¼³¸í:zlibÀÌ ¾ÐÃàÇÒ¶§ »ç¿ëÇÏ´Â ¸Þ¸ð¸®·®
    ¹®¹ý:DeflateMemLevel value
    ±âº»°ª:DeflateMemLevel 9
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Extension
    ¸ðµâ:mod_deflate
    +

    DeflateMemLevel Áö½Ã¾î´Â zlibÀÌ + ¾ÐÃàÇÒ¶§ ¾ó¸¶¸¸Å­ ¸Þ¸ð¸®¸¦ »ç¿ëÇÒÁö °áÁ¤ÇÑ´Ù. (1°ú 9 »çÀÌÀÇ + °ª)

    + +
    +
    top
    +

    DeflateWindowSize Áö½Ã¾î

    + + + + + + + +
    ¼³¸í:Zlib ¾ÐÃà window size
    ¹®¹ý:DeflateWindowSize value
    ±âº»°ª:DeflateWindowSize 15
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Extension
    ¸ðµâ:mod_deflate
    +

    DeflateWindowSize Áö½Ã¾î´Â zlib + ¾ÐÃà window size¸¦ (1°ú 15 »çÀÌÀÇ °ª) ÁöÁ¤ÇÑ´Ù. ÀϹÝÀûÀ¸·Î + window size°¡ Ŭ¼ö·Ï ¾ÐÃà·üÀÌ Áõ°¡ÇÑ´Ù.

    + +
    +
    top

    °ßº» ¼³Á¤

    ±ÞÇÑ »ç¶÷À» À§ÇÑ °ßº» ¼³Á¤ÀÌ´Ù.

    @@ -250,160 +404,6 @@ Header set Vary *

    -
    top
    -

    DeflateBufferSize Áö½Ã¾î

    - - - - - - - -
    ¼³¸í:zlibÀÌ Çѹø¿¡ ¾ÐÃàÇÒ Å©±â
    ¹®¹ý:DeflateBufferSize value
    ±âº»°ª:DeflateBufferSize 8096
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Extension
    ¸ðµâ:mod_deflate
    -

    DeflateBufferSize Áö½Ã¾î´Â zlibÀÌ - Çѹø¿¡ ¾ÐÃàÇÒ ¹ÙÀÌÆ®¼ö¸¦ ÁöÁ¤ÇÑ´Ù.

    - -
    -
    top
    -

    DeflateCompressionLevel Áö½Ã¾î

    - - - - - - - - -
    ¼³¸í:Ãâ·ÂÀ» ¾î´ÀÁ¤µµ ¾ÐÃàÇϴ°¡
    ¹®¹ý:DeflateCompressionLevel value
    ±âº»°ª:Zlib's default
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Extension
    ¸ðµâ:mod_deflate
    Áö¿ø:¾ÆÆÄÄ¡ 2.0.45 ºÎÅÍ
    -

    DeflateCompressionLevel Áö½Ã¾î´Â - »ç¿ëÇÒ ¾ÐÃà¼öÁØÀ» ¼±ÅÃÇÑ´Ù. °ªÀÌ Å¬¼ö·Ï ¾ÐÃà·üÀÌ Áõ°¡ÇÏÁö¸¸, - CPU¸¦ ´õ ¸¹ÀÌ »ç¿ëÇÑ´Ù.

    -

    (°¡Àå ´ú ¾ÐÃà) 1°ú (°¡Àå ¸¹ÀÌ ¾ÐÃà) 9 »çÀÌÀÇ °ªÀ» ÁöÁ¤ÇÑ´Ù.

    - -
    -
    top
    -

    DeflateFilterNote Áö½Ã¾î

    - - - - - - - -
    ¼³¸í:¾ÐÃà·üÀ» ·Î±×¿¡ ±â·ÏÇÑ´Ù
    ¹®¹ý:DeflateFilterNote [type] notename
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Extension
    ¸ðµâ:mod_deflate
    Áö¿ø:typeÀº ¾ÆÆÄÄ¡ 2.0.4 ºÎÅÍ
    -

    DeflateFilterNote Áö½Ã¾î´Â ¿äûÀÇ - ¾ÐÃà·üÀ» ·Î±×¿¡ ±â·ÏÇÏ´Â ±âÈ£¸¦ ÁöÁ¤ÇÑ´Ù. ±âÈ£ À̸§Àº Áö½Ã¾î·Î - ÁöÁ¤ÇÑ °ªÀÌ´Ù. Åë°è¸¦ À§ÇØ Á¢±Ù - ·Î±×¿¡¼­ ±âÈ£¸¦ »ç¿ëÇÒ ¼ö ÀÖ´Ù.

    - -

    ¿¹Á¦

    - DeflateFilterNote ratio
    -
    - LogFormat '"%r" %b (%{ratio}n) "%{User-agent}i"' deflate
    - CustomLog logs/deflate_log deflate -

    - -

    ·Î±×¿¡¼­ ´õ Á¤È®ÇÑ °ªÀ» ÃßÃâÇÏ·Á¸é type ¾Æ±Ô¸ÕÆ®·Î - ±â·ÏÇÒ ÀڷḦ ¼±ÅÃÇÑ´Ù. type´Â ´ÙÀ½Áß ÇϳªÀÌ´Ù:

    - -
    -
    Input
    -
    ÇÊÅÍ ÀԷ½ºÆ®¸²ÀÇ ¹ÙÀÌÆ®¼ö¸¦ ÀúÀåÇÑ´Ù.
    - -
    Output
    -
    ÇÊÅÍ Ãâ·Â½ºÆ®¸²ÀÇ ¹ÙÀÌÆ®¼ö¸¦ ÀúÀåÇÑ´Ù..
    - -
    Ratio
    -
    ¾ÐÃà·üÀ» (output/input * 100) ÀúÀåÇÑ´Ù. - type ¾Æ±Ô¸ÕÆ®¸¦ »ý·«ÇÏ¸é »ç¿ëÇÏ´Â ±âº»°ªÀÌ´Ù.
    -
    - -

    ±×·¡¼­ ÀÌ·¸°Ô ·Î±×¿¡ ±â·ÏÇÒ ¼ö ÀÖ´Ù:

    - -

    Á¤¹ÐÇÑ ·Î±×

    - DeflateFilterNote Input instream
    - DeflateFilterNote Output outstream
    - DeflateFilterNote Ratio ratio
    -
    - LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
    - CustomLog logs/deflate_log deflate -

    - -

    Âü°í

    - -
    -
    top
    -

    DeflateInflateLimitRequestBody Áö½Ã¾î

    - - - - - - - - -
    ¼³¸í:Maximum size of inflated request bodies
    ¹®¹ý:DeflateInflateLimitRequestBodyvalue
    ±âº»°ª:None, but LimitRequestBody applies after deflation
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    »óÅÂ:Extension
    ¸ðµâ:mod_deflate
    Áö¿ø:2.4.10 and later

    The documentation for this directive has - not been translated yet. Please have a look at the English - version.

    -
    top
    -

    DeflateInflateRatioBurst Áö½Ã¾î

    - - - - - - - - -
    ¼³¸í:Maximum number of times the inflation ratio for request bodies - can be crossed
    ¹®¹ý:DeflateInflateRatioBurst value
    ±âº»°ª:3
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    »óÅÂ:Extension
    ¸ðµâ:mod_deflate
    Áö¿ø:2.4.10 and later

    The documentation for this directive has - not been translated yet. Please have a look at the English - version.

    -
    top
    -

    DeflateInflateRatioLimit Áö½Ã¾î

    - - - - - - - - -
    ¼³¸í:Maximum inflation ratio for request bodies
    ¹®¹ý:DeflateInflateRatioLimit value
    ±âº»°ª:200
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    »óÅÂ:Extension
    ¸ðµâ:mod_deflate
    Áö¿ø:2.4.10 and later

    The documentation for this directive has - not been translated yet. Please have a look at the English - version.

    -
    top
    -

    DeflateMemLevel Áö½Ã¾î

    - - - - - - - -
    ¼³¸í:zlibÀÌ ¾ÐÃàÇÒ¶§ »ç¿ëÇÏ´Â ¸Þ¸ð¸®·®
    ¹®¹ý:DeflateMemLevel value
    ±âº»°ª:DeflateMemLevel 9
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Extension
    ¸ðµâ:mod_deflate
    -

    DeflateMemLevel Áö½Ã¾î´Â zlibÀÌ - ¾ÐÃàÇÒ¶§ ¾ó¸¶¸¸Å­ ¸Þ¸ð¸®¸¦ »ç¿ëÇÒÁö °áÁ¤ÇÑ´Ù. (1°ú 9 »çÀÌÀÇ - °ª)

    - -
    -
    top
    -

    DeflateWindowSize Áö½Ã¾î

    - - - - - - - -
    ¼³¸í:Zlib ¾ÐÃà window size
    ¹®¹ý:DeflateWindowSize value
    ±âº»°ª:DeflateWindowSize 15
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Extension
    ¸ðµâ:mod_deflate
    -

    DeflateWindowSize Áö½Ã¾î´Â zlib - ¾ÐÃà window size¸¦ (1°ú 15 »çÀÌÀÇ °ª) ÁöÁ¤ÇÑ´Ù. ÀϹÝÀûÀ¸·Î - window size°¡ Ŭ¼ö·Ï ¾ÐÃà·üÀÌ Áõ°¡ÇÑ´Ù.

    - -

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_dialup.html.en b/docs/manual/mod/mod_dialup.html.en index c08fca1d870..16524cd7122 100644 --- a/docs/manual/mod/mod_dialup.html.en +++ b/docs/manual/mod/mod_dialup.html.en @@ -53,7 +53,6 @@ once the timer hits. From there the handler can continue to send data to the cl

  • ModemStandard
    • -
    top

    ModemStandard Directive

    @@ -72,6 +71,7 @@ once the timer hits. From there the handler can continue to send data to the cl +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_dialup.html.fr b/docs/manual/mod/mod_dialup.html.fr index 0af133314e0..c83ad00f37d 100644 --- a/docs/manual/mod/mod_dialup.html.fr +++ b/docs/manual/mod/mod_dialup.html.fr @@ -60,7 +60,6 @@ client.

  • ModemStandard
    • -
    top

    Directive ModemStandard

    @@ -80,6 +79,7 @@ souhaitez simuler.

    +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_dir.html.en b/docs/manual/mod/mod_dir.html.en index 59bfc3faf63..7139b54edce 100644 --- a/docs/manual/mod/mod_dir.html.en +++ b/docs/manual/mod/mod_dir.html.en @@ -68,7 +68,6 @@

  • FallbackResource
    • -
    top

    DirectoryCheckHandler Directive

    @@ -307,6 +306,7 @@ later +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_dir.html.fr b/docs/manual/mod/mod_dir.html.fr index a4d8702af5c..d138285bc16 100644 --- a/docs/manual/mod/mod_dir.html.fr +++ b/docs/manual/mod/mod_dir.html.fr @@ -71,7 +71,6 @@ de r

  • FallbackResource
    • -
    top

    Directive DirectoryCheckHandler

    @@ -342,6 +341,7 @@ de la version 2.4.4 du serveur HTTP Apache. +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_dir.html.ja.utf8 b/docs/manual/mod/mod_dir.html.ja.utf8 index 94fc0639471..92663386509 100644 --- a/docs/manual/mod/mod_dir.html.ja.utf8 +++ b/docs/manual/mod/mod_dir.html.ja.utf8 @@ -76,7 +76,6 @@

  • FallbackResource
    • -
    top

    DirectoryCheckHandler ディレクティブ

    @@ -223,6 +222,7 @@ act as if "DirectoryCheckHandler ON" was specified.
    モジュール:mod_dir

    Documentation not yet translated. Please see English version of document.

    +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_dir.html.ko.euc-kr b/docs/manual/mod/mod_dir.html.ko.euc-kr index 3fc80893537..4485d25c4b6 100644 --- a/docs/manual/mod/mod_dir.html.ko.euc-kr +++ b/docs/manual/mod/mod_dir.html.ko.euc-kr @@ -69,7 +69,6 @@ index

  • FallbackResource
    • -
    top

    DirectoryCheckHandler Áö½Ã¾î

    @@ -208,6 +207,7 @@ act as if "DirectoryCheckHandler ON" was specified.
    ¸ðµâ:mod_dir

    Documentation not yet translated. Please see English version of document.

    +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_dir.html.tr.utf8 b/docs/manual/mod/mod_dir.html.tr.utf8 index 10e412dead0..65d68a215da 100644 --- a/docs/manual/mod/mod_dir.html.tr.utf8 +++ b/docs/manual/mod/mod_dir.html.tr.utf8 @@ -67,7 +67,6 @@

  • FallbackResource
    • -
    top

    DirectoryCheckHandler Yönergesi

    @@ -320,6 +319,7 @@ +

    Mevcut Diller:  en  | diff --git a/docs/manual/mod/mod_dumpio.html.en b/docs/manual/mod/mod_dumpio.html.en index 245b587ddd9..8b608cf29ef 100644 --- a/docs/manual/mod/mod_dumpio.html.en +++ b/docs/manual/mod/mod_dumpio.html.en @@ -54,20 +54,6 @@

  • Enabling dumpio Support
    • top
    -
    -

    Enabling dumpio Support

    - - -

    To enable the module, it should be compiled and loaded - in to your running Apache configuration. Logging can then - be enabled or disabled separately for input and output via - the below directives. Additionally, mod_dumpio - needs to be configured to LogLevel trace7: -

    - 
    LogLevel dumpio:trace7
    - -
    -
    top

    DumpIOInput Directive

    @@ -102,6 +88,20 @@ later.

    Example

    DumpIOOutput On
    + +
    top
    +
    +

    Enabling dumpio Support

    + + +

    To enable the module, it should be compiled and loaded + in to your running Apache configuration. Logging can then + be enabled or disabled separately for input and output via + the below directives. Additionally, mod_dumpio + needs to be configured to LogLevel trace7: +

    + 
    LogLevel dumpio:trace7
    +
    diff --git a/docs/manual/mod/mod_dumpio.html.fr b/docs/manual/mod/mod_dumpio.html.fr index 7d6a0f9ff8f..224f51fda23 100644 --- a/docs/manual/mod/mod_dumpio.html.fr +++ b/docs/manual/mod/mod_dumpio.html.fr @@ -56,19 +56,6 @@ erreurs de la mani
  • Activation du support dumpio
    • top
    -
    -

    Activation du support dumpio

    - - -

    Pour activer le module, ce dernier doit être compilé et chargé - par l'intermédiaire de la configuration de votre instance d'Apache. - La journalisation peut ensuite être activée ou désactivée séparément - pour les entrées et sorties à l'aide des directives ci-dessous. En - outre, mod_dumpio doit être configuré à LogLevel trace7 :

    - 
    LogLevel dumpio:trace7
    - -
    -
    top

    Directive DumpIOInput

    Description:Dump all input data to the error log

    Exemple

    DumpIOOutput On
    + +
    top
    +
    +

    Activation du support dumpio

    + + +

    Pour activer le module, ce dernier doit être compilé et chargé + par l'intermédiaire de la configuration de votre instance d'Apache. + La journalisation peut ensuite être activée ou désactivée séparément + pour les entrées et sorties à l'aide des directives ci-dessous. En + outre, mod_dumpio doit être configuré à LogLevel trace7 :

    + 
    LogLevel dumpio:trace7
    +
    diff --git a/docs/manual/mod/mod_dumpio.html.ja.utf8 b/docs/manual/mod/mod_dumpio.html.ja.utf8 index 0aee76fe494..5984acb733e 100644 --- a/docs/manual/mod/mod_dumpio.html.ja.utf8 +++ b/docs/manual/mod/mod_dumpio.html.ja.utf8 @@ -58,16 +58,6 @@
  • dumpio サポートを有効にする
    • top
    -
    -

    dumpio サポートを有効にする

    - - -

    このモジュールを有効にするには、モジュールがコンパイルされていて、 - 実行する Apache の設定でサーバに組み込まれている必要があります。 - ロギング機能は、以下のディレクティブを使って有効にしたり - 無効にしたりできます。

    -
    -
    top

    DumpIOInput ディレクティブ

    Description:Enregistre toutes les entrées dans le journal des @@ -105,6 +92,19 @@ d'Apache.
    @@ -103,6 +93,16 @@

    +
    top
    +
    +

    dumpio サポートを有効にする

    + + +

    このモジュールを有効にするには、モジュールがコンパイルされていて、 + 実行する Apache の設定でサーバに組み込まれている必要があります。 + ロギング機能は、以下のディレクティブを使って有効にしたり + 無効にしたりできます。

    +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_echo.html.en b/docs/manual/mod/mod_echo.html.en index 306cf5f00ca..429c7727c66 100644 --- a/docs/manual/mod/mod_echo.html.en +++ b/docs/manual/mod/mod_echo.html.en @@ -45,7 +45,6 @@ modules

  • ProtocolEcho
    • -
    top

    ProtocolEcho Directive

    説明:エラーログにすべての入力データをダンプ
    @@ -63,6 +62,7 @@ modules +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_echo.html.fr b/docs/manual/mod/mod_echo.html.fr index dc627304943..2636c05f087 100644 --- a/docs/manual/mod/mod_echo.html.fr +++ b/docs/manual/mod/mod_echo.html.fr @@ -45,7 +45,6 @@ protocole

  • ProtocolEcho
    • -
    top

    Directive ProtocolEcho

    @@ -63,6 +62,7 @@ protocole +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_echo.html.ja.utf8 b/docs/manual/mod/mod_echo.html.ja.utf8 index fc31313e2d5..6fc09a6f565 100644 --- a/docs/manual/mod/mod_echo.html.ja.utf8 +++ b/docs/manual/mod/mod_echo.html.ja.utf8 @@ -45,7 +45,6 @@

  • ProtocolEcho
    • -
    top

    ProtocolEcho ディレクティブ

    @@ -63,6 +62,7 @@ +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_echo.html.ko.euc-kr b/docs/manual/mod/mod_echo.html.ko.euc-kr index 29d2796bfcb..1c4a300e372 100644 --- a/docs/manual/mod/mod_echo.html.ko.euc-kr +++ b/docs/manual/mod/mod_echo.html.ko.euc-kr @@ -47,7 +47,6 @@

  • ProtocolEcho
    • -
    top

    ProtocolEcho Áö½Ã¾î

    @@ -66,6 +65,7 @@

    +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_env.html.en b/docs/manual/mod/mod_env.html.en index 3e932f632f2..bc12efc1f95 100644 --- a/docs/manual/mod/mod_env.html.en +++ b/docs/manual/mod/mod_env.html.en @@ -55,7 +55,6 @@ SSI pages

  • Environment Variables
  • SetEnvIf
    • -
    top

    PassEnv Directive

    @@ -129,6 +128,7 @@ SSI pages +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_env.html.fr b/docs/manual/mod/mod_env.html.fr index e1f4e8e2d18..f09e7030cc5 100644 --- a/docs/manual/mod/mod_env.html.fr +++ b/docs/manual/mod/mod_env.html.fr @@ -57,7 +57,6 @@ pages SSI

  • Variables d'environnement
  • SetEnvIf
    • -
    top

    Directive PassEnv

    @@ -136,6 +135,7 @@ shell +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_env.html.ja.utf8 b/docs/manual/mod/mod_env.html.ja.utf8 index 816f4fc337e..b9e6b2f4d2d 100644 --- a/docs/manual/mod/mod_env.html.ja.utf8 +++ b/docs/manual/mod/mod_env.html.ja.utf8 @@ -57,7 +57,6 @@

    -
    top

    PassEnv ディレクティブ

    @@ -115,6 +114,7 @@

    +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_env.html.ko.euc-kr b/docs/manual/mod/mod_env.html.ko.euc-kr index 9990fc87a32..2e671f578fa 100644 --- a/docs/manual/mod/mod_env.html.ko.euc-kr +++ b/docs/manual/mod/mod_env.html.ko.euc-kr @@ -53,7 +53,6 @@

    -
    top

    PassEnv Áö½Ã¾î

    @@ -108,6 +107,7 @@

    +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_env.html.tr.utf8 b/docs/manual/mod/mod_env.html.tr.utf8 index 6bec9e3e5cd..896f23dea69 100644 --- a/docs/manual/mod/mod_env.html.tr.utf8 +++ b/docs/manual/mod/mod_env.html.tr.utf8 @@ -56,7 +56,6 @@ etmek için kullanılır.

  • Ortam Değişkenleri
  • SetEnvIf
    • -
    top

    PassEnv Yönergesi

    @@ -130,6 +129,7 @@ etmek için kullanılır. +

    Mevcut Diller:  en  | diff --git a/docs/manual/mod/mod_example_hooks.html.en b/docs/manual/mod/mod_example_hooks.html.en index f4354062172..10fc2328e7e 100644 --- a/docs/manual/mod/mod_example_hooks.html.en +++ b/docs/manual/mod/mod_example_hooks.html.en @@ -60,6 +60,26 @@

  • Using the mod_example_hooks Module
    • top
    +

    Example Directive

    +
    + + + + + +
    Description:Demonstration directive to illustrate the Apache module +API
    Syntax:Example
    Context:server config, virtual host, directory, .htaccess
    Status:Experimental
    Module:mod_example_hooks
    +

    The Example directive just sets a demonstration + flag which the example module's content handler displays. It + takes no arguments. If you browse to an URL to which the + example-hooks content-handler applies, you will get a display of the + routines within the module and how and in what order they were + called to service the document request. The effect of this + directive one can observe under the point "Example + directive declared here: YES/NO".

    + +
    +
    top

    Compiling the example_hooks module

    @@ -128,26 +148,6 @@ to browse to this location and see the brief display mentioned earlier.

    -
    top
    -

    Example Directive

    - - - - - - -
    Description:Demonstration directive to illustrate the Apache module -API
    Syntax:Example
    Context:server config, virtual host, directory, .htaccess
    Status:Experimental
    Module:mod_example_hooks
    -

    The Example directive just sets a demonstration - flag which the example module's content handler displays. It - takes no arguments. If you browse to an URL to which the - example-hooks content-handler applies, you will get a display of the - routines within the module and how and in what order they were - called to service the document request. The effect of this - directive one can observe under the point "Example - directive declared here: YES/NO".

    - -

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_example_hooks.html.fr b/docs/manual/mod/mod_example_hooks.html.fr index 16e6aaf4de1..ce31ddf8439 100644 --- a/docs/manual/mod/mod_example_hooks.html.fr +++ b/docs/manual/mod/mod_example_hooks.html.fr @@ -64,6 +64,27 @@ mod_example_hooks

    top
    +

    Directive Example

    + + + + + + +
    Description:Directive de démonstration pour illustrer l'API des modules +Apache
    Syntaxe:Example
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    Statut:Expérimental
    Module:mod_example_hooks
    +

    La directive Example n'a pour fonction que + de définir un drapeau de démonstration que le gestionnaire de + contenu du module example_hooks va afficher. Elle ne possède aucun + argument. Si vous naviguez vers une URL à laquelle le gestionnaire + de contenu example_hooks s'applique, vous verrez s'afficher les routines + du module, ainsi que l'ordre dans lequel elles ont été appelées pour + servir le document demandé. On peut observer l'effet de cette + directive dans la phrase "Example + directive declared here: YES/NO".

    + +
    +
    top

    Compilation du module example_hooks

    @@ -141,27 +162,6 @@ vous devriez pouvoir accéder à ce fichier et voir s'afficher ce qui a été décrit plus haut.

    -
    top
    -

    Directive Example

    - - - - - - -
    Description:Directive de démonstration pour illustrer l'API des modules -Apache
    Syntaxe:Example
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    Statut:Expérimental
    Module:mod_example_hooks
    -

    La directive Example n'a pour fonction que - de définir un drapeau de démonstration que le gestionnaire de - contenu du module example_hooks va afficher. Elle ne possède aucun - argument. Si vous naviguez vers une URL à laquelle le gestionnaire - de contenu example_hooks s'applique, vous verrez s'afficher les routines - du module, ainsi que l'ordre dans lequel elles ont été appelées pour - servir le document demandé. On peut observer l'effet de cette - directive dans la phrase "Example - directive declared here: YES/NO".

    - -

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_example_hooks.html.ko.euc-kr b/docs/manual/mod/mod_example_hooks.html.ko.euc-kr index f922009dbfc..218cb908079 100644 --- a/docs/manual/mod/mod_example_hooks.html.ko.euc-kr +++ b/docs/manual/mod/mod_example_hooks.html.ko.euc-kr @@ -59,6 +59,24 @@

  • mod_example_hooks ¸ðµâ »ç¿ëÇϱâ
    • top
    +

    Example Áö½Ã¾î

    + + + + + + +
    ¼³¸í:¾ÆÆÄÄ¡ ¸ðµâ API¸¦ ¼³¸íÇϱâÀ§ÇÑ ¿¹Á¦ Áö½Ã¾î
    ¹®¹ý:Example
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    »óÅÂ:Experimental
    ¸ðµâ:mod_example_hooks
    +

    Example Áö½Ã¾î´Â example ¸ðµâÀÇ + ³»¿ëÇڵ鷯°¡ °£´ÜÇÑ ¹®±¸¸¦ º¸ÀÏÁö ¿©ºÎ¸¦ ¼³Á¤ÇÑ´Ù. ÀÌ Áö½Ã¾î´Â + ¾Æ±Ô¸ÕÆ®¸¦ ¹ÞÁö¾Ê´Â´Ù. example ³»¿ëÇڵ鷯¸¦ Àû¿ëÇÑ URL¿¡ + Á¢¼ÓÇÏ¸é ¹®¼­ ¿äûÀ» ¼­ºñ½ºÇϱâÀ§ÇØ ¸ðµâ¾È¿¡ ÇÔ¼öµéÀÌ ¾î¶»°Ô + ±×¸®°í ¾î¶² ¼ø¼­·Î ºÒ¸®´ÂÁö ¾Ë ¼ö ÀÖ´Ù. ÀÌ Áö½Ã¾îÀÇ È¿°ú´Â + "Example directive declared here: YES/NO"·Î + È®ÀÎÇÒ ¼ö ÀÖ´Ù.

    + +
    +
    top

    example ¸ðµâ ÄÄÆÄÀÏÇϱâ

    @@ -131,24 +149,6 @@

    ¼­¹ö¸¦ Àç½ÃÀÛÇÑ ÈÄ ÀÌ À§Ä¡¸¦ ºê¶ó¿ì¡ÇÏ¸é ¾Õ¿¡¼­ ¸»ÇÑ ³»¿ëÀ» º¸°ÔµÉ °ÍÀÌ´Ù.

    -
    top
    -

    Example Áö½Ã¾î

    - - - - - - -
    ¼³¸í:¾ÆÆÄÄ¡ ¸ðµâ API¸¦ ¼³¸íÇϱâÀ§ÇÑ ¿¹Á¦ Áö½Ã¾î
    ¹®¹ý:Example
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    »óÅÂ:Experimental
    ¸ðµâ:mod_example_hooks
    -

    Example Áö½Ã¾î´Â example ¸ðµâÀÇ - ³»¿ëÇڵ鷯°¡ °£´ÜÇÑ ¹®±¸¸¦ º¸ÀÏÁö ¿©ºÎ¸¦ ¼³Á¤ÇÑ´Ù. ÀÌ Áö½Ã¾î´Â - ¾Æ±Ô¸ÕÆ®¸¦ ¹ÞÁö¾Ê´Â´Ù. example ³»¿ëÇڵ鷯¸¦ Àû¿ëÇÑ URL¿¡ - Á¢¼ÓÇÏ¸é ¹®¼­ ¿äûÀ» ¼­ºñ½ºÇϱâÀ§ÇØ ¸ðµâ¾È¿¡ ÇÔ¼öµéÀÌ ¾î¶»°Ô - ±×¸®°í ¾î¶² ¼ø¼­·Î ºÒ¸®´ÂÁö ¾Ë ¼ö ÀÖ´Ù. ÀÌ Áö½Ã¾îÀÇ È¿°ú´Â - "Example directive declared here: YES/NO"·Î - È®ÀÎÇÒ ¼ö ÀÖ´Ù.

    - -

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_expires.html.en b/docs/manual/mod/mod_expires.html.en index 3f67827d42b..2802f87eec1 100644 --- a/docs/manual/mod/mod_expires.html.en +++ b/docs/manual/mod/mod_expires.html.en @@ -71,63 +71,6 @@ criteria

    l'intervalle
    top
    -
    -

    Autre syntaxe de définition de -l'intervalle

    -

    Pour une syntaxe plus lisible, on peut aussi utiliser les - directives ExpiresDefault et ExpiresByType comme suit :

    - - 
    ExpiresDefault "base  [plus num type] [num type] ..."
-ExpiresByType type/encoding "base  [plus num type] [num type] ..."
    - - -

    où base peut être :

    - -
      -
    • access
      • - -
    • now (équivalent à - 'access')
      • - -
    • modification
      • -
    - -

    Le mot-clé plus est optionnel. num doit - correspondre à une valeur entière [compatible avec - atoi()], et type peut être choisi parmi :

    - -
      -
    • years
      • -
    • months
      • -
    • weeks
      • -
    • days
      • -
    • hours
      • -
    • minutes
      • -
    • seconds
      • -
    - -

    Par exemple, pour faire expirer par défaut les documents 1 mois - après leur accès, on peut utiliser une des directives suivantes :

    - 
    ExpiresDefault "access plus 1 month"
-ExpiresDefault "access plus 4 weeks"
-ExpiresDefault "access plus 30 days"
    - - - -

    La date d'expiration peut être définie plus précisément en - ajoutant plusieurs clauses 'num type' :

    - - 
    ExpiresByType text/html "access plus 1 month 15 days 2 hours"
-ExpiresByType image/gif "modification plus 5 hours 3 minutes"
    - - -

    Notez que si vous utilisez une configuration basée sur la date de - modification, l'en-tête Expires ne sera pas ajouté à un contenu qui - ne provient pas directement d'un fichier sur disque ; et ceci tout - simplement parce que ce type de contenu ne possède pas de date de - modification.

    -
    -
    top

    Directive ExpiresActive

    Description:Enables generation of Expires @@ -237,6 +180,63 @@ ExpiresByType text/html M604800 description as well.

    +
    top
    +
    +

    Alternate Interval Syntax

    +

    The ExpiresDefault and + ExpiresByType directives + can also be defined in a more readable syntax of the form:

    + + 
    ExpiresDefault "base  [plus num type] [num type] ..."
+ExpiresByType type/encoding "base  [plus num type] [num type] ..."
    + + +

    where base is one of:

    + +
      +
    • access
      • + +
    • now (equivalent to + 'access')
      • + +
    • modification
      • +
    + +

    The plus keyword is optional. num + should be an integer value [acceptable to atoi()], + and type is one of:

    + +
      +
    • years
      • +
    • months
      • +
    • weeks
      • +
    • days
      • +
    • hours
      • +
    • minutes
      • +
    • seconds
      • +
    + +

    For example, any of the following directives can be used to + make documents expire 1 month after being accessed, by + default:

    + + 
    ExpiresDefault "access plus 1 month"
+ExpiresDefault "access plus 4 weeks"
+ExpiresDefault "access plus 30 days"
    + + +

    The expiry time can be fine-tuned by adding several + 'num type' clauses:

    + + 
    ExpiresByType text/html "access plus 1 month 15 days 2 hours"
+ExpiresByType image/gif "modification plus 5 hours 3 minutes"
    + + +

    Note that if you use a modification date based setting, the + Expires header will not be added to content + that does not come from a file on disk. This is due to the fact + that there is no modification time for such content.

    +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_expires.html.fr b/docs/manual/mod/mod_expires.html.fr index bfd13f2852f..96f68421b28 100644 --- a/docs/manual/mod/mod_expires.html.fr +++ b/docs/manual/mod/mod_expires.html.fr @@ -74,63 +74,6 @@ l'utilisateur

    syntaxe de l'argument, ainsi que la description de la syntaxe alternative.

    +
    top
    +
    +

    Autre syntaxe de définition de +l'intervalle

    +

    Pour une syntaxe plus lisible, on peut aussi utiliser les + directives ExpiresDefault et ExpiresByType comme suit :

    + + 
    ExpiresDefault "base  [plus num type] [num type] ..."
+ExpiresByType type/encoding "base  [plus num type] [num type] ..."
    + + +

    où base peut être :

    + +
      +
    • access
      • + +
    • now (équivalent à + 'access')
      • + +
    • modification
      • +
    + +

    Le mot-clé plus est optionnel. num doit + correspondre à une valeur entière [compatible avec + atoi()], et type peut être choisi parmi :

    + +
      +
    • years
      • +
    • months
      • +
    • weeks
      • +
    • days
      • +
    • hours
      • +
    • minutes
      • +
    • seconds
      • +
    + +

    Par exemple, pour faire expirer par défaut les documents 1 mois + après leur accès, on peut utiliser une des directives suivantes :

    + 
    ExpiresDefault "access plus 1 month"
+ExpiresDefault "access plus 4 weeks"
+ExpiresDefault "access plus 30 days"
    + + + +

    La date d'expiration peut être définie plus précisément en + ajoutant plusieurs clauses 'num type' :

    + + 
    ExpiresByType text/html "access plus 1 month 15 days 2 hours"
+ExpiresByType image/gif "modification plus 5 hours 3 minutes"
    + + +

    Notez que si vous utilisez une configuration basée sur la date de + modification, l'en-tête Expires ne sera pas ajouté à un contenu qui + ne provient pas directement d'un fichier sur disque ; et ceci tout + simplement parce que ce type de contenu ne possède pas de date de + modification.

    +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_expires.html.ja.utf8 b/docs/manual/mod/mod_expires.html.ja.utf8 index 6b1ae5ac316..dafc094d442 100644 --- a/docs/manual/mod/mod_expires.html.ja.utf8 +++ b/docs/manual/mod/mod_expires.html.ja.utf8 @@ -68,69 +68,6 @@

  • 代替期間指定構文
    • top
    -
    -

    代替期間指定構文

    - -

    ExpiresDefault ディレクティブと - ExpiresByType ディレクティブは - 以下のより読み易い構文を使って定義することができます:

    - -

    - ExpiresDefault "<base> [plus] {<num> - <type>}*"
    - ExpiresByType type/encoding "<base> [plus] - {<num> <type>}*" -

    - -

    <base> は以下のどれかです:

    - -
      -
    • access
      • - -
    • now ('access' と等価)
      • - -
    • modification
      • -
    - -

    plus キーワードは省略可能です。<num> - は (atoi() が受け付ける) 整数値、 - <type> は以下のどれかです:

    - -
      -
    • years
      • -
    • months
      • -
    • weeks
      • -
    • days
      • -
    • hours
      • -
    • minutes
      • -
    • seconds
      • -
    - -

    例えば、以下のディレクティブはどれもデフォルトで文書がアクセスの 1 ヶ月後に - 期限が切れるようにするために使えます:

    - -

    - ExpiresDefault "access plus 1 month"
    - ExpiresDefault "access plus 4 weeks"
    - ExpiresDefault "access plus 30 days" -

    - -

    期限切れ時刻はいくつか - '<num> <type>' 節を追加することでより細かく - 制御することができます:

    - -

    - ExpiresByType text/html "access plus 1 month 15 - days 2 hours"
    - ExpiresByType image/gif "modification plus 5 hours 3 - minutes" -

    - -

    修正時刻に基づいた設定を使用している場合、Expires ヘッダは - ディスクのファイル以外のコンテンツには追加されないことに注意 - してください。そのようなコンテンツには修正時刻は存在しないからです。

    -
    -
    top

    ExpiresActive ディレクティブ

    Description:Active la génération d'en-têtes @@ -243,6 +186,63 @@ d'expiration
    @@ -230,6 +167,69 @@ 参照してください。

    +
    top
    +
    +

    代替期間指定構文

    + +

    ExpiresDefault ディレクティブと + ExpiresByType ディレクティブは + 以下のより読み易い構文を使って定義することができます:

    + +

    + ExpiresDefault "<base> [plus] {<num> + <type>}*"
    + ExpiresByType type/encoding "<base> [plus] + {<num> <type>}*" +

    + +

    <base> は以下のどれかです:

    + +
      +
    • access
      • + +
    • now ('access' と等価)
      • + +
    • modification
      • +
    + +

    plus キーワードは省略可能です。<num> + は (atoi() が受け付ける) 整数値、 + <type> は以下のどれかです:

    + +
      +
    • years
      • +
    • months
      • +
    • weeks
      • +
    • days
      • +
    • hours
      • +
    • minutes
      • +
    • seconds
      • +
    + +

    例えば、以下のディレクティブはどれもデフォルトで文書がアクセスの 1 ヶ月後に + 期限が切れるようにするために使えます:

    + +

    + ExpiresDefault "access plus 1 month"
    + ExpiresDefault "access plus 4 weeks"
    + ExpiresDefault "access plus 30 days" +

    + +

    期限切れ時刻はいくつか + '<num> <type>' 節を追加することでより細かく + 制御することができます:

    + +

    + ExpiresByType text/html "access plus 1 month 15 + days 2 hours"
    + ExpiresByType image/gif "modification plus 5 hours 3 + minutes" +

    + +

    修正時刻に基づいた設定を使用している場合、Expires ヘッダは + ディスクのファイル以外のコンテンツには追加されないことに注意 + してください。そのようなコンテンツには修正時刻は存在しないからです。

    +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_expires.html.ko.euc-kr b/docs/manual/mod/mod_expires.html.ko.euc-kr index 7cff9b2eb98..18babecef07 100644 --- a/docs/manual/mod/mod_expires.html.ko.euc-kr +++ b/docs/manual/mod/mod_expires.html.ko.euc-kr @@ -66,68 +66,6 @@

  • ´Ù¸¥ ³»ºÎ ¹®¹ý
    • top
    -
    -

    ´Ù¸¥ ³»ºÎ ¹®¹ý

    -

    ExpiresDefault¿Í - ExpiresByType - Áö½Ã¾î¸¦ ´õ Àбâ ÁÁÀº Çü½ÄÀ¸·Î ±â¼úÇÒ ¼ö ÀÖ´Ù:

    - -

    - ExpiresDefault "<base> [plus] {<num> - <type>}*"
    - ExpiresByType type/encoding "<base> [plus] - {<num> <type>}*" -

    - -

    <base>´Â ´ÙÀ½Áß ÇϳªÀÌ´Ù:

    - -
      -
    • access
      • - -
    • now ('access'¿Í °°À½)
      • - -
    • modification
      • -
    - -

    plus Å°¿öµå´Â ¾ø¾îµµ µÈ´Ù. <num>Àº - [atoi()¿¡ »ç¿ëÇÒ ¼ö ÀÖ´Â] Á¤¼ö°ªÀÌ´Ù. - <type>Àº ´ÙÀ½Áß ÇϳªÀÌ´Ù:

    - -
      -
    • years
      • -
    • months
      • -
    • weeks
      • -
    • days
      • -
    • hours
      • -
    • minutes
      • -
    • seconds
      • -
    - -

    ¿¹¸¦ µé¾î, ´ÙÀ½ ¸ðµÎ´Â ¹®¼­°¡ ±âº»ÀûÀ¸·Î Á¢¼ÓµÈÁö 1´ÞÈÄ¿¡ - ¸¸±âµÈ´Ù°í ¼³Á¤ÇÑ´Ù:

    - -

    - ExpiresDefault "access plus 1 month"
    - ExpiresDefault "access plus 4 weeks"
    - ExpiresDefault "access plus 30 days" -

    - -

    '<num> <type>' ±¸¹®À» ¹Ýº¹Çؼ­ »ç¿ëÇÏ¿© - ¸¸±â½Ã°£À» ÀÚ¼¼È÷ ¼³Á¤ÇÒ ¼ö ÀÖ´Ù:

    - -

    - ExpiresByType text/html "access plus 1 month 15 - days 2 hours"
    - ExpiresByType image/gif "modification plus 5 hours 3 - minutes" -

    - -

    ¸¸¾à ¼öÁ¤½Ã°£(modification)À» ±âÁØÀ¸·Î ¸¸±â½Ã°£À» ¼³Á¤ÇÏ´Â - °æ¿ì ³»¿ëÀ» µð½ºÅ©¿¡ ÀÖ´Â ÆÄÀÏ¿¡¼­ °¡Á®¿ÀÁö ¾Ê´Â´Ù¸é Expires - Çì´õ¸¦ ºÙÀÌÁö ¾Ê´Â´Ù. ÀÌ °æ¿ì ³»¿ë¿¡ ¼öÁ¤½Ã°£ÀÌ - ¾ø±â ¶§¹®ÀÌ´Ù.

    -
    -
    top

    ExpiresActive Áö½Ã¾î

    説明:Expires ヘッダの生成を有効にする
    @@ -220,6 +158,68 @@ Âü°íÇ϶ó.

    +
    top
    +
    +

    ´Ù¸¥ ³»ºÎ ¹®¹ý

    +

    ExpiresDefault¿Í + ExpiresByType + Áö½Ã¾î¸¦ ´õ Àбâ ÁÁÀº Çü½ÄÀ¸·Î ±â¼úÇÒ ¼ö ÀÖ´Ù:

    + +

    + ExpiresDefault "<base> [plus] {<num> + <type>}*"
    + ExpiresByType type/encoding "<base> [plus] + {<num> <type>}*" +

    + +

    <base>´Â ´ÙÀ½Áß ÇϳªÀÌ´Ù:

    + +
      +
    • access
      • + +
    • now ('access'¿Í °°À½)
      • + +
    • modification
      • +
    + +

    plus Å°¿öµå´Â ¾ø¾îµµ µÈ´Ù. <num>Àº + [atoi()¿¡ »ç¿ëÇÒ ¼ö ÀÖ´Â] Á¤¼ö°ªÀÌ´Ù. + <type>Àº ´ÙÀ½Áß ÇϳªÀÌ´Ù:

    + +
      +
    • years
      • +
    • months
      • +
    • weeks
      • +
    • days
      • +
    • hours
      • +
    • minutes
      • +
    • seconds
      • +
    + +

    ¿¹¸¦ µé¾î, ´ÙÀ½ ¸ðµÎ´Â ¹®¼­°¡ ±âº»ÀûÀ¸·Î Á¢¼ÓµÈÁö 1´ÞÈÄ¿¡ + ¸¸±âµÈ´Ù°í ¼³Á¤ÇÑ´Ù:

    + +

    + ExpiresDefault "access plus 1 month"
    + ExpiresDefault "access plus 4 weeks"
    + ExpiresDefault "access plus 30 days" +

    + +

    '<num> <type>' ±¸¹®À» ¹Ýº¹Çؼ­ »ç¿ëÇÏ¿© + ¸¸±â½Ã°£À» ÀÚ¼¼È÷ ¼³Á¤ÇÒ ¼ö ÀÖ´Ù:

    + +

    + ExpiresByType text/html "access plus 1 month 15 + days 2 hours"
    + ExpiresByType image/gif "modification plus 5 hours 3 + minutes" +

    + +

    ¸¸¾à ¼öÁ¤½Ã°£(modification)À» ±âÁØÀ¸·Î ¸¸±â½Ã°£À» ¼³Á¤ÇÏ´Â + °æ¿ì ³»¿ëÀ» µð½ºÅ©¿¡ ÀÖ´Â ÆÄÀÏ¿¡¼­ °¡Á®¿ÀÁö ¾Ê´Â´Ù¸é Expires + Çì´õ¸¦ ºÙÀÌÁö ¾Ê´Â´Ù. ÀÌ °æ¿ì ³»¿ë¿¡ ¼öÁ¤½Ã°£ÀÌ + ¾ø±â ¶§¹®ÀÌ´Ù.

    +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_ext_filter.html.en b/docs/manual/mod/mod_ext_filter.html.en index 87696b791de..1160b11bcdc 100644 --- a/docs/manual/mod/mod_ext_filter.html.en +++ b/docs/manual/mod/mod_ext_filter.html.en @@ -74,130 +74,6 @@ delivery to the client

  • Filters
    • top
    -
    -

    Examples

    - -

    Generating HTML from some other type of response

    - 
    # mod_ext_filter directive to define a filter
-# to HTML-ize text/c files using the external
-# program /usr/bin/enscript, with the type of
-# the result set to text/html
-ExtFilterDefine c-to-html mode=output \
-    intype=text/c outtype=text/html \
-    cmd="/usr/bin/enscript --color -W html -Ec -o - -"
-
-<Directory "/export/home/trawick/apacheinst/htdocs/c">
-    # core directive to cause the new filter to
-    # be run on output
-    SetOutputFilter c-to-html
-    
-    # mod_mime directive to set the type of .c
-    # files to text/c
-    AddType text/c .c
-</Directory>
    - - - -

    Implementing a content encoding filter

    -

    Note: this gzip example is just for the purposes of illustration. - Please refer to mod_deflate for a practical - implementation.

    - - 
    # mod_ext_filter directive to define the external filter
-ExtFilterDefine gzip mode=output cmd=/bin/gzip
-
-<Location "/gzipped">
-    
-    # core directive to cause the gzip filter to be
-    # run on output
-    SetOutputFilter gzip
-    
-    # mod_headers directive to add
-    # "Content-Encoding: gzip" header field
-    Header set Content-Encoding gzip
-</Location>
    - - - -

    Slowing down the server

    - 
    # mod_ext_filter directive to define a filter
-# which runs everything through cat; cat doesn't
-# modify anything; it just introduces extra pathlength
-# and consumes more resources
-ExtFilterDefine slowdown mode=output cmd=/bin/cat \
-    preservescontentlength
-
-<Location "/">
-    # core directive to cause the slowdown filter to
-    # be run several times on output
-    #
-    SetOutputFilter slowdown;slowdown;slowdown
-</Location>
    - - - -

    Using sed to replace text in the response

    - 
    # mod_ext_filter directive to define a filter which
-# replaces text in the response
-#
-ExtFilterDefine fixtext mode=output intype=text/html \
-    cmd="/bin/sed s/verdana/arial/g"
-
-<Location "/">
-    # core directive to cause the fixtext filter to
-    # be run on output
-    SetOutputFilter fixtext
-</Location>
    - - -
    -

    You can do the same thing using mod_substitute -without invoking an external process.

    -
    - - -

    Tracing another filter

    - 
    # Trace the data read and written by mod_deflate
-# for a particular client (IP 192.168.1.31)
-# experiencing compression problems.
-# This filter will trace what goes into mod_deflate.
-ExtFilterDefine tracebefore \
-    cmd="/bin/tracefilter.pl /tmp/tracebefore" \
-    EnableEnv=trace_this_client
-
-# This filter will trace what goes after mod_deflate.
-# Note that without the ftype parameter, the default
-# filter type of AP_FTYPE_RESOURCE would cause the
-# filter to be placed *before* mod_deflate in the filter
-# chain.  Giving it a numeric value slightly higher than
-# AP_FTYPE_CONTENT_SET will ensure that it is placed
-# after mod_deflate.
-ExtFilterDefine traceafter \
-    cmd="/bin/tracefilter.pl /tmp/traceafter" \
-    EnableEnv=trace_this_client ftype=21
-
-<Directory "/usr/local/docs">
-    SetEnvIf Remote_Addr 192.168.1.31 trace_this_client
-    SetOutputFilter tracebefore;deflate;traceafter
-</Directory>
    - - -

    Here is the filter which traces the data:

    #!/usr/local/bin/perl -w
-use strict;
-
-open(SAVE, ">$ARGV[0]")
-    or die "can't open $ARGV[0]: $?";
-
-while (<STDIN>) {
-    print SAVE $_;
-    print $_;
-}
-
-close(SAVE);
    -
    - -
    -
    top

    ExtFilterDefine Directive

    ¼³¸í:Expires Çì´õ¸¦ »ý¼ºÇÑ´Ù
    @@ -326,6 +202,130 @@ close(SAVE);

    Messages written to the filter's standard error will be stored in the Apache error log.

    + +
    top
    +
    +

    Examples

    + +

    Generating HTML from some other type of response

    + 
    # mod_ext_filter directive to define a filter
+# to HTML-ize text/c files using the external
+# program /usr/bin/enscript, with the type of
+# the result set to text/html
+ExtFilterDefine c-to-html mode=output \
+    intype=text/c outtype=text/html \
+    cmd="/usr/bin/enscript --color -W html -Ec -o - -"
+
+<Directory "/export/home/trawick/apacheinst/htdocs/c">
+    # core directive to cause the new filter to
+    # be run on output
+    SetOutputFilter c-to-html
+    
+    # mod_mime directive to set the type of .c
+    # files to text/c
+    AddType text/c .c
+</Directory>
    + + + +

    Implementing a content encoding filter

    +

    Note: this gzip example is just for the purposes of illustration. + Please refer to mod_deflate for a practical + implementation.

    + + 
    # mod_ext_filter directive to define the external filter
+ExtFilterDefine gzip mode=output cmd=/bin/gzip
+
+<Location "/gzipped">
+    
+    # core directive to cause the gzip filter to be
+    # run on output
+    SetOutputFilter gzip
+    
+    # mod_headers directive to add
+    # "Content-Encoding: gzip" header field
+    Header set Content-Encoding gzip
+</Location>
    + + + +

    Slowing down the server

    + 
    # mod_ext_filter directive to define a filter
+# which runs everything through cat; cat doesn't
+# modify anything; it just introduces extra pathlength
+# and consumes more resources
+ExtFilterDefine slowdown mode=output cmd=/bin/cat \
+    preservescontentlength
+
+<Location "/">
+    # core directive to cause the slowdown filter to
+    # be run several times on output
+    #
+    SetOutputFilter slowdown;slowdown;slowdown
+</Location>
    + + + +

    Using sed to replace text in the response

    + 
    # mod_ext_filter directive to define a filter which
+# replaces text in the response
+#
+ExtFilterDefine fixtext mode=output intype=text/html \
+    cmd="/bin/sed s/verdana/arial/g"
+
+<Location "/">
+    # core directive to cause the fixtext filter to
+    # be run on output
+    SetOutputFilter fixtext
+</Location>
    + + +
    +

    You can do the same thing using mod_substitute +without invoking an external process.

    +
    + + +

    Tracing another filter

    + 
    # Trace the data read and written by mod_deflate
+# for a particular client (IP 192.168.1.31)
+# experiencing compression problems.
+# This filter will trace what goes into mod_deflate.
+ExtFilterDefine tracebefore \
+    cmd="/bin/tracefilter.pl /tmp/tracebefore" \
+    EnableEnv=trace_this_client
+
+# This filter will trace what goes after mod_deflate.
+# Note that without the ftype parameter, the default
+# filter type of AP_FTYPE_RESOURCE would cause the
+# filter to be placed *before* mod_deflate in the filter
+# chain.  Giving it a numeric value slightly higher than
+# AP_FTYPE_CONTENT_SET will ensure that it is placed
+# after mod_deflate.
+ExtFilterDefine traceafter \
+    cmd="/bin/tracefilter.pl /tmp/traceafter" \
+    EnableEnv=trace_this_client ftype=21
+
+<Directory "/usr/local/docs">
+    SetEnvIf Remote_Addr 192.168.1.31 trace_this_client
+    SetOutputFilter tracebefore;deflate;traceafter
+</Directory>
    + + +

    Here is the filter which traces the data:

    #!/usr/local/bin/perl -w
+use strict;
+
+open(SAVE, ">$ARGV[0]")
+    or die "can't open $ARGV[0]: $?";
+
+while (<STDIN>) {
+    print SAVE $_;
+    print $_;
+}
+
+close(SAVE);
    +
    +
    diff --git a/docs/manual/mod/mod_ext_filter.html.fr b/docs/manual/mod/mod_ext_filter.html.fr index 955b465dcce..4705185828e 100644 --- a/docs/manual/mod/mod_ext_filter.html.fr +++ b/docs/manual/mod/mod_ext_filter.html.fr @@ -77,140 +77,6 @@ externe avant de l'envoyer au client
  • Filtres
    • top
    -
    -

    Exemples

    - -

    Générer du HTML à partir d'un autre type de - contenu

    - - 
    # la directive de mod_ext_filter définissant un filtre
-# permettant de mettre des fichiers text/c au format HTML en
-# utilisant le programme externe /usr/bin/enscript, le type du
-# fichier résultant étant défini à text/html
-ExtFilterDefine c-to-html mode=output \
-    intype=text/c outtype=text/html \
-    cmd="/usr/bin/enscript --color -W html -Ec -o - -"
-
-<Directory "/export/home/trawick/apacheinst/htdocs/c">
-    # directive de base permettant de traiter la sortie avec le
-    # nouveau filtre
-    SetOutputFilter c-to-html
-
-    # directive de mod_mime définissant le type des fichiers dont
-    # le nom possède l'extension .c à text/c
-    AddType text/c .c
-</Directory>
    - - - -

    Implémentation d'un filtre de codage de - contenu

    -

    Note : cet exemple avec gzip n'est fourni qu'à titre - d'illustration. Veuillez vous reporter à la documentation de - mod_deflate pour un exemple d'implémentation plus - pratique.

    - - 
    # la directive de mod_ext_filter qui définit le filtre externe
-ExtFilterDefine gzip mode=output cmd=/bin/gzip
-
-<Location /gzipped>
-
-    # directive de base permettant de traiter la sortie avec le
-  # filtre gzip
-    SetOutputFilter gzip
-
-    # la directive de mod_headers permettant d'ajouter le champ
-  # d'en-tête "Content-Encoding: gzip"
-    Header set Content-Encoding gzip
-</Location>
    - - - - -

    Ralentissement du serveur

    - 
    # directive de mod_ext_filter définissant un filtre qui fait
-# passer tous les flux en sortie par la commande cat ; cat ne
-# modifie rien ; elle ne fait que compliquer le cheminement des
-# flux et consommer des ressources supplémentaires
-       ExtFilterDefine slowdown mode=output cmd=/bin/cat \
-ExtFilterDefine slowdown mode=output cmd=/bin/cat \
-    preservescontentlength
-
-<Location />
-    # directive de base permettant de traiter plusieurs fois la
-    # sortie avec le filtre slowdown
-    #
-    SetOutputFilter slowdown;slowdown;slowdown
-</Location>
    - - - -

    Utilisation de sed pour remplacer du texte dans la - réponse

    - - 
    # directive de mod_ext_filter définissant un filtre qui
-# remplace du texte dans la réponse
-#
-ExtFilterDefine fixtext mode=output intype=text/html \
-    cmd="/bin/sed s/verdana/arial/g"
-
-<Location />
-    # directive de base permettant de traiter la sortie avec le
-    # filtre fixtext
-    SetOutputFilter fixtext
-</Location>
    - - -
    -

    Vous pouvez aussi utiliser mod_substitute pour -effectuer le même traitement sans avoir à invoquer un programme -externe.

    -
    - - - -

    Tracer un autre filtre

    - 
    # Trace les données lues et écrites par mod_deflate pour un
-# client particulier (IP 192.168.1.31) qui a des problèmes de
-# compression.
-# Ce premier filtre va tracer ce qui entre dans mod_deflate.
-ExtFilterDefine tracebefore \
-    cmd="/bin/tracefilter.pl /tmp/tracebefore" \
-    EnableEnv=trace_this_client
-
-# Ce second filtre va tracer ce qui sort de mod_deflate.
-# Notez que sans le paramètre ftype, le type de filtre par
-# défaut AP_FTYPE_RESOURCE placerait le filtre *avant*
-# mod_deflate dans la chaîne de filtrage. Le fait d'affecter
-# à ce paramètre une valeur numérique sensiblement supérieure à
-# AP_FTYPE_CONTENT_SET permet de s'assurer que le filtre sera
-# placé après mod_deflate.
-ExtFilterDefine traceafter \
-    cmd="/bin/tracefilter.pl /tmp/traceafter" \
-    EnableEnv=trace_this_client ftype=21
-
-<Directory /usr/local/docs>
-    SetEnvIf Remote_Addr 192.168.1.31 trace_this_client
-    SetOutputFilter tracebefore;deflate;traceafter
-</Directory>
    - - -

    Voici le filtre qui trace les données :

    #!/usr/local/bin/perl -w
-use strict;
-
-open(SAVE, ">$ARGV[0]")
-    or die "can't open $ARGV[0]: $?";
-
-while (<STDIN>) {
-    print SAVE $_;
-    print $_;
-}
-
-close(SAVE);
    -
    - -
    -
    top

    Directive ExtFilterDefine

    Description:Define an external filter
    @@ -349,6 +215,140 @@ close(SAVE);

    Les messages envoyés vers la sortie d'erreurs standard du filtre seront enregistrés dans le journal des erreurs d'Apache.

    + +
    top
    +
    +

    Exemples

    + +

    Générer du HTML à partir d'un autre type de + contenu

    + + 
    # la directive de mod_ext_filter définissant un filtre
+# permettant de mettre des fichiers text/c au format HTML en
+# utilisant le programme externe /usr/bin/enscript, le type du
+# fichier résultant étant défini à text/html
+ExtFilterDefine c-to-html mode=output \
+    intype=text/c outtype=text/html \
+    cmd="/usr/bin/enscript --color -W html -Ec -o - -"
+
+<Directory "/export/home/trawick/apacheinst/htdocs/c">
+    # directive de base permettant de traiter la sortie avec le
+    # nouveau filtre
+    SetOutputFilter c-to-html
+
+    # directive de mod_mime définissant le type des fichiers dont
+    # le nom possède l'extension .c à text/c
+    AddType text/c .c
+</Directory>
    + + + +

    Implémentation d'un filtre de codage de + contenu

    +

    Note : cet exemple avec gzip n'est fourni qu'à titre + d'illustration. Veuillez vous reporter à la documentation de + mod_deflate pour un exemple d'implémentation plus + pratique.

    + + 
    # la directive de mod_ext_filter qui définit le filtre externe
+ExtFilterDefine gzip mode=output cmd=/bin/gzip
+
+<Location /gzipped>
+
+    # directive de base permettant de traiter la sortie avec le
+  # filtre gzip
+    SetOutputFilter gzip
+
+    # la directive de mod_headers permettant d'ajouter le champ
+  # d'en-tête "Content-Encoding: gzip"
+    Header set Content-Encoding gzip
+</Location>
    + + + + +

    Ralentissement du serveur

    + 
    # directive de mod_ext_filter définissant un filtre qui fait
+# passer tous les flux en sortie par la commande cat ; cat ne
+# modifie rien ; elle ne fait que compliquer le cheminement des
+# flux et consommer des ressources supplémentaires
+       ExtFilterDefine slowdown mode=output cmd=/bin/cat \
+ExtFilterDefine slowdown mode=output cmd=/bin/cat \
+    preservescontentlength
+
+<Location />
+    # directive de base permettant de traiter plusieurs fois la
+    # sortie avec le filtre slowdown
+    #
+    SetOutputFilter slowdown;slowdown;slowdown
+</Location>
    + + + +

    Utilisation de sed pour remplacer du texte dans la + réponse

    + + 
    # directive de mod_ext_filter définissant un filtre qui
+# remplace du texte dans la réponse
+#
+ExtFilterDefine fixtext mode=output intype=text/html \
+    cmd="/bin/sed s/verdana/arial/g"
+
+<Location />
+    # directive de base permettant de traiter la sortie avec le
+    # filtre fixtext
+    SetOutputFilter fixtext
+</Location>
    + + +
    +

    Vous pouvez aussi utiliser mod_substitute pour +effectuer le même traitement sans avoir à invoquer un programme +externe.

    +
    + + + +

    Tracer un autre filtre

    + 
    # Trace les données lues et écrites par mod_deflate pour un
+# client particulier (IP 192.168.1.31) qui a des problèmes de
+# compression.
+# Ce premier filtre va tracer ce qui entre dans mod_deflate.
+ExtFilterDefine tracebefore \
+    cmd="/bin/tracefilter.pl /tmp/tracebefore" \
+    EnableEnv=trace_this_client
+
+# Ce second filtre va tracer ce qui sort de mod_deflate.
+# Notez que sans le paramètre ftype, le type de filtre par
+# défaut AP_FTYPE_RESOURCE placerait le filtre *avant*
+# mod_deflate dans la chaîne de filtrage. Le fait d'affecter
+# à ce paramètre une valeur numérique sensiblement supérieure à
+# AP_FTYPE_CONTENT_SET permet de s'assurer que le filtre sera
+# placé après mod_deflate.
+ExtFilterDefine traceafter \
+    cmd="/bin/tracefilter.pl /tmp/traceafter" \
+    EnableEnv=trace_this_client ftype=21
+
+<Directory /usr/local/docs>
+    SetEnvIf Remote_Addr 192.168.1.31 trace_this_client
+    SetOutputFilter tracebefore;deflate;traceafter
+</Directory>
    + + +

    Voici le filtre qui trace les données :

    #!/usr/local/bin/perl -w
+use strict;
+
+open(SAVE, ">$ARGV[0]")
+    or die "can't open $ARGV[0]: $?";
+
+while (<STDIN>) {
+    print SAVE $_;
+    print $_;
+}
+
+close(SAVE);
    +
    +
    diff --git a/docs/manual/mod/mod_ext_filter.html.ja.utf8 b/docs/manual/mod/mod_ext_filter.html.ja.utf8 index ab7f37ed5b6..fbd4d0e31a5 100644 --- a/docs/manual/mod/mod_ext_filter.html.ja.utf8 +++ b/docs/manual/mod/mod_ext_filter.html.ja.utf8 @@ -74,6 +74,145 @@
  • フィルタ
    • top
    +

    ExtFilterDefine ディレクティブ

    +
    Description:Définit un filtre externe
    + + + + + +
    説明:外部フィルタを定義
    構文:ExtFilterDefine filtername parameters
    コンテキスト:サーバ設定ファイル
    ステータス:Extension
    モジュール:mod_ext_filter
    +

    ExtFilterDefine は、実行するプログラムや + 引数など、外部フィルタの特性を定義します。

    + +

    filtername は定義するフィルタの名前を指定します。 + この名前は後で SetOutputFilter + ディレクティブで指定できます。名前は登録されるすべてのフィルタで + 一意でなくてはなりません。現時点では、フィルタの登録 API からは + エラーは報告されません。ですから、重複する名前を使ってしまったときでも + ユーザにはそのことは報告されません。

    + +

    続くパラメータの順番は関係無く、それらは実行する外部コマンドと、 + 他の特性を定義します。cmd= だけが必須のパラメータです。 + 指定可能なパラメータは:

    + +
    +
    cmd=cmdline
    + +
    cmd= キーワードは実行する外部コマンドを指定します。 + プログラム名の後に引数がある場合は、コマンド行は引用符で囲む + 必要があります (例えば、cmd="/bin/mypgm + arg1 arg2" のように)。プログラムは + シェル経由でなく、直接実行されますので、通常のシェル用の + エスケープは必要ありません。プログラムの引数は空白で区切られます。 + プログラムの引数の一部となる必要のある空白はバックスペースでエスケープ + できます。引数の一部になるバックスラッシュはバックスラッシュで + エスケープする必要があります。標準の CGI 環境変数に加えて、 + 環境変数 DOCUMENT_URI, DOCUMENT_PATH_INFO, and + QUERY_STRING_UNESCAPED がプログラムのために設定されます。
    + +
    mode=mode
    + +
    応答を処理するフィルタには mode=output (デフォルト) + を使います。リクエストを処理するフィルタには mode=input + を使います。mode=input は Apache 2.1 以降で利用可能です。
    + +
    intype=imt
    + +
    このパラメータはフィルタされるべきドキュメントの + インターネットメディアタイプ (すなわち、MIME タイプ) を + 指定します。デフォルトではすべてのドキュメントがフィルタされます。 + intype= が指定されていれば、フィルタは指定されていない + ドキュメントには適用されなくなります。
    + +
    outtype=imt
    + +
    このパラメータはフィルタされたドキュメントの + インターネットメディアタイプ (すなわち、MIME タイプ) を + 指定します。フィルタ動作にともなってインターネットメディアタイプが + 変わる場合に有用です。デフォルトではインターネットメディアタイプは + 変更されません。
    + +
    PreservesContentLength
    + +
    PreservesContentLength キーワードはフィルタが + content length (訳注: コンテントの長さ) + を変更しないということを指定します。ほとんどのフィルタは + content length を変更するため、これはデフォルトではありません。 + フィルタが長さを変えないときは、このキーワードを指定すると + よいでしょう。
    + +
    ftype=filtertype
    + +
    このパラメータはフィルタが登録されるべきフィルタタイプの + 数値を指定します。ほとんどの場合は、デフォルトの AP_FTYPE_RESOURCE で + 十分です。フィルタがフィルタチェーンの別の場所で動作する必要がある + 場合は、このパラメータを指定する必要があります。指定可能な値は + util_filter.h の AP_FTYPE_foo 定義を参照してください。
    + +
    disableenv=env
    + +
    設定されていた場合にフィルタを無効にするための環境変数を + 指定します。
    + +
    enableenv=env
    + +
    このパラメータはフィルタが有効になるために設定されていなければ + ならない環境変数を指定します。
    +
    + +
    +
    top
    +

    ExtFilterOptions ディレクティブ

    + + + + + + + +
    説明:mod_ext_filter のオプションを設定
    構文:ExtFilterOptions option [option] ...
    デフォルト:ExtFilterOptions DebugLevel=0 NoLogStderr
    コンテキスト:ディレクトリ
    ステータス:Extension
    モジュール:mod_ext_filter
    +

    ExtFilterOptions ディレクティブは + mod_ext_filter の特別な処理用のオプションを + 指定します。Option には以下のどれかを指定します。

    + +
    +
    DebugLevel=n
    + +
    + DebugLevel で mod_ext_filter + の生成するデバッグメッセージのレベルを設定できます。 + デフォルトでは、デバッグメッセージは生成されません。 + これは DebugLevel=0 と設定するのと同じです。 + 数字が大きくなればなるほど、より多くのデバッグメッセージが + 生成され、サーバの性能は落ちます。数値の実際の意味は + mod_ext_filter.c の先頭近くの DBGLVL_ 定数の + 定義で説明されています。 + +

    注: デバッグメッセージを Apache のエラーログに + 保存するようにするためには、core のディレクティブ + LogLevel + を使う必要があります。

    +
    + +
    LogStderr | NoLogStderr
    + +
    LogStderr キーワードは外部フィルタプログラムにより + 標準エラー (訳注: stderr) に書かれたメッセージを + Apache のエラーログに保存するようにします。NoLogStderr は + 逆に保存しないようにします。
    +
    + +

    例

    + ExtFilterOptions LogStderr DebugLevel=0 +

    + +

    この例では、フィルタの標準出力に書かれたメッセージは + Apache のエラーログに保存されます。mod_ext_filter からは + デバッグメッセージは生成されません。

    + +
    +
    top

    例

    @@ -224,145 +363,6 @@ close(SAVE);

    - -
    top
    -

    ExtFilterDefine ディレクティブ

    - - - - - - -
    説明:外部フィルタを定義
    構文:ExtFilterDefine filtername parameters
    コンテキスト:サーバ設定ファイル
    ステータス:Extension
    モジュール:mod_ext_filter
    -

    ExtFilterDefine は、実行するプログラムや - 引数など、外部フィルタの特性を定義します。

    - -

    filtername は定義するフィルタの名前を指定します。 - この名前は後で SetOutputFilter - ディレクティブで指定できます。名前は登録されるすべてのフィルタで - 一意でなくてはなりません。現時点では、フィルタの登録 API からは - エラーは報告されません。ですから、重複する名前を使ってしまったときでも - ユーザにはそのことは報告されません。

    - -

    続くパラメータの順番は関係無く、それらは実行する外部コマンドと、 - 他の特性を定義します。cmd= だけが必須のパラメータです。 - 指定可能なパラメータは:

    - -
    -
    cmd=cmdline
    - -
    cmd= キーワードは実行する外部コマンドを指定します。 - プログラム名の後に引数がある場合は、コマンド行は引用符で囲む - 必要があります (例えば、cmd="/bin/mypgm - arg1 arg2" のように)。プログラムは - シェル経由でなく、直接実行されますので、通常のシェル用の - エスケープは必要ありません。プログラムの引数は空白で区切られます。 - プログラムの引数の一部となる必要のある空白はバックスペースでエスケープ - できます。引数の一部になるバックスラッシュはバックスラッシュで - エスケープする必要があります。標準の CGI 環境変数に加えて、 - 環境変数 DOCUMENT_URI, DOCUMENT_PATH_INFO, and - QUERY_STRING_UNESCAPED がプログラムのために設定されます。
    - -
    mode=mode
    - -
    応答を処理するフィルタには mode=output (デフォルト) - を使います。リクエストを処理するフィルタには mode=input - を使います。mode=input は Apache 2.1 以降で利用可能です。
    - -
    intype=imt
    - -
    このパラメータはフィルタされるべきドキュメントの - インターネットメディアタイプ (すなわち、MIME タイプ) を - 指定します。デフォルトではすべてのドキュメントがフィルタされます。 - intype= が指定されていれば、フィルタは指定されていない - ドキュメントには適用されなくなります。
    - -
    outtype=imt
    - -
    このパラメータはフィルタされたドキュメントの - インターネットメディアタイプ (すなわち、MIME タイプ) を - 指定します。フィルタ動作にともなってインターネットメディアタイプが - 変わる場合に有用です。デフォルトではインターネットメディアタイプは - 変更されません。
    - -
    PreservesContentLength
    - -
    PreservesContentLength キーワードはフィルタが - content length (訳注: コンテントの長さ) - を変更しないということを指定します。ほとんどのフィルタは - content length を変更するため、これはデフォルトではありません。 - フィルタが長さを変えないときは、このキーワードを指定すると - よいでしょう。
    - -
    ftype=filtertype
    - -
    このパラメータはフィルタが登録されるべきフィルタタイプの - 数値を指定します。ほとんどの場合は、デフォルトの AP_FTYPE_RESOURCE で - 十分です。フィルタがフィルタチェーンの別の場所で動作する必要がある - 場合は、このパラメータを指定する必要があります。指定可能な値は - util_filter.h の AP_FTYPE_foo 定義を参照してください。
    - -
    disableenv=env
    - -
    設定されていた場合にフィルタを無効にするための環境変数を - 指定します。
    - -
    enableenv=env
    - -
    このパラメータはフィルタが有効になるために設定されていなければ - ならない環境変数を指定します。
    -
    - -
    -
    top
    -

    ExtFilterOptions ディレクティブ

    - - - - - - - -
    説明:mod_ext_filter のオプションを設定
    構文:ExtFilterOptions option [option] ...
    デフォルト:ExtFilterOptions DebugLevel=0 NoLogStderr
    コンテキスト:ディレクトリ
    ステータス:Extension
    モジュール:mod_ext_filter
    -

    ExtFilterOptions ディレクティブは - mod_ext_filter の特別な処理用のオプションを - 指定します。Option には以下のどれかを指定します。

    - -
    -
    DebugLevel=n
    - -
    - DebugLevel で mod_ext_filter - の生成するデバッグメッセージのレベルを設定できます。 - デフォルトでは、デバッグメッセージは生成されません。 - これは DebugLevel=0 と設定するのと同じです。 - 数字が大きくなればなるほど、より多くのデバッグメッセージが - 生成され、サーバの性能は落ちます。数値の実際の意味は - mod_ext_filter.c の先頭近くの DBGLVL_ 定数の - 定義で説明されています。 - -

    注: デバッグメッセージを Apache のエラーログに - 保存するようにするためには、core のディレクティブ - LogLevel - を使う必要があります。

    -
    - -
    LogStderr | NoLogStderr
    - -
    LogStderr キーワードは外部フィルタプログラムにより - 標準エラー (訳注: stderr) に書かれたメッセージを - Apache のエラーログに保存するようにします。NoLogStderr は - 逆に保存しないようにします。
    -
    - -

    例

    - ExtFilterOptions LogStderr DebugLevel=0 -

    - -

    この例では、フィルタの標準出力に書かれたメッセージは - Apache のエラーログに保存されます。mod_ext_filter からは - デバッグメッセージは生成されません。

    -
    diff --git a/docs/manual/mod/mod_ext_filter.html.ko.euc-kr b/docs/manual/mod/mod_ext_filter.html.ko.euc-kr index 7bc325a7479..8a60b5abef8 100644 --- a/docs/manual/mod/mod_ext_filter.html.ko.euc-kr +++ b/docs/manual/mod/mod_ext_filter.html.ko.euc-kr @@ -73,6 +73,136 @@
  • ÇÊÅÍ
    • top
    +

    ExtFilterDefine Áö½Ã¾î

    + + + + + + +
    ¼³¸í:¿ÜºÎ ÇÊÅ͸¦ Á¤ÀÇÇÑ´Ù
    ¹®¹ý:ExtFilterDefine filtername parameters
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤
    »óÅÂ:Extension
    ¸ðµâ:mod_ext_filter
    +

    ExtFilterDefine Áö½Ã¾î´Â ¿ÜºÎ + ÇÊÅÍÀÇ ¼ºÁú°ú ½ÇÇàÇÒ ÇÁ·Î±×·¥, ¾Æ±Ô¸ÕÆ®¸¦ Á¤ÀÇÇÑ´Ù.

    + +

    filternameÀº Á¤ÀÇÇÒ ÇÊÅÍ À̸§À» ÁöÁ¤ÇÑ´Ù. + ÀÌ À̸§À» SetOutputFilter Áö½Ã¾î¿¡¼­ »ç¿ëÇÑ´Ù. µî·ÏÇÑ ¸ðµç + ÇÊÅ͵鰣¿¡ À̸§ÀÌ °ãÄ¡¸é ¾ÈµÈ´Ù. ÇöÀç ÇÊÅ͵î·Ï API´Â + ¿À·ù¸¦ º¸°íÇÏÁö ¾Ê´Â´Ù. ±×·¡¼­ »ç¿ëÀÚ´Â À̸§ÀÌ °ãÄ¡´Â ¹®Á¦¸¦ + ¾ËÁö ¸øÇÑ´Ù.

    + +

    ½ÇÇàÇÒ ¿ÜºÎ ¸í·É¾î¿Í ´Ù¸¥ ¼ºÁúÀ» Á¤ÀÇÇÏ´Â ³ª¸ÓÁö ¾Æ±Ô¸ÕÆ®´Â + ¾î¶² ¼ø¼­·Î ³ª¿Íµµ °¡´ÉÇÏ´Ù. ´Ü, cmd= ÆĶó¹ÌÅÍ´Â + ¹Ýµå½Ã ÇÊ¿äÇÏ´Ù. »ç¿ëÇÒ ¼ö ÀÖ´Â ÆĶó¹ÌÅÍ´Â ´ÙÀ½°ú °°´Ù:

    + +
    +
    cmd=cmdline
    + +
    cmd= Å°¿öµå´Â ½ÇÇàÇÒ ¿ÜºÎ ¸í·É¾î¸¦ ÁöÁ¤ÇÑ´Ù. + ÇÁ·Î±×·¥¸í µÚ¿¡ ¾Æ±Ô¸ÕÆ®°¡ ÀÖ´Ù¸é ¸í·ÉÇàÀ» ½Öµû¿ÈÇ¥·Î + ¹­¾î¾ß ÇÑ´Ù (¿¹¸¦ µé¾î, + cmd="/bin/mypgm arg1 + arg2"). ½©À» °ÅÄ¡Áö¾Ê°í Á÷Á¢ ÇÁ·Î±×·¥À» + ½ÇÇàÇϱ⶧¹®¿¡ ÀϹÝÀûÀÎ ½© µû¿ÈÇ¥´Â ÇÊ¿ä¾ø´Ù. ÇÁ·Î±×·¥ + ¾Æ±Ô¸ÕÆ®µéÀº °ø¹éÀ¸·Î ±¸ºÐÇÑ´Ù. ÇÁ·Î±×·¥ ¾Æ±Ô¸ÕÆ®¿¡ °ø¹éÀÌ + ÀÖ´Ù¸é °ø¹é ¾Õ¿¡ ¹é½½·¡½¬·Î »ç¿ëÇØ¾ß ÇÑ´Ù. ¹é½½·¡½¬°¡ + ¾Æ±Ô¸ÕÆ®ÀÇ ÀϺζó¸é ¹é½½·¡½¬¸¦ µÎ¹ø »ç¿ëÇØ¾ß ÇÑ´Ù. ÇÁ·Î±×·¥À» + ½ÇÇàÇÒ¶§ Ç¥ÁØ CGI ȯ°æº¯¼ö¿Í Ãß°¡·Î DOCUMENT_URI, + DOCUMENT_PATH_INFO, QUERY_STRING_UNESCAPED º¯¼ö¸¦ ¼³Á¤ÇÑ´Ù.
    + +
    mode=mode
    + +
    ÀÀ´äÀ» ó¸®ÇÏ´Â ÇÊÅÍ´Â (±âº»°ªÀÎ) mode=outputÀ» + »ç¿ëÇÑ´Ù. ¿äûÀ» ó¸®ÇÏ´Â ÇÊÅÍ´Â mode=inputÀ» + »ç¿ëÇÑ´Ù. mode=inputÀº ¾ÆÆÄÄ¡ 2.1¿¡ Ãß°¡µÇ¾ú´Ù.
    + +
    intype=imt
    + +
    ÀÌ ÆĶó¹ÌÅÍ´Â ÇÊÅͷΠó¸®ÇÒ ¹®¼­ÀÇ ÀÎÅÍ³Ý media + type(Áï, MIME type)À» ÁöÁ¤ÇÑ´Ù. ±âº»ÀûÀ¸·Î ¸ðµç + ¹®¼­¸¦ ÇÊÅͷΠó¸®ÇÑ´Ù. intype=À» ÁöÁ¤Çϸé + ´Ù¸¥ typeÀÇ ¹®¼­´Â ÇÊÅͷΠó¸®ÇÏÁö ¾Ê´Â´Ù.
    + +
    outtype=imt
    + +
    ÀÌ ÆĶó¹ÌÅÍ´Â ÇÊÅͷΠó¸®ÇÑ ¹®¼­ÀÇ ÀÎÅÍ³Ý media + type(Áï, MIME type)À» ÁöÁ¤ÇÑ´Ù. ÇÊÅÍó¸® ÀÛ¾÷Áß¿¡ + ÀÎÅÍ³Ý media typeÀ» º¯°æÇÒ¶§ À¯¿ëÇÏ´Ù. ±âº»ÀûÀ¸·Î, ÀÎÅÍ³Ý + media typeÀº º¯ÇÏÁö ¾Ê´Â´Ù.
    + +
    PreservesContentLength
    + +
    PreservesContentLength Å°¿öµå´Â ÇÊÅÍ°¡ + content length¸¦ À¯ÁöÇϵµ·Ï ÇÑ´Ù. ´ëºÎºÐÀÇ ÇÊÅÍ°¡ content + length¸¦ º¯°æÇϹǷΠÀÌ Å°¿öµå´Â ±âº»°ªÀÌ ¾Æ´Ï´Ù. ÇÊÅÍ°¡ + ±æÀ̸¦ À¯ÁöÇÒ¶§¸¸ ÀÌ Å°¿öµå¸¦ »ç¿ëÇØ¾ß ÇÑ´Ù.
    + +
    ftype=filtertype
    + +
    ÀÌ ÆĶó¹ÌÅÍ´Â ÇÊÅÍ Á¾·ù¿¡ ´ëÇÑ ¼ýÀÚ°ªÀ» ÁöÁ¤ÇÑ´Ù. + ´ëºÎºÐÀÇ °æ¿ì ±âº»°ªÀÎ AP_FTYPE_RESOURCE°¡ Àû´çÇÏ´Ù. + ÇÊÅ͸¦ ½ÇÇàÇÏ´Â ¼ø¼­°¡ ÀÚ¿øÇÊÅÍ¿Í ´Þ¶ó¾ßÇÏ´Â °æ¿ì ÀÌ + ÆĶó¹ÌÅÍ°¡ ÇÊ¿äÇÏ´Ù. Àû´çÇÑ °ªÀ» ¾Ë·Á¸é util_filter.h¿¡ + ÀÖ´Â AP_FTYPE_* Á¤ÀǸ¦ Âü°íÇ϶ó.
    + +
    disableenv=env
    + +
    ÀÌ ÆĶó¹ÌÅÍ·Î ¼³Á¤ÇÑ È¯°æº¯¼ö°¡ Á¤ÀǵǾú´Ù¸é ÇÊÅ͸¦ + »ç¿ëÇÏÁö ¾Ê´Â´Ù.
    + +
    enableenv=env
    + +
    ÀÌ ÆĶó¹ÌÅÍ·Î ¼³Á¤ÇÑ È¯°æº¯¼ö°¡ Á¤ÀÇµÈ °æ¿ì ÇÊÅ͸¦ + »ç¿ëÇÑ´Ù.
    +
    + +
    +
    top
    +

    ExtFilterOptions Áö½Ã¾î

    + + + + + + + +
    ¼³¸í:mod_ext_filter ¿É¼ÇÀ» ¼³Á¤ÇÑ´Ù
    ¹®¹ý:ExtFilterOptions option [option] ...
    ±âº»°ª:ExtFilterOptions DebugLevel=0 NoLogStderr
    »ç¿ëÀå¼Ò:directory
    »óÅÂ:Extension
    ¸ðµâ:mod_ext_filter
    +

    ExtFilterOptions Áö½Ã¾î´Â + mod_ext_filterÀÇ Æ¯º°ÇÑ Ã³¸®¿É¼ÇÀ» ÁöÁ¤ÇÑ´Ù. + OptionÀº ´ÙÀ½Áß Çϳª´Ù.

    + +
    +
    DebugLevel=n
    + +
    + DebugLevel Å°¿öµå´Â + mod_ext_filter°¡ ±â·ÏÇÏ´Â µð¹ö±× ¹®±¸ + ¼öÁØÀ» Á¤ÇÑ´Ù. ±âº»°ªÀº µð¹ö±×¹®À» ±â·ÏÇÏÁö ¾Ê´Â´Ù. + ÀÌ´Â DebugLevel=0°ú °°´Ù. ³ôÀº ¼ýÀÚ¸¦ + »ç¿ëÇÒ¼ö·Ï, ´õ ¸¹Àº µð¹ö±×¹®ÀÌ ±â·ÏµÇ°í ¼­¹ö ¼º´ÉÀÌ + ¶³¾îÁø´Ù. ¼ýÀÚ°ªÀÇ ½ÇÁ¦ Àǹ̴ mod_ext_filter.c + ¾ÕºÎºÐ¿¡ ÀÖ´Â DBGLVL_ »ó¼ö Á¤ÀÇ¿¡ ¼³¸íµÇÀÖ´Ù. + +

    ÁÖÀÇ: ÇÊÅÍ ·Î±×¸¦ ±â·ÏÇÏ·Á¸é core Áö½Ã¾î LogLevelÀ» »ç¿ëÇÏ¿© µð¹ö±×¹®À» + ¾ÆÆÄÄ¡ ¿À·ù·Î±×¿¡ ±â·ÏÇØ¾ß ÇÑ´Ù.

    +
    + +
    LogStderr | NoLogStderr
    + +
    LogStderr Å°¿öµå´Â ¿ÜºÎ ÇÊÅÍ ÇÁ·Î±×·¥ÀÌ + Ç¥ÁØ¿À·ù·Î Ãâ·ÂÇÏ´Â ¹®±¸¸¦ ¾ÆÆÄÄ¡ ¿À·ù·Î±×¿¡ ±â·ÏÇÑ´Ù. + NoLogStderr´Â ÀÌ ±â´ÉÀ» ÇÏÁö ¾Ê´Â´Ù.
    +
    + +

    ¿¹Á¦

    + ExtFilterOptions LogStderr DebugLevel=0 +

    + +

    À§ÀÇ ¼³Á¤À» »ç¿ëÇϸé ÇÊÅÍ°¡ Ç¥ÁØ¿À·ù·Î Ãâ·ÂÇÏ´Â ¹®±¸¸¦ + ¾ÆÆÄÄ¡ ¿À·ù·Î±×¿¡ ±â·ÏÇÏ°í, mod_ext_filter´Â + ÀÚü µð¹ö±×¹®À» ±â·ÏÇÏÁö ¾Ê´Â´Ù.

    + +
    +
    top

    ¿¹Á¦

    @@ -216,136 +346,6 @@ close(SAVE);

    - -
    top
    -

    ExtFilterDefine Áö½Ã¾î

    - - - - - - -
    ¼³¸í:¿ÜºÎ ÇÊÅ͸¦ Á¤ÀÇÇÑ´Ù
    ¹®¹ý:ExtFilterDefine filtername parameters
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤
    »óÅÂ:Extension
    ¸ðµâ:mod_ext_filter
    -

    ExtFilterDefine Áö½Ã¾î´Â ¿ÜºÎ - ÇÊÅÍÀÇ ¼ºÁú°ú ½ÇÇàÇÒ ÇÁ·Î±×·¥, ¾Æ±Ô¸ÕÆ®¸¦ Á¤ÀÇÇÑ´Ù.

    - -

    filternameÀº Á¤ÀÇÇÒ ÇÊÅÍ À̸§À» ÁöÁ¤ÇÑ´Ù. - ÀÌ À̸§À» SetOutputFilter Áö½Ã¾î¿¡¼­ »ç¿ëÇÑ´Ù. µî·ÏÇÑ ¸ðµç - ÇÊÅ͵鰣¿¡ À̸§ÀÌ °ãÄ¡¸é ¾ÈµÈ´Ù. ÇöÀç ÇÊÅ͵î·Ï API´Â - ¿À·ù¸¦ º¸°íÇÏÁö ¾Ê´Â´Ù. ±×·¡¼­ »ç¿ëÀÚ´Â À̸§ÀÌ °ãÄ¡´Â ¹®Á¦¸¦ - ¾ËÁö ¸øÇÑ´Ù.

    - -

    ½ÇÇàÇÒ ¿ÜºÎ ¸í·É¾î¿Í ´Ù¸¥ ¼ºÁúÀ» Á¤ÀÇÇÏ´Â ³ª¸ÓÁö ¾Æ±Ô¸ÕÆ®´Â - ¾î¶² ¼ø¼­·Î ³ª¿Íµµ °¡´ÉÇÏ´Ù. ´Ü, cmd= ÆĶó¹ÌÅÍ´Â - ¹Ýµå½Ã ÇÊ¿äÇÏ´Ù. »ç¿ëÇÒ ¼ö ÀÖ´Â ÆĶó¹ÌÅÍ´Â ´ÙÀ½°ú °°´Ù:

    - -
    -
    cmd=cmdline
    - -
    cmd= Å°¿öµå´Â ½ÇÇàÇÒ ¿ÜºÎ ¸í·É¾î¸¦ ÁöÁ¤ÇÑ´Ù. - ÇÁ·Î±×·¥¸í µÚ¿¡ ¾Æ±Ô¸ÕÆ®°¡ ÀÖ´Ù¸é ¸í·ÉÇàÀ» ½Öµû¿ÈÇ¥·Î - ¹­¾î¾ß ÇÑ´Ù (¿¹¸¦ µé¾î, - cmd="/bin/mypgm arg1 - arg2"). ½©À» °ÅÄ¡Áö¾Ê°í Á÷Á¢ ÇÁ·Î±×·¥À» - ½ÇÇàÇϱ⶧¹®¿¡ ÀϹÝÀûÀÎ ½© µû¿ÈÇ¥´Â ÇÊ¿ä¾ø´Ù. ÇÁ·Î±×·¥ - ¾Æ±Ô¸ÕÆ®µéÀº °ø¹éÀ¸·Î ±¸ºÐÇÑ´Ù. ÇÁ·Î±×·¥ ¾Æ±Ô¸ÕÆ®¿¡ °ø¹éÀÌ - ÀÖ´Ù¸é °ø¹é ¾Õ¿¡ ¹é½½·¡½¬·Î »ç¿ëÇØ¾ß ÇÑ´Ù. ¹é½½·¡½¬°¡ - ¾Æ±Ô¸ÕÆ®ÀÇ ÀϺζó¸é ¹é½½·¡½¬¸¦ µÎ¹ø »ç¿ëÇØ¾ß ÇÑ´Ù. ÇÁ·Î±×·¥À» - ½ÇÇàÇÒ¶§ Ç¥ÁØ CGI ȯ°æº¯¼ö¿Í Ãß°¡·Î DOCUMENT_URI, - DOCUMENT_PATH_INFO, QUERY_STRING_UNESCAPED º¯¼ö¸¦ ¼³Á¤ÇÑ´Ù.
    - -
    mode=mode
    - -
    ÀÀ´äÀ» ó¸®ÇÏ´Â ÇÊÅÍ´Â (±âº»°ªÀÎ) mode=outputÀ» - »ç¿ëÇÑ´Ù. ¿äûÀ» ó¸®ÇÏ´Â ÇÊÅÍ´Â mode=inputÀ» - »ç¿ëÇÑ´Ù. mode=inputÀº ¾ÆÆÄÄ¡ 2.1¿¡ Ãß°¡µÇ¾ú´Ù.
    - -
    intype=imt
    - -
    ÀÌ ÆĶó¹ÌÅÍ´Â ÇÊÅͷΠó¸®ÇÒ ¹®¼­ÀÇ ÀÎÅÍ³Ý media - type(Áï, MIME type)À» ÁöÁ¤ÇÑ´Ù. ±âº»ÀûÀ¸·Î ¸ðµç - ¹®¼­¸¦ ÇÊÅͷΠó¸®ÇÑ´Ù. intype=À» ÁöÁ¤Çϸé - ´Ù¸¥ typeÀÇ ¹®¼­´Â ÇÊÅͷΠó¸®ÇÏÁö ¾Ê´Â´Ù.
    - -
    outtype=imt
    - -
    ÀÌ ÆĶó¹ÌÅÍ´Â ÇÊÅͷΠó¸®ÇÑ ¹®¼­ÀÇ ÀÎÅÍ³Ý media - type(Áï, MIME type)À» ÁöÁ¤ÇÑ´Ù. ÇÊÅÍó¸® ÀÛ¾÷Áß¿¡ - ÀÎÅÍ³Ý media typeÀ» º¯°æÇÒ¶§ À¯¿ëÇÏ´Ù. ±âº»ÀûÀ¸·Î, ÀÎÅÍ³Ý - media typeÀº º¯ÇÏÁö ¾Ê´Â´Ù.
    - -
    PreservesContentLength
    - -
    PreservesContentLength Å°¿öµå´Â ÇÊÅÍ°¡ - content length¸¦ À¯ÁöÇϵµ·Ï ÇÑ´Ù. ´ëºÎºÐÀÇ ÇÊÅÍ°¡ content - length¸¦ º¯°æÇϹǷΠÀÌ Å°¿öµå´Â ±âº»°ªÀÌ ¾Æ´Ï´Ù. ÇÊÅÍ°¡ - ±æÀ̸¦ À¯ÁöÇÒ¶§¸¸ ÀÌ Å°¿öµå¸¦ »ç¿ëÇØ¾ß ÇÑ´Ù.
    - -
    ftype=filtertype
    - -
    ÀÌ ÆĶó¹ÌÅÍ´Â ÇÊÅÍ Á¾·ù¿¡ ´ëÇÑ ¼ýÀÚ°ªÀ» ÁöÁ¤ÇÑ´Ù. - ´ëºÎºÐÀÇ °æ¿ì ±âº»°ªÀÎ AP_FTYPE_RESOURCE°¡ Àû´çÇÏ´Ù. - ÇÊÅ͸¦ ½ÇÇàÇÏ´Â ¼ø¼­°¡ ÀÚ¿øÇÊÅÍ¿Í ´Þ¶ó¾ßÇÏ´Â °æ¿ì ÀÌ - ÆĶó¹ÌÅÍ°¡ ÇÊ¿äÇÏ´Ù. Àû´çÇÑ °ªÀ» ¾Ë·Á¸é util_filter.h¿¡ - ÀÖ´Â AP_FTYPE_* Á¤ÀǸ¦ Âü°íÇ϶ó.
    - -
    disableenv=env
    - -
    ÀÌ ÆĶó¹ÌÅÍ·Î ¼³Á¤ÇÑ È¯°æº¯¼ö°¡ Á¤ÀǵǾú´Ù¸é ÇÊÅ͸¦ - »ç¿ëÇÏÁö ¾Ê´Â´Ù.
    - -
    enableenv=env
    - -
    ÀÌ ÆĶó¹ÌÅÍ·Î ¼³Á¤ÇÑ È¯°æº¯¼ö°¡ Á¤ÀÇµÈ °æ¿ì ÇÊÅ͸¦ - »ç¿ëÇÑ´Ù.
    -
    - -
    -
    top
    -

    ExtFilterOptions Áö½Ã¾î

    - - - - - - - -
    ¼³¸í:mod_ext_filter ¿É¼ÇÀ» ¼³Á¤ÇÑ´Ù
    ¹®¹ý:ExtFilterOptions option [option] ...
    ±âº»°ª:ExtFilterOptions DebugLevel=0 NoLogStderr
    »ç¿ëÀå¼Ò:directory
    »óÅÂ:Extension
    ¸ðµâ:mod_ext_filter
    -

    ExtFilterOptions Áö½Ã¾î´Â - mod_ext_filterÀÇ Æ¯º°ÇÑ Ã³¸®¿É¼ÇÀ» ÁöÁ¤ÇÑ´Ù. - OptionÀº ´ÙÀ½Áß Çϳª´Ù.

    - -
    -
    DebugLevel=n
    - -
    - DebugLevel Å°¿öµå´Â - mod_ext_filter°¡ ±â·ÏÇÏ´Â µð¹ö±× ¹®±¸ - ¼öÁØÀ» Á¤ÇÑ´Ù. ±âº»°ªÀº µð¹ö±×¹®À» ±â·ÏÇÏÁö ¾Ê´Â´Ù. - ÀÌ´Â DebugLevel=0°ú °°´Ù. ³ôÀº ¼ýÀÚ¸¦ - »ç¿ëÇÒ¼ö·Ï, ´õ ¸¹Àº µð¹ö±×¹®ÀÌ ±â·ÏµÇ°í ¼­¹ö ¼º´ÉÀÌ - ¶³¾îÁø´Ù. ¼ýÀÚ°ªÀÇ ½ÇÁ¦ Àǹ̴ mod_ext_filter.c - ¾ÕºÎºÐ¿¡ ÀÖ´Â DBGLVL_ »ó¼ö Á¤ÀÇ¿¡ ¼³¸íµÇÀÖ´Ù. - -

    ÁÖÀÇ: ÇÊÅÍ ·Î±×¸¦ ±â·ÏÇÏ·Á¸é core Áö½Ã¾î LogLevelÀ» »ç¿ëÇÏ¿© µð¹ö±×¹®À» - ¾ÆÆÄÄ¡ ¿À·ù·Î±×¿¡ ±â·ÏÇØ¾ß ÇÑ´Ù.

    -
    - -
    LogStderr | NoLogStderr
    - -
    LogStderr Å°¿öµå´Â ¿ÜºÎ ÇÊÅÍ ÇÁ·Î±×·¥ÀÌ - Ç¥ÁØ¿À·ù·Î Ãâ·ÂÇÏ´Â ¹®±¸¸¦ ¾ÆÆÄÄ¡ ¿À·ù·Î±×¿¡ ±â·ÏÇÑ´Ù. - NoLogStderr´Â ÀÌ ±â´ÉÀ» ÇÏÁö ¾Ê´Â´Ù.
    -
    - -

    ¿¹Á¦

    - ExtFilterOptions LogStderr DebugLevel=0 -

    - -

    À§ÀÇ ¼³Á¤À» »ç¿ëÇϸé ÇÊÅÍ°¡ Ç¥ÁØ¿À·ù·Î Ãâ·ÂÇÏ´Â ¹®±¸¸¦ - ¾ÆÆÄÄ¡ ¿À·ù·Î±×¿¡ ±â·ÏÇÏ°í, mod_ext_filter´Â - ÀÚü µð¹ö±×¹®À» ±â·ÏÇÏÁö ¾Ê´Â´Ù.

    -
    diff --git a/docs/manual/mod/mod_file_cache.html.en b/docs/manual/mod/mod_file_cache.html.en index e2fba57cc5d..ab0bbbdb3ad 100644 --- a/docs/manual/mod/mod_file_cache.html.en +++ b/docs/manual/mod/mod_file_cache.html.en @@ -70,6 +70,64 @@
  • Using mod_file_cache
    • top
    +

    CacheFile Directive

    + + + + + + +
    Description:Cache a list of file handles at startup time
    Syntax:CacheFile file-path [file-path] ...
    Context:server config
    Status:Experimental
    Module:mod_file_cache
    +

    The CacheFile directive opens handles to + one or more files (given as whitespace separated arguments) and + places these handles into the cache at server startup + time. Handles to cached files are automatically closed on a server + shutdown. When the files have changed on the filesystem, the + server should be restarted to re-cache them.

    + +

    Be careful with the file-path arguments: They have + to literally match the filesystem path Apache's URL-to-filename + translation handlers create. We cannot compare inodes or other + stuff to match paths through symbolic links etc. + because that again would cost extra stat() system + calls which is not acceptable. This module may or may not work + with filenames rewritten by mod_alias or + mod_rewrite.

    + +

    Example

    CacheFile /usr/local/apache/htdocs/index.html
    +
    + +
    +
    top
    +

    MMapFile Directive

    + + + + + + +
    Description:Map a list of files into memory at startup time
    Syntax:MMapFile file-path [file-path] ...
    Context:server config
    Status:Experimental
    Module:mod_file_cache
    +

    The MMapFile directive maps one or more files + (given as whitespace separated arguments) into memory at server + startup time. They are automatically unmapped on a server + shutdown. When the files have changed on the filesystem at + least a HUP or USR1 signal should be send to + the server to re-mmap() them.

    + +

    Be careful with the file-path arguments: They have + to literally match the filesystem path Apache's URL-to-filename + translation handlers create. We cannot compare inodes or other + stuff to match paths through symbolic links etc. + because that again would cost extra stat() system + calls which is not acceptable. This module may or may not work + with filenames rewritten by mod_alias or + mod_rewrite.

    + +

    Example

    MMapFile /usr/local/apache/htdocs/index.html
    +
    + +
    +
    top

    Using mod_file_cache

    @@ -143,64 +201,6 @@ | sed -e 's/.*/mmapfile &/' > /www/conf/mmap.conf

    - -
    top
    -

    CacheFile Directive

    - - - - - - -
    Description:Cache a list of file handles at startup time
    Syntax:CacheFile file-path [file-path] ...
    Context:server config
    Status:Experimental
    Module:mod_file_cache
    -

    The CacheFile directive opens handles to - one or more files (given as whitespace separated arguments) and - places these handles into the cache at server startup - time. Handles to cached files are automatically closed on a server - shutdown. When the files have changed on the filesystem, the - server should be restarted to re-cache them.

    - -

    Be careful with the file-path arguments: They have - to literally match the filesystem path Apache's URL-to-filename - translation handlers create. We cannot compare inodes or other - stuff to match paths through symbolic links etc. - because that again would cost extra stat() system - calls which is not acceptable. This module may or may not work - with filenames rewritten by mod_alias or - mod_rewrite.

    - -

    Example

    CacheFile /usr/local/apache/htdocs/index.html
    -
    - -
    -
    top
    -

    MMapFile Directive

    - - - - - - -
    Description:Map a list of files into memory at startup time
    Syntax:MMapFile file-path [file-path] ...
    Context:server config
    Status:Experimental
    Module:mod_file_cache
    -

    The MMapFile directive maps one or more files - (given as whitespace separated arguments) into memory at server - startup time. They are automatically unmapped on a server - shutdown. When the files have changed on the filesystem at - least a HUP or USR1 signal should be send to - the server to re-mmap() them.

    - -

    Be careful with the file-path arguments: They have - to literally match the filesystem path Apache's URL-to-filename - translation handlers create. We cannot compare inodes or other - stuff to match paths through symbolic links etc. - because that again would cost extra stat() system - calls which is not acceptable. This module may or may not work - with filenames rewritten by mod_alias or - mod_rewrite.

    - -

    Example

    MMapFile /usr/local/apache/htdocs/index.html
    -
    -
    diff --git a/docs/manual/mod/mod_file_cache.html.fr b/docs/manual/mod/mod_file_cache.html.fr index d499be35ff6..441436cb0dc 100644 --- a/docs/manual/mod/mod_file_cache.html.fr +++ b/docs/manual/mod/mod_file_cache.html.fr @@ -78,6 +78,72 @@ fichiers
    + + + + + +
    Description:Met en cache une liste de gestionnaires de fichiers au +démarrage
    Syntaxe:CacheFile chemin fichier [chemin fichier] ...
    Contexte:configuration du serveur
    Statut:Expérimental
    Module:mod_file_cache
    +

    La directive CacheFile permet d'associer + des gestionnaires à un ou plusieurs fichiers (séparés par des + espaces), et de placer ceux-ci dans le cache au démarrage du + serveur. Les gestionnaires des fichiers mis en cache sont + automatiquement fermés à l'arrêt du serveur. Lorsqu'un ou plusieurs + fichiers ont été modifiés sur disque, le serveur doit être redémarré + afin que les modifications soient prises en compte par le cache.

    + +

    Soyez prudent avec les arguments chemin fichier : ils + doivent correspondre exactement au chemin du système de fichier que + créent les gestionnaires de traduction URL-vers-nom-fichier + d'Apache. On ne peut pas comparer des inodes ou autres identifiants + pour mettre en correspondance des chemins à l'aide de liens + symboliques (etc...), car là encore, ceci nécessiterait un + appel à stat() supplémentaire, ce qui n'est pas acceptable. + Il n'est pas garanti que ce module fonctionne avec des noms de + fichiers réécrits par mod_alias ou + mod_rewrite.

    + +

    Exemple

    CacheFile /usr/local/apache/htdocs/index.html
    +
    + +
    +
    top
    +

    Directive MMapFile

    + + + + + + +
    Description:Charge au démarrage une liste de fichiers en mémoire
    Syntaxe:MMapFile chemin fichier [chemin fichier] ...
    Contexte:configuration du serveur
    Statut:Expérimental
    Module:mod_file_cache
    +

    La directive MMapFile permet de charger un + ou plusieurs fichiers (séparés par des espaces) en mémoire au + démarrage du serveur. Ceux-ci sont automatiquement déchargés de la + mémoire à l'arrêt du serveur. Lorsqu'un ou plusieurs fichiers ont + été modifiés sur disque, on doit au minimum envoyer un signal + HUP ou USR1 au serveur afin de les + remmap()er.

    + +

    Soyez prudent avec les arguments chemin fichier : ils + doivent correspondre exactement au chemin du système de fichier que + créent les gestionnaires de traduction URL-vers-nom-fichier + d'Apache. On ne peut pas comparer des inodes ou autres identifiants + pour mettre en correspondance des chemins à l'aide de liens + symboliques (etc...), car là encore, ceci nécessiterait un + appel à stat() supplémentaire, ce qui n'est pas + acceptable. + Il n'est pas garanti que ce module fonctionne avec des noms de + fichiers réécrits par mod_alias ou + mod_rewrite.

    + +

    Exemple

    MMapFile /usr/local/apache/htdocs/index.html
    +
    + +
    +
    top

    Utilisation de mod_file_cache

    @@ -168,72 +234,6 @@ fichiers
    - - - - - -
    Description:Met en cache une liste de gestionnaires de fichiers au -démarrage
    Syntaxe:CacheFile chemin fichier [chemin fichier] ...
    Contexte:configuration du serveur
    Statut:Expérimental
    Module:mod_file_cache
    -

    La directive CacheFile permet d'associer - des gestionnaires à un ou plusieurs fichiers (séparés par des - espaces), et de placer ceux-ci dans le cache au démarrage du - serveur. Les gestionnaires des fichiers mis en cache sont - automatiquement fermés à l'arrêt du serveur. Lorsqu'un ou plusieurs - fichiers ont été modifiés sur disque, le serveur doit être redémarré - afin que les modifications soient prises en compte par le cache.

    - -

    Soyez prudent avec les arguments chemin fichier : ils - doivent correspondre exactement au chemin du système de fichier que - créent les gestionnaires de traduction URL-vers-nom-fichier - d'Apache. On ne peut pas comparer des inodes ou autres identifiants - pour mettre en correspondance des chemins à l'aide de liens - symboliques (etc...), car là encore, ceci nécessiterait un - appel à stat() supplémentaire, ce qui n'est pas acceptable. - Il n'est pas garanti que ce module fonctionne avec des noms de - fichiers réécrits par mod_alias ou - mod_rewrite.

    - -

    Exemple

    CacheFile /usr/local/apache/htdocs/index.html
    -
    - -
    -
    top
    -

    Directive MMapFile

    - - - - - - -
    Description:Charge au démarrage une liste de fichiers en mémoire
    Syntaxe:MMapFile chemin fichier [chemin fichier] ...
    Contexte:configuration du serveur
    Statut:Expérimental
    Module:mod_file_cache
    -

    La directive MMapFile permet de charger un - ou plusieurs fichiers (séparés par des espaces) en mémoire au - démarrage du serveur. Ceux-ci sont automatiquement déchargés de la - mémoire à l'arrêt du serveur. Lorsqu'un ou plusieurs fichiers ont - été modifiés sur disque, on doit au minimum envoyer un signal - HUP ou USR1 au serveur afin de les - remmap()er.

    - -

    Soyez prudent avec les arguments chemin fichier : ils - doivent correspondre exactement au chemin du système de fichier que - créent les gestionnaires de traduction URL-vers-nom-fichier - d'Apache. On ne peut pas comparer des inodes ou autres identifiants - pour mettre en correspondance des chemins à l'aide de liens - symboliques (etc...), car là encore, ceci nécessiterait un - appel à stat() supplémentaire, ce qui n'est pas - acceptable. - Il n'est pas garanti que ce module fonctionne avec des noms de - fichiers réécrits par mod_alias ou - mod_rewrite.

    - -

    Exemple

    MMapFile /usr/local/apache/htdocs/index.html
    -
    -
    diff --git a/docs/manual/mod/mod_file_cache.html.ko.euc-kr b/docs/manual/mod/mod_file_cache.html.ko.euc-kr index 300804af319..892a51308b9 100644 --- a/docs/manual/mod/mod_file_cache.html.ko.euc-kr +++ b/docs/manual/mod/mod_file_cache.html.ko.euc-kr @@ -71,6 +71,63 @@
  • mod_file_cache »ç¿ëÇϱâ
    • top
    +

    CacheFile Áö½Ã¾î

    + + + + + + +
    ¼³¸í:½ÃÀ۽à ¿©·¯ ÆÄÀÏ ÇÚµéÀ» ij½¬ÇÑ´Ù
    ¹®¹ý:CacheFile file-path [file-path] ...
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤
    »óÅÂ:Experimental
    ¸ðµâ:mod_file_cache
    +

    CacheFile Áö½Ã¾î´Â ¼­¹ö°¡ ½ÃÀÛÇÒ¶§ + ¿©·¯ ÆÄÀÏÀ» ¿­°í(open) ÆÄÀϵéÀÇ ÇÚµéÀ» ij½¬¿¡ ÀúÀåÇÑ´Ù. + ¼­¹ö Á¾·á½Ã ÀÚµ¿À¸·Î ij½¬ÇÑ ÆÄÀÏÀÇ ÇÚµéÀ» ´Ý´Â´Ù(close). + ÆÄÀϽýºÅÛ¿¡¼­ ÆÄÀÏÀÌ º¯°æµÇ¸é ÆÄÀÏÀ» ´Ù½Ã ij½¬ÇϱâÀ§ÇØ + ¼­¹ö¸¦ Àç½ÃÀÛÇØ¾ß ÇÑ´Ù.

    + +

    file-path ¾Æ±Ô¸ÕÆ®¸¦ Á¶½ÉÇضó. ¾Æ±Ô¸ÕÆ®´Â + ¾ÆÆÄÄ¡ÀÇ URL-ÆÄÀÏ¸í º¯È¯ Çڵ鷯°¡ ¸¸µç ÆÄÀϽýºÅÛ °æ·Î¿Í + Á¤È®È÷ ÀÏÄ¡ÇØ¾ß ÇÑ´Ù. Çѹø ´õ ºÒÇÊ¿äÇÑ stat() + ½Ã½ºÅÛÈ£ÃâÀÌ ÇÊ¿äÇϱ⶧¹®¿¡ inode³ª ½Éº¼¸µÅ© µîÀ» + °æ·Î¸¦ ÁöÁ¤ÇÒ ¼ö ¾ø´Ù. ÀÌ ¸ðµâÀº mod_alias³ª + mod_rewrite·Î ÀçÀÛ¼ºÇÑ ÆÄÀϸíÀ» ´Ù·ê ¼ö + Àֱ⵵ ¾ø±âµµ ÇÏ´Ù.

    + +

    ¿¹Á¦

    + CacheFile /usr/local/apache/htdocs/index.html +

    + +
    +
    top
    +

    MMapFile Áö½Ã¾î

    + + + + + + +
    ¼³¸í:½ÃÀ۽à ¿©·¯ ÆÄÀÏÀ» ¸Þ¸ð¸®¿¡ ´ëÀÀÇÑ´Ù
    ¹®¹ý:MMapFile file-path [file-path] ...
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤
    »óÅÂ:Experimental
    ¸ðµâ:mod_file_cache
    +

    MMapFile Áö½Ã¾î´Â ¼­¹ö°¡ ½ÃÀÛÇÒ¶§ + (°ø¹éÀ¸·Î ±¸ºÐÇÑ ¾Æ±Ô¸ÕÆ®·Î ÁöÁ¤ÇÑ) ¿©·¯ ÆÄÀÏÀ» ¸Þ¸ð¸®¿¡ + ´ëÀÀÇÑ´Ù(map). ¼­¹ö Á¾·á½Ã ÀÚµ¿À¸·Î ´ëÀÀÀ» Ǭ´Ù(unmap). + ÆÄÀϽýºÅÛ¿¡¼­ ÆÄÀÏÀÌ º¯°æµÇ¸é ÆÄÀϵéÀ» ´Ù½Ã + mmap()ÇϱâÀ§ÇØ ÃÖ¼ÒÇÑ ¼­¹ö¿¡ HUPÀ̳ª + USR1 ½Ã±×³ÎÀ» º¸³»¾ß ÇÑ´Ù.

    + +

    file-path ¾Æ±Ô¸ÕÆ®¸¦ Á¶½ÉÇضó. ¾Æ±Ô¸ÕÆ®´Â + ¾ÆÆÄÄ¡ÀÇ URL-ÆÄÀÏ¸í º¯È¯ Çڵ鷯°¡ ¸¸µç ÆÄÀϽýºÅÛ °æ·Î¿Í + Á¤È®È÷ ÀÏÄ¡ÇØ¾ß ÇÑ´Ù. Çѹø ´õ ºÒÇÊ¿äÇÑ stat() + ½Ã½ºÅÛÈ£ÃâÀÌ ÇÊ¿äÇϱ⶧¹®¿¡ inode³ª ½Éº¼¸µÅ© µîÀ» + °æ·Î¸¦ ÁöÁ¤ÇÒ ¼ö ¾ø´Ù. ÀÌ ¸ðµâÀº mod_alias³ª + mod_rewrite·Î ÀçÀÛ¼ºÇÑ ÆÄÀϸíÀ» ´Ù·ê ¼ö + Àֱ⵵ ¾ø±âµµ ÇÏ´Ù.

    + +

    ¿¹Á¦

    + MMapFile /usr/local/apache/htdocs/index.html +

    + +
    +
    top

    mod_file_cache »ç¿ëÇϱâ

    @@ -139,63 +196,6 @@

    -
    top
    -

    CacheFile Áö½Ã¾î

    - - - - - - -
    ¼³¸í:½ÃÀ۽à ¿©·¯ ÆÄÀÏ ÇÚµéÀ» ij½¬ÇÑ´Ù
    ¹®¹ý:CacheFile file-path [file-path] ...
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤
    »óÅÂ:Experimental
    ¸ðµâ:mod_file_cache
    -

    CacheFile Áö½Ã¾î´Â ¼­¹ö°¡ ½ÃÀÛÇÒ¶§ - ¿©·¯ ÆÄÀÏÀ» ¿­°í(open) ÆÄÀϵéÀÇ ÇÚµéÀ» ij½¬¿¡ ÀúÀåÇÑ´Ù. - ¼­¹ö Á¾·á½Ã ÀÚµ¿À¸·Î ij½¬ÇÑ ÆÄÀÏÀÇ ÇÚµéÀ» ´Ý´Â´Ù(close). - ÆÄÀϽýºÅÛ¿¡¼­ ÆÄÀÏÀÌ º¯°æµÇ¸é ÆÄÀÏÀ» ´Ù½Ã ij½¬ÇϱâÀ§ÇØ - ¼­¹ö¸¦ Àç½ÃÀÛÇØ¾ß ÇÑ´Ù.

    - -

    file-path ¾Æ±Ô¸ÕÆ®¸¦ Á¶½ÉÇضó. ¾Æ±Ô¸ÕÆ®´Â - ¾ÆÆÄÄ¡ÀÇ URL-ÆÄÀÏ¸í º¯È¯ Çڵ鷯°¡ ¸¸µç ÆÄÀϽýºÅÛ °æ·Î¿Í - Á¤È®È÷ ÀÏÄ¡ÇØ¾ß ÇÑ´Ù. Çѹø ´õ ºÒÇÊ¿äÇÑ stat() - ½Ã½ºÅÛÈ£ÃâÀÌ ÇÊ¿äÇϱ⶧¹®¿¡ inode³ª ½Éº¼¸µÅ© µîÀ» - °æ·Î¸¦ ÁöÁ¤ÇÒ ¼ö ¾ø´Ù. ÀÌ ¸ðµâÀº mod_alias³ª - mod_rewrite·Î ÀçÀÛ¼ºÇÑ ÆÄÀϸíÀ» ´Ù·ê ¼ö - Àֱ⵵ ¾ø±âµµ ÇÏ´Ù.

    - -

    ¿¹Á¦

    - CacheFile /usr/local/apache/htdocs/index.html -

    - -
    -
    top
    -

    MMapFile Áö½Ã¾î

    - - - - - - -
    ¼³¸í:½ÃÀ۽à ¿©·¯ ÆÄÀÏÀ» ¸Þ¸ð¸®¿¡ ´ëÀÀÇÑ´Ù
    ¹®¹ý:MMapFile file-path [file-path] ...
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤
    »óÅÂ:Experimental
    ¸ðµâ:mod_file_cache
    -

    MMapFile Áö½Ã¾î´Â ¼­¹ö°¡ ½ÃÀÛÇÒ¶§ - (°ø¹éÀ¸·Î ±¸ºÐÇÑ ¾Æ±Ô¸ÕÆ®·Î ÁöÁ¤ÇÑ) ¿©·¯ ÆÄÀÏÀ» ¸Þ¸ð¸®¿¡ - ´ëÀÀÇÑ´Ù(map). ¼­¹ö Á¾·á½Ã ÀÚµ¿À¸·Î ´ëÀÀÀ» Ǭ´Ù(unmap). - ÆÄÀϽýºÅÛ¿¡¼­ ÆÄÀÏÀÌ º¯°æµÇ¸é ÆÄÀϵéÀ» ´Ù½Ã - mmap()ÇϱâÀ§ÇØ ÃÖ¼ÒÇÑ ¼­¹ö¿¡ HUPÀ̳ª - USR1 ½Ã±×³ÎÀ» º¸³»¾ß ÇÑ´Ù.

    - -

    file-path ¾Æ±Ô¸ÕÆ®¸¦ Á¶½ÉÇضó. ¾Æ±Ô¸ÕÆ®´Â - ¾ÆÆÄÄ¡ÀÇ URL-ÆÄÀÏ¸í º¯È¯ Çڵ鷯°¡ ¸¸µç ÆÄÀϽýºÅÛ °æ·Î¿Í - Á¤È®È÷ ÀÏÄ¡ÇØ¾ß ÇÑ´Ù. Çѹø ´õ ºÒÇÊ¿äÇÑ stat() - ½Ã½ºÅÛÈ£ÃâÀÌ ÇÊ¿äÇϱ⶧¹®¿¡ inode³ª ½Éº¼¸µÅ© µîÀ» - °æ·Î¸¦ ÁöÁ¤ÇÒ ¼ö ¾ø´Ù. ÀÌ ¸ðµâÀº mod_alias³ª - mod_rewrite·Î ÀçÀÛ¼ºÇÑ ÆÄÀϸíÀ» ´Ù·ê ¼ö - Àֱ⵵ ¾ø±âµµ ÇÏ´Ù.

    - -

    ¿¹Á¦

    - MMapFile /usr/local/apache/htdocs/index.html -

    - -

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_filter.html.en b/docs/manual/mod/mod_filter.html.en index ba54748b99e..28805848193 100644 --- a/docs/manual/mod/mod_filter.html.en +++ b/docs/manual/mod/mod_filter.html.en @@ -66,200 +66,6 @@

  • Protocol Handling
    • top
    -
    -

    Smart Filtering

    -

    In the traditional filtering model, filters are inserted unconditionally - using AddOutputFilter and family. - Each filter then needs to determine whether to run, and there is little - flexibility available for server admins to allow the chain to be - configured dynamically.

    - -

    mod_filter by contrast gives server administrators a - great deal of flexibility in configuring the filter chain. In fact, - filters can be inserted based on complex boolean - expressions This generalises the limited - flexibility offered by AddOutputFilterByType.

    -
    top
    -
    -

    Filter Declarations, Providers and Chains

    -

    - [This image displays the traditional filter model]
    - Figure 1: The traditional filter model

    - -

    In the traditional model, output filters are a simple chain - from the content generator (handler) to the client. This works well - provided the filter chain can be correctly configured, but presents - problems when the filters need to be configured dynamically based on - the outcome of the handler.

    - -

    - [This image shows the mod_filter model]
    - Figure 2: The mod_filter model

    - -

    mod_filter works by introducing indirection into - the filter chain. Instead of inserting filters in the chain, we insert - a filter harness which in turn dispatches conditionally - to a filter provider. Any content filter may be used as a provider - to mod_filter; no change to existing filter modules - is required (although it may be possible to simplify them). There can be - multiple providers for one filter, but no more than one provider will - run for any single request.

    - -

    A filter chain comprises any number of instances of the filter - harness, each of which may have any number of providers. A special - case is that of a single provider with unconditional dispatch: this - is equivalent to inserting the provider filter directly into the chain.

    -
    top
    -
    -

    Configuring the Chain

    -

    There are three stages to configuring a filter chain with - mod_filter. For details of the directives, see below.

    - -
    -
    Declare Filters
    -
    The FilterDeclare directive - declares a filter, assigning it a name and filter type. Required - only if the filter is not the default type AP_FTYPE_RESOURCE.
    - -
    Register Providers
    -
    The FilterProvider - directive registers a provider with a filter. The filter may have - been declared with FilterDeclare; if not, FilterProvider will implicitly - declare it with the default type AP_FTYPE_RESOURCE. The provider - must have been - registered with ap_register_output_filter by some module. - The final argument to FilterProvider is an expression: the provider will be - selected to run for a request if and only if the expression evaluates - to true. The expression may evaluate HTTP request or response - headers, environment variables, or the Handler used by this request. - Unlike earlier versions, mod_filter now supports complex expressions - involving multiple criteria with AND / OR logic (&& / ||) - and brackets. The details of the expression syntax are described in - the ap_expr documentation.
    - -
    Configure the Chain
    -
    The above directives build components of a smart filter chain, - but do not configure it to run. The FilterChain directive builds a filter chain from smart - filters declared, offering the flexibility to insert filters at the - beginning or end of the chain, remove a filter, or clear the chain.
    -
    -
    top
    -
    -

    Filtering and Response Status

    -

    mod_filter normally only runs filters on responses with - HTTP status 200 (OK). If you want to filter documents with - other response statuses, you can set the filter-errordocs - environment variable, and it will work on all responses - regardless of status. To refine this further, you can use - expression conditions with FilterProvider.

    -
    top
    -
    -

    Upgrading from Apache HTTP Server 2.2 Configuration

    -

    The FilterProvider - directive has changed from httpd 2.2: the match and - dispatch arguments are replaced with a single but - more versatile expression. In general, you can convert - a match/dispatch pair to the two sides of an expression, using - something like:

    -

    "dispatch = 'match'"

    -

    The Request headers, Response headers and Environment variables - are now interpreted from syntax %{req:foo}, - %{resp:foo} and %{env:foo} respectively. - The variables %{HANDLER} and %{CONTENT_TYPE} - are also supported.

    -

    Note that the match no longer support substring matches. They can be - replaced by regular expression matches.

    -
    top
    -
    -

    Examples

    -
    -
    Server side Includes (SSI)
    -
    A simple case of replacing AddOutputFilterByType - 
    FilterDeclare SSI
-FilterProvider SSI INCLUDES "%{CONTENT_TYPE} =~ m|^text/html|"
-FilterChain SSI
    - -
    - -
    Server side Includes (SSI)
    -
    The same as the above but dispatching on handler (classic - SSI behaviour; .shtml files get processed). - 
    FilterProvider SSI INCLUDES "%{HANDLER} = 'server-parsed'"
-FilterChain SSI
    - -
    - -
    Emulating mod_gzip with mod_deflate
    -
    Insert INFLATE filter only if "gzip" is NOT in the - Accept-Encoding header. This filter runs with ftype CONTENT_SET. - 
    FilterDeclare gzip CONTENT_SET
-FilterProvider gzip inflate "%{req:Accept-Encoding} !~ /gzip/"
-FilterChain gzip
    - -
    - -
    Image Downsampling
    -
    Suppose we want to downsample all web images, and have filters - for GIF, JPEG and PNG. - 
    FilterProvider unpack jpeg_unpack "%{CONTENT_TYPE} = 'image/jpeg'"
-FilterProvider unpack gif_unpack "%{CONTENT_TYPE} = 'image/gif'"
-FilterProvider unpack png_unpack "%{CONTENT_TYPE} = 'image/png'"
-
-FilterProvider downsample downsample_filter "%{CONTENT_TYPE} = m|^image/(jpeg|gif|png)|"
-FilterProtocol downsample "change=yes"
-
-FilterProvider repack jpeg_pack "%{CONTENT_TYPE} = 'image/jpeg'"
-FilterProvider repack gif_pack "%{CONTENT_TYPE} = 'image/gif'"
-FilterProvider repack png_pack "%{CONTENT_TYPE} = 'image/png'"
-<Location "/image-filter">
-    FilterChain unpack downsample repack
-</Location>
    - -
    -
    -
    top
    -
    -

    Protocol Handling

    -

    Historically, each filter is responsible for ensuring that whatever - changes it makes are correctly represented in the HTTP response headers, - and that it does not run when it would make an illegal change. This - imposes a burden on filter authors to re-implement some common - functionality in every filter:

    - -
      -
    • Many filters will change the content, invalidating existing content - tags, checksums, hashes, and lengths.
      • - -
    • Filters that require an entire, unbroken response in input need to - ensure they don't get byteranges from a backend.
      • - -
    • Filters that transform output in a filter need to ensure they don't - violate a Cache-Control: no-transform header from the - backend.
      • - -
    • Filters may make responses uncacheable.
      • -
    - -

    mod_filter aims to offer generic handling of these - details of filter implementation, reducing the complexity required of - content filter modules. This is work-in-progress; the - FilterProtocol implements - some of this functionality for back-compatibility with Apache 2.0 - modules. For httpd 2.1 and later, the - ap_register_output_filter_protocol and - ap_filter_protocol API enables filter modules to - declare their own behaviour.

    - -

    At the same time, mod_filter should not interfere - with a filter that wants to handle all aspects of the protocol. By - default (i.e. in the absence of any FilterProtocol directives), mod_filter - will leave the headers untouched.

    - -

    At the time of writing, this feature is largely untested, - as modules in common use are designed to work with 2.0. - Modules using it should test it carefully.

    -
    -
    top

    AddOutputFilterByType Directive

    @@ -490,6 +296,200 @@ for a complete reference and examples. +
    top
    +
    +

    Smart Filtering

    +

    In the traditional filtering model, filters are inserted unconditionally + using AddOutputFilter and family. + Each filter then needs to determine whether to run, and there is little + flexibility available for server admins to allow the chain to be + configured dynamically.

    + +

    mod_filter by contrast gives server administrators a + great deal of flexibility in configuring the filter chain. In fact, + filters can be inserted based on complex boolean + expressions This generalises the limited + flexibility offered by AddOutputFilterByType.

    +
    top
    +
    +

    Filter Declarations, Providers and Chains

    +

    + [This image displays the traditional filter model]
    + Figure 1: The traditional filter model

    + +

    In the traditional model, output filters are a simple chain + from the content generator (handler) to the client. This works well + provided the filter chain can be correctly configured, but presents + problems when the filters need to be configured dynamically based on + the outcome of the handler.

    + +

    + [This image shows the mod_filter model]
    + Figure 2: The mod_filter model

    + +

    mod_filter works by introducing indirection into + the filter chain. Instead of inserting filters in the chain, we insert + a filter harness which in turn dispatches conditionally + to a filter provider. Any content filter may be used as a provider + to mod_filter; no change to existing filter modules + is required (although it may be possible to simplify them). There can be + multiple providers for one filter, but no more than one provider will + run for any single request.

    + +

    A filter chain comprises any number of instances of the filter + harness, each of which may have any number of providers. A special + case is that of a single provider with unconditional dispatch: this + is equivalent to inserting the provider filter directly into the chain.

    +
    top
    +
    +

    Configuring the Chain

    +

    There are three stages to configuring a filter chain with + mod_filter. For details of the directives, see below.

    + +
    +
    Declare Filters
    +
    The FilterDeclare directive + declares a filter, assigning it a name and filter type. Required + only if the filter is not the default type AP_FTYPE_RESOURCE.
    + +
    Register Providers
    +
    The FilterProvider + directive registers a provider with a filter. The filter may have + been declared with FilterDeclare; if not, FilterProvider will implicitly + declare it with the default type AP_FTYPE_RESOURCE. The provider + must have been + registered with ap_register_output_filter by some module. + The final argument to FilterProvider is an expression: the provider will be + selected to run for a request if and only if the expression evaluates + to true. The expression may evaluate HTTP request or response + headers, environment variables, or the Handler used by this request. + Unlike earlier versions, mod_filter now supports complex expressions + involving multiple criteria with AND / OR logic (&& / ||) + and brackets. The details of the expression syntax are described in + the ap_expr documentation.
    + +
    Configure the Chain
    +
    The above directives build components of a smart filter chain, + but do not configure it to run. The FilterChain directive builds a filter chain from smart + filters declared, offering the flexibility to insert filters at the + beginning or end of the chain, remove a filter, or clear the chain.
    +
    +
    top
    +
    +

    Filtering and Response Status

    +

    mod_filter normally only runs filters on responses with + HTTP status 200 (OK). If you want to filter documents with + other response statuses, you can set the filter-errordocs + environment variable, and it will work on all responses + regardless of status. To refine this further, you can use + expression conditions with FilterProvider.

    +
    top
    +
    +

    Upgrading from Apache HTTP Server 2.2 Configuration

    +

    The FilterProvider + directive has changed from httpd 2.2: the match and + dispatch arguments are replaced with a single but + more versatile expression. In general, you can convert + a match/dispatch pair to the two sides of an expression, using + something like:

    +

    "dispatch = 'match'"

    +

    The Request headers, Response headers and Environment variables + are now interpreted from syntax %{req:foo}, + %{resp:foo} and %{env:foo} respectively. + The variables %{HANDLER} and %{CONTENT_TYPE} + are also supported.

    +

    Note that the match no longer support substring matches. They can be + replaced by regular expression matches.

    +
    top
    +
    +

    Examples

    +
    +
    Server side Includes (SSI)
    +
    A simple case of replacing AddOutputFilterByType + 
    FilterDeclare SSI
+FilterProvider SSI INCLUDES "%{CONTENT_TYPE} =~ m|^text/html|"
+FilterChain SSI
    + +
    + +
    Server side Includes (SSI)
    +
    The same as the above but dispatching on handler (classic + SSI behaviour; .shtml files get processed). + 
    FilterProvider SSI INCLUDES "%{HANDLER} = 'server-parsed'"
+FilterChain SSI
    + +
    + +
    Emulating mod_gzip with mod_deflate
    +
    Insert INFLATE filter only if "gzip" is NOT in the + Accept-Encoding header. This filter runs with ftype CONTENT_SET. + 
    FilterDeclare gzip CONTENT_SET
+FilterProvider gzip inflate "%{req:Accept-Encoding} !~ /gzip/"
+FilterChain gzip
    + +
    + +
    Image Downsampling
    +
    Suppose we want to downsample all web images, and have filters + for GIF, JPEG and PNG. + 
    FilterProvider unpack jpeg_unpack "%{CONTENT_TYPE} = 'image/jpeg'"
+FilterProvider unpack gif_unpack "%{CONTENT_TYPE} = 'image/gif'"
+FilterProvider unpack png_unpack "%{CONTENT_TYPE} = 'image/png'"
+
+FilterProvider downsample downsample_filter "%{CONTENT_TYPE} = m|^image/(jpeg|gif|png)|"
+FilterProtocol downsample "change=yes"
+
+FilterProvider repack jpeg_pack "%{CONTENT_TYPE} = 'image/jpeg'"
+FilterProvider repack gif_pack "%{CONTENT_TYPE} = 'image/gif'"
+FilterProvider repack png_pack "%{CONTENT_TYPE} = 'image/png'"
+<Location "/image-filter">
+    FilterChain unpack downsample repack
+</Location>
    + +
    +
    +
    top
    +
    +

    Protocol Handling

    +

    Historically, each filter is responsible for ensuring that whatever + changes it makes are correctly represented in the HTTP response headers, + and that it does not run when it would make an illegal change. This + imposes a burden on filter authors to re-implement some common + functionality in every filter:

    + +
      +
    • Many filters will change the content, invalidating existing content + tags, checksums, hashes, and lengths.
      • + +
    • Filters that require an entire, unbroken response in input need to + ensure they don't get byteranges from a backend.
      • + +
    • Filters that transform output in a filter need to ensure they don't + violate a Cache-Control: no-transform header from the + backend.
      • + +
    • Filters may make responses uncacheable.
      • +
    + +

    mod_filter aims to offer generic handling of these + details of filter implementation, reducing the complexity required of + content filter modules. This is work-in-progress; the + FilterProtocol implements + some of this functionality for back-compatibility with Apache 2.0 + modules. For httpd 2.1 and later, the + ap_register_output_filter_protocol and + ap_filter_protocol API enables filter modules to + declare their own behaviour.

    + +

    At the same time, mod_filter should not interfere + with a filter that wants to handle all aspects of the protocol. By + default (i.e. in the absence of any FilterProtocol directives), mod_filter + will leave the headers untouched.

    + +

    At the time of writing, this feature is largely untested, + as modules in common use are designed to work with 2.0. + Modules using it should test it carefully.

    +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_filter.html.fr b/docs/manual/mod/mod_filter.html.fr index b6af2d1bdff..771b22418ec 100644 --- a/docs/manual/mod/mod_filter.html.fr +++ b/docs/manual/mod/mod_filter.html.fr @@ -75,230 +75,6 @@ serveur HTTP Apache 2.2

  • Gestion de protocole
    • top
    -
    -

    Filtrage intelligent

    -

    Dans le modèle de filtrage traditionnel, les filtres sont insérés - sans condition à l'aide de la directive AddOutputFilter et des directives - apparentées. Chaque filtre doit ensuite déterminer s'il doit - s'exécuter ou non, et les administrateurs du serveur disposent de - peu de souplesse pour faire en sorte que la chaîne soit traitée de - manière dynamique.

    - -

    mod_filter, à l'opposé, fournit aux - administrateurs du serveur un grand degré de souplesse pour - configurer la chaîne de filtrage. Concrètement, la décision - d'insérer un filtre peut être prise en fonction d'une expression booléenne complexe. Ceci - généralise le fonctionnement relativement souple de la directive - AddOutputFilterByType.

    -
    top
    -
    -

    Déclarations de filtres, fournisseurs et -chaînes

    -

    - [Cette image illustre le modèle de filtrage traditionnel]
    - Figure 1: Le modèle de filtrage traditionnel

    - -

    Dans le modèle traditionnel, les filtres en sortie constituent - une simple chaîne s'étendant depuis le générateur de contenu (ou - gestionnaire) jusqu'au client. Ce fonctionnement peut convenir s'il - permet d'atteindre le but recherché, mais pose - problème lorsque cette chaîne doit être configurée dynamiquement en - fonction de la sortie du gestionnaire.

    - -

    - [Cette image illustre le modèle de fonctionnement de mod_filter]
    - Figure 2: Le modèle de fonctionnement de - mod_filter

    - -

    Le fonctionnement de mod_filter consiste à - introduire des branchements dans la chaîne de filtrage. Plutôt que - d'insérer directement des filtres dans la chaîne, on insère un - sélecteur de filtre qui va effectuer un branchement conditionnel - vers un fournisseur de filtre. mod_filter peut - utiliser tout filtre de contenu comme fournisseur ; aucune - modification des modules de filtrage existants n'est nécessaire - (bien qu'il soit tout de même possible de les simplifier). Il peut y - avoir plusieurs fournisseurs pour un seul filtre, mais un seul - fournisseur sera choisi pour chaque requête.

    - -

    Une chaîne de filtrage peut comporter autant d'instances du - sélecteur de filtre que l'on souhaite, chacune d'entre elles pouvant - disposer de plusieurs fournisseurs. Un sélecteur de filtre possédant - un seul fournisseur dont le choix est inconditionnel constitue un - cas particulier : cette situation est équivalente à l'insertion - directe du filtre dans la chaîne.

    -
    top
    -
    -

    Configuration de la chaîne de -filtrage

    -

    Trois étapes sont nécessaires pour configurer une chaîne de - filtrage avec mod_filter. Voir ci-dessous la - description détaillée des directives.

    - -
    -
    Déclaration des filtres
    -
    La directive FilterDeclare permet de déclarer un - filtre en lui assignant un nom et un type. Elle n'est obligatoire - que si le filtre n'est pas du type par défaut - AP_FTYPE_RESOURCE.
    - -
    Enregistrement des fournisseurs
    -
    La directive FilterProvider permet d'associer un - fournisseur à un filtre. Le filtre a été éventuellement déclaré à - l'aide de la directive FilterDeclare ; si ce n'est pas le cas, FilterProvider - va le déclarer implicitement avec le type par défaut - AP_FTYPE_RESOURCE. Le fournisseur doit avoir été enregistré à - l'aide de ap_register_output_filter par un module - quelconque. Le dernier argument de la directive FilterProvider est une expression : - le fournisseur s'exécutera pour une requête si et seulement si - l'expression est évaluée vraie. L'expression peut évaluer une - requête HTTP ou les en-têtes de la réponse, des variables - d'environnement, ou le gestionnaire utilisé par cette requête. À la - différence des version précédentes, mod_filter supporte désormais - les expressions complexes associant des critères multiples au moyen - d'une logique AND / OR (&& / ||) et de parenthèses. Pour les - détails sur la syntaxe de l'expression, voir la documentation sur ap_expr.
    - -
    Configuration de la chaîne de filtrage
    -
    Les directives ci-dessus permettent d'élaborer les éléments - d'une chaîne de filtrage intelligente, mais pas de les configurer en - vue de leur exécution. La directive FilterChain élabore une chaîne de filtrage à - partir de filtres intelligents déclarés, permettant avec souplesse - d'insérer des filtres au début ou à la fin de la chaîne, de - supprimer un filtre ou même la chaîne complète.
    -
    -
    top
    -
    -

    Filtrage et statut de la réponse

    -

    Normalement, mod_filter n'applique les filtres qu'aux réponses - possédant un statut HTTP 200 (OK). Pour pouvoir filtrer des - documents possédant un autre statut, vous devez définir la variable - d'environnement filter-errordocs, les réponses étant - alors filtrées sans se préoccuper de leur statut. Pour définir ce - comportement de manière plus fine, vous pouvez utiliser des - conditions dans la directive - FilterProvider.

    -
    top
    -
    -

    Mise à jour depuis une configuration du -serveur HTTP Apache 2.2

    -

    La directive FilterProvider a été modifiée par - rapport à httpd 2.2 : les arguments match et - dispatch ont été remplacés par l'argument unique - expression plus polyvalent. En général, il est possible - de convertir une paire match/dispatch vers les deux côtés d'une - expression, de la manière suivante :

    -

    "dispatch = 'match'"

    -

    Les en-têtes de requête et de réponse et les variables - d'environnement sont maintenant interprétés selon les syntaxes - respectives %{req:foo}, %{resp:foo} et - %{env:foo}. Les variables %{HANDLER} et - %{CONTENT_TYPE} sont également supportées.

    -

    Notez que l'évaluation de l'expression ne supporte plus les - comparaisons de sous-chaînes. Ces dernières peuvent - être remplacées par des comparaisons d'expressions rationnelles.

    -
    top
    -
    -

    Exemples

    -
    -
    Inclusions côté serveur (SSI)
    -
    Un exemple simple de remplacement de la directive AddOutputFilterByType - 
    FilterDeclare SSI
-FilterProvider SSI INCLUDES "%{CONTENT_TYPE} =~ m|^text/html|"
-FilterChain SSI
    - -
    - -
    Inclusions côté serveur (SSI)
    -
    Même exemple que ci-dessus, mais envoi vers un gestionnaire - (comportement classique des SSI ; les fichiers .shtml sont - traités). - 
    FilterProvider SSI INCLUDES "%{HANDLER} = 'server-parsed'"
-FilterChain SSI
    - -
    - -
    Émulation de mod_gzip avec mod_deflate
    -
    Insertion du filtre INFLATE seulement si l'en-tête - Accept-Encoding a une valeur autre que "gzip". Ce filtre s'exécute - avec le type ftype CONTENT_SET. - 
    FilterDeclare gzip CONTENT_SET
-FilterProvider gzip inflate "%{req:Accept-Encoding} !~ /gzip/"
-FilterChain gzip
    - -
    - -
    Diminution de la résolution d'une image
    -
    Supposons que nous voulions réduire la résolution de toutes les - images web, et que nous disposions de filtres pour les images GIF, - JPEG et PNG. - 
    FilterProvider unpack jpeg_unpack "%{CONTENT_TYPE} = 'image/jpeg'"
-FilterProvider unpack gif_unpack "%{CONTENT_TYPE} = 'image/gif'"
-FilterProvider unpack png_unpack "%{CONTENT_TYPE} = 'image/png'"
-
-FilterProvider downsample downsample_filter "%{CONTENT_TYPE} = m|^image/(jpeg|gif|png)|"
-FilterProtocol downsample "change=yes"
-
-FilterProvider repack jpeg_pack "%{CONTENT_TYPE} = 'image/jpeg'"
-FilterProvider repack gif_pack "%{CONTENT_TYPE} = 'image/gif'"
-FilterProvider repack png_pack "%{CONTENT_TYPE} = 'image/png'"
-<Location /image-filter>
-    FilterChain unpack downsample repack
-</Location>
    - -
    -
    -
    top
    -
    -

    Gestion de protocole

    -

    Historiquement, tout filtre doit s'assurer que toute modification - qu'il effectue est correctement représentée dans les en-têtes de la - réponse HTTP, et qu'il ne s'exécutera pas si cette exécution - résultait en une modification interdite. Ceci impose aux auteurs de - filtres la corvée de réimplémenter certaines fonctionnalités - communes dans chaque filtre :

    - -
      -
    • De nombreux filtres modifient les contenus, et de ce fait - invalident les balises de ces contenus, leur somme de - contrôle, leur condensé (hash) existant, ainsi que leur - taille.
      • - -
    • Les filtres qui nécessitent une réponse entière et non tronquée en - entrée, doivent s'assurer qu'il n'ont pas reçu une réponse à une - requête partielle.
      • - -
    • Les filtres qui modifient la sortie d'un autre filtre doivent - s'assurer qu'ils ne violent pas la directive d'un en-tête - Cache-Control: no-transform éventuel.
      • - -
    • Les filtres peuvent agir sur des réponses de façon à ce qu'elles - ne puissent plus être mises en cache.
      • -
    - -

    mod_filter a pour but de gérer de manière - générale ces détails de l'implémentation des filtres, réduisant par - là-même la complexité des modules de filtrage de contenu. Le - travail permettant d'atteindre ce but est cependant toujours en - cours ; la directive FilterProtocol - implémente certaines de ces fonctionnalités à des fins de - compatibilité ascendante avec les modules d'Apache 2.0. Pour les - versions 2.1 et supérieures de httpd, les API - ap_register_output_filter_protocol et - ap_filter_protocol permettent aux modules de filtrage - de définir leurs propres comportements.

    - -

    Cependant, mod_filter ne doit pas interférer - avec un filtre qui gère déjà tous les aspects du protocole. Par - défaut (c'est à dire en l'absence de toute directive FilterProtocol), - mod_filter ne modifiera donc pas les en-têtes.

    - -

    Au moment où ces lignes sont écrites, cette fonctionnalité a été - très peu testée, car les modules d'usage courant ont été conçus pour - fonctionner avec httpd 2.0. Les modules qui l'utilisent devront donc - l'expérimenter avec précautions.

    -
    -
    top

    Directive AddOutputFilterByType

    Description:assigns an output filter to a particular media-type
  • Examples
    • top
    -
    -

    Order of Processing

    - -

    The directives provided by mod_headers can - occur almost anywhere within the server configuration, and can be - limited in scope by enclosing them in configuration sections.

    - -

    Order of processing is important and is affected both by the - order in the configuration file and by placement in configuration sections. These - two directives have a different effect if reversed:

    - - 
    RequestHeader append MirrorID "mirror 12"
-RequestHeader unset MirrorID
    - - -

    This way round, the MirrorID header is not set. If - reversed, the MirrorID header is set to "mirror 12".

    -
    top
    -
    -

    Early and Late Processing

    -

    mod_headers can be applied either early or late - in the request. The normal mode is late, when Request Headers are - set immediately before running the content generator and Response - Headers just as the response is sent down the wire. Always use - Late mode in an operational server.

    - -

    Early mode is designed as a test/debugging aid for developers. - Directives defined using the early keyword are set - right at the beginning of processing the request. This means - they can be used to simulate different requests and set up test - cases, but it also means that headers may be changed at any time - by other modules before generating a Response.

    - -

    Because early directives are processed before the request path's - configuration is traversed, early headers can only be set in a - main server or virtual host context. Early directives cannot depend - on a request path, so they will fail in contexts such as - <Directory> or - <Location>.

    -
    top
    -
    -

    Examples

    - -
      -
    1. - Copy all request headers that begin with "TS" to the - response headers: - - 
      Header echo ^TS
      - -
      2. - -
    2. - Add a header, MyHeader, to the response including a - timestamp for when the request was received and how long it - took to begin serving the request. This header can be used by - the client to intuit load on the server or in isolating - bottlenecks between the client and the server. - - 
      Header set MyHeader "%D %t"
      - - -

      results in this header being added to the response:

      - -

      - MyHeader: D=3775428 t=991424704447256 -

      -
      3. - -
    3. - Say hello to Joe - - 
      Header set MyHeader "Hello Joe. It took %D microseconds for Apache to serve this request."
      - - -

      results in this header being added to the response:

      - -

      - MyHeader: Hello Joe. It took D=3775428 microseconds for Apache - to serve this request. -

      -
      4. - -
    4. - Conditionally send MyHeader on the response if and - only if header MyRequestHeader is present on the request. - This is useful for constructing headers in response to some client - stimulus. Note that this example requires the services of the - mod_setenvif module. - - 
      SetEnvIf MyRequestHeader myvalue HAVE_MyRequestHeader
-Header set MyHeader "%D %t mytext" env=HAVE_MyRequestHeader
      - - -

      If the header MyRequestHeader: myvalue is present on - the HTTP request, the response will contain the following header:

      - -

      - MyHeader: D=3775428 t=991424704447256 mytext -

      -
      5. - -
    5. - Enable DAV to work with Apache running HTTP through SSL hardware - (problem - description) by replacing https: with - http: in the Destination header: - - 
      RequestHeader edit Destination ^https: http: early
      - -
      6. - -
    6. - Set the same header value under multiple nonexclusive conditions, - but do not duplicate the value in the final header. - If all of the following conditions applied to a request (i.e., - if the CGI, NO_CACHE and - NO_STORE environment variables all existed for the - request): - - 
      Header merge Cache-Control no-cache env=CGI
-Header merge Cache-Control no-cache env=NO_CACHE
-Header merge Cache-Control no-store env=NO_STORE
      - - -

      then the response would contain the following header:

      - -

      - Cache-Control: no-cache, no-store -

      - -

      If append was used instead of merge, - then the response would contain the following header:

      - -

      - Cache-Control: no-cache, no-cache, no-store -

      -
      7. -
    7. - Set a test cookie if and only if the client didn't send us a cookie - 
      Header set Set-Cookie testcookie "expr=-z %{req:Cookie}"
      - -
      8. -
    8. - Append a Caching header for responses with a HTTP status code of 200 - 
      Header append Cache-Control s-maxage=600 "expr=%{REQUEST_STATUS} == 200"
      - -
      9. - -
    -
    -
    top

    Header Directive

    Description:assigne un filtre en sortie pour un type de média @@ -536,6 +312,230 @@ provenance de mod_filter +
    top
    +
    +

    Filtrage intelligent

    +

    Dans le modèle de filtrage traditionnel, les filtres sont insérés + sans condition à l'aide de la directive AddOutputFilter et des directives + apparentées. Chaque filtre doit ensuite déterminer s'il doit + s'exécuter ou non, et les administrateurs du serveur disposent de + peu de souplesse pour faire en sorte que la chaîne soit traitée de + manière dynamique.

    + +

    mod_filter, à l'opposé, fournit aux + administrateurs du serveur un grand degré de souplesse pour + configurer la chaîne de filtrage. Concrètement, la décision + d'insérer un filtre peut être prise en fonction d'une expression booléenne complexe. Ceci + généralise le fonctionnement relativement souple de la directive + AddOutputFilterByType.

    +
    top
    +
    +

    Déclarations de filtres, fournisseurs et +chaînes

    +

    + [Cette image illustre le modèle de filtrage traditionnel]
    + Figure 1: Le modèle de filtrage traditionnel

    + +

    Dans le modèle traditionnel, les filtres en sortie constituent + une simple chaîne s'étendant depuis le générateur de contenu (ou + gestionnaire) jusqu'au client. Ce fonctionnement peut convenir s'il + permet d'atteindre le but recherché, mais pose + problème lorsque cette chaîne doit être configurée dynamiquement en + fonction de la sortie du gestionnaire.

    + +

    + [Cette image illustre le modèle de fonctionnement de mod_filter]
    + Figure 2: Le modèle de fonctionnement de + mod_filter

    + +

    Le fonctionnement de mod_filter consiste à + introduire des branchements dans la chaîne de filtrage. Plutôt que + d'insérer directement des filtres dans la chaîne, on insère un + sélecteur de filtre qui va effectuer un branchement conditionnel + vers un fournisseur de filtre. mod_filter peut + utiliser tout filtre de contenu comme fournisseur ; aucune + modification des modules de filtrage existants n'est nécessaire + (bien qu'il soit tout de même possible de les simplifier). Il peut y + avoir plusieurs fournisseurs pour un seul filtre, mais un seul + fournisseur sera choisi pour chaque requête.

    + +

    Une chaîne de filtrage peut comporter autant d'instances du + sélecteur de filtre que l'on souhaite, chacune d'entre elles pouvant + disposer de plusieurs fournisseurs. Un sélecteur de filtre possédant + un seul fournisseur dont le choix est inconditionnel constitue un + cas particulier : cette situation est équivalente à l'insertion + directe du filtre dans la chaîne.

    +
    top
    +
    +

    Configuration de la chaîne de +filtrage

    +

    Trois étapes sont nécessaires pour configurer une chaîne de + filtrage avec mod_filter. Voir ci-dessous la + description détaillée des directives.

    + +
    +
    Déclaration des filtres
    +
    La directive FilterDeclare permet de déclarer un + filtre en lui assignant un nom et un type. Elle n'est obligatoire + que si le filtre n'est pas du type par défaut + AP_FTYPE_RESOURCE.
    + +
    Enregistrement des fournisseurs
    +
    La directive FilterProvider permet d'associer un + fournisseur à un filtre. Le filtre a été éventuellement déclaré à + l'aide de la directive FilterDeclare ; si ce n'est pas le cas, FilterProvider + va le déclarer implicitement avec le type par défaut + AP_FTYPE_RESOURCE. Le fournisseur doit avoir été enregistré à + l'aide de ap_register_output_filter par un module + quelconque. Le dernier argument de la directive FilterProvider est une expression : + le fournisseur s'exécutera pour une requête si et seulement si + l'expression est évaluée vraie. L'expression peut évaluer une + requête HTTP ou les en-têtes de la réponse, des variables + d'environnement, ou le gestionnaire utilisé par cette requête. À la + différence des version précédentes, mod_filter supporte désormais + les expressions complexes associant des critères multiples au moyen + d'une logique AND / OR (&& / ||) et de parenthèses. Pour les + détails sur la syntaxe de l'expression, voir la documentation sur ap_expr.
    + +
    Configuration de la chaîne de filtrage
    +
    Les directives ci-dessus permettent d'élaborer les éléments + d'une chaîne de filtrage intelligente, mais pas de les configurer en + vue de leur exécution. La directive FilterChain élabore une chaîne de filtrage à + partir de filtres intelligents déclarés, permettant avec souplesse + d'insérer des filtres au début ou à la fin de la chaîne, de + supprimer un filtre ou même la chaîne complète.
    +
    +
    top
    +
    +

    Filtrage et statut de la réponse

    +

    Normalement, mod_filter n'applique les filtres qu'aux réponses + possédant un statut HTTP 200 (OK). Pour pouvoir filtrer des + documents possédant un autre statut, vous devez définir la variable + d'environnement filter-errordocs, les réponses étant + alors filtrées sans se préoccuper de leur statut. Pour définir ce + comportement de manière plus fine, vous pouvez utiliser des + conditions dans la directive + FilterProvider.

    +
    top
    +
    +

    Mise à jour depuis une configuration du +serveur HTTP Apache 2.2

    +

    La directive FilterProvider a été modifiée par + rapport à httpd 2.2 : les arguments match et + dispatch ont été remplacés par l'argument unique + expression plus polyvalent. En général, il est possible + de convertir une paire match/dispatch vers les deux côtés d'une + expression, de la manière suivante :

    +

    "dispatch = 'match'"

    +

    Les en-têtes de requête et de réponse et les variables + d'environnement sont maintenant interprétés selon les syntaxes + respectives %{req:foo}, %{resp:foo} et + %{env:foo}. Les variables %{HANDLER} et + %{CONTENT_TYPE} sont également supportées.

    +

    Notez que l'évaluation de l'expression ne supporte plus les + comparaisons de sous-chaînes. Ces dernières peuvent + être remplacées par des comparaisons d'expressions rationnelles.

    +
    top
    +
    +

    Exemples

    +
    +
    Inclusions côté serveur (SSI)
    +
    Un exemple simple de remplacement de la directive AddOutputFilterByType + 
    FilterDeclare SSI
+FilterProvider SSI INCLUDES "%{CONTENT_TYPE} =~ m|^text/html|"
+FilterChain SSI
    + +
    + +
    Inclusions côté serveur (SSI)
    +
    Même exemple que ci-dessus, mais envoi vers un gestionnaire + (comportement classique des SSI ; les fichiers .shtml sont + traités). + 
    FilterProvider SSI INCLUDES "%{HANDLER} = 'server-parsed'"
+FilterChain SSI
    + +
    + +
    Émulation de mod_gzip avec mod_deflate
    +
    Insertion du filtre INFLATE seulement si l'en-tête + Accept-Encoding a une valeur autre que "gzip". Ce filtre s'exécute + avec le type ftype CONTENT_SET. + 
    FilterDeclare gzip CONTENT_SET
+FilterProvider gzip inflate "%{req:Accept-Encoding} !~ /gzip/"
+FilterChain gzip
    + +
    + +
    Diminution de la résolution d'une image
    +
    Supposons que nous voulions réduire la résolution de toutes les + images web, et que nous disposions de filtres pour les images GIF, + JPEG et PNG. + 
    FilterProvider unpack jpeg_unpack "%{CONTENT_TYPE} = 'image/jpeg'"
+FilterProvider unpack gif_unpack "%{CONTENT_TYPE} = 'image/gif'"
+FilterProvider unpack png_unpack "%{CONTENT_TYPE} = 'image/png'"
+
+FilterProvider downsample downsample_filter "%{CONTENT_TYPE} = m|^image/(jpeg|gif|png)|"
+FilterProtocol downsample "change=yes"
+
+FilterProvider repack jpeg_pack "%{CONTENT_TYPE} = 'image/jpeg'"
+FilterProvider repack gif_pack "%{CONTENT_TYPE} = 'image/gif'"
+FilterProvider repack png_pack "%{CONTENT_TYPE} = 'image/png'"
+<Location /image-filter>
+    FilterChain unpack downsample repack
+</Location>
    + +
    +
    +
    top
    +
    +

    Gestion de protocole

    +

    Historiquement, tout filtre doit s'assurer que toute modification + qu'il effectue est correctement représentée dans les en-têtes de la + réponse HTTP, et qu'il ne s'exécutera pas si cette exécution + résultait en une modification interdite. Ceci impose aux auteurs de + filtres la corvée de réimplémenter certaines fonctionnalités + communes dans chaque filtre :

    + +
      +
    • De nombreux filtres modifient les contenus, et de ce fait + invalident les balises de ces contenus, leur somme de + contrôle, leur condensé (hash) existant, ainsi que leur + taille.
      • + +
    • Les filtres qui nécessitent une réponse entière et non tronquée en + entrée, doivent s'assurer qu'il n'ont pas reçu une réponse à une + requête partielle.
      • + +
    • Les filtres qui modifient la sortie d'un autre filtre doivent + s'assurer qu'ils ne violent pas la directive d'un en-tête + Cache-Control: no-transform éventuel.
      • + +
    • Les filtres peuvent agir sur des réponses de façon à ce qu'elles + ne puissent plus être mises en cache.
      • +
    + +

    mod_filter a pour but de gérer de manière + générale ces détails de l'implémentation des filtres, réduisant par + là-même la complexité des modules de filtrage de contenu. Le + travail permettant d'atteindre ce but est cependant toujours en + cours ; la directive FilterProtocol + implémente certaines de ces fonctionnalités à des fins de + compatibilité ascendante avec les modules d'Apache 2.0. Pour les + versions 2.1 et supérieures de httpd, les API + ap_register_output_filter_protocol et + ap_filter_protocol permettent aux modules de filtrage + de définir leurs propres comportements.

    + +

    Cependant, mod_filter ne doit pas interférer + avec un filtre qui gère déjà tous les aspects du protocole. Par + défaut (c'est à dire en l'absence de toute directive FilterProtocol), + mod_filter ne modifiera donc pas les en-têtes.

    + +

    Au moment où ces lignes sont écrites, cette fonctionnalité a été + très peu testée, car les modules d'usage courant ont été conçus pour + fonctionner avec httpd 2.0. Les modules qui l'utilisent devront donc + l'expérimenter avec précautions.

    +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_headers.html.en b/docs/manual/mod/mod_headers.html.en index 8b22e094bd4..7a5a45a704b 100644 --- a/docs/manual/mod/mod_headers.html.en +++ b/docs/manual/mod/mod_headers.html.en @@ -52,158 +52,6 @@ headers

    @@ -544,6 +392,158 @@ available in 2.4.10 and later input filters to be overridden or modified.

    +
    top
    +
    +

    Order of Processing

    + +

    The directives provided by mod_headers can + occur almost anywhere within the server configuration, and can be + limited in scope by enclosing them in configuration sections.

    + +

    Order of processing is important and is affected both by the + order in the configuration file and by placement in configuration sections. These + two directives have a different effect if reversed:

    + + 
    RequestHeader append MirrorID "mirror 12"
+RequestHeader unset MirrorID
    + + +

    This way round, the MirrorID header is not set. If + reversed, the MirrorID header is set to "mirror 12".

    +
    top
    +
    +

    Early and Late Processing

    +

    mod_headers can be applied either early or late + in the request. The normal mode is late, when Request Headers are + set immediately before running the content generator and Response + Headers just as the response is sent down the wire. Always use + Late mode in an operational server.

    + +

    Early mode is designed as a test/debugging aid for developers. + Directives defined using the early keyword are set + right at the beginning of processing the request. This means + they can be used to simulate different requests and set up test + cases, but it also means that headers may be changed at any time + by other modules before generating a Response.

    + +

    Because early directives are processed before the request path's + configuration is traversed, early headers can only be set in a + main server or virtual host context. Early directives cannot depend + on a request path, so they will fail in contexts such as + <Directory> or + <Location>.

    +
    top
    +
    +

    Examples

    + +
      +
    1. + Copy all request headers that begin with "TS" to the + response headers: + + 
      Header echo ^TS
      + +
      2. + +
    2. + Add a header, MyHeader, to the response including a + timestamp for when the request was received and how long it + took to begin serving the request. This header can be used by + the client to intuit load on the server or in isolating + bottlenecks between the client and the server. + + 
      Header set MyHeader "%D %t"
      + + +

      results in this header being added to the response:

      + +

      + MyHeader: D=3775428 t=991424704447256 +

      +
      3. + +
    3. + Say hello to Joe + + 
      Header set MyHeader "Hello Joe. It took %D microseconds for Apache to serve this request."
      + + +

      results in this header being added to the response:

      + +

      + MyHeader: Hello Joe. It took D=3775428 microseconds for Apache + to serve this request. +

      +
      4. + +
    4. + Conditionally send MyHeader on the response if and + only if header MyRequestHeader is present on the request. + This is useful for constructing headers in response to some client + stimulus. Note that this example requires the services of the + mod_setenvif module. + + 
      SetEnvIf MyRequestHeader myvalue HAVE_MyRequestHeader
+Header set MyHeader "%D %t mytext" env=HAVE_MyRequestHeader
      + + +

      If the header MyRequestHeader: myvalue is present on + the HTTP request, the response will contain the following header:

      + +

      + MyHeader: D=3775428 t=991424704447256 mytext +

      +
      5. + +
    5. + Enable DAV to work with Apache running HTTP through SSL hardware + (problem + description) by replacing https: with + http: in the Destination header: + + 
      RequestHeader edit Destination ^https: http: early
      + +
      6. + +
    6. + Set the same header value under multiple nonexclusive conditions, + but do not duplicate the value in the final header. + If all of the following conditions applied to a request (i.e., + if the CGI, NO_CACHE and + NO_STORE environment variables all existed for the + request): + + 
      Header merge Cache-Control no-cache env=CGI
+Header merge Cache-Control no-cache env=NO_CACHE
+Header merge Cache-Control no-store env=NO_STORE
      + + +

      then the response would contain the following header:

      + +

      + Cache-Control: no-cache, no-store +

      + +

      If append was used instead of merge, + then the response would contain the following header:

      + +

      + Cache-Control: no-cache, no-cache, no-store +

      +
      7. +
    7. + Set a test cookie if and only if the client didn't send us a cookie + 
      Header set Set-Cookie testcookie "expr=-z %{req:Cookie}"
      + +
      8. +
    8. + Append a Caching header for responses with a HTTP status code of 200 + 
      Header append Cache-Control s-maxage=600 "expr=%{REQUEST_STATUS} == 200"
      + +
      9. + +
    +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_headers.html.fr b/docs/manual/mod/mod_headers.html.fr index 97ae18b11c4..4d2dde37754 100644 --- a/docs/manual/mod/mod_headers.html.fr +++ b/docs/manual/mod/mod_headers.html.fr @@ -53,173 +53,6 @@ tardif

  • Exemples
    • top
    -
    -

    Chronologie du traitement

    - -

    Les directives fournies par mod_headers peuvent - s'insérer presque partout dans la configuration du serveur, et on - peut limiter leur portée en les plaçant dans des sections de configuration.

    - -

    La chronologie du traitement est importante et est affectée par - l'ordre d'apparition des directives dans le fichier de configuration - et par leur placement dans les sections de configuration. Ainsi, - ces deux directives ont un effet différent si leur ordre est inversé - :

    - - 
    RequestHeader append MirrorID "mirror 12"
-RequestHeader unset MirrorID
    - - -

    Dans cet ordre, l'en-tête MirrorID n'est pas défini. - Si l'ordre des directives était inversé, l'en-tête - MirrorID serait défini à "mirror 12".

    -
    top
    -
    -

    Traitement précoce et traitement -tardif

    -

    mod_headers peut agir soir précocement, soit - tardivement au niveau de la requête. Le mode normal est le mode - tardif, lorsque les en-têtes de requête sont définis, immédiatement - avant l'exécution du générateur de contenu, et pour les en-têtes de - réponse, juste au moment où la réponse est envoyée sur le réseau. - Utilisez toujours le mode tardif sur un serveur en production.

    - -

    Le mode précoce a été conçu à des fins d'aide aux tests et au - débogage pour les développeurs. Les directives définies en utilisant - le mot-clé early sont censées agir au tout début du - traitement de la requête. Cela signifie que l'on peut les utiliser - pour simuler différentes requêtes et définir des situations de test, - tout en gardant à l'esprit que les en-têtes peuvent être modifiés à - tout moment par d'autres modules avant que le réponse ne soit - générée.

    - -

    Comme les directives précoces sont traitées avant que le - chemin de la requête ne soit parcouru, les en-têtes - précoces ne peuvent être définis que dans un contexte de serveur - principal ou de serveur virtuel. Les directives précoces ne peuvent - pas dépendre d'un chemin de requête, si bien qu'elles échoueront - dans des contextes tels que <Directory> ou <Location>.

    -
    top
    -
    -

    Exemples

    - -
      -
    1. - Copie tous les en-têtes de requête qui commencent par "TS" vers - les en-têtes de la réponse : - - 
      Header echo ^TS
      - -
      2. - -
    2. - Ajoute à la réponse un en-tête, mon-en-tête, qui - contient un horodatage permettant de déterminer le moment où la - requête a été reçue, et le temps qui s'est écoulé jusqu'à ce que - la requête ait commencé à être servie. Cet en-tête peut être - utilisé par le client pour estimer la charge du serveur ou - isoler les goulets d'étranglement entre le client et le - serveur. - - 
      Header set mon-en-tête "%D %t"
      - - -

      le résultat est l'ajout à la réponse d'un en-tête du type :

      - -

      - mon-en-tête: D=3775428 t=991424704447256 -

      -
      3. - -
    3. - Dit Bonjour à Joe - -

      - Header set mon-en-tête "Bonjour Joe. Il a fallu %D microsecondes \
      - à Apache pour servir cette requête." -

      - -

      le résultat est l'ajout à la réponse d'un en-tête du type :

      - - 
      	Header set MyHeader "Bonjour Joe. Il a fallu D=3775428 microsecondes à Apache
-          pour servir cette requête."
      - -
      4. - -
    4. - Ajoute l'en-tête mon-en-tête à la réponse si et - seulement si l'en-tête mon-en-tête-requête est - présent dans la requête. Ceci peut s'avérer utile pour générer - des en-têtes de réponse "à la tête du client". Notez que cet - exemple nécessite les services du module - mod_setenvif. - - 
      SetEnvIf MyRequestHeader myvalue HAVE_MyRequestHeader
-Header set MyHeader "%D %t mytext" env=HAVE_MyRequestHeader
      - - -

      Si l'en-tête mon-en-tête-requête: mavaleur est - présent dans la requête HTTP, la réponse contiendra un en-tête - du type :

      - -

      - mon-en-tête: D=3775428 t=991424704447256 montexte -

      -
      5. - -
    5. - Permet à DAV de fonctionner avec Apache sur SSL (voir la description - du problème) en remplaçant https: par - http: dans l'en-tête Destination : - - 
      RequestHeader edit Destination ^https: http: early
      - -
      6. - -
    6. - Définit la valeur d'un même en-tête sous de multiples conditions - non exclusives, mais ne duplique pas une valeur déjà définie - dans l'en-tête qui en résulte. Si toutes les conditions - suivantes sont satisfaites pour une requête (en d'autres termes, - si les trois variables d'environnement CGI, - NO_CACHE et NO_STORE existent pour la - requête) : - - 
      Header merge Cache-Control no-cache env=CGI
-Header merge Cache-Control no-cache env=NO_CACHE
-Header merge Cache-Control no-store env=NO_STORE
      - - -

      alors, la réponse contiendra l'en-tête suivant :

      - -

      - Cache-Control: no-cache, no-store -

      - -

      Si append avait été utilisé à la place de - merge, la réponse aurait contenu l'en-tête suivant - :

      - -

      - Cache-Control: no-cache, no-cache, no-store -

      -
      7. -
    7. - Définit un cookie de test si et seulement si le client n'envoie - pas de cookie - 
      Header set Set-Cookie testcookie "expr=-z %{req:Cookie}"
      - -
      8. -
    8. - Ajoute un en-tête de mise en cache pour les réponses avec un - code d'état HTTP de 200 - 
      Header append Cache-Control s-maxage=600 "expr=%{REQUEST_STATUS} == 200"
      - -
      9. - -
    -
    -
    top

    Directive Header

    Description:Configure HTTP response headers
    @@ -605,6 +438,173 @@ version 2.4.10 d'Apache.

    +
    top
    +
    +

    Chronologie du traitement

    + +

    Les directives fournies par mod_headers peuvent + s'insérer presque partout dans la configuration du serveur, et on + peut limiter leur portée en les plaçant dans des sections de configuration.

    + +

    La chronologie du traitement est importante et est affectée par + l'ordre d'apparition des directives dans le fichier de configuration + et par leur placement dans les sections de configuration. Ainsi, + ces deux directives ont un effet différent si leur ordre est inversé + :

    + + 
    RequestHeader append MirrorID "mirror 12"
+RequestHeader unset MirrorID
    + + +

    Dans cet ordre, l'en-tête MirrorID n'est pas défini. + Si l'ordre des directives était inversé, l'en-tête + MirrorID serait défini à "mirror 12".

    +
    top
    +
    +

    Traitement précoce et traitement +tardif

    +

    mod_headers peut agir soir précocement, soit + tardivement au niveau de la requête. Le mode normal est le mode + tardif, lorsque les en-têtes de requête sont définis, immédiatement + avant l'exécution du générateur de contenu, et pour les en-têtes de + réponse, juste au moment où la réponse est envoyée sur le réseau. + Utilisez toujours le mode tardif sur un serveur en production.

    + +

    Le mode précoce a été conçu à des fins d'aide aux tests et au + débogage pour les développeurs. Les directives définies en utilisant + le mot-clé early sont censées agir au tout début du + traitement de la requête. Cela signifie que l'on peut les utiliser + pour simuler différentes requêtes et définir des situations de test, + tout en gardant à l'esprit que les en-têtes peuvent être modifiés à + tout moment par d'autres modules avant que le réponse ne soit + générée.

    + +

    Comme les directives précoces sont traitées avant que le + chemin de la requête ne soit parcouru, les en-têtes + précoces ne peuvent être définis que dans un contexte de serveur + principal ou de serveur virtuel. Les directives précoces ne peuvent + pas dépendre d'un chemin de requête, si bien qu'elles échoueront + dans des contextes tels que <Directory> ou <Location>.

    +
    top
    +
    +

    Exemples

    + +
      +
    1. + Copie tous les en-têtes de requête qui commencent par "TS" vers + les en-têtes de la réponse : + + 
      Header echo ^TS
      + +
      2. + +
    2. + Ajoute à la réponse un en-tête, mon-en-tête, qui + contient un horodatage permettant de déterminer le moment où la + requête a été reçue, et le temps qui s'est écoulé jusqu'à ce que + la requête ait commencé à être servie. Cet en-tête peut être + utilisé par le client pour estimer la charge du serveur ou + isoler les goulets d'étranglement entre le client et le + serveur. + + 
      Header set mon-en-tête "%D %t"
      + + +

      le résultat est l'ajout à la réponse d'un en-tête du type :

      + +

      + mon-en-tête: D=3775428 t=991424704447256 +

      +
      3. + +
    3. + Dit Bonjour à Joe + +

      + Header set mon-en-tête "Bonjour Joe. Il a fallu %D microsecondes \
      + à Apache pour servir cette requête." +

      + +

      le résultat est l'ajout à la réponse d'un en-tête du type :

      + + 
      	Header set MyHeader "Bonjour Joe. Il a fallu D=3775428 microsecondes à Apache
+          pour servir cette requête."
      + +
      4. + +
    4. + Ajoute l'en-tête mon-en-tête à la réponse si et + seulement si l'en-tête mon-en-tête-requête est + présent dans la requête. Ceci peut s'avérer utile pour générer + des en-têtes de réponse "à la tête du client". Notez que cet + exemple nécessite les services du module + mod_setenvif. + + 
      SetEnvIf MyRequestHeader myvalue HAVE_MyRequestHeader
+Header set MyHeader "%D %t mytext" env=HAVE_MyRequestHeader
      + + +

      Si l'en-tête mon-en-tête-requête: mavaleur est + présent dans la requête HTTP, la réponse contiendra un en-tête + du type :

      + +

      + mon-en-tête: D=3775428 t=991424704447256 montexte +

      +
      5. + +
    5. + Permet à DAV de fonctionner avec Apache sur SSL (voir la description + du problème) en remplaçant https: par + http: dans l'en-tête Destination : + + 
      RequestHeader edit Destination ^https: http: early
      + +
      6. + +
    6. + Définit la valeur d'un même en-tête sous de multiples conditions + non exclusives, mais ne duplique pas une valeur déjà définie + dans l'en-tête qui en résulte. Si toutes les conditions + suivantes sont satisfaites pour une requête (en d'autres termes, + si les trois variables d'environnement CGI, + NO_CACHE et NO_STORE existent pour la + requête) : + + 
      Header merge Cache-Control no-cache env=CGI
+Header merge Cache-Control no-cache env=NO_CACHE
+Header merge Cache-Control no-store env=NO_STORE
      + + +

      alors, la réponse contiendra l'en-tête suivant :

      + +

      + Cache-Control: no-cache, no-store +

      + +

      Si append avait été utilisé à la place de + merge, la réponse aurait contenu l'en-tête suivant + :

      + +

      + Cache-Control: no-cache, no-cache, no-store +

      +
      7. +
    7. + Définit un cookie de test si et seulement si le client n'envoie + pas de cookie + 
      Header set Set-Cookie testcookie "expr=-z %{req:Cookie}"
      + +
      8. +
    8. + Ajoute un en-tête de mise en cache pour les réponses avec un + code d'état HTTP de 200 + 
      Header append Cache-Control s-maxage=600 "expr=%{REQUEST_STATUS} == 200"
      + +
      9. + +
    +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_headers.html.ja.utf8 b/docs/manual/mod/mod_headers.html.ja.utf8 index a4a05c62977..8dce0e9fb79 100644 --- a/docs/manual/mod/mod_headers.html.ja.utf8 +++ b/docs/manual/mod/mod_headers.html.ja.utf8 @@ -57,109 +57,6 @@

  • 例
    • top
    -
    -

    処理の順番

    - -

    mod_headers のディレクティブはサーバ設定のほぼどこにでも - 書くことができ、影響する範囲を設定用セクションで囲むことで限定する - ことができます。

    - -

    処理の順番は重要で、設定ファイル中の順番と、設定用セクション内の位置との両方に - 影響されます。以下の二つのヘッダは順番が逆になると - 違う結果になります:

    - -

    - RequestHeader append MirrorID "mirror 12"
    - RequestHeader unset MirrorID -

    - -

    この順番の場合は、MirrorID ヘッダは設定されません。 - 逆になっていると、MirrorID ヘッダは "mirror 12" に設定されます。

    -
    top
    -
    -

    早期処理、後期処理

    -

    mod_headers では、リクエストの早期か後期かの - どちらで適用するかを選べます。通常は後期モードで、 - コンテンツ生成が実行される直前にリクエストヘッダがセットされ、 - レスポンスとして送出される直前にレスポンスヘッダがセットされます。 - 運用中のサーバでは必ず後期モードを使ってください。

    - -

    早期モードは開発者向けのテスト/デバッグ用に設計されています。 - early キーワード指定されたディレクティブによって、 - リクエスト処理の開始地点になります。 - つまり、異なるリクエストを試したりテストケースをセットアップするのに - 活用できる一方で、レスポンスを生成する前に他のモジュールによって - ヘッダが書き換えられてしまうかもしれないということを意味します。

    - -

    early ディレクティブではリクエストパスの設定が解決される前に - 処理されるので、メインサーバかバーチャルホストコンテキストでのみ、 - 早期ヘッダをセットできます。early ディレクティブはリクエストパスに - 依存することはできませんので、<Directory> や - <Location> といったコンテキスト内では使用 - できません。

    -
    top
    -
    -

    例

    - -
      -
    1. リクエストヘッダ中の "TS" で始まるフィールドをすべて応答ヘッダに - コピーします: -

      - Header echo ^TS -

      -
      2. - -
    2. - リクエストを受け付けた時刻とリクエストを処理した時間を入れたヘッダ、 - MyHeader を応答に追加します。このヘッダはクライアントが - サーバの負荷を直観的に知るためや、クライアント-サーバ間の - ボトルネックを調べるために使うことができます。 - -

      - Header add MyHeader "%D %t" -

      - -

      上記の設定では、以下のようなヘッダが応答に追加されることになります:

      - -

      - MyHeader: D=3775428 t=991424704447256 -

      -
      3. - -
    3. - Joe にあいさつをします: - -

      - Header add MyHeader "Hello Joe. It took %D microseconds for Apache to serve this request." -

      - -

      以下のようなヘッダが応答に追加されることになります

      - -

      - MyHeader: Hello Joe. It took D=3775428 microseconds for Apache to serve this request. -

      -
      4. - -
    4. リクエストに "MyRequestHeader" があるときに限り MyHeader を応答に - 付けます。これは、クライアントの要求に応えてヘッダを作成するときに - 役に立ちます。この例では mod_setenvif モジュールが必要なことに - 注意してください。 - -

      - SetEnvIf MyRequestHeader value HAVE_MyRequestHeader
      - Header add MyHeader "%D %t mytext" env=HAVE_MyRequestHeader -

      - -

      もし HTTP リクエストに MyRequestHeader: value ヘッダが - あると、応答には以下のようなヘッダが付加されます。

      - -

      - MyHeader: D=3775428 t=991424704447256 mytext -

      -
      5. -
    -
    -
    top

    Header ディレクティブ

    Description:Configure les en-têtes d'une réponse HTTP
    @@ -344,6 +241,109 @@ 生成されたヘッダを上書きしたり修正したりできるようになっています。

    +
    top
    +
    +

    処理の順番

    + +

    mod_headers のディレクティブはサーバ設定のほぼどこにでも + 書くことができ、影響する範囲を設定用セクションで囲むことで限定する + ことができます。

    + +

    処理の順番は重要で、設定ファイル中の順番と、設定用セクション内の位置との両方に + 影響されます。以下の二つのヘッダは順番が逆になると + 違う結果になります:

    + +

    + RequestHeader append MirrorID "mirror 12"
    + RequestHeader unset MirrorID +

    + +

    この順番の場合は、MirrorID ヘッダは設定されません。 + 逆になっていると、MirrorID ヘッダは "mirror 12" に設定されます。

    +
    top
    +
    +

    早期処理、後期処理

    +

    mod_headers では、リクエストの早期か後期かの + どちらで適用するかを選べます。通常は後期モードで、 + コンテンツ生成が実行される直前にリクエストヘッダがセットされ、 + レスポンスとして送出される直前にレスポンスヘッダがセットされます。 + 運用中のサーバでは必ず後期モードを使ってください。

    + +

    早期モードは開発者向けのテスト/デバッグ用に設計されています。 + early キーワード指定されたディレクティブによって、 + リクエスト処理の開始地点になります。 + つまり、異なるリクエストを試したりテストケースをセットアップするのに + 活用できる一方で、レスポンスを生成する前に他のモジュールによって + ヘッダが書き換えられてしまうかもしれないということを意味します。

    + +

    early ディレクティブではリクエストパスの設定が解決される前に + 処理されるので、メインサーバかバーチャルホストコンテキストでのみ、 + 早期ヘッダをセットできます。early ディレクティブはリクエストパスに + 依存することはできませんので、<Directory> や + <Location> といったコンテキスト内では使用 + できません。

    +
    top
    +
    +

    例

    + +
      +
    1. リクエストヘッダ中の "TS" で始まるフィールドをすべて応答ヘッダに + コピーします: +

      + Header echo ^TS +

      +
      2. + +
    2. + リクエストを受け付けた時刻とリクエストを処理した時間を入れたヘッダ、 + MyHeader を応答に追加します。このヘッダはクライアントが + サーバの負荷を直観的に知るためや、クライアント-サーバ間の + ボトルネックを調べるために使うことができます。 + +

      + Header add MyHeader "%D %t" +

      + +

      上記の設定では、以下のようなヘッダが応答に追加されることになります:

      + +

      + MyHeader: D=3775428 t=991424704447256 +

      +
      3. + +
    3. + Joe にあいさつをします: + +

      + Header add MyHeader "Hello Joe. It took %D microseconds for Apache to serve this request." +

      + +

      以下のようなヘッダが応答に追加されることになります

      + +

      + MyHeader: Hello Joe. It took D=3775428 microseconds for Apache to serve this request. +

      +
      4. + +
    4. リクエストに "MyRequestHeader" があるときに限り MyHeader を応答に + 付けます。これは、クライアントの要求に応えてヘッダを作成するときに + 役に立ちます。この例では mod_setenvif モジュールが必要なことに + 注意してください。 + +

      + SetEnvIf MyRequestHeader value HAVE_MyRequestHeader
      + Header add MyHeader "%D %t mytext" env=HAVE_MyRequestHeader +

      + +

      もし HTTP リクエストに MyRequestHeader: value ヘッダが + あると、応答には以下のようなヘッダが付加されます。

      + +

      + MyHeader: D=3775428 t=991424704447256 mytext +

      +
      5. +
    +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_headers.html.ko.euc-kr b/docs/manual/mod/mod_headers.html.ko.euc-kr index c0be03e7c5a..2a33cace21f 100644 --- a/docs/manual/mod/mod_headers.html.ko.euc-kr +++ b/docs/manual/mod/mod_headers.html.ko.euc-kr @@ -54,111 +54,6 @@

  • ¿¹Á¦
    • top
    -
    -

    ó¸® ¼ø¼­

    - -

    mod_headers°¡ Á¦°øÇÏ´Â Áö½Ã¾î´Â ¼­¹ö¼³Á¤ÀÇ - °ÅÀÇ ¸ðµç Àå¼Ò¿¡¼­ »ç¿ëÇÒ ¼ö ÀÖÀ¸¸ç, ¼³Á¤ ¼½¼ÇÀ¸·Î °¨½Î¼­ Áö½Ã¾îÀÇ - ¹üÀ§¸¦ Á¦ÇÑÇÒ ¼öµµ ÀÖ´Ù.

    - -

    󸮼ø¼­´Â Áß¿äÇϸç, ¼³Á¤ÆÄÀÏ¿¡ ³ª¿Â ¼ø¼­¿Í ¼³Á¤ ¼½¼ÇÀÇ ¿µÇâÀ» ¹Þ´Â´Ù. - ´ÙÀ½ µÎ Áö½Ã¾î¸¦ ¹Ý´ë·Î ÀûÀ¸¸é È¿°ú°¡ ´Þ¶óÁø´Ù.

    - -

    - RequestHeader append MirrorID "mirror 12"
    - RequestHeader unset MirrorID -

    - -

    À§¿Í °°ÀÌ ÀûÀ¸¸é MirrorID Çì´õ°¡ ³ª¿ÀÁö - ¾Ê´Â´Ù. ¹Ý´ë·Î ÀûÀ¸¸é MirrorID Çì´õ¸¦ "mirror 12"·Î ¼³Á¤ÇÑ´Ù.

    -
    top
    -
    -

    À̸¥(early) ó¸®¿Í ´ÊÀº(late) ó¸®

    -

    mod_headers¸¦ ¿äû Ãʱ⳪ ³ªÁß¿¡ Àû¿ëÇÒ - ¼ö ÀÖ´Ù. º¸ÅëÀº ³»¿ë»ý¼ºÀÚ¸¦ ½ÇÇàÇϱâ Á÷Àü¿¡ ¿äû Çì´õ¸¦ - ¼³Á¤ÇÏ°í ÀÀ´äÀ» ³×Æ®¿÷¿¡ ¾µ¶§ ÀÀ´ä Çì´õ¸¦ ¼³Á¤ÇÏ´Â ´ÊÀº(late) - ¹æ½ÄÀ» »ç¿ëÇÑ´Ù. ½ÇÁ¦ ¼­ºñ½ºÇÏ´Â ¼­¹ö¿¡¼­´Â Ç×»ó ´À¸° ¹æ½ÄÀ» - »ç¿ëÇ϶ó.

    - -

    À̸¥(early) ¹æ½ÄÀº °³¹ßÀÚ¸¦ À§ÇØ °Ë»ç/µð¹ö±ë¿ëÀ¸·Î ¸¸µé¾ú´Ù. - early Å°¿öµå¸¦ »ç¿ëÇÏ¿© Á¤ÀÇÇÑ Áö½Ã¾î´Â ¿äûÀ» - ó¸®Çϱ⠽ÃÀÛÇÒ¶§ ¼³Á¤ÇÑ´Ù. Áï, ´Ù¸¥ ¿äûÀ» ¸ðÀǽÇÇèÇϰųª - °Ë»ç¸¦ ÇϱâÀ§ÇØ »ç¿ëÇÒ ¼ö ÀÖÁö¸¸, ÀÀ´äÀ» »ý¼ºÇϱâ Àü¿¡ ´Ù¸¥ - ¸ðµâÀÌ ºÒ½Ã¿¡ Çì´õ¸¦ ¼öÁ¤ÇÒ ¼ö ÀÖ´Ù.

    - -

    ¿äû°æ·Î¿¡ ´ëÇÑ ¼³Á¤À» »ìÆ캸±â Àü¿¡ À̸¥ Áö½Ã¾î¸¦ - ó¸®Çϱ⶧¹®¿¡ À̸¥ Çì´õ Áö½Ã¾î´Â ÁÖ¼­¹öÀ̳ª °¡»óÈ£½ºÆ® - »ç¿ëÀå¼Ò¿¡¼­¸¸ »ç¿ëÇÒ ¼ö ÀÖ´Ù. À̸¥ Áö½Ã¾î´Â ¿äû°æ·Î¿¡ - ÀÇÁ¸ÇÒ ¼ö ¾ø±â¶§¹®¿¡ <Directory>³ª - <Location>°°Àº »ç¿ëÀå¼Ò¿¡¼­ »ç¿ëÇÒ ¼ö - ¾ø´Ù.

    -
    top
    -
    -

    ¿¹Á¦

    - -
      -
    1. - "TS"·Î ½ÃÀÛÇÏ´Â ¸ðµç ¿äû Çì´õ¸¦ ÀÀ´ä Çì´õ·Î º¹»çÇÑ´Ù. - -

      - Header echo ^TS -

      -
      2. - -
    2. - ÀÀ´ä¿¡ ¿äûÀ» ¹ÞÀº ½Ã°£°ú ¿äûÀ» ¼­ºñ½ºÇϴµ¥ °É¸± ½Ã°£À» - ¾Ë·ÁÁÖ´Â MyHeader Çì´õ¸¦ Ãß°¡ÇÑ´Ù. Ŭ¶óÀ̾ðÆ®´Â - ÀÌ Çì´õ¸¦ º¸°í ¼­¹öÀÇ ºÎÇϸ¦ ÃßÁ¤Çϰųª Ŭ¶óÀ̾ðÆ®¿Í - ¼­¹ö°£ÀÇ º´¸ñÁ¡À» ãÀ» ¼ö ÀÖ´Ù. - -

      - Header add MyHeader "%D %t" -

      - -

      ÀÀ´ä¿¡ ´ÙÀ½°ú °°Àº Çì´õ°¡ »ý±ä´Ù.

      - -

      - MyHeader: D=3775428 t=991424704447256 -

      -
      3. - -
    3. - Joe¿¡°Ô ¾È³ç - -

      - Header add MyHeader "Hello Joe. It took %D microseconds \
      - for Apache to serve this request." -

      - -

      ÀÀ´ä¿¡ ´ÙÀ½°ú °°Àº Çì´õ°¡ »ý±ä´Ù.

      - -

      - MyHeader: Hello Joe. It took D=3775428 microseconds for Apache - to serve this request. -

      -
      4. - -
    4. - ¿äû¿¡ "MyRequestHeader" Çì´õ°¡ ÀÖ´Â °æ¿ì¿¡¸¸ ¼±ÅÃÀûÀ¸·Î - ÀÀ´ä¿¡ MyHeader¸¦ º¸³½´Ù. ƯÁ¤ Ŭ¶óÀ̾ðÆ®¿¡°Ô¸¸ - ÀÀ´ä¿¡ Çì´õ¸¦ Ãß°¡ÇÒ¶§ À¯¿ëÇÏ´Ù. ÀÌ ¿¹Á¦°¡ µ¿ÀÛÇÏ·Á¸é - mod_setenvif ¸ðµâÀÌ ÇÊ¿äÇÏ´Ù. - -

      - SetEnvIf MyRequestHeader value HAVE_MyRequestHeader
      - Header add MyHeader "%D %t mytext" env=HAVE_MyRequestHeader
      -

      - -

      HTTP ¿äû¿¡ MyRequestHeader: value Çì´õ°¡ - ÀÖ´Ù¸é, ÀÀ´ä¿¡ ´ÙÀ½°ú °°Àº Çì´õ°¡ »ý±ä´Ù.

      - -

      - MyHeader: D=3775428 t=991424704447256 mytext -

      -
      5. -
    -
    -
    top

    Header Áö½Ã¾î

    説明:HTTP 応答ヘッダの設定
    @@ -332,6 +227,111 @@ ¼öÁ¤ÇÒ ¼ö ÀÖ´Ù.

    +
    top
    +
    +

    ó¸® ¼ø¼­

    + +

    mod_headers°¡ Á¦°øÇÏ´Â Áö½Ã¾î´Â ¼­¹ö¼³Á¤ÀÇ + °ÅÀÇ ¸ðµç Àå¼Ò¿¡¼­ »ç¿ëÇÒ ¼ö ÀÖÀ¸¸ç, ¼³Á¤ ¼½¼ÇÀ¸·Î °¨½Î¼­ Áö½Ã¾îÀÇ + ¹üÀ§¸¦ Á¦ÇÑÇÒ ¼öµµ ÀÖ´Ù.

    + +

    󸮼ø¼­´Â Áß¿äÇϸç, ¼³Á¤ÆÄÀÏ¿¡ ³ª¿Â ¼ø¼­¿Í ¼³Á¤ ¼½¼ÇÀÇ ¿µÇâÀ» ¹Þ´Â´Ù. + ´ÙÀ½ µÎ Áö½Ã¾î¸¦ ¹Ý´ë·Î ÀûÀ¸¸é È¿°ú°¡ ´Þ¶óÁø´Ù.

    + +

    + RequestHeader append MirrorID "mirror 12"
    + RequestHeader unset MirrorID +

    + +

    À§¿Í °°ÀÌ ÀûÀ¸¸é MirrorID Çì´õ°¡ ³ª¿ÀÁö + ¾Ê´Â´Ù. ¹Ý´ë·Î ÀûÀ¸¸é MirrorID Çì´õ¸¦ "mirror 12"·Î ¼³Á¤ÇÑ´Ù.

    +
    top
    +
    +

    À̸¥(early) ó¸®¿Í ´ÊÀº(late) ó¸®

    +

    mod_headers¸¦ ¿äû Ãʱ⳪ ³ªÁß¿¡ Àû¿ëÇÒ + ¼ö ÀÖ´Ù. º¸ÅëÀº ³»¿ë»ý¼ºÀÚ¸¦ ½ÇÇàÇϱâ Á÷Àü¿¡ ¿äû Çì´õ¸¦ + ¼³Á¤ÇÏ°í ÀÀ´äÀ» ³×Æ®¿÷¿¡ ¾µ¶§ ÀÀ´ä Çì´õ¸¦ ¼³Á¤ÇÏ´Â ´ÊÀº(late) + ¹æ½ÄÀ» »ç¿ëÇÑ´Ù. ½ÇÁ¦ ¼­ºñ½ºÇÏ´Â ¼­¹ö¿¡¼­´Â Ç×»ó ´À¸° ¹æ½ÄÀ» + »ç¿ëÇ϶ó.

    + +

    À̸¥(early) ¹æ½ÄÀº °³¹ßÀÚ¸¦ À§ÇØ °Ë»ç/µð¹ö±ë¿ëÀ¸·Î ¸¸µé¾ú´Ù. + early Å°¿öµå¸¦ »ç¿ëÇÏ¿© Á¤ÀÇÇÑ Áö½Ã¾î´Â ¿äûÀ» + ó¸®Çϱ⠽ÃÀÛÇÒ¶§ ¼³Á¤ÇÑ´Ù. Áï, ´Ù¸¥ ¿äûÀ» ¸ðÀǽÇÇèÇϰųª + °Ë»ç¸¦ ÇϱâÀ§ÇØ »ç¿ëÇÒ ¼ö ÀÖÁö¸¸, ÀÀ´äÀ» »ý¼ºÇϱâ Àü¿¡ ´Ù¸¥ + ¸ðµâÀÌ ºÒ½Ã¿¡ Çì´õ¸¦ ¼öÁ¤ÇÒ ¼ö ÀÖ´Ù.

    + +

    ¿äû°æ·Î¿¡ ´ëÇÑ ¼³Á¤À» »ìÆ캸±â Àü¿¡ À̸¥ Áö½Ã¾î¸¦ + ó¸®Çϱ⶧¹®¿¡ À̸¥ Çì´õ Áö½Ã¾î´Â ÁÖ¼­¹öÀ̳ª °¡»óÈ£½ºÆ® + »ç¿ëÀå¼Ò¿¡¼­¸¸ »ç¿ëÇÒ ¼ö ÀÖ´Ù. À̸¥ Áö½Ã¾î´Â ¿äû°æ·Î¿¡ + ÀÇÁ¸ÇÒ ¼ö ¾ø±â¶§¹®¿¡ <Directory>³ª + <Location>°°Àº »ç¿ëÀå¼Ò¿¡¼­ »ç¿ëÇÒ ¼ö + ¾ø´Ù.

    +
    top
    +
    +

    ¿¹Á¦

    + +
      +
    1. + "TS"·Î ½ÃÀÛÇÏ´Â ¸ðµç ¿äû Çì´õ¸¦ ÀÀ´ä Çì´õ·Î º¹»çÇÑ´Ù. + +

      + Header echo ^TS +

      +
      2. + +
    2. + ÀÀ´ä¿¡ ¿äûÀ» ¹ÞÀº ½Ã°£°ú ¿äûÀ» ¼­ºñ½ºÇϴµ¥ °É¸± ½Ã°£À» + ¾Ë·ÁÁÖ´Â MyHeader Çì´õ¸¦ Ãß°¡ÇÑ´Ù. Ŭ¶óÀ̾ðÆ®´Â + ÀÌ Çì´õ¸¦ º¸°í ¼­¹öÀÇ ºÎÇϸ¦ ÃßÁ¤Çϰųª Ŭ¶óÀ̾ðÆ®¿Í + ¼­¹ö°£ÀÇ º´¸ñÁ¡À» ãÀ» ¼ö ÀÖ´Ù. + +

      + Header add MyHeader "%D %t" +

      + +

      ÀÀ´ä¿¡ ´ÙÀ½°ú °°Àº Çì´õ°¡ »ý±ä´Ù.

      + +

      + MyHeader: D=3775428 t=991424704447256 +

      +
      3. + +
    3. + Joe¿¡°Ô ¾È³ç + +

      + Header add MyHeader "Hello Joe. It took %D microseconds \
      + for Apache to serve this request." +

      + +

      ÀÀ´ä¿¡ ´ÙÀ½°ú °°Àº Çì´õ°¡ »ý±ä´Ù.

      + +

      + MyHeader: Hello Joe. It took D=3775428 microseconds for Apache + to serve this request. +

      +
      4. + +
    4. + ¿äû¿¡ "MyRequestHeader" Çì´õ°¡ ÀÖ´Â °æ¿ì¿¡¸¸ ¼±ÅÃÀûÀ¸·Î + ÀÀ´ä¿¡ MyHeader¸¦ º¸³½´Ù. ƯÁ¤ Ŭ¶óÀ̾ðÆ®¿¡°Ô¸¸ + ÀÀ´ä¿¡ Çì´õ¸¦ Ãß°¡ÇÒ¶§ À¯¿ëÇÏ´Ù. ÀÌ ¿¹Á¦°¡ µ¿ÀÛÇÏ·Á¸é + mod_setenvif ¸ðµâÀÌ ÇÊ¿äÇÏ´Ù. + +

      + SetEnvIf MyRequestHeader value HAVE_MyRequestHeader
      + Header add MyHeader "%D %t mytext" env=HAVE_MyRequestHeader
      +

      + +

      HTTP ¿äû¿¡ MyRequestHeader: value Çì´õ°¡ + ÀÖ´Ù¸é, ÀÀ´ä¿¡ ´ÙÀ½°ú °°Àº Çì´õ°¡ »ý±ä´Ù.

      + +

      + MyHeader: D=3775428 t=991424704447256 mytext +

      +
      5. +
    +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_heartbeat.html.en b/docs/manual/mod/mod_heartbeat.html.en index 6e6b6aac0bd..39163898143 100644 --- a/docs/manual/mod/mod_heartbeat.html.en +++ b/docs/manual/mod/mod_heartbeat.html.en @@ -61,6 +61,25 @@ of ProxyPass Consuming mod_heartbeat Output

    top
    +

    HeartbeatAddress Directive

    +
    ¼³¸í:HTTP ÀÀ´ä Çì´õ¸¦ ±¸¼ºÇÑ´Ù
    + + + + + + +
    Description:Multicast address for heartbeat packets
    Syntax:HeartbeatAddress addr:port
    Default:disabled
    Context:server config
    Status:Experimental
    Module:mod_heartbeat
    +

    The HeartbeatAddress directive specifies the +multicast address to which mod_heartbeat will send +status information. This address will usually correspond to a configured + HeartbeatListen on a +frontend proxy system.

    +
    HeartbeatAddress 239.0.0.1:27999
    + + +
    +
    top

    Consuming mod_heartbeat Output

    @@ -80,25 +99,6 @@ v=1&ready=75&busy=0 separated by '&', being added in the future.

    -
    -
    top
    -

    HeartbeatAddress Directive

    - - - - - - - -
    Description:Multicast address for heartbeat packets
    Syntax:HeartbeatAddress addr:port
    Default:disabled
    Context:server config
    Status:Experimental
    Module:mod_heartbeat
    -

    The HeartbeatAddress directive specifies the -multicast address to which mod_heartbeat will send -status information. This address will usually correspond to a configured - HeartbeatListen on a -frontend proxy system.

    -
    HeartbeatAddress 239.0.0.1:27999
    - -
    diff --git a/docs/manual/mod/mod_heartbeat.html.fr b/docs/manual/mod/mod_heartbeat.html.fr index 83ebcaeb516..7e1e8cdd69a 100644 --- a/docs/manual/mod/mod_heartbeat.html.fr +++ b/docs/manual/mod/mod_heartbeat.html.fr @@ -67,6 +67,26 @@ du serveur HTTP Apache
  • Utilisation de la sortie de mod_heartbeat
    • top
    +

    Directive HeartbeatAddress

    + + + + + + + +
    Description:Adresse multicast à laquelle envoyer les requêtes +heartbeat
    Syntaxe:HeartbeatAddress addr:port
    Défaut:disabled
    Contexte:configuration du serveur
    Statut:Expérimental
    Module:mod_heartbeat
    +

    La directive HeartbeatAddress permet de + spécifier l'adresse multicast à laquelle mod_heartbeat va + envoyer ses informations. En général, cette adresse correspond à la + valeur définie par la directive HeartbeatListen sur le serveur + mandataire frontal.

    + 
    HeartbeatAddress 239.0.0.1:27999
    + + +
    +
    top

    Utilisation de la sortie de mod_heartbeat

    @@ -86,26 +106,6 @@ v=1&ready=75&busy=0 plus de busy et ready, et toujours séparées par des '&'.

    -
    -
    top
    -

    Directive HeartbeatAddress

    - - - - - - - -
    Description:Adresse multicast à laquelle envoyer les requêtes -heartbeat
    Syntaxe:HeartbeatAddress addr:port
    Défaut:disabled
    Contexte:configuration du serveur
    Statut:Expérimental
    Module:mod_heartbeat
    -

    La directive HeartbeatAddress permet de - spécifier l'adresse multicast à laquelle mod_heartbeat va - envoyer ses informations. En général, cette adresse correspond à la - valeur définie par la directive HeartbeatListen sur le serveur - mandataire frontal.

    - 
    HeartbeatAddress 239.0.0.1:27999
    - -
    diff --git a/docs/manual/mod/mod_heartmonitor.html.en b/docs/manual/mod/mod_heartmonitor.html.en index 8d8c7c2eebf..f086d626454 100644 --- a/docs/manual/mod/mod_heartmonitor.html.en +++ b/docs/manual/mod/mod_heartmonitor.html.en @@ -61,7 +61,6 @@ use mod_slotmem_shm HeartbeatStorage
    -
    top

    HeartbeatListen Directive

    @@ -116,6 +115,7 @@ heartbeat requests to this servermod_slotmem_shm is not loaded.

    +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_heartmonitor.html.fr b/docs/manual/mod/mod_heartmonitor.html.fr index 558e84704cc..43e6b51cb57 100644 --- a/docs/manual/mod/mod_heartmonitor.html.fr +++ b/docs/manual/mod/mod_heartmonitor.html.fr @@ -62,7 +62,6 @@ configuration suppl

  • HeartbeatStorage
    • -
    top

    Directive HeartbeatListen

    @@ -123,6 +122,7 @@ des requ pas chargé.

    +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_ident.html.en b/docs/manual/mod/mod_ident.html.en index 2b990a3890b..a27189d427d 100644 --- a/docs/manual/mod/mod_ident.html.en +++ b/docs/manual/mod/mod_ident.html.en @@ -48,7 +48,6 @@

    -
    top

    IdentityCheck Directive

    @@ -96,6 +95,7 @@ user timeout value according to your local network speed.

    +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_ident.html.fr b/docs/manual/mod/mod_ident.html.fr index 499f418c4a5..2f6f4f6c24e 100644 --- a/docs/manual/mod/mod_ident.html.fr +++ b/docs/manual/mod/mod_ident.html.fr @@ -50,7 +50,6 @@

    -
    top

    Directive IdentityCheck

    @@ -105,6 +104,7 @@ ident valeur de ce délai en fonction du débit de votre réseau local.

    +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_ident.html.ja.utf8 b/docs/manual/mod/mod_ident.html.ja.utf8 index b294db7ee65..ddac05552c1 100644 --- a/docs/manual/mod/mod_ident.html.ja.utf8 +++ b/docs/manual/mod/mod_ident.html.ja.utf8 @@ -48,7 +48,6 @@

    -
    top

    IdentityCheck ディレクティブ

    @@ -96,6 +95,7 @@ 合わせてタイムアウト値を調節するのがよいでしょう。

    +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_ident.html.ko.euc-kr b/docs/manual/mod/mod_ident.html.ko.euc-kr index 8d16692065a..74ad7292069 100644 --- a/docs/manual/mod/mod_ident.html.ko.euc-kr +++ b/docs/manual/mod/mod_ident.html.ko.euc-kr @@ -49,7 +49,6 @@

    -
    top

    IdentityCheck Áö½Ã¾î

    @@ -93,6 +92,7 @@ ¼öÁ¤ÇÒ ¼ö ÀÖ´Ù.

    +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_imagemap.html.en b/docs/manual/mod/mod_imagemap.html.en index 1c57a175959..68204cb92aa 100644 --- a/docs/manual/mod/mod_imagemap.html.en +++ b/docs/manual/mod/mod_imagemap.html.en @@ -70,6 +70,94 @@

  • Referencing your mapfile
    • top
    +

    ImapBase Directive

    +
    + + + + + + + +
    Description:Default base for imagemap files
    Syntax:ImapBase map|referer|URL
    Default:ImapBase http://servername/
    Context:server config, virtual host, directory, .htaccess
    Override:Indexes
    Status:Base
    Module:mod_imagemap
    +

    The ImapBase directive sets the default + base used in the imagemap files. Its value is + overridden by a base directive within the imagemap + file. If not present, the base defaults to + http://servername/.

    + +

    See also

    + +
    +
    top
    +

    ImapDefault Directive

    + + + + + + + + +
    Description:Default action when an imagemap is called with coordinates +that are not explicitly mapped
    Syntax:ImapDefault error|nocontent|map|referer|URL
    Default:ImapDefault nocontent
    Context:server config, virtual host, directory, .htaccess
    Override:Indexes
    Status:Base
    Module:mod_imagemap
    +

    The ImapDefault directive sets the default + default used in the imagemap files. Its value is + overridden by a default directive within the + imagemap file. If not present, the default action + is nocontent, which means that a 204 No + Content is sent to the client. In this case, the client + should continue to display the original page.

    + +
    +
    top
    +

    ImapMenu Directive

    + + + + + + + + +
    Description:Action if no coordinates are given when calling +an imagemap
    Syntax:ImapMenu none|formatted|semiformatted|unformatted
    Default:ImapMenu formatted
    Context:server config, virtual host, directory, .htaccess
    Override:Indexes
    Status:Base
    Module:mod_imagemap
    +

    The ImapMenu directive determines the + action taken if an imagemap file is called without valid + coordinates.

    + +
    +
    none
    +
    If ImapMenu is none, no menu is generated, + and the default action is performed.
    + +
    formatted
    +
    A formatted menu is the simplest menu. + Comments in the imagemap file are ignored. A level one header + is printed, then an hrule, then the links each on a separate + line. The menu has a consistent, plain look close to that of + a directory listing.
    + +
    semiformatted
    +
    In the semiformatted menu, comments are + printed where they occur in the imagemap file. Blank lines + are turned into HTML breaks. No header or hrule is printed, + but otherwise the menu is the same as a + formatted menu.
    + +
    unformatted
    +
    Comments are printed, blank lines are ignored. Nothing is + printed that does not appear in the imagemap file. All breaks + and headers must be included as comments in the imagemap + file. This gives you the most flexibility over the appearance + of your menus, but requires you to treat your map files as + HTML instead of plaintext.
    +
    + +
    +
    top

    New Features

    @@ -291,94 +379,6 @@ </a>

    - -
    top
    -

    ImapBase Directive

    - - - - - - - - -
    Description:Default base for imagemap files
    Syntax:ImapBase map|referer|URL
    Default:ImapBase http://servername/
    Context:server config, virtual host, directory, .htaccess
    Override:Indexes
    Status:Base
    Module:mod_imagemap
    -

    The ImapBase directive sets the default - base used in the imagemap files. Its value is - overridden by a base directive within the imagemap - file. If not present, the base defaults to - http://servername/.

    - -

    See also

    - -
    -
    top
    -

    ImapDefault Directive

    - - - - - - - - -
    Description:Default action when an imagemap is called with coordinates -that are not explicitly mapped
    Syntax:ImapDefault error|nocontent|map|referer|URL
    Default:ImapDefault nocontent
    Context:server config, virtual host, directory, .htaccess
    Override:Indexes
    Status:Base
    Module:mod_imagemap
    -

    The ImapDefault directive sets the default - default used in the imagemap files. Its value is - overridden by a default directive within the - imagemap file. If not present, the default action - is nocontent, which means that a 204 No - Content is sent to the client. In this case, the client - should continue to display the original page.

    - -
    -
    top
    -

    ImapMenu Directive

    - - - - - - - - -
    Description:Action if no coordinates are given when calling -an imagemap
    Syntax:ImapMenu none|formatted|semiformatted|unformatted
    Default:ImapMenu formatted
    Context:server config, virtual host, directory, .htaccess
    Override:Indexes
    Status:Base
    Module:mod_imagemap
    -

    The ImapMenu directive determines the - action taken if an imagemap file is called without valid - coordinates.

    - -
    -
    none
    -
    If ImapMenu is none, no menu is generated, - and the default action is performed.
    - -
    formatted
    -
    A formatted menu is the simplest menu. - Comments in the imagemap file are ignored. A level one header - is printed, then an hrule, then the links each on a separate - line. The menu has a consistent, plain look close to that of - a directory listing.
    - -
    semiformatted
    -
    In the semiformatted menu, comments are - printed where they occur in the imagemap file. Blank lines - are turned into HTML breaks. No header or hrule is printed, - but otherwise the menu is the same as a - formatted menu.
    - -
    unformatted
    -
    Comments are printed, blank lines are ignored. Nothing is - printed that does not appear in the imagemap file. All breaks - and headers must be included as comments in the imagemap - file. This gives you the most flexibility over the appearance - of your menus, but requires you to treat your map files as - HTML instead of plaintext.
    -
    -
    diff --git a/docs/manual/mod/mod_imagemap.html.fr b/docs/manual/mod/mod_imagemap.html.fr index 1ea8f1b3ca6..7c23ab8b07e 100644 --- a/docs/manual/mod/mod_imagemap.html.fr +++ b/docs/manual/mod/mod_imagemap.html.fr @@ -72,6 +72,101 @@ imagemap
    top
    +

    Directive ImapBase

    + + + + + + + + +
    Description:Valeur par défaut de la directive base des +fichiers imagemap
    Syntaxe:ImapBase map|referer|URL
    Défaut:ImapBase http://nom_serveur/
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:Indexes
    Statut:Base
    Module:mod_imagemap
    +

    La directive ImapBase permet de définir la + valeur par défaut de la directive base des fichiers + imagemap. Sa valeur est écrasée par la présence éventuelle d'une + directive base dans le fichier imagemap. Si cette + directive est absente, la valeur par défaut de la directive + base est + http://nom_serveur/.

    + +

    Voir aussi

    + +
    +
    top
    +

    Directive ImapDefault

    + + + + + + + + +
    Description:Action à entreprendre par défaut lorsqu'un fichier imagemap +est invoqué avec des coordonnées qui ne correspondent à aucune +cible
    Syntaxe:ImapDefault error|nocontent|map|referer|URL
    Défaut:ImapDefault nocontent
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:Indexes
    Statut:Base
    Module:mod_imagemap
    +

    La directive ImapDefault permet de définir + la valeur par défaut de la directive default utilisée + dans les fichiers imagemap. Sa valeur est écrasée par la présence + éventuelle d'une directive default dans le fichier + imagemap. Si cette directive est absente, l'action associée à + default est nocontent, ce qui implique + l'envoi d'un code de statut 204 No Content au client. + Dans ce cas, le client doit continuer à afficher la même page.

    + +
    +
    top
    +

    Directive ImapMenu

    + + + + + + + + +
    Description:Action à entreprendre si aucune coordonnée n'est fournie +lorsqu'on invoque un fichier imagemap
    Syntaxe:ImapMenu none|formatted|semiformatted|unformatted
    Défaut:ImapMenu formatted
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:Indexes
    Statut:Base
    Module:mod_imagemap
    +

    La directive ImapMenu permet de spécifier + l'action à entreprendre lorsqu'un fichier imagemap est invoqué sans + coordonnées valides.

    + +
    +
    none
    +
    Si l'argument d'ImapMenu est none, aucun menu + n'est généré, et l'action default est effectuée.
    + +
    formatted
    +
    Le menu formatted est le menu le plus simple. Les + commentaires du fichier imagemap sont ignorés. Un en-tête de + niveau un est affiché, puis un séparateur horizontal, puis chacun + des liens sur une ligne séparée. L'aspect du menu est similaire à + celui d'un listing de répertoire.
    + +
    semiformatted
    +
    Dans le menu semiformatted, les commentaires sont + affichés au moment où ils apparaissent dans le fichier imagemap. + Les lignes vides sont interprètées comme des lignes de séparation + HTML. Aucun en-tête ni séparateur horizontal n'est affiché. À part + ces différences, le menu semiformatted est identique + au menu formatted.
    + +
    unformatted
    +
    Les commentaires sont affichés et les lignes vides sont + ignorées. N'est affiché que ce qui apparait dans le fichier + imagemap. Toutes les lignes de séparation HTML et les + en-têtes doivent être inclus en tant que commentaires dans le + fichier imagemap. Cela vous procure une grande souplesse pour + définir l'apparence de vos menus, mais vous oblige à rédiger vos + fichiers imagemap en HTML, et non en texte plat.
    +
    + +
    +
    top

    Nouvelles fonctionnalités

    @@ -308,101 +403,6 @@ imagemap </a>

    - -
    top
    -

    Directive ImapBase

    - - - - - - - - -
    Description:Valeur par défaut de la directive base des -fichiers imagemap
    Syntaxe:ImapBase map|referer|URL
    Défaut:ImapBase http://nom_serveur/
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:Indexes
    Statut:Base
    Module:mod_imagemap
    -

    La directive ImapBase permet de définir la - valeur par défaut de la directive base des fichiers - imagemap. Sa valeur est écrasée par la présence éventuelle d'une - directive base dans le fichier imagemap. Si cette - directive est absente, la valeur par défaut de la directive - base est - http://nom_serveur/.

    - -

    Voir aussi

    - -
    -
    top
    -

    Directive ImapDefault

    - - - - - - - - -
    Description:Action à entreprendre par défaut lorsqu'un fichier imagemap -est invoqué avec des coordonnées qui ne correspondent à aucune -cible
    Syntaxe:ImapDefault error|nocontent|map|referer|URL
    Défaut:ImapDefault nocontent
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:Indexes
    Statut:Base
    Module:mod_imagemap
    -

    La directive ImapDefault permet de définir - la valeur par défaut de la directive default utilisée - dans les fichiers imagemap. Sa valeur est écrasée par la présence - éventuelle d'une directive default dans le fichier - imagemap. Si cette directive est absente, l'action associée à - default est nocontent, ce qui implique - l'envoi d'un code de statut 204 No Content au client. - Dans ce cas, le client doit continuer à afficher la même page.

    - -
    -
    top
    -

    Directive ImapMenu

    - - - - - - - - -
    Description:Action à entreprendre si aucune coordonnée n'est fournie -lorsqu'on invoque un fichier imagemap
    Syntaxe:ImapMenu none|formatted|semiformatted|unformatted
    Défaut:ImapMenu formatted
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:Indexes
    Statut:Base
    Module:mod_imagemap
    -

    La directive ImapMenu permet de spécifier - l'action à entreprendre lorsqu'un fichier imagemap est invoqué sans - coordonnées valides.

    - -
    -
    none
    -
    Si l'argument d'ImapMenu est none, aucun menu - n'est généré, et l'action default est effectuée.
    - -
    formatted
    -
    Le menu formatted est le menu le plus simple. Les - commentaires du fichier imagemap sont ignorés. Un en-tête de - niveau un est affiché, puis un séparateur horizontal, puis chacun - des liens sur une ligne séparée. L'aspect du menu est similaire à - celui d'un listing de répertoire.
    - -
    semiformatted
    -
    Dans le menu semiformatted, les commentaires sont - affichés au moment où ils apparaissent dans le fichier imagemap. - Les lignes vides sont interprètées comme des lignes de séparation - HTML. Aucun en-tête ni séparateur horizontal n'est affiché. À part - ces différences, le menu semiformatted est identique - au menu formatted.
    - -
    unformatted
    -
    Les commentaires sont affichés et les lignes vides sont - ignorées. N'est affiché que ce qui apparait dans le fichier - imagemap. Toutes les lignes de séparation HTML et les - en-têtes doivent être inclus en tant que commentaires dans le - fichier imagemap. Cela vous procure une grande souplesse pour - définir l'apparence de vos menus, mais vous oblige à rédiger vos - fichiers imagemap en HTML, et non en texte plat.
    -
    -
    diff --git a/docs/manual/mod/mod_imagemap.html.ko.euc-kr b/docs/manual/mod/mod_imagemap.html.ko.euc-kr index 9d99a0db363..e8ea7d8377f 100644 --- a/docs/manual/mod/mod_imagemap.html.ko.euc-kr +++ b/docs/manual/mod/mod_imagemap.html.ko.euc-kr @@ -67,6 +67,88 @@
  • ¸ÊÆÄÀÏ »ç¿ëÇϱâ
    • top
    +

    ImapBase Áö½Ã¾î

    + + + + + + + + +
    ¼³¸í:À̹ÌÁö¸Ê ÆÄÀÏ¿¡¼­ base ±âº»°ª
    ¹®¹ý:ImapBase map|referer|URL
    ±âº»°ª:ImapBase http://servername/
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    Override ¿É¼Ç:Indexes
    »óÅÂ:Base
    ¸ðµâ:mod_imagemap
    +

    ImapBase Áö½Ã¾î´Â À̹ÌÁö¸Ê ÆÄÀÏ¿¡¼­ + »ç¿ëÇÒ base ±âº»°ªÀ» ¼³Á¤ÇÑ´Ù. À̹ÌÁö¸Ê ÆÄÀÏ + ¾È¿¡¼­ base Áö½Ã¾î¸¦ »ç¿ëÇÏ¸é ¿©±â¼­ ¼³Á¤ÇÑ + °ªÀº ¹«½ÃÇÑ´Ù. µÑ ¸ðµÎ ¾ø´Ù¸é, base ±âº»°ªÀº + http://servername/ÀÌ´Ù.

    + +

    Âü°í

    + +
    +
    top
    +

    ImapDefault Áö½Ã¾î

    + + + + + + + + +
    ¼³¸í:À̹ÌÁö¸Ê¿¡ ¾î´À ¿µ¿ª¿¡µµ ÇØ´çÇÏÁö ¾Ê´Â ÁÂÇ¥¸¦ ÁØ +°æ¿ì ±âº» Çൿ
    ¹®¹ý:ImapDefault error|nocontent|map|referer|URL
    ±âº»°ª:ImapDefault nocontent
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    Override ¿É¼Ç:Indexes
    »óÅÂ:Base
    ¸ðµâ:mod_imagemap
    +

    ImapDefault Áö½Ã¾î´Â À̹ÌÁö¸Ê + ÆÄÀÏ¿¡¼­ »ç¿ëÇÒ default ±âº»°ªÀ» ¼³Á¤ÇÑ´Ù. + À̹ÌÁö¸Ê ÆÄÀÏ ¾È¿¡¼­ default Áö½Ã¾î¸¦ »ç¿ëÇϸé + ¿©±â¼­ ¼³Á¤ÇÑ °ªÀº ¹«½ÃÇÑ´Ù. µÑ ¸ðµÎ ¾ø´Ù¸é, default + ÇൿÀº Ŭ¶óÀ̾ðÆ®¿¡°Ô 204 No Content¸¦ º¸³»´Â + nocontentÀÌ´Ù. ÀÌ °æ¿ì Ŭ¶óÀ̾ðÆ®´Â ¿ø·¡ ÆäÀÌÁö¸¦ + ±×´ë·Î º¸¿©Áà¾ß ÇÑ´Ù.

    + +
    +
    top
    +

    ImapMenu Áö½Ã¾î

    + + + + + + + +
    ¼³¸í:ÁÂÇ¥¾øÀÌ À̹ÌÁö¸Ê ¿äû½Ã ÃëÇÒ Çൿ
    ¹®¹ý:ImapMenu none|formatted|semiformatted|unformatted
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    Override ¿É¼Ç:Indexes
    »óÅÂ:Base
    ¸ðµâ:mod_imagemap
    +

    ImapMenu Áö½Ã¾î´Â À̹ÌÁö¸Ê ÆÄÀÏ¿¡ + À¯È¿ÇÑ ÁÂÇ¥¸¦ ÁÖÁö ¾ÊÀº °æ¿ì ÃëÇÒ ÇൿÀ» °áÁ¤ÇÑ´Ù.

    + +
    +
    none
    +
    ImapMenu°¡ noneÀ̸é, ¸Þ´º¸¦ ¸¸µéÁö¾Ê°í + default ÇൿÀ» ÃëÇÑ´Ù.
    + +
    formatted
    +
    formatted ¸Þ´º´Â °¡Àå °£´ÜÇÑ ¸Þ´º´Ù. + À̹ÌÁö¸Ê ÆÄÀÏÀÇ ÁÖ¼®Àº ¹«½ÃÇÑ´Ù. °¡Àå Å« Ç¥Á¦¿Í ¼öÁ÷¼±À» + Ãâ·ÂÇÏ°í, ¸µÅ©¸¦ ÇÑÁÙ¾¿ Ãâ·ÂÇÑ´Ù. ¸Þ´º´Â ÀÏ°üµÇ°í ÆòÀÌÇϸç, + µð·ºÅ丮 ¸ñ·Ï°ú Èí»çÇÏ´Ù.
    + +
    semiformatted
    +
    semiformatted ¸Þ´º´Â À̹ÌÁö¸Ê ÆÄÀÏ¿¡ + ³ª¿À´Â ÁÖ¼®À» Ãâ·ÂÇÑ´Ù. ºóÁÙÀº HTML Çà¹Ù²ÞÀ¸·Î º¯È¯ÇÑ´Ù. + Ç¥Á¦³ª ¼öÁ÷¼±À» ±×¸®Áö ¾ÊÁö¸¸, ³ª¸ÓÁö´Â formatted + ¸Þ´º¿Í °°´Ù.
    + +
    unformatted
    +
    ÁÖ¼®Àº Ãâ·ÂÇÏ°í, ºóÁÙÀº ¹«½ÃÇÑ´Ù. À̹ÌÁö¸Ê ÆÄÀÏ¿¡ + ÀÖ´Â ³»¿ë¸¸ Ãâ·ÂÇÑ´Ù. À̹ÌÁö¸Ê ÆÄÀÏÀÇ ÁÖ¼®¿¡ ÇÊ¿äÇÑ ¸ðµç + Çà¹Ù²Þ°ú Ç¥Á¦¸¦ Àû¾î¾ß ÇÑ´Ù. ¸Þ´ºÀÇ ¿Ü°üÀ» °¡Àå ÀÚÀ¯ÀÚÁ¦·Î + ²Ù¹Ð ¼ö ÀÖÁö¸¸, À̹ÌÁö¸Ê ÆÄÀÏÀ» »ç½Ç»ó ÀÏ¹Ý ¹®ÀÚÆÄÀÏÀÌ + ¾Æ´Ñ HTML·Î ºÁ¾ß ÇÑ´Ù.
    +
    + +
    +
    top

    »õ·Î¿î ±â´É

    @@ -274,88 +356,6 @@ </a>

    - -
    top
    -

    ImapBase Áö½Ã¾î

    - - - - - - - - -
    ¼³¸í:À̹ÌÁö¸Ê ÆÄÀÏ¿¡¼­ base ±âº»°ª
    ¹®¹ý:ImapBase map|referer|URL
    ±âº»°ª:ImapBase http://servername/
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    Override ¿É¼Ç:Indexes
    »óÅÂ:Base
    ¸ðµâ:mod_imagemap
    -

    ImapBase Áö½Ã¾î´Â À̹ÌÁö¸Ê ÆÄÀÏ¿¡¼­ - »ç¿ëÇÒ base ±âº»°ªÀ» ¼³Á¤ÇÑ´Ù. À̹ÌÁö¸Ê ÆÄÀÏ - ¾È¿¡¼­ base Áö½Ã¾î¸¦ »ç¿ëÇÏ¸é ¿©±â¼­ ¼³Á¤ÇÑ - °ªÀº ¹«½ÃÇÑ´Ù. µÑ ¸ðµÎ ¾ø´Ù¸é, base ±âº»°ªÀº - http://servername/ÀÌ´Ù.

    - -

    Âü°í

    - -
    -
    top
    -

    ImapDefault Áö½Ã¾î

    - - - - - - - - -
    ¼³¸í:À̹ÌÁö¸Ê¿¡ ¾î´À ¿µ¿ª¿¡µµ ÇØ´çÇÏÁö ¾Ê´Â ÁÂÇ¥¸¦ ÁØ -°æ¿ì ±âº» Çൿ
    ¹®¹ý:ImapDefault error|nocontent|map|referer|URL
    ±âº»°ª:ImapDefault nocontent
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    Override ¿É¼Ç:Indexes
    »óÅÂ:Base
    ¸ðµâ:mod_imagemap
    -

    ImapDefault Áö½Ã¾î´Â À̹ÌÁö¸Ê - ÆÄÀÏ¿¡¼­ »ç¿ëÇÒ default ±âº»°ªÀ» ¼³Á¤ÇÑ´Ù. - À̹ÌÁö¸Ê ÆÄÀÏ ¾È¿¡¼­ default Áö½Ã¾î¸¦ »ç¿ëÇϸé - ¿©±â¼­ ¼³Á¤ÇÑ °ªÀº ¹«½ÃÇÑ´Ù. µÑ ¸ðµÎ ¾ø´Ù¸é, default - ÇൿÀº Ŭ¶óÀ̾ðÆ®¿¡°Ô 204 No Content¸¦ º¸³»´Â - nocontentÀÌ´Ù. ÀÌ °æ¿ì Ŭ¶óÀ̾ðÆ®´Â ¿ø·¡ ÆäÀÌÁö¸¦ - ±×´ë·Î º¸¿©Áà¾ß ÇÑ´Ù.

    - -
    -
    top
    -

    ImapMenu Áö½Ã¾î

    - - - - - - - -
    ¼³¸í:ÁÂÇ¥¾øÀÌ À̹ÌÁö¸Ê ¿äû½Ã ÃëÇÒ Çൿ
    ¹®¹ý:ImapMenu none|formatted|semiformatted|unformatted
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    Override ¿É¼Ç:Indexes
    »óÅÂ:Base
    ¸ðµâ:mod_imagemap
    -

    ImapMenu Áö½Ã¾î´Â À̹ÌÁö¸Ê ÆÄÀÏ¿¡ - À¯È¿ÇÑ ÁÂÇ¥¸¦ ÁÖÁö ¾ÊÀº °æ¿ì ÃëÇÒ ÇൿÀ» °áÁ¤ÇÑ´Ù.

    - -
    -
    none
    -
    ImapMenu°¡ noneÀ̸é, ¸Þ´º¸¦ ¸¸µéÁö¾Ê°í - default ÇൿÀ» ÃëÇÑ´Ù.
    - -
    formatted
    -
    formatted ¸Þ´º´Â °¡Àå °£´ÜÇÑ ¸Þ´º´Ù. - À̹ÌÁö¸Ê ÆÄÀÏÀÇ ÁÖ¼®Àº ¹«½ÃÇÑ´Ù. °¡Àå Å« Ç¥Á¦¿Í ¼öÁ÷¼±À» - Ãâ·ÂÇÏ°í, ¸µÅ©¸¦ ÇÑÁÙ¾¿ Ãâ·ÂÇÑ´Ù. ¸Þ´º´Â ÀÏ°üµÇ°í ÆòÀÌÇϸç, - µð·ºÅ丮 ¸ñ·Ï°ú Èí»çÇÏ´Ù.
    - -
    semiformatted
    -
    semiformatted ¸Þ´º´Â À̹ÌÁö¸Ê ÆÄÀÏ¿¡ - ³ª¿À´Â ÁÖ¼®À» Ãâ·ÂÇÑ´Ù. ºóÁÙÀº HTML Çà¹Ù²ÞÀ¸·Î º¯È¯ÇÑ´Ù. - Ç¥Á¦³ª ¼öÁ÷¼±À» ±×¸®Áö ¾ÊÁö¸¸, ³ª¸ÓÁö´Â formatted - ¸Þ´º¿Í °°´Ù.
    - -
    unformatted
    -
    ÁÖ¼®Àº Ãâ·ÂÇÏ°í, ºóÁÙÀº ¹«½ÃÇÑ´Ù. À̹ÌÁö¸Ê ÆÄÀÏ¿¡ - ÀÖ´Â ³»¿ë¸¸ Ãâ·ÂÇÑ´Ù. À̹ÌÁö¸Ê ÆÄÀÏÀÇ ÁÖ¼®¿¡ ÇÊ¿äÇÑ ¸ðµç - Çà¹Ù²Þ°ú Ç¥Á¦¸¦ Àû¾î¾ß ÇÑ´Ù. ¸Þ´ºÀÇ ¿Ü°üÀ» °¡Àå ÀÚÀ¯ÀÚÁ¦·Î - ²Ù¹Ð ¼ö ÀÖÁö¸¸, À̹ÌÁö¸Ê ÆÄÀÏÀ» »ç½Ç»ó ÀÏ¹Ý ¹®ÀÚÆÄÀÏÀÌ - ¾Æ´Ñ HTML·Î ºÁ¾ß ÇÑ´Ù.
    -
    -
    diff --git a/docs/manual/mod/mod_include.html.en b/docs/manual/mod/mod_include.html.en index df0000eeaf8..1a4f2d79501 100644 --- a/docs/manual/mod/mod_include.html.en +++ b/docs/manual/mod/mod_include.html.en @@ -70,1016 +70,1016 @@
  • SSI Tutorial
    • top
    -
    -

    Enabling Server-Side Includes

    - - -

    Server Side Includes are implemented by the - INCLUDES filter. If - documents containing server-side include directives are given - the extension .shtml, the following directives will make Apache - parse them and assign the resulting document the mime type of - text/html:

    - - 
    AddType text/html .shtml
-AddOutputFilter INCLUDES .shtml
    +

    SSIEndTag Directive

    + + + + + + + +
    Description:String that ends an include element
    Syntax:SSIEndTag tag
    Default:SSIEndTag "-->"
    Context:server config, virtual host
    Status:Base
    Module:mod_include
    +

    This directive changes the string that mod_include + looks for to mark the end of an include element.

    + 
    SSIEndTag "%>"
    -

    The following directive must be given for the directories - containing the shtml files (typically in a - <Directory> section, - but this directive is also valid in .htaccess files if - AllowOverride Options - is set):

    - 
    Options +Includes
    +

    See also

    + +
    +
    top
    +

    SSIErrorMsg Directive

    + + + + + + + + +
    Description:Error message displayed when there is an SSI +error
    Syntax:SSIErrorMsg message
    Default:SSIErrorMsg "[an error occurred while processing this +directive]"
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Base
    Module:mod_include
    +

    The SSIErrorMsg directive changes the error + message displayed when mod_include encounters an + error. For production servers you may consider changing the default + error message to "<!-- Error -->" so that + the message is not presented to the user.

    -

    For backwards compatibility, the server-parsed - handler also activates the - INCLUDES filter. As well, Apache will activate the INCLUDES - filter for any document with mime type - text/x-server-parsed-html or - text/x-server-parsed-html3 (and the resulting - output will have the mime type text/html).

    +

    This directive has the same effect as the <!--#config + errmsg=message --> element.

    -

    For more information, see our Tutorial on Server Side Includes.

    -
    top
    -
    -

    PATH_INFO with Server Side Includes

    - + 
    SSIErrorMsg "<!-- Error -->"
    -

    Files processed for server-side includes no longer accept - requests with PATH_INFO (trailing pathname information) - by default. You can use the AcceptPathInfo directive to - configure the server to accept requests with PATH_INFO.

    -
    top
    -
    -

    Available Elements

    -

    The document is parsed as an HTML document, with special - commands embedded as SGML comments. A command has the syntax:

    -

    - <!--#element attribute=value - attribute=value ... --> -

    +
    +
    top
    +

    SSIETag Directive

    + + + + + + + + +
    Description:Controls whether ETags are generated by the server.
    Syntax:SSIETag on|off
    Default:SSIETag off
    Context:directory, .htaccess
    Status:Base
    Module:mod_include
    Compatibility:Available in version 2.2.15 and later.
    +

    Under normal circumstances, a file filtered by mod_include + may contain elements that are either dynamically generated, or that may + have changed independently of the original file. As a result, by default + the server is asked not to generate an ETag header for the + response by adding no-etag to the request notes.

    -

    The value will often be enclosed in double quotes, but single - quotes (') and backticks (`) are also - possible. Many commands only allow a single attribute-value pair. - Note that the comment terminator (-->) should be - preceded by whitespace to ensure that it isn't considered part of - an SSI token. Note that the leading <!--# is one - token and may not contain any whitespaces.

    +

    The SSIETag directive suppresses this + behaviour, and allows the server to generate an ETag header. + This can be used to enable caching of the output. Note that a backend server + or dynamic content generator may generate an ETag of its own, ignoring + no-etag, and this ETag will be passed by + mod_include regardless of the value of this setting. + SSIETag can take on the following values:

    -

    The allowed elements are listed in the following table:

    +
    - - - - - - - - - - - - - - - - - - -
    ElementDescription
    configconfigure output formats
    echoprint variables
    execexecute external programs
    fsizeprint size of a file
    flastmodprint last modification time of a file
    includeinclude a file
    printenvprint all available variables
    setset a value of a variable
    +
    off
    +
    no-etag will be added to the request notes, and the server + is asked not to generate an ETag. Where a server ignores the value of + no-etag and generates an ETag anyway, the ETag will be + respected.
    -

    SSI elements may be defined by modules other than - mod_include. In fact, the exec element is provided by - mod_cgi, and will only be available if this - module is loaded.

    +
    on
    +
    Existing ETags will be respected, and ETags generated by the server will + be passed on in the response.
    -

    The config Element

    -

    This command controls various aspects of the parsing. The - valid attributes are:

    +
    -
    -
    echomsg (Apache 2.1 and later)
    -
    -

    The value is a message that is sent back to the - client if the echo element - attempts to echo an undefined variable. This overrides any SSIUndefinedEcho directives.

    -

    - <!--#config echomsg="[Value Undefined]" --> -

    -
    +
    +
    top
    +

    SSILastModified Directive

    + + + + + + + + +
    Description:Controls whether Last-Modified headers are generated by the +server.
    Syntax:SSILastModified on|off
    Default:SSILastModified off
    Context:directory, .htaccess
    Status:Base
    Module:mod_include
    Compatibility:Available in version 2.2.15 and later.
    +

    Under normal circumstances, a file filtered by mod_include + may contain elements that are either dynamically generated, or that may + have changed independently of the original file. As a result, by default + the Last-Modified header is stripped from the response.

    -
    errmsg
    -

    The value is a message that is sent back to the - client if an error occurs while parsing the - document. This overrides any SSIErrorMsg directives.

    - -

    - <!--#config errmsg="[Oops, something broke.]" --> -

    -
    +

    The SSILastModified directive overrides this + behaviour, and allows the Last-Modified header to be respected + if already present, or set if the header is not already present. This can + be used to enable caching of the output. SSILastModified + can take on the following values:

    -
    sizefmt
    -

    The value sets the format to be used when displaying - the size of a file. Valid values are bytes - for a count in bytes, or abbrev for a count - in Kb or Mb as appropriate, for example a size of 1024 bytes - will be printed as "1K".

    +
    -

    - <!--#config sizefmt="abbrev" --> -

    -
    +
    off
    +
    The Last-Modified header will be stripped from responses, + unless the XBitHack directive + is set to full as described below.
    -
    timefmt
    -

    The value is a string to be used by the - strftime(3) library routine when printing - dates.

    - -

    - <!--#config timefmt=""%R, %B %d, %Y"" --> -

    +
    on
    +
    The Last-Modified header will be respected if already + present in a response, and added to the response if the response is a + file and the header is missing. The + SSILastModified directive + takes precedence over XBitHack.
    - - - -

    The echo Element

    -

    This command prints one of the include - variables defined below. If the variable is unset, the result is - determined by the SSIUndefinedEcho directive. Any dates printed are - subject to the currently configured timefmt.

    - -

    Attributes:

    -
    -
    var
    -
    The value is the name of the variable to print.
    +
    +
    top
    +

    SSILegacyExprParser Directive

    + + + + + + + + +
    Description:Enable compatibility mode for conditional expressions.
    Syntax:SSILegacyExprParser on|off
    Default:SSILegacyExprParser off
    Context:directory, .htaccess
    Status:Base
    Module:mod_include
    Compatibility:Available in version 2.3.13 and later.
    +

    As of version 2.3.13, mod_include has switched to the + new ap_expr syntax for conditional expressions + in #if flow control elements. This directive allows to + switch to the old syntax which is compatible + with Apache HTTPD version 2.2.x and earlier. +

    -
    decoding
    -

    Specifies whether Apache should strip an encoding from - the variable before processing the variable further. The default - is none, where no decoding will be done. If set to - url, then URL decoding (also known as %-encoding; - this is appropriate for use within URLs in links, etc.) will be - performed. If set to urlencoded, - application/x-www-form-urlencoded compatible encoding (found in - query strings) will be stripped. If set to base64, - base64 will be decoded, and if set to entity, HTML - entity encoding will be stripped. Decoding is done prior to any - further encoding on the variable. Multiple encodings can be - stripped by specifying more than one comma separated encoding. - The decoding setting will remain in effect until the next decoding - attribute is encountered, or the element ends.

    +
    +
    top
    +

    SSIStartTag Directive

    + + + + + + + +
    Description:String that starts an include element
    Syntax:SSIStartTag tag
    Default:SSIStartTag "<!--#"
    Context:server config, virtual host
    Status:Base
    Module:mod_include
    +

    This directive changes the string that mod_include + looks for to mark an include element to process.

    -

    The decoding attribute must precede the - corresponding var attribute to be effective.

    - +

    You may want to use this option if you have 2 servers parsing the + output of a file each processing different commands (possibly at + different times).

    -
    encoding
    -

    Specifies how Apache should encode special characters - contained in the variable before outputting them. If set - to none, no encoding will be done. If set to - url, then URL encoding (also known as %-encoding; - this is appropriate for use within URLs in links, etc.) will be - performed. If set to urlencoded, - application/x-www-form-urlencoded compatible encoding will be - performed instead, and should be used with query strings. If set - to base64, base64 encoding will be performed. At - the start of an echo element, the default is set to - entity, resulting in entity encoding (which is - appropriate in the context of a block-level HTML element, - e.g. a paragraph of text). This can be changed by adding - an encoding attribute, which will remain in effect - until the next encoding attribute is encountered or - the element ends, whichever comes first.

    + 
          SSIStartTag "<%"
    
+      SSIEndTag   "%>"
    -

    The encoding attribute must precede the - corresponding var attribute to be effective.

    -
    - In order to avoid cross-site scripting issues, you should - always encode user supplied data. -
    +

    The example given above, which also specifies a matching + SSIEndTag, will + allow you to use SSI directives as shown in the example + below:

    -

    Example

    - <!--#echo encoding="entity" var="QUERY_STRING" --> -

    -
    - - +

    SSI directives with alternate start and end tags

    + <%printenv %> +

    -

    The exec Element

    -

    The exec command executes a given shell command or - CGI script. It requires mod_cgi to be present - in the server. If Options - IncludesNOEXEC is set, this command is completely - disabled. The valid attributes are:

    +

    See also

    + +
    +
    top
    +

    SSITimeFormat Directive

    + + + + + + + + +
    Description:Configures the format in which date strings are +displayed
    Syntax:SSITimeFormat formatstring
    Default:SSITimeFormat "%A, %d-%b-%Y %H:%M:%S %Z"
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Base
    Module:mod_include
    +

    This directive changes the format in which date strings are displayed + when echoing DATE environment variables. The + formatstring is as in strftime(3) from the + C standard library.

    -
    -
    cgi
    -

    The value specifies a (%-encoded) URL-path to - the CGI script. If the path does not begin with a slash (/), - then it is taken to be relative to the current - document. The document referenced by this path is - invoked as a CGI script, even if the server would not - normally recognize it as such. However, the directory - containing the script must be enabled for CGI scripts - (with ScriptAlias - or Options - ExecCGI).

    +

    This directive has the same effect as the <!--#config + timefmt=formatstring --> element.

    -

    The CGI script is given the PATH_INFO and query - string (QUERY_STRING) of the original request from the - client; these cannot be specified in the URL path. The - include variables will be available to the script in addition to - the standard CGI environment.

    + 
    SSITimeFormat "%R, %B %d, %Y"
    -

    Example

    - <!--#exec cgi="/cgi-bin/example.cgi" --> -

    -

    If the script returns a Location: header instead of - output, then this will be translated into an HTML anchor.

    +

    The above directive would cause times to be displayed in the + format "22:26, June 14, 2002".

    -

    The include virtual - element should be used in preference to exec cgi. In - particular, if you need to pass additional arguments to a CGI program, - using the query string, this cannot be done with exec - cgi, but can be done with include virtual, as - shown here:

    +
    +
    top
    +

    SSIUndefinedEcho Directive

    + + + + + + + + +
    Description:String displayed when an unset variable is echoed
    Syntax:SSIUndefinedEcho string
    Default:SSIUndefinedEcho "(none)"
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Base
    Module:mod_include
    +

    This directive changes the string that mod_include + displays when a variable is not set and "echoed".

    -

    - <!--#include virtual="/cgi-bin/example.cgi?argument=value" --> -

    - + 
    SSIUndefinedEcho "<!-- undef -->"
    -
    cmd
    -

    The server will execute the given string using - /bin/sh. The include variables are available to the command, in addition - to the usual set of CGI variables.

    -

    The use of #include virtual is almost always prefered to using - either #exec cgi or #exec cmd. The former - (#include virtual) uses the standard Apache sub-request - mechanism to include files or scripts. It is much better tested and - maintained.

    +
    +
    top
    +

    XBitHack Directive

    + + + + + + + + +
    Description:Parse SSI directives in files with the execute bit +set
    Syntax:XBitHack on|off|full
    Default:XBitHack off
    Context:server config, virtual host, directory, .htaccess
    Override:Options
    Status:Base
    Module:mod_include
    +

    The XBitHack directive controls the parsing + of ordinary html documents. This directive only affects files associated + with the MIME-type text/html. XBitHack can take on the following values:

    -

    In addition, on some platforms, like Win32, and on unix when - using suexec, you cannot pass arguments - to a command in an exec directive, or otherwise include - spaces in the command. Thus, while the following will work under a - non-suexec configuration on unix, it will not produce the desired - result under Win32, or when running suexec:

    +
    +
    off
    +
    No special treatment of executable files.
    -

    - <!--#exec cmd="perl /path/to/perlscript arg1 arg2" --> -

    - -
    - +
    on
    +
    Any text/html file that has the user-execute bit + set will be treated as a server-parsed html document.
    -

    The fsize Element

    -

    This command prints the size of the specified file, subject - to the sizefmt format specification. Attributes:

    +
    full
    +
    As for on but also test the group-execute bit. + If it is set, then set the Last-modified date of the + returned file to be the last modified time of the file. If + it is not set, then no last-modified date is sent. Setting + this bit allows clients and proxies to cache the result of + the request. -
    -
    file
    -
    The value is a path relative to the directory - containing the current document being parsed. +

    Note

    +

    You would not want to use the full option, unless you assure the + group-execute bit is unset for every SSI script which might #include a CGI or otherwise produces different output on + each hit (or could potentially change on subsequent requests).

    -

    - This file is <!--#fsize file="mod_include.html" --> bytes. -

    +

    The SSILastModified + directive takes precedence over the + XBitHack directive when + SSILastModified is set to + on.

    +
    - The value of file cannot start with a slash - (/), nor can it contain ../ so as to - refer to a file above the current directory or outside of the - document root. Attempting to so will result in the error message: - The given path was above the root path.
    +
    -
    virtual
    -
    The value is a (%-encoded) URL-path. If it does not begin with - a slash (/) then it is taken to be relative to the current document. - Note, that this does not print the size of any CGI output, - but the size of the CGI script itself.
    - -

    - This file is <!--#fsize virtual="/docs/mod/mod_include.html" --> bytes. -

    +
    +
    top
    +
    +

    Enabling Server-Side Includes

    + -

    Note that in many cases these two are exactly the same thing. - However, the file attribute doesn't respect URL-space - aliases.

    - +

    Server Side Includes are implemented by the + INCLUDES filter. If + documents containing server-side include directives are given + the extension .shtml, the following directives will make Apache + parse them and assign the resulting document the mime type of + text/html:

    -

    The flastmod Element

    -

    This command prints the last modification date of the - specified file, subject to the timefmt format - specification. The attributes are the same as for the - fsize command.

    - + 
    AddType text/html .shtml
+AddOutputFilter INCLUDES .shtml
    -

    The include Element

    -

    This command inserts the text of another document or file - into the parsed file. Any included file is subject to the usual - access control. If the directory containing the parsed file has - Options - IncludesNOEXEC set, then only documents with a text - MIME-type (text/plain, - text/html etc.) will be included. Otherwise CGI - scripts are invoked as normal using the complete URL given in - the command, including any query string.

    -

    An attribute defines the location of the document, and may - appear more than once in an include element; an inclusion is - done for each attribute given to the include command in turn. - The valid attributes are:

    +

    The following directive must be given for the directories + containing the shtml files (typically in a + <Directory> section, + but this directive is also valid in .htaccess files if + AllowOverride Options + is set):

    -
    -
    file
    -
    The value is a path relative to the directory - containing the current document being parsed. It cannot - contain ../, nor can it be an absolute path. - Therefore, you cannot include files that are outside of the - document root, or above the current document in the directory - structure. The virtual attribute should always be - used in preference to this one.
    + 
    Options +Includes
    -
    virtual
    -

    The value is a (%-encoded) URL-path. The URL cannot contain a - scheme or hostname, only a path and an optional query string. If it - does not begin with a slash (/) then it is taken to be relative to the - current document.

    -

    A URL is constructed from the attribute, and the output the - server would return if the URL were accessed by the client is - included in the parsed output. Thus included files can be nested.

    +

    For backwards compatibility, the server-parsed + handler also activates the + INCLUDES filter. As well, Apache will activate the INCLUDES + filter for any document with mime type + text/x-server-parsed-html or + text/x-server-parsed-html3 (and the resulting + output will have the mime type text/html).

    -

    If the specified URL is a CGI program, the program will be - executed and its output inserted in place of the directive in the - parsed file. You may include a query string in a CGI url:

    +

    For more information, see our Tutorial on Server Side Includes.

    +
    top
    +
    +

    PATH_INFO with Server Side Includes

    + -

    - <!--#include virtual="/cgi-bin/example.cgi?argument=value" --> -

    +

    Files processed for server-side includes no longer accept + requests with PATH_INFO (trailing pathname information) + by default. You can use the AcceptPathInfo directive to + configure the server to accept requests with PATH_INFO.

    +
    top
    +
    +

    Available Elements

    +

    The document is parsed as an HTML document, with special + commands embedded as SGML comments. A command has the syntax:

    -

    include virtual should be used in preference - to exec cgi to include the output of CGI programs - into an HTML document.

    +

    + <!--#element attribute=value + attribute=value ... --> +

    -

    If the KeptBodySize - directive is correctly configured and valid for this included - file, attempts to POST requests to the enclosing HTML document - will be passed through to subrequests as POST requests as well. - Without the directive, all subrequests are processed as GET - requests.

    +

    The value will often be enclosed in double quotes, but single + quotes (') and backticks (`) are also + possible. Many commands only allow a single attribute-value pair. + Note that the comment terminator (-->) should be + preceded by whitespace to ensure that it isn't considered part of + an SSI token. Note that the leading <!--# is one + token and may not contain any whitespaces.

    + +

    The allowed elements are listed in the following table:

    + + + + + + + + + + + + + + + + + + + +
    ElementDescription
    configconfigure output formats
    echoprint variables
    execexecute external programs
    fsizeprint size of a file
    flastmodprint last modification time of a file
    includeinclude a file
    printenvprint all available variables
    setset a value of a variable
    + +

    SSI elements may be defined by modules other than + mod_include. In fact, the exec element is provided by + mod_cgi, and will only be available if this + module is loaded.

    + +

    The config Element

    +

    This command controls various aspects of the parsing. The + valid attributes are:

    + +
    +
    echomsg (Apache 2.1 and later)
    +
    +

    The value is a message that is sent back to the + client if the echo element + attempts to echo an undefined variable. This overrides any SSIUndefinedEcho directives.

    +

    + <!--#config echomsg="[Value Undefined]" --> +

    -
    onerror
    -

    The value is a (%-encoded) URL-path which is shown should a - previous attempt to include a file or virtual attribute failed. - To be effective, this attribute must be specified after the - file or virtual attributes being covered. If the attempt to - include the onerror path fails, or if onerror is not specified, the - default error message will be included.

    +
    errmsg
    +

    The value is a message that is sent back to the + client if an error occurs while parsing the + document. This overrides any SSIErrorMsg directives.

    + +

    + <!--#config errmsg="[Oops, something broke.]" --> +

    +
    + +
    sizefmt
    +

    The value sets the format to be used when displaying + the size of a file. Valid values are bytes + for a count in bytes, or abbrev for a count + in Kb or Mb as appropriate, for example a size of 1024 bytes + will be printed as "1K".

    - # Simple example
    - <!--#include virtual="/not-exist.html" onerror="/error.html" --> + <!--#config sizefmt="abbrev" -->

    +
    +
    timefmt
    +

    The value is a string to be used by the + strftime(3) library routine when printing + dates.

    +

    - # Dedicated onerror paths
    - <!--#include virtual="/path-a.html" onerror="/error-a.html" virtual="/path-b.html" onerror="/error-b.html" --> + <!--#config timefmt=""%R, %B %d, %Y"" -->

    +
    -

    The printenv Element

    -

    This prints out a plain text listing of all existing variables and - their values. Special characters are entity encoded (see the echo element for details) - before being output. There are no attributes.

    - -

    Example

    - <pre> - <!--#printenv --> - </pre> -

    - +

    The echo Element

    +

    This command prints one of the include + variables defined below. If the variable is unset, the result is + determined by the SSIUndefinedEcho directive. Any dates printed are + subject to the currently configured timefmt.

    -

    The set Element

    -

    This sets the value of a variable. Attributes:

    +

    Attributes:

    var
    -
    The name of the variable to set.
    - -
    value
    -
    The value to give a variable.
    +
    The value is the name of the variable to print.
    decoding

    Specifies whether Apache should strip an encoding from the variable before processing the variable further. The default is none, where no decoding will be done. If set to - url, urlencoded, base64 - or entity, URL decoding, - application/x-www-form-urlencoded decoding, base64 decoding or HTML - entity decoding will be performed respectively. More than one - decoding can be specified by separating with commas. The decoding - setting will remain in effect until the next decoding attribute - is encountered, or the element ends. The decoding - attribute must precede the corresponding - var attribute to be effective.

    + url, then URL decoding (also known as %-encoding; + this is appropriate for use within URLs in links, etc.) will be + performed. If set to urlencoded, + application/x-www-form-urlencoded compatible encoding (found in + query strings) will be stripped. If set to base64, + base64 will be decoded, and if set to entity, HTML + entity encoding will be stripped. Decoding is done prior to any + further encoding on the variable. Multiple encodings can be + stripped by specifying more than one comma separated encoding. + The decoding setting will remain in effect until the next decoding + attribute is encountered, or the element ends.

    + +

    The decoding attribute must precede the + corresponding var attribute to be effective.

    encoding

    Specifies how Apache should encode special characters - contained in the variable before setting them. The default is - none, where no encoding will be done. If set to - url, urlencoding, base64 - or entity, URL encoding, - application/x-www-form-urlencoded encoding, base64 encoding or - HTML entity encoding will be performed respectively. More than - one encoding can be specified by separating with commas. The - encoding setting will remain in effect until the next encoding - attribute is encountered, or the element ends. The - encoding attribute must precede the - corresponding var attribute to be effective. - Encodings are applied after all decodings have been - stripped.

    -
    -
    + contained in the variable before outputting them. If set + to none, no encoding will be done. If set to + url, then URL encoding (also known as %-encoding; + this is appropriate for use within URLs in links, etc.) will be + performed. If set to urlencoded, + application/x-www-form-urlencoded compatible encoding will be + performed instead, and should be used with query strings. If set + to base64, base64 encoding will be performed. At + the start of an echo element, the default is set to + entity, resulting in entity encoding (which is + appropriate in the context of a block-level HTML element, + e.g. a paragraph of text). This can be changed by adding + an encoding attribute, which will remain in effect + until the next encoding attribute is encountered or + the element ends, whichever comes first.

    + +

    The encoding attribute must precede the + corresponding var attribute to be effective.

    + +
    + In order to avoid cross-site scripting issues, you should + always encode user supplied data. +

    Example

    - <!--#set var="category" value="help" --> + <!--#echo encoding="entity" var="QUERY_STRING" -->

    + + -
    top
    -
    -

    Include Variables

    - -

    In addition to the variables in the standard CGI environment, - these are available for the echo command, for - if and elif, and to any program - invoked by the document.

    +

    The exec Element

    +

    The exec command executes a given shell command or + CGI script. It requires mod_cgi to be present + in the server. If Options + IncludesNOEXEC is set, this command is completely + disabled. The valid attributes are:

    -
    -
    DATE_GMT
    -
    The current date in Greenwich Mean Time.
    +
    +
    cgi
    +

    The value specifies a (%-encoded) URL-path to + the CGI script. If the path does not begin with a slash (/), + then it is taken to be relative to the current + document. The document referenced by this path is + invoked as a CGI script, even if the server would not + normally recognize it as such. However, the directory + containing the script must be enabled for CGI scripts + (with ScriptAlias + or Options + ExecCGI).

    -
    DATE_LOCAL
    -
    The current date in the local time zone.
    +

    The CGI script is given the PATH_INFO and query + string (QUERY_STRING) of the original request from the + client; these cannot be specified in the URL path. The + include variables will be available to the script in addition to + the standard CGI environment.

    -
    DOCUMENT_NAME
    -
    The filename (excluding directories) of the document - requested by the user.
    +

    Example

    + <!--#exec cgi="/cgi-bin/example.cgi" --> +

    -
    DOCUMENT_URI
    -
    The (%-decoded) URL path of the document requested by the - user. Note that in the case of nested include files, this is - not the URL for the current document. Note also that - if the URL is modified internally (e.g. by an alias or directoryindex), the modified - URL is shown.
    +

    If the script returns a Location: header instead of + output, then this will be translated into an HTML anchor.

    -
    LAST_MODIFIED
    -
    The last modification date of the document requested by - the user.
    +

    The include virtual + element should be used in preference to exec cgi. In + particular, if you need to pass additional arguments to a CGI program, + using the query string, this cannot be done with exec + cgi, but can be done with include virtual, as + shown here:

    -
    QUERY_STRING_UNESCAPED
    -
    If a query string is present, this variable contains the - (%-decoded) query string, which is escaped for shell - usage (special characters like & etc. are - preceded by backslashes).
    -
    -
    top
    -
    -

    Variable Substitution

    +

    + <!--#include virtual="/cgi-bin/example.cgi?argument=value" --> +

    + -

    Variable substitution is done within quoted strings in most - cases where they may reasonably occur as an argument to an SSI - directive. This includes the config, - exec, flastmod, fsize, - include, echo, and set - directives. If SSILegacyExprParser is set to on, - substitution also occurs in the arguments to conditional operators. - You can insert a literal dollar sign into the string using backslash - quoting:

    +
    cmd
    +

    The server will execute the given string using + /bin/sh. The include variables are available to the command, in addition + to the usual set of CGI variables.

    -

    - <!--#set var="cur" value="\$test" --> -

    +

    The use of #include virtual is almost always prefered to using + either #exec cgi or #exec cmd. The former + (#include virtual) uses the standard Apache sub-request + mechanism to include files or scripts. It is much better tested and + maintained.

    -

    If a variable reference needs to be substituted in the - middle of a character sequence that might otherwise be - considered a valid identifier in its own right, it can be - disambiguated by enclosing the reference in braces, - a la shell substitution:

    +

    In addition, on some platforms, like Win32, and on unix when + using suexec, you cannot pass arguments + to a command in an exec directive, or otherwise include + spaces in the command. Thus, while the following will work under a + non-suexec configuration on unix, it will not produce the desired + result under Win32, or when running suexec:

    + +

    + <!--#exec cmd="perl /path/to/perlscript arg1 arg2" --> +

    +
    + + + +

    The fsize Element

    +

    This command prints the size of the specified file, subject + to the sizefmt format specification. Attributes:

    + +
    +
    file
    +
    The value is a path relative to the directory + containing the current document being parsed.

    - <!--#set var="Zed" value="${REMOTE_HOST}_${REQUEST_METHOD}" --> + This file is <!--#fsize file="mod_include.html" --> bytes.

    -

    This will result in the Zed variable being set - to "X_Y" if REMOTE_HOST is - "X" and REQUEST_METHOD is - "Y".

    -
    top
    -
    -

    Flow Control Elements

    - + The value of file cannot start with a slash + (/), nor can it contain ../ so as to + refer to a file above the current directory or outside of the + document root. Attempting to so will result in the error message: + The given path was above the root path. + -

    The basic flow control elements are:

    +
    virtual
    +
    The value is a (%-encoded) URL-path. If it does not begin with + a slash (/) then it is taken to be relative to the current document. + Note, that this does not print the size of any CGI output, + but the size of the CGI script itself.
    +

    - <!--#if expr="test_condition" -->
    - <!--#elif expr="test_condition" -->
    - <!--#else -->
    - <!--#endif --> + This file is <!--#fsize virtual="/docs/mod/mod_include.html" --> bytes.

    -

    The if element works like an if statement in a - programming language. The test condition is evaluated and if - the result is true, then the text until the next elif, - else or endif element is included in the - output stream.

    +

    Note that in many cases these two are exactly the same thing. + However, the file attribute doesn't respect URL-space + aliases.

    + -

    The elif or else statements are used - to put text into the output stream if the original - test_condition was false. These elements are optional.

    +

    The flastmod Element

    +

    This command prints the last modification date of the + specified file, subject to the timefmt format + specification. The attributes are the same as for the + fsize command.

    + -

    The endif element ends the if element - and is required.

    +

    The include Element

    +

    This command inserts the text of another document or file + into the parsed file. Any included file is subject to the usual + access control. If the directory containing the parsed file has + Options + IncludesNOEXEC set, then only documents with a text + MIME-type (text/plain, + text/html etc.) will be included. Otherwise CGI + scripts are invoked as normal using the complete URL given in + the command, including any query string.

    -

    test_condition is a boolean expression which follows the - ap_expr syntax. The syntax can be changed - to be compatible with Apache HTTPD 2.2.x using SSILegacyExprParser.

    +

    An attribute defines the location of the document, and may + appear more than once in an include element; an inclusion is + done for each attribute given to the include command in turn. + The valid attributes are:

    -

    The SSI variables set with the var element are exported - into the request environment and can be accessed with the - reqenv function. As a short-cut, the function name - v is also available inside mod_include.

    +
    +
    file
    +
    The value is a path relative to the directory + containing the current document being parsed. It cannot + contain ../, nor can it be an absolute path. + Therefore, you cannot include files that are outside of the + document root, or above the current document in the directory + structure. The virtual attribute should always be + used in preference to this one.
    -

    The below example will print "from local net" if client IP address - belongs to the 10.0.0.0/8 subnet.

    +
    virtual
    +

    The value is a (%-encoded) URL-path. The URL cannot contain a + scheme or hostname, only a path and an optional query string. If it + does not begin with a slash (/) then it is taken to be relative to the + current document.

    -

    - <!--#if expr='-R "10.0.0.0/8"' -->
    - - from local net
    -     - <!--#else -->
    - - from somewhere else
    -     - <!--#endif --> -

    +

    A URL is constructed from the attribute, and the output the + server would return if the URL were accessed by the client is + included in the parsed output. Thus included files can be nested.

    -

    The below example will print "foo is bar" if the variable - foo is set to the value "bar".

    +

    If the specified URL is a CGI program, the program will be + executed and its output inserted in place of the directive in the + parsed file. You may include a query string in a CGI url:

    -

    - <!--#if expr='v("foo") = "bar"' -->
    - - foo is bar
    -     - <!--#endif --> -

    +

    + <!--#include virtual="/cgi-bin/example.cgi?argument=value" --> +

    -

    Reference Documentation

    -

    See also: Expressions in Apache HTTP Server, - for a complete reference and examples. The restricted functions - are not available inside mod_include

    -
    -
    top
    -
    -

    Legacy expression syntax

    - +

    include virtual should be used in preference + to exec cgi to include the output of CGI programs + into an HTML document.

    -

    This section describes the syntax of the #if expr - element if SSILegacyExprParser - is set to on.

    +

    If the KeptBodySize + directive is correctly configured and valid for this included + file, attempts to POST requests to the enclosing HTML document + will be passed through to subrequests as POST requests as well. + Without the directive, all subrequests are processed as GET + requests.

    -
    -
    string
    -
    true if string is not empty
    + -
    -A string
    -

    true if the URL represented by the string is accessible by - configuration, false otherwise. This is useful where content on a - page is to be hidden from users who are not authorized to view the - URL, such as a link to that URL. Note that the URL is only tested - for whether access would be granted, not whether the URL exists.

    +
    onerror
    +

    The value is a (%-encoded) URL-path which is shown should a + previous attempt to include a file or virtual attribute failed. + To be effective, this attribute must be specified after the + file or virtual attributes being covered. If the attempt to + include the onerror path fails, or if onerror is not specified, the + default error message will be included.

    -

    Example

    - <!--#if expr="-A /private" -->
    - - Click <a href="/private">here</a> to access private - information.
    -     - <!--#endif --> +

    + # Simple example
    + <!--#include virtual="/not-exist.html" onerror="/error.html" -->

    -
    -
    string1 = string2
    - string1 == string2
    - string1 != string2
    +

    + # Dedicated onerror paths
    + <!--#include virtual="/path-a.html" onerror="/error-a.html" virtual="/path-b.html" onerror="/error-b.html" --> +

    -

    Compare string1 with string2. If - string2 has the form /string2/ - then it is treated as a regular expression. Regular expressions are - implemented by the PCRE engine and - have the same syntax as those in perl - 5. Note that == is just an alias for = - and behaves exactly the same way.

    +
    +
    + -

    If you are matching positive (= or ==), you - can capture grouped parts of the regular expression. The captured parts - are stored in the special variables $1 .. - $9. The whole string matched by the regular expression is - stored in the special variable $0

    +

    The printenv Element

    +

    This prints out a plain text listing of all existing variables and + their values. Special characters are entity encoded (see the echo element for details) + before being output. There are no attributes.

    Example

    - <!--#if expr="$QUERY_STRING = /^sid=([a-zA-Z0-9]+)/" -->
    - - <!--#set var="session" value="$1" -->
    -     - <!--#endif --> + <pre> + <!--#printenv --> + </pre>

    - - -
    string1 < string2
    - string1 <= string2
    - string1 > string2
    - string1 >= string2
    - -
    Compare string1 with string2. Note, that - strings are compared literally (using - strcmp(3)). Therefore the string "100" is less than - "20".
    - -
    ( test_condition )
    -
    true if test_condition is true
    - -
    ! test_condition
    -
    true if test_condition is false
    - -
    test_condition1 && - test_condition2
    -
    true if both test_condition1 and - test_condition2 are true
    - -
    test_condition1 || - test_condition2
    -
    true if either test_condition1 or - test_condition2 is true
    - - -

    "=" and "!=" bind more tightly than - "&&" and "||". "!" binds - most tightly. Thus, the following are equivalent:

    + -

    - <!--#if expr="$a = test1 && $b = test2" -->
    - <!--#if expr="($a = test1) && ($b = test2)" --> -

    +

    The set Element

    +

    This sets the value of a variable. Attributes:

    -

    The boolean operators && and || - share the same priority. So if you want to bind such an operator more - tightly, you should use parentheses.

    +
    +
    var
    +
    The name of the variable to set.
    -

    Anything that's not recognized as a variable or an operator - is treated as a string. Strings can also be quoted: - 'string'. Unquoted strings can't contain whitespace - (blanks and tabs) because it is used to separate tokens such as - variables. If multiple strings are found in a row, they are - concatenated using blanks. So,

    +
    value
    +
    The value to give a variable.
    -

    string1    string2 results in string1 string2
    -
    - and
    -
    - 'string1    string2' results in string1    string2.

    +
    decoding
    +

    Specifies whether Apache should strip an encoding from + the variable before processing the variable further. The default + is none, where no decoding will be done. If set to + url, urlencoded, base64 + or entity, URL decoding, + application/x-www-form-urlencoded decoding, base64 decoding or HTML + entity decoding will be performed respectively. More than one + decoding can be specified by separating with commas. The decoding + setting will remain in effect until the next decoding attribute + is encountered, or the element ends. The decoding + attribute must precede the corresponding + var attribute to be effective.

    +
    -

    Optimization of Boolean Expressions

    -

    If the expressions become more complex and slow down processing - significantly, you can try to optimize them according to the - evaluation rules:

    -
      -
    • Expressions are evaluated from left to right
      • -
    • Binary boolean operators (&& and ||) - are short circuited wherever possible. In conclusion with the rule - above that means, mod_include evaluates at first - the left expression. If the left result is sufficient to determine - the end result, processing stops here. Otherwise it evaluates the - right side and computes the end result from both left and right - results.
      • -
    • Short circuit evaluation is turned off as long as there are regular - expressions to deal with. These must be evaluated to fill in the - backreference variables ($1 .. $9).
      • -
    -

    If you want to look how a particular expression is handled, you can - recompile mod_include using the - -DDEBUG_INCLUDE compiler option. This inserts for every - parsed expression tokenizer information, the parse tree and how it is - evaluated into the output sent to the client.

    -
    +
    encoding
    +

    Specifies how Apache should encode special characters + contained in the variable before setting them. The default is + none, where no encoding will be done. If set to + url, urlencoding, base64 + or entity, URL encoding, + application/x-www-form-urlencoded encoding, base64 encoding or + HTML entity encoding will be performed respectively. More than + one encoding can be specified by separating with commas. The + encoding setting will remain in effect until the next encoding + attribute is encountered, or the element ends. The + encoding attribute must precede the + corresponding var attribute to be effective. + Encodings are applied after all decodings have been + stripped.

    +
    +
    -

    Escaping slashes in regex strings

    -

    All slashes which are not intended to act as delimiters in your regex must - be escaped. This is regardless of their meaning to the regex engine.

    -
    +

    Example

    + <!--#set var="category" value="help" --> +

    + +
    top
    +
    +

    Include Variables

    + -
    -
    top
    -

    SSIEndTag Directive

    - - - - - - - -
    Description:String that ends an include element
    Syntax:SSIEndTag tag
    Default:SSIEndTag "-->"
    Context:server config, virtual host
    Status:Base
    Module:mod_include
    -

    This directive changes the string that mod_include - looks for to mark the end of an include element.

    +

    In addition to the variables in the standard CGI environment, + these are available for the echo command, for + if and elif, and to any program + invoked by the document.

    - 
    SSIEndTag "%>"
    +
    +
    DATE_GMT
    +
    The current date in Greenwich Mean Time.
    +
    DATE_LOCAL
    +
    The current date in the local time zone.
    +
    DOCUMENT_NAME
    +
    The filename (excluding directories) of the document + requested by the user.
    -

    See also

    - -
    -
    top
    -

    SSIErrorMsg Directive

    - - - - - - - - -
    Description:Error message displayed when there is an SSI -error
    Syntax:SSIErrorMsg message
    Default:SSIErrorMsg "[an error occurred while processing this -directive]"
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Base
    Module:mod_include
    -

    The SSIErrorMsg directive changes the error - message displayed when mod_include encounters an - error. For production servers you may consider changing the default - error message to "<!-- Error -->" so that - the message is not presented to the user.

    +
    DOCUMENT_URI
    +
    The (%-decoded) URL path of the document requested by the + user. Note that in the case of nested include files, this is + not the URL for the current document. Note also that + if the URL is modified internally (e.g. by an alias or directoryindex), the modified + URL is shown.
    -

    This directive has the same effect as the <!--#config - errmsg=message --> element.

    +
    LAST_MODIFIED
    +
    The last modification date of the document requested by + the user.
    - 
    SSIErrorMsg "<!-- Error -->"
    +
    QUERY_STRING_UNESCAPED
    +
    If a query string is present, this variable contains the + (%-decoded) query string, which is escaped for shell + usage (special characters like & etc. are + preceded by backslashes).
    + +
    top
    +
    +

    Variable Substitution

    +

    Variable substitution is done within quoted strings in most + cases where they may reasonably occur as an argument to an SSI + directive. This includes the config, + exec, flastmod, fsize, + include, echo, and set + directives. If SSILegacyExprParser is set to on, + substitution also occurs in the arguments to conditional operators. + You can insert a literal dollar sign into the string using backslash + quoting:

    -
    -
    top
    -

    SSIETag Directive

    - - - - - - - - -
    Description:Controls whether ETags are generated by the server.
    Syntax:SSIETag on|off
    Default:SSIETag off
    Context:directory, .htaccess
    Status:Base
    Module:mod_include
    Compatibility:Available in version 2.2.15 and later.
    -

    Under normal circumstances, a file filtered by mod_include - may contain elements that are either dynamically generated, or that may - have changed independently of the original file. As a result, by default - the server is asked not to generate an ETag header for the - response by adding no-etag to the request notes.

    +

    + <!--#set var="cur" value="\$test" --> +

    -

    The SSIETag directive suppresses this - behaviour, and allows the server to generate an ETag header. - This can be used to enable caching of the output. Note that a backend server - or dynamic content generator may generate an ETag of its own, ignoring - no-etag, and this ETag will be passed by - mod_include regardless of the value of this setting. - SSIETag can take on the following values:

    +

    If a variable reference needs to be substituted in the + middle of a character sequence that might otherwise be + considered a valid identifier in its own right, it can be + disambiguated by enclosing the reference in braces, + a la shell substitution:

    -
    +

    + <!--#set var="Zed" value="${REMOTE_HOST}_${REQUEST_METHOD}" --> +

    -
    off
    -
    no-etag will be added to the request notes, and the server - is asked not to generate an ETag. Where a server ignores the value of - no-etag and generates an ETag anyway, the ETag will be - respected.
    +

    This will result in the Zed variable being set + to "X_Y" if REMOTE_HOST is + "X" and REQUEST_METHOD is + "Y".

    +
    top
    +
    +

    Flow Control Elements

    + -
    on
    -
    Existing ETags will be respected, and ETags generated by the server will - be passed on in the response.
    +

    The basic flow control elements are:

    - +

    + <!--#if expr="test_condition" -->
    + <!--#elif expr="test_condition" -->
    + <!--#else -->
    + <!--#endif --> +

    +

    The if element works like an if statement in a + programming language. The test condition is evaluated and if + the result is true, then the text until the next elif, + else or endif element is included in the + output stream.

    -
    -
    top
    -

    SSILastModified Directive

    - - - - - - - - -
    Description:Controls whether Last-Modified headers are generated by the -server.
    Syntax:SSILastModified on|off
    Default:SSILastModified off
    Context:directory, .htaccess
    Status:Base
    Module:mod_include
    Compatibility:Available in version 2.2.15 and later.
    -

    Under normal circumstances, a file filtered by mod_include - may contain elements that are either dynamically generated, or that may - have changed independently of the original file. As a result, by default - the Last-Modified header is stripped from the response.

    +

    The elif or else statements are used + to put text into the output stream if the original + test_condition was false. These elements are optional.

    -

    The SSILastModified directive overrides this - behaviour, and allows the Last-Modified header to be respected - if already present, or set if the header is not already present. This can - be used to enable caching of the output. SSILastModified - can take on the following values:

    +

    The endif element ends the if element + and is required.

    -
    +

    test_condition is a boolean expression which follows the + ap_expr syntax. The syntax can be changed + to be compatible with Apache HTTPD 2.2.x using SSILegacyExprParser.

    -
    off
    -
    The Last-Modified header will be stripped from responses, - unless the XBitHack directive - is set to full as described below.
    +

    The SSI variables set with the var element are exported + into the request environment and can be accessed with the + reqenv function. As a short-cut, the function name + v is also available inside mod_include.

    -
    on
    -
    The Last-Modified header will be respected if already - present in a response, and added to the response if the response is a - file and the header is missing. The - SSILastModified directive - takes precedence over XBitHack.
    +

    The below example will print "from local net" if client IP address + belongs to the 10.0.0.0/8 subnet.

    -
    +

    + <!--#if expr='-R "10.0.0.0/8"' -->
    + + from local net
    +     + <!--#else -->
    + + from somewhere else
    +     + <!--#endif --> +

    +

    The below example will print "foo is bar" if the variable + foo is set to the value "bar".

    -
    -
    top
    -

    SSILegacyExprParser Directive

    - - - - - - - - -
    Description:Enable compatibility mode for conditional expressions.
    Syntax:SSILegacyExprParser on|off
    Default:SSILegacyExprParser off
    Context:directory, .htaccess
    Status:Base
    Module:mod_include
    Compatibility:Available in version 2.3.13 and later.
    -

    As of version 2.3.13, mod_include has switched to the - new ap_expr syntax for conditional expressions - in #if flow control elements. This directive allows to - switch to the old syntax which is compatible - with Apache HTTPD version 2.2.x and earlier. -

    +

    + <!--#if expr='v("foo") = "bar"' -->
    + + foo is bar
    +     + <!--#endif --> +

    -
    -
    top
    -

    SSIStartTag Directive

    - - - - - - - -
    Description:String that starts an include element
    Syntax:SSIStartTag tag
    Default:SSIStartTag "<!--#"
    Context:server config, virtual host
    Status:Base
    Module:mod_include
    -

    This directive changes the string that mod_include - looks for to mark an include element to process.

    +

    Reference Documentation

    +

    See also: Expressions in Apache HTTP Server, + for a complete reference and examples. The restricted functions + are not available inside mod_include

    +
    +
    top
    +
    +

    Legacy expression syntax

    + -

    You may want to use this option if you have 2 servers parsing the - output of a file each processing different commands (possibly at - different times).

    +

    This section describes the syntax of the #if expr + element if SSILegacyExprParser + is set to on.

    - 
          SSIStartTag "<%"
    
-      SSIEndTag   "%>"
    +
    +
    string
    +
    true if string is not empty
    +
    -A string
    +

    true if the URL represented by the string is accessible by + configuration, false otherwise. This is useful where content on a + page is to be hidden from users who are not authorized to view the + URL, such as a link to that URL. Note that the URL is only tested + for whether access would be granted, not whether the URL exists.

    -

    The example given above, which also specifies a matching - SSIEndTag, will - allow you to use SSI directives as shown in the example - below:

    +

    Example

    + <!--#if expr="-A /private" -->
    + + Click <a href="/private">here</a> to access private + information.
    +     + <!--#endif --> +

    +
    -

    SSI directives with alternate start and end tags

    - <%printenv %> -

    +
    string1 = string2
    + string1 == string2
    + string1 != string2
    -

    See also

    - -
    -
    top
    -

    SSITimeFormat Directive

    - - - - - - - - -
    Description:Configures the format in which date strings are -displayed
    Syntax:SSITimeFormat formatstring
    Default:SSITimeFormat "%A, %d-%b-%Y %H:%M:%S %Z"
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Base
    Module:mod_include
    -

    This directive changes the format in which date strings are displayed - when echoing DATE environment variables. The - formatstring is as in strftime(3) from the - C standard library.

    +

    Compare string1 with string2. If + string2 has the form /string2/ + then it is treated as a regular expression. Regular expressions are + implemented by the PCRE engine and + have the same syntax as those in perl + 5. Note that == is just an alias for = + and behaves exactly the same way.

    -

    This directive has the same effect as the <!--#config - timefmt=formatstring --> element.

    +

    If you are matching positive (= or ==), you + can capture grouped parts of the regular expression. The captured parts + are stored in the special variables $1 .. + $9. The whole string matched by the regular expression is + stored in the special variable $0

    - 
    SSITimeFormat "%R, %B %d, %Y"
    +

    Example

    + <!--#if expr="$QUERY_STRING = /^sid=([a-zA-Z0-9]+)/" -->
    + + <!--#set var="session" value="$1" -->
    +     + <!--#endif --> +

    +
    +
    string1 < string2
    + string1 <= string2
    + string1 > string2
    + string1 >= string2
    -

    The above directive would cause times to be displayed in the - format "22:26, June 14, 2002".

    +
    Compare string1 with string2. Note, that + strings are compared literally (using + strcmp(3)). Therefore the string "100" is less than + "20".
    -
    -
    top
    -

    SSIUndefinedEcho Directive

    - - - - - - - - -
    Description:String displayed when an unset variable is echoed
    Syntax:SSIUndefinedEcho string
    Default:SSIUndefinedEcho "(none)"
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Base
    Module:mod_include
    -

    This directive changes the string that mod_include - displays when a variable is not set and "echoed".

    +
    ( test_condition )
    +
    true if test_condition is true
    - 
    SSIUndefinedEcho "<!-- undef -->"
    +
    ! test_condition
    +
    true if test_condition is false
    +
    test_condition1 && + test_condition2
    +
    true if both test_condition1 and + test_condition2 are true
    -
    -
    top
    -

    XBitHack Directive

    - - - - - - - - -
    Description:Parse SSI directives in files with the execute bit -set
    Syntax:XBitHack on|off|full
    Default:XBitHack off
    Context:server config, virtual host, directory, .htaccess
    Override:Options
    Status:Base
    Module:mod_include
    -

    The XBitHack directive controls the parsing - of ordinary html documents. This directive only affects files associated - with the MIME-type text/html. XBitHack can take on the following values:

    +
    test_condition1 || + test_condition2
    +
    true if either test_condition1 or + test_condition2 is true
    + -
    -
    off
    -
    No special treatment of executable files.
    +

    "=" and "!=" bind more tightly than + "&&" and "||". "!" binds + most tightly. Thus, the following are equivalent:

    -
    on
    -
    Any text/html file that has the user-execute bit - set will be treated as a server-parsed html document.
    +

    + <!--#if expr="$a = test1 && $b = test2" -->
    + <!--#if expr="($a = test1) && ($b = test2)" --> +

    -
    full
    -
    As for on but also test the group-execute bit. - If it is set, then set the Last-modified date of the - returned file to be the last modified time of the file. If - it is not set, then no last-modified date is sent. Setting - this bit allows clients and proxies to cache the result of - the request. +

    The boolean operators && and || + share the same priority. So if you want to bind such an operator more + tightly, you should use parentheses.

    -

    Note

    -

    You would not want to use the full option, unless you assure the - group-execute bit is unset for every SSI script which might #include a CGI or otherwise produces different output on - each hit (or could potentially change on subsequent requests).

    +

    Anything that's not recognized as a variable or an operator + is treated as a string. Strings can also be quoted: + 'string'. Unquoted strings can't contain whitespace + (blanks and tabs) because it is used to separate tokens such as + variables. If multiple strings are found in a row, they are + concatenated using blanks. So,

    -

    The SSILastModified - directive takes precedence over the - XBitHack directive when - SSILastModified is set to - on.

    -
    +

    string1    string2 results in string1 string2
    +
    + and
    +
    + 'string1    string2' results in string1    string2.

    -
    -
    +

    Optimization of Boolean Expressions

    +

    If the expressions become more complex and slow down processing + significantly, you can try to optimize them according to the + evaluation rules:

    +
      +
    • Expressions are evaluated from left to right
      • +
    • Binary boolean operators (&& and ||) + are short circuited wherever possible. In conclusion with the rule + above that means, mod_include evaluates at first + the left expression. If the left result is sufficient to determine + the end result, processing stops here. Otherwise it evaluates the + right side and computes the end result from both left and right + results.
      • +
    • Short circuit evaluation is turned off as long as there are regular + expressions to deal with. These must be evaluated to fill in the + backreference variables ($1 .. $9).
      • +
    +

    If you want to look how a particular expression is handled, you can + recompile mod_include using the + -DDEBUG_INCLUDE compiler option. This inserts for every + parsed expression tokenizer information, the parse tree and how it is + evaluated into the output sent to the client.

    +
    +

    Escaping slashes in regex strings

    +

    All slashes which are not intended to act as delimiters in your regex must + be escaped. This is regardless of their meaning to the regex engine.

    +
    diff --git a/docs/manual/mod/mod_include.html.fr b/docs/manual/mod/mod_include.html.fr index 712416d0310..31379ca0736 100644 --- a/docs/manual/mod/mod_include.html.fr +++ b/docs/manual/mod/mod_include.html.fr @@ -72,1092 +72,1092 @@ Includes ou SSI)
  • Tutoriel SSI
    • top
    -
    -

    Activation des SSI

    - - -

    Les SSI sont implémentés par le filtre INCLUDES. Si des - documents contenant des directives SSI possèdent une extension - .shtml, les directives suivantes indiqueront à Apache de les - interpréter et d'assigner le type MIME - text/html au document obtenu :

    - - 
    AddType text/html .shtml
-AddOutputFilter INCLUDES .shtml
    - - -

    L'option suivante doit être définie pour les répertoires qui - contiennent les fichiers shtml (en général dans une section - <Directory>, mais - cette option peut également être définie dans un fichier - .htaccess si AllowOverride Options a été défini pour le - répertoire considéré) :

    - - 
    Options +Includes
    - +

    Directive SSIEndTag

    + + + + + + + +
    Description:Chaîne qui termine l'élément include
    Syntaxe:SSIEndTag tag
    Défaut:SSIEndTag "-->"
    Contexte:configuration du serveur, serveur virtuel
    Statut:Base
    Module:mod_include
    +

    Cette directive permet de modifier la chaîne que + mod_include interprète comme la fin d'un élément + include.

    -

    Pour des raisons de compatibilité ascendante, le gestionnaire server-parsed - peut aussi activer le filtre INCLUDES. Ainsi, Apache va activer le - filtre INCLUDES pour tout document de type MIME - text/x-server-parsed-html ou - text/x-server-parsed-html3 (et le document obtenu aura - pour type MIME text/html).

    + 
    SSIEndTag "%>"
    -

    Pour plus d'informations, voyez notre Tutoriel SSI.

    -
    top
    -
    -

    PATH_INFO et SSI

    - -

    Les fichiers traités dans le cadre des SSI n'acceptent plus par - défaut les requêtes avec PATH_INFO (les informations - relatives au chemin en fin de requête). La directive AcceptPathInfo permet de configurer le - serveur de façon à ce qu'il accepte ce genre de requête.

    -
    top
    -
    -

    Eléments disponibles

    -

    Le document est interprété comme un document HTML, avec des - commandes spéciales incluses sous forme de commentaires SGML. La - syntaxe d'une commande est la suivante :

    -

    - <!--#élément attribut=valeur - attribut=valeur ... --> -

    +

    Voir aussi

    + +
    +
    top
    +

    Directive SSIErrorMsg

    + + + + + + + + +
    Description:Message d'erreur affiché lorsqu'une erreur SSI +survient
    Syntaxe:SSIErrorMsg message
    Défaut:SSIErrorMsg "[an error occurred while processing this +directive]"
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Base
    Module:mod_include
    +

    La directive SSIErrorMsg permet de + modifier le message d'erreur affiché lorsqu'une erreur SSI survient. + Pour les serveurs en production, il est recommandé de modifier le + message d'erreur par défaut en "<!-- Error + -->", de façon à ce que le message ne soit pas + présenté à l'utilisateur.

    -

    Les valeurs sont souvent entourées de guillemets, mais on peut - aussi utiliser des apostrophes (') ou des apostrophes - inverses (`). De nombreuses commandes n'acceptent - qu'une seule paire attribut-valeur. Notez que le terminateur de - commentaire (-->) doit être précédé d'un espace afin - d'être sûr qu'il ne soit pas considéré comme un élément de commande - SSI. Notez aussi que le délimiteur de début <!--# - est un élément de commande et ne doit donc pas contenir - d'espace.

    +

    Cette directive a le même effet que l'élément + <!--#config errmsg=message -->.

    -

    La table suivante contient la liste des éléments autorisés :

    + 
    SSIErrorMsg "<!-- Error -->"
    - - - - - - - - - - - - - - - - - - -
    ElémentDescription
    configconfigure les formats de sortie
    echoaffiche le contenu de variables
    execexécute des programmes externes
    fsizeaffiche la taille d'un fichier
    flastmodaffiche la date de dernière modification d'un fichier
    includeinclut un fichier
    printenvaffiche toutes les variables disponibles
    setdéfinit la valeur d'une variable
    -

    Les éléments SSI peuvent être définis par d'autres modules que - mod_include. À ce titre, l'élément exec est fourni par - mod_cgi, et ne sera disponible que si ce module est - chargé.

    +
    +
    top
    +

    Directive SSIETag

    + + + + + + + + +
    Description:Définit si des en-têtes ETags sont générés par le serveur.
    Syntaxe:SSIETag on|off
    Défaut:SSIETag off
    Contexte:répertoire, .htaccess
    Statut:Base
    Module:mod_include
    Compatibilité:Disponible à partir de la version 2.2.15 du serveur HTTP +Apache.
    +

    Dans le cas général, un fichier filtré par + mod_include peut contenir des éléments soit + générés dynamiquement, soit éventuellement modifiés indépendemment + du fichier original. En conséquence, il est demandé par défaut au + serveur de ne pas générer d'en-tête ETag à la réponse + en ajoutant no-etag aux informations de requête.

    -

    L'élément config

    -

    Cette commande contrôle divers aspects de l'interprétation. Les - attributs valides sont :

    +

    Ce comportement peut être modifié via la directive + SSIETag qui permet au serveur de générer un + en-tête ETag. On peut aussi l'utiliser pour la mise + en cache de la sortie. Notez qu'un serveur d'arrière-plan ou un + générateur de contenu dynamique peut lui-même générer un en-tête + ETag, en ignorant l'information no-etag, + cet en-tête ETag étant transmis par + mod_include sans tenir compte de la définition de + la présente directive. La directive SSIETag + peut prendre une des valeurs suivantes :

    -
    echomsg (Versions 2.1 et supérieures - d'Apache)
    -

    La valeur est un message qui sera envoyé au client si - l'élément echo tente - d'afficher le contenu d'une variable non définie. Cet attribut - l'emporte sur toute directive SSIUndefinedEcho.

    - -

    - <!--#config echomsg="[Valeur non définie]" --> -

    -
    -
    errmsg
    -

    La valeur est un message qui sera envoyé au client si une - erreur survient lors de l'interprétation du document. Cet attribut - l'emporte sur toute directive SSIErrorMsg.

    +
    off
    +
    no-etag sera ajouté aux informations de + requête, et il sera demandé au serveur de ne pas générer + d'en-tête ETag. Lorsqu'un serveur ignore la valeur + de no-etag et génère tout de même un en-tête + ETag, ce dernier sera respecté.
    -

    - <!--#config errmsg="[Zut, quelque chose s'est mal passé.]" --> -

    - +
    on
    +
    Les en-têtes ETag existants seront respectés, + et ceux générés par le serveur seront ajoutés à la réponse.
    -
    sizefmt
    -

    La valeur définit l'unité employée lors de l'affichage de la - taille d'un fichier. Les valeurs possibles sont bytes - pour une taille en octets, ou abbrev pour une taille - en Ko ou Mo selon son importance ; par exemple, une taille de 1024 - octets sera affichée sous la forme "1K".

    +
    -

    - <!--#config sizefmt="abbrev" --> -

    - +
    +
    top
    +

    Directive SSILastModified

    + + + + + + + + +
    Description:Définit si des en-têtes Last-Modified sont +générés par le serveur.
    Syntaxe:SSILastModified on|off
    Défaut:SSILastModified off
    Contexte:répertoire, .htaccess
    Statut:Base
    Module:mod_include
    Compatibilité:Disponible à partir de la version 2.2.15 du serveur HTTP +Apache.
    +

    Dans le cas général, un fichier filtré par + mod_include peut contenir des éléments soit + générés dynamiquement, soit éventuellement modifiés indépendemment + du fichier original. En conséquence, l'en-tête + Last-Modified est supprimé par défaut de la réponse.

    -
    timefmt
    -

    La valeur est une chaîne que pourra utiliser la fonction de la - bibliothèque standard strftime(3) lors de l'affichage - des dates.

    +

    La directive SSILastModified permet de + modifier ce comportement en faisant en sorte que l'en-tête + Last-Modified soit respecté s'il est déjà présent, ou + défini dans le cas contraire. On peut aussi l'utiliser pour la mise + en cache de la sortie. La directive + SSILastModified peut prendre une des + valeurs suivantes :

    -

    - <!--#config timefmt=""%R, %B %d, %Y"" --> -

    +
    -
    - - +
    off
    +
    L'en-tête Last-Modified sera supprimé des + réponses, à moins que la directive XBitHack ne soit définie à + full comme décrit plus loin.
    -

    L'élément echo

    -

    Cette commande affiche le contenu d'une des variables include définies ci-dessous. Si - la variable n'est pas définie, le résultat est déterminé par la - valeur de la directive SSIUndefinedEcho. Le format d'affichage des dates est - défini par l'attribut timefmt de la commande - config.

    +
    on
    +
    L'en-tête Last-Modified sera respecté s'il est + déjà présent, et ajouté à la réponse si cette dernière est un + fichier et si l'en-tête est manquant. La directive SSILastModified l'emporte sur + la directive XBitHack.
    -

    Attributs:

    + -
    -
    var
    -
    La valeur est le nom de la variable à afficher.
    -
    decoding
    -

    Spécifie si Apache doit effectuer un décodage dans la - variable avant son traitement ultérieur. La valeur par défaut est - none, et dans ce cas, aucun décodage n'est effectué. - Si la valeur est url, un décodage de type URL sera - effectué (il s'agit du codage de type %-encoding utilisé dans les - URLs des liens, etc...). Si la valeur est urlencoded, - c'est un décodage des éléments de type - application/x-www-form-urlencode (que l'on trouve dans les chaînes - de paramètres) qui sera effectué. Si la valeur est - base64, un - decodage de type base64 sera effectué, et si elle est - entity, c'est un décodage des entités HTML qui sera - effectué. Ce décodage est effectué avant tout codage ultérieur de - la variable. Il est possible d'effectuer plusieurs décodages en - spécifiant plusieurs valeurs séparées par des virgules. Les - spécifications de décodages restent valables jusqu'au prochain - attribut de décodage, ou la fin de l'élément.

    +
    +
    top
    +

    Directive SSILegacyExprParser

    + + + + + + + + +
    Description:Active le mode de compatibilité pour les expressions +conditionnelles.
    Syntaxe:SSILegacyExprParser on|off
    Défaut:SSILegacyExprParser off
    Contexte:répertoire, .htaccess
    Statut:Base
    Module:mod_include
    Compatibilité:Disponible à partir de la version 2.3.13.
    +

    Depuis la version 2.3.13, mod_include a adopté + la nouvelle syntaxe ap_expr pour ses + expressions conditionnelles dans les éléments de contrôle de flux + #if. Cette directive permet de réactiver l'ancienne syntaxe qui est compatible avec les + versions 2.2.x et antérieures d'Apache HTTPD. +

    -

    Pour être pris en compte, l'attribut de décodage - doit précéder l'attribut var correspondant.

    - +
    +
    top
    +

    Directive SSIStartTag

    + + + + + + + +
    Description:Chaîne qui marque le début d'un élément +include
    Syntaxe:SSIStartTag tag
    Défaut:SSIStartTag "<!--#"
    Contexte:configuration du serveur, serveur virtuel
    Statut:Base
    Module:mod_include
    +

    Cette directive permet de modifier la chaîne que + mod_include interprète comme le début d'un élément + include.

    -
    encoding
    -

    Spécifie la manière dont Apache va coder les caractères - spéciaux que la variable contient avant leur affichage. S'il est - défini à none, aucun codage ne sera effectué. S'il - est défini à url, un codage de type URL sera effectué - (aussi connu sous le nom de codage avec caractères % , il convient - pour les URLS des liens, etc...). S'il est défini à - urlencoded, c'est un codage compatible - application/x-www-form-urlencoded qui sera effectué (à utiliser - dans les chaînes de paramètres). S'il est défini à - base64, c'est un encodage de type base64 qui sera - effectué. Au début d'un élément - echo, la valeur par défaut est définie à - entity, ce qui correspond à un codage de type entité - (codage qui convient pour un élément HTML de type bloc, comme le - paragraphe d'un texte). Cette valeur par défaut peut être modifiée - en ajoutant un attribut encoding, qui fera effet - jusqu'à la définition d'un nouvel attribut encoding - ou la fin de l'élément echo.

    +

    Cette option peut vous être utile si vous avez deux serveurs qui + interprètent un fichier avec des commandes différentes (et + éventuellement à des moments différents).

    -

    Pour produire son effet, l'attribut encoding doit - précéder l'attribut var concerné.

    + 
          SSIStartTag "<%"
    
+      SSIEndTag   "%>"
    -
    - Afin de prévenir les attaques de type cross-site scripting, il - est recommandé de toujours encoder les données fournies - par les utilisateurs. -
    -

    Example

    - <!--#echo encoding="entity" var="QUERY_STRING" --> -

    -
    - - +

    Avec l'exemple ci-dessus, qui définit aussi une directive + SSIEndTag, vous pourrez + inscrire des directives SSI comme dans l'exemple suivant :

    -

    L'élément exec

    -

    La commande exec exécute la commande shell ou le - script spécifié. Elle nécessite le chargement du module - mod_cgi. Si Options IncludesNOEXEC est - définie, cette commande est désactivée. Les attributs disponibles - sont :

    +

    Directives SSI avec marques de début et de fin + personnalisées

    + <%printenv %> +

    -
    -
    cgi
    -

    La valeur spécifie un chemin URL vers le script CGI (encodé - avec caractères %). Si le chemin ne commence pas par un slash (/), - il est considéré comme relatif au document courant. Le document - référencé par ce chemin est invoqué en tant que script CGI, même - s'il n'est pas censé être reconnu comme tel par le serveur. Les - scripts CGI doivent cependant être activés dans le répertoire qui - contient les scripts (via la directive ScriptAlias ou l'Options ExecCGI).

    +

    Voir aussi

    + +
    +
    top
    +

    Directive SSITimeFormat

    + + + + + + + + +
    Description:Configuration du format d'affichage des dates
    Syntaxe:SSITimeFormat chaîne de formatage
    Défaut:SSITimeFormat "%A, %d-%b-%Y %H:%M:%S %Z"
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Base
    Module:mod_include
    +

    Cette directive permet de modifier le format d'affichage des +variables d'environnement DATE. La chaîne de +formatage est identique à celle de la fonction +strftime(3) de la bibliothèque C standard.

    -

    Le PATH_INFO et la chaîne d'arguments - (QUERY_STRING) de la requête originale du client sont - fournis au script CGI ; ils ne peuvent pas être spécifiés - dans le chemin de l'URL. Le script disposera des variables include - en plus de l'environnement standard CGI.

    +

    Cette directive a le même effet que l'élément + <!--#config timefmt=chaîne de formatage + -->.

    -

    Exemple

    - <!--#exec cgi="/cgi-bin/exemple.cgi" --> -

    + 
    SSITimeFormat "%R, %B %d, %Y"
    -

    Si, à la place d'un flux de sortie, le script renvoie un - en-tête Location:, ce dernier sera traduit en ancrage - HTML.

    -

    L'élément include - virtual doit être préféré à exec cgi. En - particulier, si vous devez transmettre des arguments - supplémentaires à un programme CGI en utilisant la chaîne - d'arguments de la requête, c'est impossible avec exec - cgi, mais vous pouvez y parvenir avec include - virtual comme suit :

    +

    Avec l'exemple ci-dessus, les dates seront affichées dans le + style "22:26, June 14, 2002".

    -

    - <!--#include virtual="/cgi-bin/exemple.cgi?argument=valeur" --> -

    - +
    +
    top
    +

    Directive SSIUndefinedEcho

    + + + + + + + + +
    Description:Chaîne à afficher lorsqu'on tente d'extraire le contenu +d'une variable non définie
    Syntaxe:SSIUndefinedEcho chaîne
    Défaut:SSIUndefinedEcho "(none)"
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Base
    Module:mod_include
    +

    Cette directive permet de modifier la chaîne affichée par + mod_include lorsqu'on tente d'extraire le contenu + d'une variable non définie.

    -
    cmd
    -

    Le serveur va exécuter la commande fournie en utilisant - /bin/sh. La commande dispose des variables include, en plus du jeu habituel - de variables CGI.

    + 
    SSIUndefinedEcho "<!-- nondef -->"
    -

    Il est toujours préférable d'utiliser #include virtual à la place de - #exec cgi ou #exec cmd. #include - virtual utilise le mécanisme standard des sous-requêtes - d'Apache pour inclure des fichiers ou des scripts. Il a fait - l'objet de tests plus approfondis et sa maintenance est mieux - suivie.

    -

    De plus, sur certaines plate-formes, comme Win32, et sous unix, - si l'on utilise suexec, il est - impossible de transmettre des arguments à une commande dans une - directive exec, à moins d'insérer des espaces dans la - commande. Ainsi, alors que ce qui suit fonctionnera sous unix avec - une configuration sans suexec, l'effet produit ne sera pas celui - désiré sous Win32, ou dans le cas de l'utilisation de suexec - :

    +
    +
    top
    +

    Directive XBitHack

    + + + + + + + + +
    Description:Interprète les directives SSI dans les fichiers dont le bit +d'exécution est positionné
    Syntaxe:XBitHack on|off|full
    Défaut:XBitHack off
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:Options
    Statut:Base
    Module:mod_include
    +

    La directive XBitHack permet de contrôler + l'interprétation des documents html standards. Elle n'affecte que + les fichiers dont le type MIME est + text/html. XBitHack peut prendre + les valeurs suivantes :

    + +
    +
    off
    +
    Aucun traitement particulier pour les fichiers + exécutables.
    + +
    on
    +
    Tout fichier text/html dont le bit d'exécution + est positionné pour le propriétaire sera traité en tant que + document html interprété par le serveur.
    + +
    full
    +
    Identique à on, avec test du bit d'exécution pour + le groupe. Si ce dernier est positionné, la date de dernière + modification du fichier renvoyé est définie à la date de + dernière modification du fichier. Dans le cas contraire, aucune + date de dernière modification n'est renvoyée. Le positionnement de + ce bit permet aux clients et aux mandataires de gérer la mise en + cache du résultat de la requête. + +

    Note

    +

    Il est recommandé de n'utiliser l'option full que dans le cas + où vous êtes certain que le bit d'exécution du groupe est non + positionné pour les scripts SSI qui pourraient effectuer l'#include d'un programme CGI ou bien produire des sorties + différentes à chaque accès (ou seraient susceptibles d'être + modifiées au cours des requêtes ultérieures).

    + +

    Lorsqu'elle est définie à on, la directive + SSILastModified + l'emporte sur la directive XBitHack.

    +
    -

    - <!--#exec cmd="perl /chemin/vers/script_perl arg1 arg2" --> -

    -
    - + -

    L'élément fsize

    -

    Cette commande permet d'afficher la taille du fichier spécifié - en fonction des spécifications de format de sizefmt. - Attributs :

    -
    -
    file
    -
    La valeur est le chemin du fichier, relatif au répertoire - contenant le document en cours d'interprétation. +
    +
    top
    +
    +

    Activation des SSI

    + + +

    Les SSI sont implémentés par le filtre INCLUDES. Si des + documents contenant des directives SSI possèdent une extension + .shtml, les directives suivantes indiqueront à Apache de les + interpréter et d'assigner le type MIME + text/html au document obtenu :

    + + 
    AddType text/html .shtml
+AddOutputFilter INCLUDES .shtml
    + + +

    L'option suivante doit être définie pour les répertoires qui + contiennent les fichiers shtml (en général dans une section + <Directory>, mais + cette option peut également être définie dans un fichier + .htaccess si AllowOverride Options a été défini pour le + répertoire considéré) :

    -

    - Ce fichier a une taille de <!--#fsize file="mod_include.html" - --> octets. -

    + 
    Options +Includes
    - La valeur de file ne peut pas faire référence à un - fichier situé à un niveau supérieur de l'arborescence du répertoire - courant ou en dehors de la racine des documents ; il ne peut donc - ni commencer par un slash, ni contenir la séquence de caractères - ../. Si c'est le cas, le message d'erreur The - given path was above the root path sera renvoyé. - -
    virtual
    -
    La valeur est un chemin URL (codé avec caractères %). S'il ne - commence pas par un slash (/), il est considéré comme relatif au - document courant. Notez que cette commande n'affiche pas - la taille de la sortie d'un programme CGI, mais la taille du - programme CGI lui-même.
    - +

    Pour des raisons de compatibilité ascendante, le gestionnaire server-parsed + peut aussi activer le filtre INCLUDES. Ainsi, Apache va activer le + filtre INCLUDES pour tout document de type MIME + text/x-server-parsed-html ou + text/x-server-parsed-html3 (et le document obtenu aura + pour type MIME text/html).

    -

    - Ce fichier a une taille de <!--#fsize - virtual="/docs/mod/mod_include.html" --> octets. -

    +

    Pour plus d'informations, voyez notre Tutoriel SSI.

    +
    top
    +
    +

    PATH_INFO et SSI

    + -

    Notez que dans la plupart des cas, ces deux attributs sont - identiques. Cependant, l'attribut file ne respecte - pas les aliases URL-space.

    - +

    Les fichiers traités dans le cadre des SSI n'acceptent plus par + défaut les requêtes avec PATH_INFO (les informations + relatives au chemin en fin de requête). La directive AcceptPathInfo permet de configurer le + serveur de façon à ce qu'il accepte ce genre de requête.

    +
    top
    +
    +

    Eléments disponibles

    +

    Le document est interprété comme un document HTML, avec des + commandes spéciales incluses sous forme de commentaires SGML. La + syntaxe d'une commande est la suivante :

    -

    L'élément flastmod

    -

    Cette commande permet d'afficher la date de dernière - modification du fichier spécifié, en fonction des spécifications - de format de timefmt. Les attributs sont les mêmes - que ceux de la commande fsize.

    - +

    + <!--#élément attribut=valeur + attribut=valeur ... --> +

    -

    L'élément include

    -

    Cette commande permet d'insérer le texte d'un autre document ou - fichier dans le fichier en cours d'interprétation. Tout fichier - inclus est soumis au contrôle d'accès habituel. Si Options IncludesNOEXEC - est défini pour le répertoire contenant le fichier - interprété, seuls les documents possèdant un - type MIME de type texte - (text/plain, text/html, etc...) seront - inclus. Les scripts CGI, quant à eux, sont invoqués de manière - habituelle en utilisant l'URL complète fournie avec la commande, y - compris toute chaîne d'arguments éventuelle.

    +

    Les valeurs sont souvent entourées de guillemets, mais on peut + aussi utiliser des apostrophes (') ou des apostrophes + inverses (`). De nombreuses commandes n'acceptent + qu'une seule paire attribut-valeur. Notez que le terminateur de + commentaire (-->) doit être précédé d'un espace afin + d'être sûr qu'il ne soit pas considéré comme un élément de commande + SSI. Notez aussi que le délimiteur de début <!--# + est un élément de commande et ne doit donc pas contenir + d'espace.

    -

    Un attribut définit le chemin du document à inclure, et peut - apparaître plusieurs fois dans l'élément à inclure ; en retour, pour - chaque attribut fourni à la commande include, une inclusion est - effectuée. Les attributs disponibles sont :

    +

    La table suivante contient la liste des éléments autorisés :

    -
    -
    file
    -
    La valeur est un chemin relatif au répertoire contenant le - fichier en cours d'interprétation. Elle ne peut ni contenir - ../, ni être un chemin absolu. Ainsi, vous ne pouvez - pas inclure de fichiers situés en dehors de l'arborescence du - site web ou dans un niveau supérieur à celui du fichier courant - dans cette arborescence. Il est toujours préférable d'utiliser - l'attribut virtual.
    + + + + + + + + + + + + + + + + + + +
    ElémentDescription
    configconfigure les formats de sortie
    echoaffiche le contenu de variables
    execexécute des programmes externes
    fsizeaffiche la taille d'un fichier
    flastmodaffiche la date de dernière modification d'un fichier
    includeinclut un fichier
    printenvaffiche toutes les variables disponibles
    setdéfinit la valeur d'une variable
    -
    virtual
    -

    La valeur est un chemin URL (codé avec caractères %). L'URL - ne peut contenir qu'un chemin et une chaîne d'arguments - éventuelle, à l'exclusion de tout protocole ou nom d'hôte. S'il ne - commence pas par un slash (/), il est considéré comme relatif au - document courant.

    +

    Les éléments SSI peuvent être définis par d'autres modules que + mod_include. À ce titre, l'élément exec est fourni par + mod_cgi, et ne sera disponible que si ce module est + chargé.

    -

    Une URL est construite à partir de l'attribut, et la sortie que - renverrait le serveur si l'URL était accédée par le client est - incluse dans la sortie interprétée. Les inclusions de fichiers - peuvent ainsi être imbriquées.

    +

    L'élément config

    +

    Cette commande contrôle divers aspects de l'interprétation. Les + attributs valides sont :

    -

    Si l'URL spécifiée correspond à un programme CGI, le programme - sera exécuté, et son flux de sortie inséré à la place de la - directive dans le fichier interprété. Vous pouvez insérer une - chaîne d'arguments dans une URL correspond à un programme CGI - :

    +
    +
    echomsg (Versions 2.1 et supérieures + d'Apache)
    +

    La valeur est un message qui sera envoyé au client si + l'élément echo tente + d'afficher le contenu d'une variable non définie. Cet attribut + l'emporte sur toute directive SSIUndefinedEcho.

    - <!--#include virtual="/cgi-bin/exemple.cgi?argument=valeur" --> + <!--#config echomsg="[Valeur non définie]" -->

    +
    -

    include virtual doit être préféré à exec - cgi pour inclure le flux de sortie d'un programme CGI dans - un document HTML.

    - -

    Si la directive KeptBodySize est correctement - définie et valide pour le fichier inclus, les tentatives de - requêtes POST vers le document HTML qui inclut des fichiers seront - transmises aux sous-requêtes en tant que requêtes POST - elles-mêmes. Sans cette directive, toutes les sous-requêtes sont - traitées en tant que requêtes GET.

    +
    errmsg
    +

    La valeur est un message qui sera envoyé au client si une + erreur survient lors de l'interprétation du document. Cet attribut + l'emporte sur toute directive SSIErrorMsg.

    +

    + <!--#config errmsg="[Zut, quelque chose s'est mal passé.]" --> +

    -
    onerror
    -

    La valeur est un chemin-URL (codé-%) qui est affiché si une - tentative précédente d'inclure un fichier ou un attribut virtuel a - échoué. Pour produire son effet, cet attribut doit être spécifié - après le fichier ou les attributs virtuels concernés. Si la - tentative d'inclure le chemin onerror échoue, ou si onerror n'est - pas spécifié, c'est le message d'erreur par défaut qui sera - inclus.

    +
    sizefmt
    +

    La valeur définit l'unité employée lors de l'affichage de la + taille d'un fichier. Les valeurs possibles sont bytes + pour une taille en octets, ou abbrev pour une taille + en Ko ou Mo selon son importance ; par exemple, une taille de 1024 + octets sera affichée sous la forme "1K".

    - # Exemple simple
    - <!--#include virtual="/not-exist.html" onerror="/error.html" --> + <!--#config sizefmt="abbrev" -->

    +
    + +
    timefmt
    +

    La valeur est une chaîne que pourra utiliser la fonction de la + bibliothèque standard strftime(3) lors de l'affichage + des dates.

    +

    - # Chemins onerror dédiés
    - <!--#include virtual="/path-a.html" onerror="/error-a.html" virtual="/path-b.html" onerror="/error-b.html" --> + <!--#config timefmt=""%R, %B %d, %Y"" -->

    -

    L'élément printenv

    -

    Cette commande affiche la liste en mode texte de toutes les variables et de - leurs valeurs. Les caractères spéciaux sont encodés entity avant - d'être affichés (se reporter à l'élément echo pour plus de détails). Cette - commande ne comporte pas d'attributs.

    - -

    Exemple

    - <pre> - <!--#printenv --> - </pre> -

    - +

    L'élément echo

    +

    Cette commande affiche le contenu d'une des variables include définies ci-dessous. Si + la variable n'est pas définie, le résultat est déterminé par la + valeur de la directive SSIUndefinedEcho. Le format d'affichage des dates est + défini par l'attribut timefmt de la commande + config.

    -

    L'élément set

    -

    Cette commande permet de définir la valeur d'une variable. Les - attributs sont :

    +

    Attributs:

    var
    -
    Le nom de la variable à définir.
    +
    La valeur est le nom de la variable à afficher.
    -
    value
    -
    La valeur à affecter à la variable.
    decoding

    Spécifie si Apache doit effectuer un décodage dans la variable avant son traitement ultérieur. La valeur par défaut est none, et dans ce cas, aucun décodage n'est effectué. - Si la valeur est url, urlencoded, - base64 ou - entity, c'est un décodage de type URL, - application/x-www-form-urlencoded, base64 ou - entité HTML qui sera respectivement effectué. Il est possible - d'effectuer plusieurs décodages en + Si la valeur est url, un décodage de type URL sera + effectué (il s'agit du codage de type %-encoding utilisé dans les + URLs des liens, etc...). Si la valeur est urlencoded, + c'est un décodage des éléments de type + application/x-www-form-urlencode (que l'on trouve dans les chaînes + de paramètres) qui sera effectué. Si la valeur est + base64, un + decodage de type base64 sera effectué, et si elle est + entity, c'est un décodage des entités HTML qui sera + effectué. Ce décodage est effectué avant tout codage ultérieur de + la variable. Il est possible d'effectuer plusieurs décodages en spécifiant plusieurs valeurs séparées par des virgules. Les spécifications de décodages restent valables jusqu'au prochain - attribut de décodage, ou la fin de l'élément. Pour être pris en - compte, l'attribut de décodage + attribut de décodage, ou la fin de l'élément.

    + +

    Pour être pris en compte, l'attribut de décodage doit précéder l'attribut var correspondant.

    encoding
    -

    Spécifie la manière dont Apache va encoder les caractères +

    Spécifie la manière dont Apache va coder les caractères spéciaux que la variable contient avant leur affichage. S'il est - défini à none, aucun encodage ne sera effectué. Si la - valeur est url, urlencoding, - base64 ou - entity, c'est un encodage de type URL, - application/x-www-form-urlencoded, base64 ou - entité HTML qui sera respectivement effectué. Il est possible de - spécifier plusieurs types d'encodage en les séparant par des - virgules. La spécification du type d'encodage fera effet - jusqu'à la définition d'un nouvel attribut encoding - ou la fin de l'élément. Pour produire son effet, l'attribut encoding doit - précéder l'attribut var concerné. Les encodages sont - effectués après les opérations de décodage.

    -
    + défini à none, aucun codage ne sera effectué. S'il + est défini à url, un codage de type URL sera effectué + (aussi connu sous le nom de codage avec caractères % , il convient + pour les URLS des liens, etc...). S'il est défini à + urlencoded, c'est un codage compatible + application/x-www-form-urlencoded qui sera effectué (à utiliser + dans les chaînes de paramètres). S'il est défini à + base64, c'est un encodage de type base64 qui sera + effectué. Au début d'un élément + echo, la valeur par défaut est définie à + entity, ce qui correspond à un codage de type entité + (codage qui convient pour un élément HTML de type bloc, comme le + paragraphe d'un texte). Cette valeur par défaut peut être modifiée + en ajoutant un attribut encoding, qui fera effet + jusqu'à la définition d'un nouvel attribut encoding + ou la fin de l'élément echo.

    -
    +

    Pour produire son effet, l'attribut encoding doit + précéder l'attribut var concerné.

    -

    Exemple

    - <!--#set var="category" value="help" --> +

    + Afin de prévenir les attaques de type cross-site scripting, il + est recommandé de toujours encoder les données fournies + par les utilisateurs. +
    + +

    Example

    + <!--#echo encoding="entity" var="QUERY_STRING" -->

    +
    +
    -
    top
    -
    -

    Variables include

    - - -

    À l'instar des variables de l'environnement CGI standard, ces - variables sont mises à la disposition de la commande - echo, des opérateurs conditionnels if et - elif, et de tout programme invoqué par le document.

    -
    -
    DATE_GMT
    -
    La date GMT (Greenwich Mean Time) courante.
    +

    L'élément exec

    +

    La commande exec exécute la commande shell ou le + script spécifié. Elle nécessite le chargement du module + mod_cgi. Si Options IncludesNOEXEC est + définie, cette commande est désactivée. Les attributs disponibles + sont :

    -
    DATE_LOCAL
    -
    La date locale courante.
    +
    +
    cgi
    +

    La valeur spécifie un chemin URL vers le script CGI (encodé + avec caractères %). Si le chemin ne commence pas par un slash (/), + il est considéré comme relatif au document courant. Le document + référencé par ce chemin est invoqué en tant que script CGI, même + s'il n'est pas censé être reconnu comme tel par le serveur. Les + scripts CGI doivent cependant être activés dans le répertoire qui + contient les scripts (via la directive ScriptAlias ou l'Options ExecCGI).

    -
    DOCUMENT_NAME
    -
    Le nom de base du fichier demandé par l'utilisateur (sans son - chemin).
    +

    Le PATH_INFO et la chaîne d'arguments + (QUERY_STRING) de la requête originale du client sont + fournis au script CGI ; ils ne peuvent pas être spécifiés + dans le chemin de l'URL. Le script disposera des variables include + en plus de l'environnement standard CGI.

    -
    DOCUMENT_URI
    -
    Le chemin URL (caractères % décodés) du document demandé par - l'utilisateur. Notez que dans le cas d'inclusions de fichiers - imbriquées, il ne s'agit pas de l'URL du document - courant. Notez également que si l'URL est modifiée en interne (par - exemple via une directive alias ou directoryindex), c'est l'URL modifiée - que contiendra la variable.
    +

    Exemple

    + <!--#exec cgi="/cgi-bin/exemple.cgi" --> +

    -
    LAST_MODIFIED
    -
    La date de dernière modification du document demandé par - l'utilisateur.
    +

    Si, à la place d'un flux de sortie, le script renvoie un + en-tête Location:, ce dernier sera traduit en ancrage + HTML.

    -
    QUERY_STRING_UNESCAPED
    -
    Si une chaîne d'arguments est présente, elle sera affectée à - cette variable, les caractères % décodés, et éventuellement - échappés pour qu'ils ne soient pas interprétés par le - shell (les caractères spéciaux comme &,etc... - sont précédés d'anti-slashes).
    -
    -
    top
    -
    -

    Substitution de variable

    +

    L'élément include + virtual doit être préféré à exec cgi. En + particulier, si vous devez transmettre des arguments + supplémentaires à un programme CGI en utilisant la chaîne + d'arguments de la requête, c'est impossible avec exec + cgi, mais vous pouvez y parvenir avec include + virtual comme suit :

    -

    Une substitution de variable à l'intérieur d'une chaîne entre - guillemets s'effectue dans la plupart des situations où cette - dernière peut raisonablement constituer un argument d'une directive - SSI. Sont concernées les directives config, - exec, flastmod, fsize, - include, echo, et set. Si la - directive SSILegacyExprParser est définie à - on, la substitution s'effectue aussi dans les arguments - des opérateurs conditionnels. Vous pouvez insérer - un signe dollar en tant que caractère littéral dans une chaîne en - utilisant un anti-slash :

    +

    + <!--#include virtual="/cgi-bin/exemple.cgi?argument=valeur" --> +

    + -

    - <!--#set var="cur" value="\$test" --> -

    +
    cmd
    +

    Le serveur va exécuter la commande fournie en utilisant + /bin/sh. La commande dispose des variables include, en plus du jeu habituel + de variables CGI.

    -

    Si une référence de variable doit être substituée au beau milieu - d'une séquence de caractères qui pourrait être elle-même considérée - comme un identifiant valide, l'ambiguïté peut être levée en - entourant la référence d'accolades, à la manière du shell :

    +

    Il est toujours préférable d'utiliser #include virtual à la place de + #exec cgi ou #exec cmd. #include + virtual utilise le mécanisme standard des sous-requêtes + d'Apache pour inclure des fichiers ou des scripts. Il a fait + l'objet de tests plus approfondis et sa maintenance est mieux + suivie.

    -

    - <!--#set var="Zed" value="${REMOTE_HOST}_${REQUEST_METHOD}" --> -

    +

    De plus, sur certaines plate-formes, comme Win32, et sous unix, + si l'on utilise suexec, il est + impossible de transmettre des arguments à une commande dans une + directive exec, à moins d'insérer des espaces dans la + commande. Ainsi, alors que ce qui suit fonctionnera sous unix avec + une configuration sans suexec, l'effet produit ne sera pas celui + désiré sous Win32, ou dans le cas de l'utilisation de suexec + :

    -

    Dans cet exemple, la variable Zed se verra affecter - la valeur "X_Y" si REMOTE_HOST et - REQUEST_METHOD contiennent respectivement - "X" et "Y".

    +

    + <!--#exec cmd="perl /chemin/vers/script_perl arg1 arg2" --> +

    +
    + + -
    top
    -
    -

    Eléments de contrôle d'inclusion conditionnelle

    - +

    L'élément fsize

    +

    Cette commande permet d'afficher la taille du fichier spécifié + en fonction des spécifications de format de sizefmt. + Attributs :

    -

    Les éléments de base du contrôle d'inclusion conditionnelle sont - :

    +
    +
    file
    +
    La valeur est le chemin du fichier, relatif au répertoire + contenant le document en cours d'interprétation. -

    - <!--#if expr="test_condition" -->
    - <!--#elif expr="test_condition" -->
    - <!--#else -->
    - <!--#endif --> +

    + Ce fichier a une taille de <!--#fsize file="mod_include.html" + --> octets.

    -

    L'élément if fonctionne de la même manière que - la directive if d'un langage de programmation. La condition est - évaluée et si le résultat est vrai, le texte qui suit jusqu'au - prochain élément elif, else ou - endif sera inclus dans le flux de sortie.

    - -

    Les éléments elif ou else permettent - d'insérer du texte dans le flux de sortie si - test_condition s'est révélé faux. Ces éléments sont - optionnels.

    - -

    L'élément endif termine le bloc de traitement - conditionnel if et est obligatoire.

    - -

    test_condition est une expression booléenne qui - emprunte la syntaxe ap_expr. La directive - SSILegacyExprParser - permet de modifier cette syntaxe pour la rendre compatible avec - Apache HTTPD 2.2.x.

    - -

    Le jeu de variables SSI avec l'élément var sont - exportées vers l'environnement de la requête et sont accessibles via - la fonction reqenv. Pour faire simple, le nom de - fonction v est aussi disponible dans le module - mod_include.

    + La valeur de file ne peut pas faire référence à un + fichier situé à un niveau supérieur de l'arborescence du répertoire + courant ou en dehors de la racine des documents ; il ne peut donc + ni commencer par un slash, ni contenir la séquence de caractères + ../. Si c'est le cas, le message d'erreur The + given path was above the root path sera renvoyé. +
    -

    Dans l'exemple suivant, "depuis le réseau local" sera affiché si - l'adresse IP du client appartient au sous-réseau 10.0.0.0/8.

    +
    virtual
    +
    La valeur est un chemin URL (codé avec caractères %). S'il ne + commence pas par un slash (/), il est considéré comme relatif au + document courant. Notez que cette commande n'affiche pas + la taille de la sortie d'un programme CGI, mais la taille du + programme CGI lui-même.
    +
    -

    - <!--#if expr='-R "10.0.0.0/8"' -->
    - - depuis le réseau local
    -     - <!--#else -->
    - - depuis ailleurs
    -     - <!--#endif --> +

    + Ce fichier a une taille de <!--#fsize + virtual="/docs/mod/mod_include.html" --> octets.

    -

    Dans l'exemple suivant, "foo vaut bar" sera affiché si la variable - foo contient la valeur "bar".

    +

    Notez que dans la plupart des cas, ces deux attributs sont + identiques. Cependant, l'attribut file ne respecte + pas les aliases URL-space.

    + -

    - <!--#if expr='v("foo") = "bar"' -->
    - - foo vaut bar
    -     - <!--#endif --> -

    +

    L'élément flastmod

    +

    Cette commande permet d'afficher la date de dernière + modification du fichier spécifié, en fonction des spécifications + de format de timefmt. Les attributs sont les mêmes + que ceux de la commande fsize.

    + + +

    L'élément include

    +

    Cette commande permet d'insérer le texte d'un autre document ou + fichier dans le fichier en cours d'interprétation. Tout fichier + inclus est soumis au contrôle d'accès habituel. Si Options IncludesNOEXEC + est défini pour le répertoire contenant le fichier + interprété, seuls les documents possèdant un + type MIME de type texte + (text/plain, text/html, etc...) seront + inclus. Les scripts CGI, quant à eux, sont invoqués de manière + habituelle en utilisant l'URL complète fournie avec la commande, y + compris toute chaîne d'arguments éventuelle.

    -

    Documentation de référence

    -

    Voir aussi Les expressions dans le serveur - HTTP Apache pour une référence complète et des exemples. Les - fonctions restricted ne sont pas disponibles dans - mod_include.

    -
    -
    top
    -
    -

    Syntaxe des expressions héritée

    - +

    Un attribut définit le chemin du document à inclure, et peut + apparaître plusieurs fois dans l'élément à inclure ; en retour, pour + chaque attribut fourni à la commande include, une inclusion est + effectuée. Les attributs disponibles sont :

    -

    Cette section décrit la syntaxe de l'élément #if - expr dans le cas où la directive SSILegacyExprParser est définie à - on.

    +
    +
    file
    +
    La valeur est un chemin relatif au répertoire contenant le + fichier en cours d'interprétation. Elle ne peut ni contenir + ../, ni être un chemin absolu. Ainsi, vous ne pouvez + pas inclure de fichiers situés en dehors de l'arborescence du + site web ou dans un niveau supérieur à celui du fichier courant + dans cette arborescence. Il est toujours préférable d'utiliser + l'attribut virtual.
    -
    -
    chaîne
    -
    vrai si chaîne n'est pas vide
    +
    virtual
    +

    La valeur est un chemin URL (codé avec caractères %). L'URL + ne peut contenir qu'un chemin et une chaîne d'arguments + éventuelle, à l'exclusion de tout protocole ou nom d'hôte. S'il ne + commence pas par un slash (/), il est considéré comme relatif au + document courant.

    -
    -A string
    -

    vrai si l'URL que contient la chaîne est accessible du - point de vue de la configuration, faux sinon. Il - s'avère utile lorsqu'un lien vers une URL doit être caché aux - utilisateurs qui ne sont pas autorisés à voir cette URL. Notez que - le test porte sur l'autorisation d'accès à l'URL, et non sur son - existence.

    +

    Une URL est construite à partir de l'attribut, et la sortie que + renverrait le serveur si l'URL était accédée par le client est + incluse dans la sortie interprétée. Les inclusions de fichiers + peuvent ainsi être imbriquées.

    -

    Exemple

    - <!--#if expr="-A /prive" -->
    - - Cliquez <a href="/prive">ici</a> pour accéder aux - informations privées.
    -     - <!--#endif --> -

    -
    +

    Si l'URL spécifiée correspond à un programme CGI, le programme + sera exécuté, et son flux de sortie inséré à la place de la + directive dans le fichier interprété. Vous pouvez insérer une + chaîne d'arguments dans une URL correspond à un programme CGI + :

    -
    chaîne1 = chaîne2
    - chaîne1 == chaîne2
    - chaîne1 != chaîne2
    +

    + <!--#include virtual="/cgi-bin/exemple.cgi?argument=valeur" --> +

    -

    Compare chaîne1 à chaîne2. Si - chaîne2 est de la forme - /chaîne2/, elle est traitée comme une - expression rationnelle. Les expressions rationnelles sont - implémentées par le moteur PCRE - et possèdent la même syntaxe que celles de perl 5. Notez que == - n'est qu'un alias pour = et se comporte exactement de - la même manière que ce dernier.

    +

    include virtual doit être préféré à exec + cgi pour inclure le flux de sortie d'un programme CGI dans + un document HTML.

    -

    Si vous faites une comparaison directe (= ou - ==), vous pouvez extraire des parties de l'expression - rationnelle. Les parties extraites sont stockées dans les - variables spéciales $1 .. $9. L'ensemble - de la chaîne correspondant à l'expression rationnelle est stocké - dans la variable spéciale $0.

    +

    Si la directive KeptBodySize est correctement + définie et valide pour le fichier inclus, les tentatives de + requêtes POST vers le document HTML qui inclut des fichiers seront + transmises aux sous-requêtes en tant que requêtes POST + elles-mêmes. Sans cette directive, toutes les sous-requêtes sont + traitées en tant que requêtes GET.

    -

    Exemple

    - <!--#if expr="$QUERY_STRING = /^sid=([a-zA-Z0-9]+)/" -->
    - - <!--#set var="session" value="$1" -->
    -     - <!--#endif --> -

    -
    chaîne1 < chaîne2
    - chaîne1 <= chaîne2
    - chaîne1 > chaîne2
    - chaîne1 >= chaîne2
    - -
    Compare chaîne1 à chaîne2. Notez que les - chaînes sont comparées de manière littérale (en utilisant - strcmp(3)). Ainsi, la chaîne "100" est inférieure à - "20".
    +
    onerror
    +

    La valeur est un chemin-URL (codé-%) qui est affiché si une + tentative précédente d'inclure un fichier ou un attribut virtuel a + échoué. Pour produire son effet, cet attribut doit être spécifié + après le fichier ou les attributs virtuels concernés. Si la + tentative d'inclure le chemin onerror échoue, ou si onerror n'est + pas spécifié, c'est le message d'erreur par défaut qui sera + inclus.

    -
    ( test_condition )
    -
    vrai si test_condition est vrai
    +

    + # Exemple simple
    + <!--#include virtual="/not-exist.html" onerror="/error.html" --> +

    -
    ! test_condition
    -
    vrai si test_condition est faux
    +

    + # Chemins onerror dédiés
    + <!--#include virtual="/path-a.html" onerror="/error-a.html" virtual="/path-b.html" onerror="/error-b.html" --> +

    -
    test_condition1 && - test_condition2
    -
    vrai si test_condition1 et - test_condition2 sont tous les deux vrais
    + +
    + -
    test_condition1 || - test_condition2
    -
    vrai si au moins un des tests test_condition1 ou - test_condition2 est vrai
    -
    +

    L'élément printenv

    +

    Cette commande affiche la liste en mode texte de toutes les variables et de + leurs valeurs. Les caractères spéciaux sont encodés entity avant + d'être affichés (se reporter à l'élément echo pour plus de détails). Cette + commande ne comporte pas d'attributs.

    -

    "=" et "!=" ont une priorité supérieure - à "&&" et "||". "!" a - la priorité la plus haute. Ainsi, les deux directives suivantes sont - équivalentes :

    +

    Exemple

    + <pre> + <!--#printenv --> + </pre> +

    + -

    - <!--#if expr="$a = test1 && $b = test2" -->
    - <!--#if expr="($a = test1) && ($b = test2)" --> -

    +

    L'élément set

    +

    Cette commande permet de définir la valeur d'une variable. Les + attributs sont :

    -

    Les opérateurs booléens && et - || ont la même priorité. Ainsi, si vous voulez - augmenter la priorité d'un de ces opérateurs, vous devez utiliser - des parenthèses.

    +
    +
    var
    +
    Le nom de la variable à définir.
    -

    Tout ce qui n'est pas reconnu comme variable ou opérateur est - traité comme une chaîne. Les chaînes peuvent aussi être entourées - d'apostrophes : 'chaîne'. Les chaînes sans apostrophe - ne peuvent pas contenir d'espaces (espaces ou tabulations) car - ceux-ci servent à séparer certains éléments comme les variables. Si - plusieurs chaînes se trouvent dans une ligne, elles sont concaténées - en utilisant des espaces. Ainsi,

    +
    value
    +
    La valeur à affecter à la variable.
    +
    decoding
    +

    Spécifie si Apache doit effectuer un décodage dans la + variable avant son traitement ultérieur. La valeur par défaut est + none, et dans ce cas, aucun décodage n'est effectué. + Si la valeur est url, urlencoded, + base64 ou + entity, c'est un décodage de type URL, + application/x-www-form-urlencoded, base64 ou + entité HTML qui sera respectivement effectué. Il est possible + d'effectuer plusieurs décodages en + spécifiant plusieurs valeurs séparées par des virgules. Les + spécifications de décodages restent valables jusqu'au prochain + attribut de décodage, ou la fin de l'élément. Pour être pris en + compte, l'attribut de décodage + doit précéder l'attribut var correspondant.

    +
    -

    chaîne1    chaîne2 devient chaîne1 chaîne2
    -
    - et
    -
    - 'chaîne1    chaîne2' devient chaîne1    chaîne2.

    +
    encoding
    +

    Spécifie la manière dont Apache va encoder les caractères + spéciaux que la variable contient avant leur affichage. S'il est + défini à none, aucun encodage ne sera effectué. Si la + valeur est url, urlencoding, + base64 ou + entity, c'est un encodage de type URL, + application/x-www-form-urlencoded, base64 ou + entité HTML qui sera respectivement effectué. Il est possible de + spécifier plusieurs types d'encodage en les séparant par des + virgules. La spécification du type d'encodage fera effet + jusqu'à la définition d'un nouvel attribut encoding + ou la fin de l'élément. Pour produire son effet, l'attribut encoding doit + précéder l'attribut var concerné. Les encodages sont + effectués après les opérations de décodage.

    +
    -

    Optimisation des expressions booléennes

    -

    Si les expressions atteignent une complexité suffisante pour - ralentir les traitements de manière significative, vous pouvez - essayer de les optimiser en fonction des règles d'évaluation :

    -
      -
    • Les expressions sont évaluées de la gauche vers la droite
      • -
    • Les opérateurs booléens binaires (&& et - ||) font l'objet d'une évaluation abrégée chaque fois - que cela est possible. En d'autres termes, et selon la règle - ci-dessus, mod_include évalue tout d'abord la - partie gauche de l'expression. Si le résultat de l'évaluation de - cette partie gauche suffit à déterminer le résultat final, - l'évaluation s'arrête ici. Dans le cas contraire, la partie droite - est évaluée, et le résultat final tient compte des résultats des - évaluations des parties gauche et droite.
      • -
    • L'évaluation abrégée est désactivée tant qu'il reste des - expressions régulières à traiter. Ces dernières doivent être - évaluées afin de définir les variables correspondant aux - références arrières ($1 .. $9).
      • -
    -

    Si vous voulez déterminer la manière dont une expression est - traitée, vous pouvez recompiler mod_include en - utilisant l'option de compilation -DDEBUG_INCLUDE. - Ceci a pour effet d'insérer, pour chaque expression interprétée, - des informations étiquetées, l'arbre d'interprétation et la - manière dont elle est évaluée au sein du flux de sortie envoyé au - client.

    -
    +
    -

    Slashes d'échappement dans les expressions - rationnelles

    -

    Tous les caractères slashes qui ne sont pas des séparateurs dans - votre expression rationnelle doivent être échappés, et ceci sans - tenir compte de leur signification du point de vue du moteur - d'expressions rationnelles.

    -
    +

    Exemple

    + <!--#set var="category" value="help" --> +

    + +
    top
    +
    +

    Variables include

    + -

    Documentation de référence

    -

    Voir le document Les expressions dans le - serveur HTTP Apache, pour une référence complète et des exemples.

    -
    +

    À l'instar des variables de l'environnement CGI standard, ces + variables sont mises à la disposition de la commande + echo, des opérateurs conditionnels if et + elif, et de tout programme invoqué par le document.

    +
    +
    DATE_GMT
    +
    La date GMT (Greenwich Mean Time) courante.
    -
    -
    top
    -

    Directive SSIEndTag

    - - - - - - - -
    Description:Chaîne qui termine l'élément include
    Syntaxe:SSIEndTag tag
    Défaut:SSIEndTag "-->"
    Contexte:configuration du serveur, serveur virtuel
    Statut:Base
    Module:mod_include
    -

    Cette directive permet de modifier la chaîne que - mod_include interprète comme la fin d'un élément - include.

    +
    DATE_LOCAL
    +
    La date locale courante.
    - 
    SSIEndTag "%>"
    +
    DOCUMENT_NAME
    +
    Le nom de base du fichier demandé par l'utilisateur (sans son + chemin).
    +
    DOCUMENT_URI
    +
    Le chemin URL (caractères % décodés) du document demandé par + l'utilisateur. Notez que dans le cas d'inclusions de fichiers + imbriquées, il ne s'agit pas de l'URL du document + courant. Notez également que si l'URL est modifiée en interne (par + exemple via une directive alias ou directoryindex), c'est l'URL modifiée + que contiendra la variable.
    +
    LAST_MODIFIED
    +
    La date de dernière modification du document demandé par + l'utilisateur.
    -

    Voir aussi

    - -
    -
    top
    -

    Directive SSIErrorMsg

    - - - - - - - - -
    Description:Message d'erreur affiché lorsqu'une erreur SSI -survient
    Syntaxe:SSIErrorMsg message
    Défaut:SSIErrorMsg "[an error occurred while processing this -directive]"
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Base
    Module:mod_include
    -

    La directive SSIErrorMsg permet de - modifier le message d'erreur affiché lorsqu'une erreur SSI survient. - Pour les serveurs en production, il est recommandé de modifier le - message d'erreur par défaut en "<!-- Error - -->", de façon à ce que le message ne soit pas - présenté à l'utilisateur.

    +
    QUERY_STRING_UNESCAPED
    +
    Si une chaîne d'arguments est présente, elle sera affectée à + cette variable, les caractères % décodés, et éventuellement + échappés pour qu'ils ne soient pas interprétés par le + shell (les caractères spéciaux comme &,etc... + sont précédés d'anti-slashes).
    + +
    top
    +
    +

    Substitution de variable

    -

    Cette directive a le même effet que l'élément - <!--#config errmsg=message -->.

    +

    Une substitution de variable à l'intérieur d'une chaîne entre + guillemets s'effectue dans la plupart des situations où cette + dernière peut raisonablement constituer un argument d'une directive + SSI. Sont concernées les directives config, + exec, flastmod, fsize, + include, echo, et set. Si la + directive SSILegacyExprParser est définie à + on, la substitution s'effectue aussi dans les arguments + des opérateurs conditionnels. Vous pouvez insérer + un signe dollar en tant que caractère littéral dans une chaîne en + utilisant un anti-slash :

    - 
    SSIErrorMsg "<!-- Error -->"
    +

    + <!--#set var="cur" value="\$test" --> +

    +

    Si une référence de variable doit être substituée au beau milieu + d'une séquence de caractères qui pourrait être elle-même considérée + comme un identifiant valide, l'ambiguïté peut être levée en + entourant la référence d'accolades, à la manière du shell :

    -
    -
    top
    -

    Directive SSIETag

    - - - - - - - - -
    Description:Définit si des en-têtes ETags sont générés par le serveur.
    Syntaxe:SSIETag on|off
    Défaut:SSIETag off
    Contexte:répertoire, .htaccess
    Statut:Base
    Module:mod_include
    Compatibilité:Disponible à partir de la version 2.2.15 du serveur HTTP -Apache.
    -

    Dans le cas général, un fichier filtré par - mod_include peut contenir des éléments soit - générés dynamiquement, soit éventuellement modifiés indépendemment - du fichier original. En conséquence, il est demandé par défaut au - serveur de ne pas générer d'en-tête ETag à la réponse - en ajoutant no-etag aux informations de requête.

    +

    + <!--#set var="Zed" value="${REMOTE_HOST}_${REQUEST_METHOD}" --> +

    -

    Ce comportement peut être modifié via la directive - SSIETag qui permet au serveur de générer un - en-tête ETag. On peut aussi l'utiliser pour la mise - en cache de la sortie. Notez qu'un serveur d'arrière-plan ou un - générateur de contenu dynamique peut lui-même générer un en-tête - ETag, en ignorant l'information no-etag, - cet en-tête ETag étant transmis par - mod_include sans tenir compte de la définition de - la présente directive. La directive SSIETag - peut prendre une des valeurs suivantes :

    +

    Dans cet exemple, la variable Zed se verra affecter + la valeur "X_Y" si REMOTE_HOST et + REQUEST_METHOD contiennent respectivement + "X" et "Y".

    -
    +
    top
    +
    +

    Eléments de contrôle d'inclusion conditionnelle

    + -
    off
    -
    no-etag sera ajouté aux informations de - requête, et il sera demandé au serveur de ne pas générer - d'en-tête ETag. Lorsqu'un serveur ignore la valeur - de no-etag et génère tout de même un en-tête - ETag, ce dernier sera respecté.
    +

    Les éléments de base du contrôle d'inclusion conditionnelle sont + :

    -
    on
    -
    Les en-têtes ETag existants seront respectés, - et ceux générés par le serveur seront ajoutés à la réponse.
    +

    + <!--#if expr="test_condition" -->
    + <!--#elif expr="test_condition" -->
    + <!--#else -->
    + <!--#endif --> +

    - +

    L'élément if fonctionne de la même manière que + la directive if d'un langage de programmation. La condition est + évaluée et si le résultat est vrai, le texte qui suit jusqu'au + prochain élément elif, else ou + endif sera inclus dans le flux de sortie.

    +

    Les éléments elif ou else permettent + d'insérer du texte dans le flux de sortie si + test_condition s'est révélé faux. Ces éléments sont + optionnels.

    -
    -
    top
    -

    Directive SSILastModified

    - - - - - - - - -
    Description:Définit si des en-têtes Last-Modified sont -générés par le serveur.
    Syntaxe:SSILastModified on|off
    Défaut:SSILastModified off
    Contexte:répertoire, .htaccess
    Statut:Base
    Module:mod_include
    Compatibilité:Disponible à partir de la version 2.2.15 du serveur HTTP -Apache.
    -

    Dans le cas général, un fichier filtré par - mod_include peut contenir des éléments soit - générés dynamiquement, soit éventuellement modifiés indépendemment - du fichier original. En conséquence, l'en-tête - Last-Modified est supprimé par défaut de la réponse.

    +

    L'élément endif termine le bloc de traitement + conditionnel if et est obligatoire.

    -

    La directive SSILastModified permet de - modifier ce comportement en faisant en sorte que l'en-tête - Last-Modified soit respecté s'il est déjà présent, ou - défini dans le cas contraire. On peut aussi l'utiliser pour la mise - en cache de la sortie. La directive - SSILastModified peut prendre une des - valeurs suivantes :

    +

    test_condition est une expression booléenne qui + emprunte la syntaxe ap_expr. La directive + SSILegacyExprParser + permet de modifier cette syntaxe pour la rendre compatible avec + Apache HTTPD 2.2.x.

    -
    +

    Le jeu de variables SSI avec l'élément var sont + exportées vers l'environnement de la requête et sont accessibles via + la fonction reqenv. Pour faire simple, le nom de + fonction v est aussi disponible dans le module + mod_include.

    -
    off
    -
    L'en-tête Last-Modified sera supprimé des - réponses, à moins que la directive XBitHack ne soit définie à - full comme décrit plus loin.
    +

    Dans l'exemple suivant, "depuis le réseau local" sera affiché si + l'adresse IP du client appartient au sous-réseau 10.0.0.0/8.

    -
    on
    -
    L'en-tête Last-Modified sera respecté s'il est - déjà présent, et ajouté à la réponse si cette dernière est un - fichier et si l'en-tête est manquant. La directive SSILastModified l'emporte sur - la directive XBitHack.
    +

    + <!--#if expr='-R "10.0.0.0/8"' -->
    + + depuis le réseau local
    +     + <!--#else -->
    + + depuis ailleurs
    +     + <!--#endif --> +

    -
    +

    Dans l'exemple suivant, "foo vaut bar" sera affiché si la variable + foo contient la valeur "bar".

    +

    + <!--#if expr='v("foo") = "bar"' -->
    + + foo vaut bar
    +     + <!--#endif --> +

    -
    -
    top
    -

    Directive SSILegacyExprParser

    - - - - - - - - -
    Description:Active le mode de compatibilité pour les expressions -conditionnelles.
    Syntaxe:SSILegacyExprParser on|off
    Défaut:SSILegacyExprParser off
    Contexte:répertoire, .htaccess
    Statut:Base
    Module:mod_include
    Compatibilité:Disponible à partir de la version 2.3.13.
    -

    Depuis la version 2.3.13, mod_include a adopté - la nouvelle syntaxe ap_expr pour ses - expressions conditionnelles dans les éléments de contrôle de flux - #if. Cette directive permet de réactiver l'ancienne syntaxe qui est compatible avec les - versions 2.2.x et antérieures d'Apache HTTPD. -

    +

    Documentation de référence

    +

    Voir aussi Les expressions dans le serveur + HTTP Apache pour une référence complète et des exemples. Les + fonctions restricted ne sont pas disponibles dans + mod_include.

    +
    +
    top
    +
    +

    Syntaxe des expressions héritée

    + -
    -
    top
    -

    Directive SSIStartTag

    - - - - - - - -
    Description:Chaîne qui marque le début d'un élément -include
    Syntaxe:SSIStartTag tag
    Défaut:SSIStartTag "<!--#"
    Contexte:configuration du serveur, serveur virtuel
    Statut:Base
    Module:mod_include
    -

    Cette directive permet de modifier la chaîne que - mod_include interprète comme le début d'un élément - include.

    +

    Cette section décrit la syntaxe de l'élément #if + expr dans le cas où la directive SSILegacyExprParser est définie à + on.

    -

    Cette option peut vous être utile si vous avez deux serveurs qui - interprètent un fichier avec des commandes différentes (et - éventuellement à des moments différents).

    +
    +
    chaîne
    +
    vrai si chaîne n'est pas vide
    - 
          SSIStartTag "<%"
    
-      SSIEndTag   "%>"
    +
    -A string
    +

    vrai si l'URL que contient la chaîne est accessible du + point de vue de la configuration, faux sinon. Il + s'avère utile lorsqu'un lien vers une URL doit être caché aux + utilisateurs qui ne sont pas autorisés à voir cette URL. Notez que + le test porte sur l'autorisation d'accès à l'URL, et non sur son + existence.

    +

    Exemple

    + <!--#if expr="-A /prive" -->
    + + Cliquez <a href="/prive">ici</a> pour accéder aux + informations privées.
    +     + <!--#endif --> +

    +
    -

    Avec l'exemple ci-dessus, qui définit aussi une directive - SSIEndTag, vous pourrez - inscrire des directives SSI comme dans l'exemple suivant :

    +
    chaîne1 = chaîne2
    + chaîne1 == chaîne2
    + chaîne1 != chaîne2
    -

    Directives SSI avec marques de début et de fin - personnalisées

    - <%printenv %> -

    +

    Compare chaîne1 à chaîne2. Si + chaîne2 est de la forme + /chaîne2/, elle est traitée comme une + expression rationnelle. Les expressions rationnelles sont + implémentées par le moteur PCRE + et possèdent la même syntaxe que celles de perl 5. Notez que == + n'est qu'un alias pour = et se comporte exactement de + la même manière que ce dernier.

    -

    Voir aussi

    - -
    -
    top
    -

    Directive SSITimeFormat

    - - - - - - - - -
    Description:Configuration du format d'affichage des dates
    Syntaxe:SSITimeFormat chaîne de formatage
    Défaut:SSITimeFormat "%A, %d-%b-%Y %H:%M:%S %Z"
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Base
    Module:mod_include
    -

    Cette directive permet de modifier le format d'affichage des -variables d'environnement DATE. La chaîne de -formatage est identique à celle de la fonction -strftime(3) de la bibliothèque C standard.

    +

    Si vous faites une comparaison directe (= ou + ==), vous pouvez extraire des parties de l'expression + rationnelle. Les parties extraites sont stockées dans les + variables spéciales $1 .. $9. L'ensemble + de la chaîne correspondant à l'expression rationnelle est stocké + dans la variable spéciale $0.

    -

    Cette directive a le même effet que l'élément - <!--#config timefmt=chaîne de formatage - -->.

    +

    Exemple

    + <!--#if expr="$QUERY_STRING = /^sid=([a-zA-Z0-9]+)/" -->
    + + <!--#set var="session" value="$1" -->
    +     + <!--#endif --> +

    + - 
    SSITimeFormat "%R, %B %d, %Y"
    +
    chaîne1 < chaîne2
    + chaîne1 <= chaîne2
    + chaîne1 > chaîne2
    + chaîne1 >= chaîne2
    +
    Compare chaîne1 à chaîne2. Notez que les + chaînes sont comparées de manière littérale (en utilisant + strcmp(3)). Ainsi, la chaîne "100" est inférieure à + "20".
    -

    Avec l'exemple ci-dessus, les dates seront affichées dans le - style "22:26, June 14, 2002".

    +
    ( test_condition )
    +
    vrai si test_condition est vrai
    -
    -
    top
    -

    Directive SSIUndefinedEcho

    - - - - - - - - -
    Description:Chaîne à afficher lorsqu'on tente d'extraire le contenu -d'une variable non définie
    Syntaxe:SSIUndefinedEcho chaîne
    Défaut:SSIUndefinedEcho "(none)"
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Base
    Module:mod_include
    -

    Cette directive permet de modifier la chaîne affichée par - mod_include lorsqu'on tente d'extraire le contenu - d'une variable non définie.

    +
    ! test_condition
    +
    vrai si test_condition est faux
    - 
    SSIUndefinedEcho "<!-- nondef -->"
    +
    test_condition1 && + test_condition2
    +
    vrai si test_condition1 et + test_condition2 sont tous les deux vrais
    +
    test_condition1 || + test_condition2
    +
    vrai si au moins un des tests test_condition1 ou + test_condition2 est vrai
    + -
    -
    top
    -

    Directive XBitHack

    - - - - - - - - -
    Description:Interprète les directives SSI dans les fichiers dont le bit -d'exécution est positionné
    Syntaxe:XBitHack on|off|full
    Défaut:XBitHack off
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:Options
    Statut:Base
    Module:mod_include
    -

    La directive XBitHack permet de contrôler - l'interprétation des documents html standards. Elle n'affecte que - les fichiers dont le type MIME est - text/html. XBitHack peut prendre - les valeurs suivantes :

    +

    "=" et "!=" ont une priorité supérieure + à "&&" et "||". "!" a + la priorité la plus haute. Ainsi, les deux directives suivantes sont + équivalentes :

    -
    -
    off
    -
    Aucun traitement particulier pour les fichiers - exécutables.
    +

    + <!--#if expr="$a = test1 && $b = test2" -->
    + <!--#if expr="($a = test1) && ($b = test2)" --> +

    -
    on
    -
    Tout fichier text/html dont le bit d'exécution - est positionné pour le propriétaire sera traité en tant que - document html interprété par le serveur.
    +

    Les opérateurs booléens && et + || ont la même priorité. Ainsi, si vous voulez + augmenter la priorité d'un de ces opérateurs, vous devez utiliser + des parenthèses.

    -
    full
    -
    Identique à on, avec test du bit d'exécution pour - le groupe. Si ce dernier est positionné, la date de dernière - modification du fichier renvoyé est définie à la date de - dernière modification du fichier. Dans le cas contraire, aucune - date de dernière modification n'est renvoyée. Le positionnement de - ce bit permet aux clients et aux mandataires de gérer la mise en - cache du résultat de la requête. +

    Tout ce qui n'est pas reconnu comme variable ou opérateur est + traité comme une chaîne. Les chaînes peuvent aussi être entourées + d'apostrophes : 'chaîne'. Les chaînes sans apostrophe + ne peuvent pas contenir d'espaces (espaces ou tabulations) car + ceux-ci servent à séparer certains éléments comme les variables. Si + plusieurs chaînes se trouvent dans une ligne, elles sont concaténées + en utilisant des espaces. Ainsi,

    -

    Note

    -

    Il est recommandé de n'utiliser l'option full que dans le cas - où vous êtes certain que le bit d'exécution du groupe est non - positionné pour les scripts SSI qui pourraient effectuer l'#include d'un programme CGI ou bien produire des sorties - différentes à chaque accès (ou seraient susceptibles d'être - modifiées au cours des requêtes ultérieures).

    +

    chaîne1    chaîne2 devient chaîne1 chaîne2
    +
    + et
    +
    + 'chaîne1    chaîne2' devient chaîne1    chaîne2.

    -

    Lorsqu'elle est définie à on, la directive - SSILastModified - l'emporte sur la directive XBitHack.

    -
    +

    Optimisation des expressions booléennes

    +

    Si les expressions atteignent une complexité suffisante pour + ralentir les traitements de manière significative, vous pouvez + essayer de les optimiser en fonction des règles d'évaluation :

    +
      +
    • Les expressions sont évaluées de la gauche vers la droite
      • +
    • Les opérateurs booléens binaires (&& et + ||) font l'objet d'une évaluation abrégée chaque fois + que cela est possible. En d'autres termes, et selon la règle + ci-dessus, mod_include évalue tout d'abord la + partie gauche de l'expression. Si le résultat de l'évaluation de + cette partie gauche suffit à déterminer le résultat final, + l'évaluation s'arrête ici. Dans le cas contraire, la partie droite + est évaluée, et le résultat final tient compte des résultats des + évaluations des parties gauche et droite.
      • +
    • L'évaluation abrégée est désactivée tant qu'il reste des + expressions régulières à traiter. Ces dernières doivent être + évaluées afin de définir les variables correspondant aux + références arrières ($1 .. $9).
      • +
    +

    Si vous voulez déterminer la manière dont une expression est + traitée, vous pouvez recompiler mod_include en + utilisant l'option de compilation -DDEBUG_INCLUDE. + Ceci a pour effet d'insérer, pour chaque expression interprétée, + des informations étiquetées, l'arbre d'interprétation et la + manière dont elle est évaluée au sein du flux de sortie envoyé au + client.

    +
    -
    -
    +

    Slashes d'échappement dans les expressions + rationnelles

    +

    Tous les caractères slashes qui ne sont pas des séparateurs dans + votre expression rationnelle doivent être échappés, et ceci sans + tenir compte de leur signification du point de vue du moteur + d'expressions rationnelles.

    +
    + +

    Documentation de référence

    +

    Voir le document Les expressions dans le + serveur HTTP Apache, pour une référence complète et des exemples.

    +
    diff --git a/docs/manual/mod/mod_include.html.ja.utf8 b/docs/manual/mod/mod_include.html.ja.utf8 index 60af7bb5315..be118a2384e 100644 --- a/docs/manual/mod/mod_include.html.ja.utf8 +++ b/docs/manual/mod/mod_include.html.ja.utf8 @@ -73,6 +73,225 @@
  • SSI チュートリアル
    • top
    +

    SSIEndTag ディレクティブ

    + + + + + + + + +
    説明:include 要素を終了させる文字列
    構文:SSIEndTag tag
    デフォルト:SSIEndTag "-->"
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Base
    モジュール:mod_include
    互換性:2.0.30 以降で利用可能
    +

    このディレクティブは mod_include が探す、 + include 要素の終了を示す文字列を変更します。

    + +

    例

    + SSIEndTag "%>" +

    + + +

    参照

    + +
    +
    top
    +

    SSIErrorMsg ディレクティブ

    + + + + + + + + + +
    説明:SSI のエラーがあったときに表示されるエラーメッセージ
    構文:SSIErrorMsg message
    デフォルト:SSIErrorMsg "[an error occurred while processing this +directive]"
    コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
    上書き:All
    ステータス:Base
    モジュール:mod_include
    互換性:バージョン 2.0.30 以降で使用可能
    +

    SSIErrorMsg ディレクティブは mod_include + がエラーが起こったときに表示するメッセージを変更します。プロダクションサーバでは + メッセージがユーザに表示されないようにするために + デフォルトエラーメッセージを "<!-- Error -->" + に変えるというようなことを考えるかもしれません。

    + +

    このディレクティブは <!--#config + errmsg=message --> 要素と同じ効果になります。

    + +

    例

    + SSIErrorMsg "<!-- Error -->" +

    + +
    +
    top
    +

    SSIETag ディレクティブ

    + + + + + + + + +
    説明:Controls whether ETags are generated by the server.
    構文:SSIETag on|off
    デフォルト:SSIETag off
    コンテキスト:ディレクトリ, .htaccess
    ステータス:Base
    モジュール:mod_include
    互換性:Available in version 2.2.15 and later.

    このディレクティブの解説文書は + まだ翻訳されていません。英語版をご覧ください。 +

    +
    top
    +

    SSILastModified ディレクティブ

    + + + + + + + + +
    説明:Controls whether Last-Modified headers are generated by the +server.
    構文:SSILastModified on|off
    デフォルト:SSILastModified off
    コンテキスト:ディレクトリ, .htaccess
    ステータス:Base
    モジュール:mod_include
    互換性:Available in version 2.2.15 and later.

    このディレクティブの解説文書は + まだ翻訳されていません。英語版をご覧ください。 +

    +
    top
    +

    SSILegacyExprParser ディレクティブ

    + + + + + + + + +
    説明:Enable compatibility mode for conditional expressions.
    構文:SSILegacyExprParser on|off
    デフォルト:SSILegacyExprParser off
    コンテキスト:ディレクトリ, .htaccess
    ステータス:Base
    モジュール:mod_include
    互換性:Available in version 2.3.13 and later.

    このディレクティブの解説文書は + まだ翻訳されていません。英語版をご覧ください。 +

    +
    top
    +

    SSIStartTag ディレクティブ

    + + + + + + + + +
    説明:include 要素を開始する文字列
    構文:SSIStartTag tag
    デフォルト:SSIStartTag "<!--#"
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Base
    モジュール:mod_include
    互換性:バージョン 2.0.30 以降で使用可能
    + +

    このディレクティブは mod_include が探す、include + 要素の開始を示す文字列を変更します。

    + +

    二つのサーバで (もしかすると別々の段階で) ファイルの出力を解析していて、 + それぞれに違うコマンドを処理させたい、 + というようなときにこのオプションを使います。

    + +

    例

    + SSIStartTag "<%"
    + SSIEndTag "%>" +

    + +

    上の例のように対応する + SSIEndTag を併せて使うと、 + 下に示す例のように SSI ディレクティブを使えます:

    + +

    違う開始と終了のタグを使った SSI ディレクティブ

    + <%printenv %> +

    + +

    参照

    + +
    +
    top
    +

    SSITimeFormat ディレクティブ

    + + + + + + + + + +
    説明:日付けを現す文字列の書式を設定する
    構文:SSITimeFormat formatstring
    デフォルト:SSITimeFormat "%A, %d-%b-%Y %H:%M:%S %Z"
    コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
    上書き:All
    ステータス:Base
    モジュール:mod_include
    互換性:2.0.30 以降で使用可能
    +

    このディレクティブは DATE 環境変数を echo して日付を現す文字列が + 表示されるときの書式を変更します。formatstring は + C 標準ライブラリの strftime(3) と同じ形式です。

    + +

    このディレクティブは <!--#config + timefmt=formatstring --> 要素と同じ効果になります。

    + +

    例

    + SSITimeFormat "%R, %B %d, %Y" +

    + +

    上のディレクティブでは、日付は "22:26, June 14, 2002" という + 形式で表示されます。

    + +
    +
    top
    +

    SSIUndefinedEcho ディレクティブ

    + + + + + + + + + +
    説明:未定義の変数が echo されたときに表示される文字列
    構文:SSIUndefinedEcho string
    デフォルト:SSIUndefinedEcho "(none)"
    コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
    上書き:All
    ステータス:Base
    モジュール:mod_include
    互換性:2.0.34 以降で利用可能
    +

    このディレクティブは変数が定義されていないにも関わらず + "echo" されたときに mod_include + が表示する文字列を変更します。

    + +

    例

    + SSIUndefinedEcho "<!-- undef -->" +

    + +
    +
    top
    +

    XBitHack ディレクティブ

    + + + + + + + + +
    説明:実行ビットが設定されたファイルの SSI ディレクティブを +解析する
    構文:XBitHack on|off|full
    デフォルト:XBitHack off
    コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
    上書き:Options
    ステータス:Base
    モジュール:mod_include
    +

    XBitHack ディレクティブは通常の HTML + ドキュメントの解析を制御します。このディレクティブは MIME タイプ + text/html と関連付けられているファイルにのみ影響します。 + XBitHack は以下の値をとることができます。

    + +
    +
    off
    +
    実行可能ファイルに対して特別な扱いをしません。
    + +
    on
    +
    ユーザの実行ビットが設定されている text/html + ファイルは全てサーバで解析する html ドキュメントとして扱われます。
    + +
    full
    +
    on と同様ですが、グループ実行ビットもテストします。 + もしそれが設定されていれば、返されるファイルの Last-modified の + 日付をファイルの最終修正時刻にします。それが設定されていないときは、 + last-modified の日付は送られません。このビットを設定すると、 + クライアントやプロキシがリクエストをキャッシュできるようになります。 + +
    注意 他の CGI を #include + するかもしれないものや、各アクセスに対して違う出力を生成する + (もしくは後のリクエストで変わるかもしれないもの) + すべての SSI スクリプトに対してグループ実行ビットが + 設定されていないことを確認できない場合は、full は使わない方が良い + でしょう。
    +
    +
    + + +
    +
    top

    Server-Side Includes を有効にする

    @@ -647,225 +866,6 @@ エスケープしなければなりません。 正規表現の意味がどうであろうとエスケープは必要です。

    -
    -
    top
    -

    SSIEndTag ディレクティブ

    - - - - - - - - -
    説明:include 要素を終了させる文字列
    構文:SSIEndTag tag
    デフォルト:SSIEndTag "-->"
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Base
    モジュール:mod_include
    互換性:2.0.30 以降で利用可能
    -

    このディレクティブは mod_include が探す、 - include 要素の終了を示す文字列を変更します。

    - -

    例

    - SSIEndTag "%>" -

    - - -

    参照

    - -
    -
    top
    -

    SSIErrorMsg ディレクティブ

    - - - - - - - - - -
    説明:SSI のエラーがあったときに表示されるエラーメッセージ
    構文:SSIErrorMsg message
    デフォルト:SSIErrorMsg "[an error occurred while processing this -directive]"
    コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
    上書き:All
    ステータス:Base
    モジュール:mod_include
    互換性:バージョン 2.0.30 以降で使用可能
    -

    SSIErrorMsg ディレクティブは mod_include - がエラーが起こったときに表示するメッセージを変更します。プロダクションサーバでは - メッセージがユーザに表示されないようにするために - デフォルトエラーメッセージを "<!-- Error -->" - に変えるというようなことを考えるかもしれません。

    - -

    このディレクティブは <!--#config - errmsg=message --> 要素と同じ効果になります。

    - -

    例

    - SSIErrorMsg "<!-- Error -->" -

    - -
    -
    top
    -

    SSIETag ディレクティブ

    - - - - - - - - -
    説明:Controls whether ETags are generated by the server.
    構文:SSIETag on|off
    デフォルト:SSIETag off
    コンテキスト:ディレクトリ, .htaccess
    ステータス:Base
    モジュール:mod_include
    互換性:Available in version 2.2.15 and later.

    このディレクティブの解説文書は - まだ翻訳されていません。英語版をご覧ください。 -

    -
    top
    -

    SSILastModified ディレクティブ

    - - - - - - - - -
    説明:Controls whether Last-Modified headers are generated by the -server.
    構文:SSILastModified on|off
    デフォルト:SSILastModified off
    コンテキスト:ディレクトリ, .htaccess
    ステータス:Base
    モジュール:mod_include
    互換性:Available in version 2.2.15 and later.

    このディレクティブの解説文書は - まだ翻訳されていません。英語版をご覧ください。 -

    -
    top
    -

    SSILegacyExprParser ディレクティブ

    - - - - - - - - -
    説明:Enable compatibility mode for conditional expressions.
    構文:SSILegacyExprParser on|off
    デフォルト:SSILegacyExprParser off
    コンテキスト:ディレクトリ, .htaccess
    ステータス:Base
    モジュール:mod_include
    互換性:Available in version 2.3.13 and later.

    このディレクティブの解説文書は - まだ翻訳されていません。英語版をご覧ください。 -

    -
    top
    -

    SSIStartTag ディレクティブ

    - - - - - - - - -
    説明:include 要素を開始する文字列
    構文:SSIStartTag tag
    デフォルト:SSIStartTag "<!--#"
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Base
    モジュール:mod_include
    互換性:バージョン 2.0.30 以降で使用可能
    - -

    このディレクティブは mod_include が探す、include - 要素の開始を示す文字列を変更します。

    - -

    二つのサーバで (もしかすると別々の段階で) ファイルの出力を解析していて、 - それぞれに違うコマンドを処理させたい、 - というようなときにこのオプションを使います。

    - -

    例

    - SSIStartTag "<%"
    - SSIEndTag "%>" -

    - -

    上の例のように対応する - SSIEndTag を併せて使うと、 - 下に示す例のように SSI ディレクティブを使えます:

    - -

    違う開始と終了のタグを使った SSI ディレクティブ

    - <%printenv %> -

    - -

    参照

    - -
    -
    top
    -

    SSITimeFormat ディレクティブ

    - - - - - - - - - -
    説明:日付けを現す文字列の書式を設定する
    構文:SSITimeFormat formatstring
    デフォルト:SSITimeFormat "%A, %d-%b-%Y %H:%M:%S %Z"
    コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
    上書き:All
    ステータス:Base
    モジュール:mod_include
    互換性:2.0.30 以降で使用可能
    -

    このディレクティブは DATE 環境変数を echo して日付を現す文字列が - 表示されるときの書式を変更します。formatstring は - C 標準ライブラリの strftime(3) と同じ形式です。

    - -

    このディレクティブは <!--#config - timefmt=formatstring --> 要素と同じ効果になります。

    - -

    例

    - SSITimeFormat "%R, %B %d, %Y" -

    - -

    上のディレクティブでは、日付は "22:26, June 14, 2002" という - 形式で表示されます。

    - -
    -
    top
    -

    SSIUndefinedEcho ディレクティブ

    - - - - - - - - - -
    説明:未定義の変数が echo されたときに表示される文字列
    構文:SSIUndefinedEcho string
    デフォルト:SSIUndefinedEcho "(none)"
    コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
    上書き:All
    ステータス:Base
    モジュール:mod_include
    互換性:2.0.34 以降で利用可能
    -

    このディレクティブは変数が定義されていないにも関わらず - "echo" されたときに mod_include - が表示する文字列を変更します。

    - -

    例

    - SSIUndefinedEcho "<!-- undef -->" -

    - -
    -
    top
    -

    XBitHack ディレクティブ

    - - - - - - - - -
    説明:実行ビットが設定されたファイルの SSI ディレクティブを -解析する
    構文:XBitHack on|off|full
    デフォルト:XBitHack off
    コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
    上書き:Options
    ステータス:Base
    モジュール:mod_include
    -

    XBitHack ディレクティブは通常の HTML - ドキュメントの解析を制御します。このディレクティブは MIME タイプ - text/html と関連付けられているファイルにのみ影響します。 - XBitHack は以下の値をとることができます。

    - -
    -
    off
    -
    実行可能ファイルに対して特別な扱いをしません。
    - -
    on
    -
    ユーザの実行ビットが設定されている text/html - ファイルは全てサーバで解析する html ドキュメントとして扱われます。
    - -
    full
    -
    on と同様ですが、グループ実行ビットもテストします。 - もしそれが設定されていれば、返されるファイルの Last-modified の - 日付をファイルの最終修正時刻にします。それが設定されていないときは、 - last-modified の日付は送られません。このビットを設定すると、 - クライアントやプロキシがリクエストをキャッシュできるようになります。 - -
    注意 他の CGI を #include - するかもしれないものや、各アクセスに対して違う出力を生成する - (もしくは後のリクエストで変わるかもしれないもの) - すべての SSI スクリプトに対してグループ実行ビットが - 設定されていないことを確認できない場合は、full は使わない方が良い - でしょう。
    -
    -
    - -
    diff --git a/docs/manual/mod/mod_info.html.en b/docs/manual/mod/mod_info.html.en index 1249991023c..79b5b0a86c5 100644 --- a/docs/manual/mod/mod_info.html.en +++ b/docs/manual/mod/mod_info.html.en @@ -70,6 +70,26 @@ configuration
  • Known Limitations
    • top
    +

    AddModuleInfo Directive

    + + + + + + +
    Description:Adds additional information to the module +information displayed by the server-info handler
    Syntax:AddModuleInfo module-name string
    Context:server config, virtual host
    Status:Extension
    Module:mod_info
    +

    This allows the content of string to be shown as + HTML interpreted, Additional Information for + the module module-name. Example:

    + + 
    AddModuleInfo mod_deflate.c 'See <a \
+    href="http://httpd.apache.org/docs/2.4/mod/mod_deflate.html">\
+    http://httpd.apache.org/docs/2.4/mod/mod_deflate.html</a>'
    + + +
    +
    top

    Security Issues

    Once mod_info is loaded into the server, its @@ -167,26 +187,6 @@ configuration

  • Directives generated by third party modules such as mod_perl might not be listed.
    • -
    -
    top
    -

    AddModuleInfo Directive

    - - - - - - -
    Description:Adds additional information to the module -information displayed by the server-info handler
    Syntax:AddModuleInfo module-name string
    Context:server config, virtual host
    Status:Extension
    Module:mod_info
    -

    This allows the content of string to be shown as - HTML interpreted, Additional Information for - the module module-name. Example:

    - - 
    AddModuleInfo mod_deflate.c 'See <a \
-    href="http://httpd.apache.org/docs/2.4/mod/mod_deflate.html">\
-    http://httpd.apache.org/docs/2.4/mod/mod_deflate.html</a>'
    - -
    diff --git a/docs/manual/mod/mod_info.html.fr b/docs/manual/mod/mod_info.html.fr index 1f4eac00b8e..0907a61358e 100644 --- a/docs/manual/mod/mod_info.html.fr +++ b/docs/manual/mod/mod_info.html.fr @@ -72,6 +72,26 @@ serveur
  • Limitations connues
    • top
    +

    Directive AddModuleInfo

    + + + + + + +
    Description:Ajoute des données supplémentaires aux informations de +module affichées par le gestionnaire server-info
    Syntaxe:AddModuleInfo nom-module chaîne
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_info
    +

    Cette directive permet d'afficher le contenu de chaîne + en tant qu'Information supplémentaire interprétée + en HTML pour le module nom-module. Exemple :

    + + 
    AddModuleInfo mod_deflate.c 'See <a \
+    href="http://httpd.apache.org/docs/2.4/mod/mod_deflate.html">\
+    http://httpd.apache.org/docs/2.4/mod/mod_deflate.html</a>'
    + + +
    +
    top

    Problèmes liés à la sécurité

    Une fois mod_info chargé dans le serveur, sa @@ -177,26 +197,6 @@ serveur mod_perl peuvent ne pas être prises en compte. -

    -
    top
    -

    Directive AddModuleInfo

    - - - - - - -
    Description:Ajoute des données supplémentaires aux informations de -module affichées par le gestionnaire server-info
    Syntaxe:AddModuleInfo nom-module chaîne
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_info
    -

    Cette directive permet d'afficher le contenu de chaîne - en tant qu'Information supplémentaire interprétée - en HTML pour le module nom-module. Exemple :

    - - 
    AddModuleInfo mod_deflate.c 'See <a \
-    href="http://httpd.apache.org/docs/2.4/mod/mod_deflate.html">\
-    http://httpd.apache.org/docs/2.4/mod/mod_deflate.html</a>'
    - -
    diff --git a/docs/manual/mod/mod_info.html.ja.utf8 b/docs/manual/mod/mod_info.html.ja.utf8 index fc88471218d..431ac736154 100644 --- a/docs/manual/mod/mod_info.html.ja.utf8 +++ b/docs/manual/mod/mod_info.html.ja.utf8 @@ -79,6 +79,30 @@
  • 既知の制限
    • top
    +

    AddModuleInfo ディレクティブ

    + + + + + + + +
    説明:server-info ハンドラにより表示されるモジュールの情報に +追加の情報を付け加える
    構文:AddModuleInfo module-name string
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Extension
    モジュール:mod_info
    互換性:Apache 1.3 以降
    +

    これは、string の内容がモジュール module-name + の追加情報 として HTML + として解釈され、表示されるようにします。例:

    + +

    + AddModuleInfo mod_deflate.c 'See <a \
    + + href="http://www.apache.org/docs/2.4/mod/mod_deflate.html">\
    + http://www.apache.org/docs/2.4/mod/mod_deflate.html</a>' +     +

    + +
    +
    top

    Security Issues

    一旦 mod_info がサーバに読み込まれると、 @@ -161,30 +185,6 @@ のディレクティブは表示されないかもしれません。

    -
    top
    -

    AddModuleInfo ディレクティブ

    - - - - - - - -
    説明:server-info ハンドラにより表示されるモジュールの情報に -追加の情報を付け加える
    構文:AddModuleInfo module-name string
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Extension
    モジュール:mod_info
    互換性:Apache 1.3 以降
    -

    これは、string の内容がモジュール module-name - の追加情報 として HTML - として解釈され、表示されるようにします。例:

    - -

    - AddModuleInfo mod_deflate.c 'See <a \
    - - href="http://www.apache.org/docs/2.4/mod/mod_deflate.html">\
    - http://www.apache.org/docs/2.4/mod/mod_deflate.html</a>' -     -

    - -

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_info.html.ko.euc-kr b/docs/manual/mod/mod_info.html.ko.euc-kr index d3af4d25b9f..66e42058207 100644 --- a/docs/manual/mod/mod_info.html.ko.euc-kr +++ b/docs/manual/mod/mod_info.html.ko.euc-kr @@ -63,6 +63,29 @@

  • ¾Ë·ÁÁø ÇÑ°è
    • top
    +

    AddModuleInfo Áö½Ã¾î

    + + + + + + + +
    ¼³¸í:¸ðµâ¿¡ ´ëÇÑ Ãß°¡ Á¤º¸¸¦ server-info Çڵ鷯°¡ º¸¿©ÁÖµµ·Ï +Ãß°¡ÇÑ´Ù
    ¹®¹ý:AddModuleInfo module-name string
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Extension
    ¸ðµâ:mod_info
    Áö¿ø:¾ÆÆÄÄ¡ 1.3 ÀÌÈÄ
    +

    module-name ¸ðµâ¿¡ ´ëÇÑ Ãß°¡ Á¤º¸·Î + stringÀÇ ³»¿ëÀ» HTML·Î º¸¿©ÁØ´Ù. ¿¹¸¦ µé¾î,

    + +

    + AddModuleInfo mod_deflate.c 'See <a \
    + + href="http://www.apache.org/docs/2.4/mod/mod_deflate.html">\
    + http://www.apache.org/docs/docs/2.4/mod/mod_deflate.html</a>' +     +

    + +
    +
    top

    º¸¾È ¹®Á¦

    Çѹø ¼­¹ö°¡ mod_info¸¦ ÀоîµéÀ̸é, µð·ºÅ丮º° @@ -139,29 +162,6 @@ Áö½Ã¾î¸¦ º¸¿©ÁÖÁö ¸øÇÒ ¼ö ÀÖ´Ù.

    -
    top
    -

    AddModuleInfo Áö½Ã¾î

    - - - - - - - -
    ¼³¸í:¸ðµâ¿¡ ´ëÇÑ Ãß°¡ Á¤º¸¸¦ server-info Çڵ鷯°¡ º¸¿©ÁÖµµ·Ï -Ãß°¡ÇÑ´Ù
    ¹®¹ý:AddModuleInfo module-name string
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Extension
    ¸ðµâ:mod_info
    Áö¿ø:¾ÆÆÄÄ¡ 1.3 ÀÌÈÄ
    -

    module-name ¸ðµâ¿¡ ´ëÇÑ Ãß°¡ Á¤º¸·Î - stringÀÇ ³»¿ëÀ» HTML·Î º¸¿©ÁØ´Ù. ¿¹¸¦ µé¾î,

    - -

    - AddModuleInfo mod_deflate.c 'See <a \
    - - href="http://www.apache.org/docs/2.4/mod/mod_deflate.html">\
    - http://www.apache.org/docs/docs/2.4/mod/mod_deflate.html</a>' -     -

    - -

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_isapi.html.en b/docs/manual/mod/mod_isapi.html.en index fff973ceeb3..5ec80d16842 100644 --- a/docs/manual/mod/mod_isapi.html.en +++ b/docs/manual/mod/mod_isapi.html.en @@ -63,6 +63,109 @@

  • Programmer's Journal
    • top
    +

    ISAPIAppendLogToErrors Directive

    + + + + + + + + +
    Description:Record HSE_APPEND_LOG_PARAMETER requests from +ISAPI extensions to the error log
    Syntax:ISAPIAppendLogToErrors on|off
    Default:ISAPIAppendLogToErrors off
    Context:server config, virtual host, directory, .htaccess
    Override:FileInfo
    Status:Base
    Module:mod_isapi
    +

    Record HSE_APPEND_LOG_PARAMETER requests from ISAPI + extensions to the server error log.

    + +
    +
    top
    +

    ISAPIAppendLogToQuery Directive

    + + + + + + + + +
    Description:Record HSE_APPEND_LOG_PARAMETER requests from +ISAPI extensions to the query field
    Syntax:ISAPIAppendLogToQuery on|off
    Default:ISAPIAppendLogToQuery on
    Context:server config, virtual host, directory, .htaccess
    Override:FileInfo
    Status:Base
    Module:mod_isapi
    +

    Record HSE_APPEND_LOG_PARAMETER requests from ISAPI + extensions to the query field (appended to the CustomLog %q + component).

    + +
    +
    top
    +

    ISAPICacheFile Directive

    + + + + + + +
    Description:ISAPI .dll files to be loaded at startup
    Syntax:ISAPICacheFile file-path [file-path] +...
    Context:server config, virtual host
    Status:Base
    Module:mod_isapi
    +

    Specifies a space-separated list of file names to be loaded + when the Apache server is launched, and remain loaded until the + server is shut down. This directive may be repeated for every + ISAPI .dll file desired. The full path name of each file should + be specified. If the path name is not absolute, it will be treated + relative to ServerRoot.

    + +
    +
    top
    +

    ISAPIFakeAsync Directive

    + + + + + + + + +
    Description:Fake asynchronous support for ISAPI callbacks
    Syntax:ISAPIFakeAsync on|off
    Default:ISAPIFakeAsync off
    Context:server config, virtual host, directory, .htaccess
    Override:FileInfo
    Status:Base
    Module:mod_isapi
    +

    While set to on, asynchronous support for ISAPI callbacks is + simulated.

    + +
    +
    top
    +

    ISAPILogNotSupported Directive

    + + + + + + + + +
    Description:Log unsupported feature requests from ISAPI +extensions
    Syntax:ISAPILogNotSupported on|off
    Default:ISAPILogNotSupported off
    Context:server config, virtual host, directory, .htaccess
    Override:FileInfo
    Status:Base
    Module:mod_isapi
    +

    Logs all requests for unsupported features from ISAPI + extensions in the server error log. This may help administrators + to track down problems. Once set to on and all desired ISAPI modules + are functioning, it should be set back to off.

    + +
    +
    top
    +

    ISAPIReadAheadBuffer Directive

    + + + + + + + + +
    Description:Size of the Read Ahead Buffer sent to ISAPI +extensions
    Syntax:ISAPIReadAheadBuffer size
    Default:ISAPIReadAheadBuffer 49152
    Context:server config, virtual host, directory, .htaccess
    Override:FileInfo
    Status:Base
    Module:mod_isapi
    +

    Defines the maximum size of the Read Ahead Buffer sent to + ISAPI extensions when they are initially invoked. All remaining + data must be retrieved using the ReadClient callback; some + ISAPI extensions may not support the ReadClient function. + Refer questions to the ISAPI extension's author.

    + +
    +
    top

    Usage

    @@ -232,109 +335,6 @@ TransmitFile semantics. Apache httpd also supports preloading ISAPI .dlls for performance.

    -
    top
    -

    ISAPIAppendLogToErrors Directive

    - - - - - - - - -
    Description:Record HSE_APPEND_LOG_PARAMETER requests from -ISAPI extensions to the error log
    Syntax:ISAPIAppendLogToErrors on|off
    Default:ISAPIAppendLogToErrors off
    Context:server config, virtual host, directory, .htaccess
    Override:FileInfo
    Status:Base
    Module:mod_isapi
    -

    Record HSE_APPEND_LOG_PARAMETER requests from ISAPI - extensions to the server error log.

    - -
    -
    top
    -

    ISAPIAppendLogToQuery Directive

    - - - - - - - - -
    Description:Record HSE_APPEND_LOG_PARAMETER requests from -ISAPI extensions to the query field
    Syntax:ISAPIAppendLogToQuery on|off
    Default:ISAPIAppendLogToQuery on
    Context:server config, virtual host, directory, .htaccess
    Override:FileInfo
    Status:Base
    Module:mod_isapi
    -

    Record HSE_APPEND_LOG_PARAMETER requests from ISAPI - extensions to the query field (appended to the CustomLog %q - component).

    - -
    -
    top
    -

    ISAPICacheFile Directive

    - - - - - - -
    Description:ISAPI .dll files to be loaded at startup
    Syntax:ISAPICacheFile file-path [file-path] -...
    Context:server config, virtual host
    Status:Base
    Module:mod_isapi
    -

    Specifies a space-separated list of file names to be loaded - when the Apache server is launched, and remain loaded until the - server is shut down. This directive may be repeated for every - ISAPI .dll file desired. The full path name of each file should - be specified. If the path name is not absolute, it will be treated - relative to ServerRoot.

    - -
    -
    top
    -

    ISAPIFakeAsync Directive

    - - - - - - - - -
    Description:Fake asynchronous support for ISAPI callbacks
    Syntax:ISAPIFakeAsync on|off
    Default:ISAPIFakeAsync off
    Context:server config, virtual host, directory, .htaccess
    Override:FileInfo
    Status:Base
    Module:mod_isapi
    -

    While set to on, asynchronous support for ISAPI callbacks is - simulated.

    - -
    -
    top
    -

    ISAPILogNotSupported Directive

    - - - - - - - - -
    Description:Log unsupported feature requests from ISAPI -extensions
    Syntax:ISAPILogNotSupported on|off
    Default:ISAPILogNotSupported off
    Context:server config, virtual host, directory, .htaccess
    Override:FileInfo
    Status:Base
    Module:mod_isapi
    -

    Logs all requests for unsupported features from ISAPI - extensions in the server error log. This may help administrators - to track down problems. Once set to on and all desired ISAPI modules - are functioning, it should be set back to off.

    - -
    -
    top
    -

    ISAPIReadAheadBuffer Directive

    - - - - - - - - -
    Description:Size of the Read Ahead Buffer sent to ISAPI -extensions
    Syntax:ISAPIReadAheadBuffer size
    Default:ISAPIReadAheadBuffer 49152
    Context:server config, virtual host, directory, .htaccess
    Override:FileInfo
    Status:Base
    Module:mod_isapi
    -

    Defines the maximum size of the Read Ahead Buffer sent to - ISAPI extensions when they are initially invoked. All remaining - data must be retrieved using the ReadClient callback; some - ISAPI extensions may not support the ReadClient function. - Refer questions to the ISAPI extension's author.

    - -

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_isapi.html.fr b/docs/manual/mod/mod_isapi.html.fr index 34665e78d13..b31bf1759ef 100644 --- a/docs/manual/mod/mod_isapi.html.fr +++ b/docs/manual/mod/mod_isapi.html.fr @@ -64,6 +64,120 @@

  • Journal du programmeur
    • top
    +

    Directive ISAPIAppendLogToErrors

    + + + + + + + + +
    Description:Enregistrement des requêtes +HSE_APPEND_LOG_PARAMETER de la part des extensions ISAPI +dans le journal des erreurs
    Syntaxe:ISAPIAppendLogToErrors on|off
    Défaut:ISAPIAppendLogToErrors off
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:FileInfo
    Statut:Base
    Module:mod_isapi
    +

    Cette directive permet d'enregistrer les requêtes + HSE_APPEND_LOG_PARAMETER de la part des extensions + ISAPI dans le journal des erreurs.

    + +
    +
    top
    +

    Directive ISAPIAppendLogToQuery

    + + + + + + + + +
    Description:Enregistre les requêtes +HSE_APPEND_LOG_PARAMETER de la part des extensions ISAPI +dans la partie arguments de la requête
    Syntaxe:ISAPIAppendLogToQuery on|off
    Défaut:ISAPIAppendLogToQuery on
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:FileInfo
    Statut:Base
    Module:mod_isapi
    +

    Cette directive permet d'enregistrer les requêtes + HSE_APPEND_LOG_PARAMETER de la part des extensions + ISAPI dans la partie arguments de la requête (ajouté au composant + %q de la directive CustomLog).

    + +
    +
    top
    +

    Directive ISAPICacheFile

    + + + + + + +
    Description:Fichiers .dll ISAPI devant être chargés au +démarrage
    Syntaxe:ISAPICacheFile chemin-fichier +[chemin-fichier] +...
    Contexte:configuration du serveur, serveur virtuel
    Statut:Base
    Module:mod_isapi
    +

    Cette directive permet de spécifier une liste, séparés par des + espaces, de noms de fichiers devant être chargés au démarrage + du serveur Apache, et rester en mémoire jusqu'à l'arrêt du serveur. + Cette directive peut être répétée pour chaque fichier .dll ISAPI + souhaité. Le chemin complet du fichier doit être spécifié. Si le + chemin n'est pas absolu, il sera considéré comme relatif au + répertoire défini par la directive ServerRoot.

    + +
    +
    top
    +

    Directive ISAPIFakeAsync

    + + + + + + + + +
    Description:Emulation du support des entrées/sorties asynchrones pour +les appels ISAPI
    Syntaxe:ISAPIFakeAsync on|off
    Défaut:ISAPIFakeAsync off
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:FileInfo
    Statut:Base
    Module:mod_isapi
    +

    Lorsquelle est définie à "on", cette directive permet d'émuler le + support des entrées/sorties asynchrones pour les appels ISAPI.

    + +
    +
    top
    +

    Directive ISAPILogNotSupported

    + + + + + + + + +
    Description:Journalisation des demandes de fonctionnalités non +supportées de la part des extensions ISAPI
    Syntaxe:ISAPILogNotSupported on|off
    Défaut:ISAPILogNotSupported off
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:FileInfo
    Statut:Base
    Module:mod_isapi
    +

    Cette directive permet d'enregistrer dans le journal des erreurs + toutes les demandes de fonctionnalités non supportées de la part des + extensions ISAPI. Ceci peut aider les administrateurs à décortiquer + certains problèmes. Lorsqu'elle a été définie à "on" et si tous les + modules ISAPI fonctionnent, elle peut être redéfinie à "off".

    + +
    +
    top
    +

    Directive ISAPIReadAheadBuffer

    + + + + + + + + +
    Description:Taille du tampon de lecture anticipée envoyé aux extensions +ISAPI
    Syntaxe:ISAPIReadAheadBuffer taille
    Défaut:ISAPIReadAheadBuffer 49152
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:FileInfo
    Statut:Base
    Module:mod_isapi
    +

    Cette directive permet de définir la taille maximale du tampon de + lecture anticipée envoyé aux extensions ISAPI lorsqu'elles sont + initialement invoquées. Toute donnée restante doit être extraite en + faisant appel à ReadClient ; certaines extensions ISAPI + peuvent ne pas supporter la fonction ReadClient. + Pour plus de détails, veuillez vous adresser à l'auteur de + l'extension ISAPI.

    + +
    +
    top

    Utilisation

    @@ -243,120 +357,6 @@ TransmitFile. Apache httpd supporte aussi le préchargement des .dlls ISAPI à des fins de performances.

    -
    top
    -

    Directive ISAPIAppendLogToErrors

    - - - - - - - - -
    Description:Enregistrement des requêtes -HSE_APPEND_LOG_PARAMETER de la part des extensions ISAPI -dans le journal des erreurs
    Syntaxe:ISAPIAppendLogToErrors on|off
    Défaut:ISAPIAppendLogToErrors off
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:FileInfo
    Statut:Base
    Module:mod_isapi
    -

    Cette directive permet d'enregistrer les requêtes - HSE_APPEND_LOG_PARAMETER de la part des extensions - ISAPI dans le journal des erreurs.

    - -
    -
    top
    -

    Directive ISAPIAppendLogToQuery

    - - - - - - - - -
    Description:Enregistre les requêtes -HSE_APPEND_LOG_PARAMETER de la part des extensions ISAPI -dans la partie arguments de la requête
    Syntaxe:ISAPIAppendLogToQuery on|off
    Défaut:ISAPIAppendLogToQuery on
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:FileInfo
    Statut:Base
    Module:mod_isapi
    -

    Cette directive permet d'enregistrer les requêtes - HSE_APPEND_LOG_PARAMETER de la part des extensions - ISAPI dans la partie arguments de la requête (ajouté au composant - %q de la directive CustomLog).

    - -
    -
    top
    -

    Directive ISAPICacheFile

    - - - - - - -
    Description:Fichiers .dll ISAPI devant être chargés au -démarrage
    Syntaxe:ISAPICacheFile chemin-fichier -[chemin-fichier] -...
    Contexte:configuration du serveur, serveur virtuel
    Statut:Base
    Module:mod_isapi
    -

    Cette directive permet de spécifier une liste, séparés par des - espaces, de noms de fichiers devant être chargés au démarrage - du serveur Apache, et rester en mémoire jusqu'à l'arrêt du serveur. - Cette directive peut être répétée pour chaque fichier .dll ISAPI - souhaité. Le chemin complet du fichier doit être spécifié. Si le - chemin n'est pas absolu, il sera considéré comme relatif au - répertoire défini par la directive ServerRoot.

    - -
    -
    top
    -

    Directive ISAPIFakeAsync

    - - - - - - - - -
    Description:Emulation du support des entrées/sorties asynchrones pour -les appels ISAPI
    Syntaxe:ISAPIFakeAsync on|off
    Défaut:ISAPIFakeAsync off
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:FileInfo
    Statut:Base
    Module:mod_isapi
    -

    Lorsquelle est définie à "on", cette directive permet d'émuler le - support des entrées/sorties asynchrones pour les appels ISAPI.

    - -
    -
    top
    -

    Directive ISAPILogNotSupported

    - - - - - - - - -
    Description:Journalisation des demandes de fonctionnalités non -supportées de la part des extensions ISAPI
    Syntaxe:ISAPILogNotSupported on|off
    Défaut:ISAPILogNotSupported off
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:FileInfo
    Statut:Base
    Module:mod_isapi
    -

    Cette directive permet d'enregistrer dans le journal des erreurs - toutes les demandes de fonctionnalités non supportées de la part des - extensions ISAPI. Ceci peut aider les administrateurs à décortiquer - certains problèmes. Lorsqu'elle a été définie à "on" et si tous les - modules ISAPI fonctionnent, elle peut être redéfinie à "off".

    - -
    -
    top
    -

    Directive ISAPIReadAheadBuffer

    - - - - - - - - -
    Description:Taille du tampon de lecture anticipée envoyé aux extensions -ISAPI
    Syntaxe:ISAPIReadAheadBuffer taille
    Défaut:ISAPIReadAheadBuffer 49152
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:FileInfo
    Statut:Base
    Module:mod_isapi
    -

    Cette directive permet de définir la taille maximale du tampon de - lecture anticipée envoyé aux extensions ISAPI lorsqu'elles sont - initialement invoquées. Toute donnée restante doit être extraite en - faisant appel à ReadClient ; certaines extensions ISAPI - peuvent ne pas supporter la fonction ReadClient. - Pour plus de détails, veuillez vous adresser à l'auteur de - l'extension ISAPI.

    - -

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_isapi.html.ko.euc-kr b/docs/manual/mod/mod_isapi.html.ko.euc-kr index c83a2573dfd..d69353641bc 100644 --- a/docs/manual/mod/mod_isapi.html.ko.euc-kr +++ b/docs/manual/mod/mod_isapi.html.ko.euc-kr @@ -63,6 +63,106 @@

  • °³¹ßÀÚ Á¤º¸
    • top
    +

    ISAPIAppendLogToErrors Áö½Ã¾î

    + + + + + + + + +
    ¼³¸í:ISAPI exntensionÀÇ HSE_APPEND_LOG_PARAMETER +¿äûÀ» ¿À·ù ·Î±×¿¡ ±â·ÏÇÑ´Ù
    ¹®¹ý:ISAPIAppendLogToErrors on|off
    ±âº»°ª:ISAPIAppendLogToErrors off
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    Override ¿É¼Ç:FileInfo
    »óÅÂ:Base
    ¸ðµâ:mod_isapi
    +

    ISAPI exntensionÀÇ HSE_APPEND_LOG_PARAMETER + ¿äûÀ» ¿À·ù ·Î±×¿¡ ±â·ÏÇÑ´Ù.

    + +
    +
    top
    +

    ISAPIAppendLogToQuery Áö½Ã¾î

    + + + + + + + + +
    ¼³¸í:ISAPI exntensionÀÇ HSE_APPEND_LOG_PARAMETER +¿äûÀ» ÁúÀǹ®ÀÚ¿­¿¡ ±â·ÏÇÑ´Ù
    ¹®¹ý:ISAPIAppendLogToQuery on|off
    ±âº»°ª:ISAPIAppendLogToQuery on
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    Override ¿É¼Ç:FileInfo
    »óÅÂ:Base
    ¸ðµâ:mod_isapi
    +

    ISAPI exntensionÀÇ HSE_APPEND_LOG_PARAMETER + ¿äûÀ» ÁúÀǹ®ÀÚ¿­¿¡ ±â·ÏÇÑ´Ù (CustomLog %q + Ç׸ñ¿¡ µ¡ºÙÀδÙ).

    + +
    +
    top
    +

    ISAPICacheFile Áö½Ã¾î

    + + + + + + +
    ¼³¸í:¼­¹ö°¡ ½ÃÀÛÇÒ¶§ ¸Þ¸ð¸®·Î ÀоîµéÀÏ ISAPI .dll ÆÄÀϵé
    ¹®¹ý:ISAPICacheFile file-path [file-path] +...
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Base
    ¸ðµâ:mod_isapi
    +

    ¾ÆÆÄÄ¡ ¼­¹ö°¡ ½ÃÀÛÇÒ¶§ ¸Þ¸ð¸®·Î Àоîµé¿©¼­ ¼­¹ö¸¦ Á¾·áÇÒ¶§±îÁö + ¸Þ¸ð¸®¿¡ ³²¾ÆÀÖÀ» ÆÄÀϸíÀ» °ø¹éÀ¸·Î ±¸ºÐÇÏ¿© ÁöÁ¤ÇÑ´Ù. ÀÌ + Áö½Ã¾î´Â ISAPI .dll ÆÄÀϺ°·Î ¿©·¯¹ø »ç¿ëÇÒ ¼ö ÀÖ´Ù. ÆÄÀÏÀÇ + Àüü °æ·Î¸¦ Àû´Â´Ù. Àý´ë °æ·Î°¡ ¾Æ´Ï¸é ServerRoot¿¡ »ó´ë °æ·Î·Î ¹Þ¾ÆµéÀδÙ.

    + +
    +
    top
    +

    ISAPIFakeAsync Áö½Ã¾î

    + + + + + + + + +
    ¼³¸í:ºñµ¿±â ISAPI ÄݹéÀ» Áö¿øÇϴ ôÇÑ´Ù
    ¹®¹ý:ISAPIFakeAsync on|off
    ±âº»°ª:ISAPIFakeAsync off
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    Override ¿É¼Ç:FileInfo
    »óÅÂ:Base
    ¸ðµâ:mod_isapi
    +

    onÀ¸·Î ¼³Á¤ÇÏ¸é ºñµ¿±â ISAPI Äݹé Áö¿øÀ» Èä³»³½´Ù.

    + +
    +
    top
    +

    ISAPILogNotSupported Áö½Ã¾î

    + + + + + + + + +
    ¼³¸í:ISAPI extensionÀÌ Áö¿øÇÏÁö ¾Ê´Â ±â´ÉÀ» ¿äûÇϸé +·Î±×¿¡ ±â·ÏÇÑ´Ù
    ¹®¹ý:ISAPILogNotSupported on|off
    ±âº»°ª:ISAPILogNotSupported off
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    Override ¿É¼Ç:FileInfo
    »óÅÂ:Base
    ¸ðµâ:mod_isapi
    +

    ISAPI extensionÀÌ Áö¿øÇÏÁö ¾Ê´Â ±â´ÉÀ» ¿äûÇÏ¸é ¼­¹ö + ¿À·ù ·Î±×¿¡ ±â·ÏÇÑ´Ù. ³ªÁß¿¡ °ü¸®ÀÚ°¡ ¹®Á¦¸¦ ÃßÀûÇϴµ¥ + µµ¿òÀÌ µÈ´Ù. ¿øÇÏ´Â ¸ðµç ISAPI ¸ðµâÀÌ Á¤»óÀûÀ¸·Î µ¿ÀÛÇϸé + ´Ù½Ã off·Î µÇµ¹·Á¾ß ÇÑ´Ù.

    + +
    +
    top
    +

    ISAPIReadAheadBuffer Áö½Ã¾î

    + + + + + + + + +
    ¼³¸í:ISAPI extensionÀÇ ¹Ì¸®Àбâ¹öÆÛ(read ahead buffer) +Å©±â
    ¹®¹ý:ISAPIReadAheadBuffer size
    ±âº»°ª:ISAPIReadAheadBuffer 49152
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    Override ¿É¼Ç:FileInfo
    »óÅÂ:Base
    ¸ðµâ:mod_isapi
    +

    ISAPI extensionÀ» óÀ½ È£ÃâÇÒ¶§ ¹Ì¸®Àбâ¹öÆÛÀÇ ÃÖ´ë Å©±â¸¦ + ÁöÁ¤ÇÑ´Ù. (ÀÌ Å©±âº¸´Ù Å«) ³ª¸ÓÁö ÀÚ·á´Â ReadClient + ÄݹéÀ» »ç¿ëÇÏ¿© Àоî¾ß ÇÑ´Ù. ¾î¶² ISAPI extensionÀº + ReadClient ±â´ÉÀ» Áö¿øÇÏÁö ¾Ê´Â´Ù. ÀÌ °æ¿ì + ISAPI extension Á¦ÀÛÀÚ¿¡°Ô ¹®ÀÇÇ϶ó.

    + +
    +
    top

    »ç¿ë¹ý

    @@ -213,106 +313,6 @@ .dllÀ» ¹Ì¸® Àоîµé¿©¼­ ¼º´ÉÀ» ³ôÀÌ´Â ¾ÆÆÄÄ¡ 1.3 mod_isapi¿¡´Â ¾ø´Â ±â´ÉÀ» Áö¿øÇÑ´Ù.

    -
    top
    -

    ISAPIAppendLogToErrors Áö½Ã¾î

    - - - - - - - - -
    ¼³¸í:ISAPI exntensionÀÇ HSE_APPEND_LOG_PARAMETER -¿äûÀ» ¿À·ù ·Î±×¿¡ ±â·ÏÇÑ´Ù
    ¹®¹ý:ISAPIAppendLogToErrors on|off
    ±âº»°ª:ISAPIAppendLogToErrors off
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    Override ¿É¼Ç:FileInfo
    »óÅÂ:Base
    ¸ðµâ:mod_isapi
    -

    ISAPI exntensionÀÇ HSE_APPEND_LOG_PARAMETER - ¿äûÀ» ¿À·ù ·Î±×¿¡ ±â·ÏÇÑ´Ù.

    - -
    -
    top
    -

    ISAPIAppendLogToQuery Áö½Ã¾î

    - - - - - - - - -
    ¼³¸í:ISAPI exntensionÀÇ HSE_APPEND_LOG_PARAMETER -¿äûÀ» ÁúÀǹ®ÀÚ¿­¿¡ ±â·ÏÇÑ´Ù
    ¹®¹ý:ISAPIAppendLogToQuery on|off
    ±âº»°ª:ISAPIAppendLogToQuery on
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    Override ¿É¼Ç:FileInfo
    »óÅÂ:Base
    ¸ðµâ:mod_isapi
    -

    ISAPI exntensionÀÇ HSE_APPEND_LOG_PARAMETER - ¿äûÀ» ÁúÀǹ®ÀÚ¿­¿¡ ±â·ÏÇÑ´Ù (CustomLog %q - Ç׸ñ¿¡ µ¡ºÙÀδÙ).

    - -
    -
    top
    -

    ISAPICacheFile Áö½Ã¾î

    - - - - - - -
    ¼³¸í:¼­¹ö°¡ ½ÃÀÛÇÒ¶§ ¸Þ¸ð¸®·Î ÀоîµéÀÏ ISAPI .dll ÆÄÀϵé
    ¹®¹ý:ISAPICacheFile file-path [file-path] -...
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Base
    ¸ðµâ:mod_isapi
    -

    ¾ÆÆÄÄ¡ ¼­¹ö°¡ ½ÃÀÛÇÒ¶§ ¸Þ¸ð¸®·Î Àоîµé¿©¼­ ¼­¹ö¸¦ Á¾·áÇÒ¶§±îÁö - ¸Þ¸ð¸®¿¡ ³²¾ÆÀÖÀ» ÆÄÀϸíÀ» °ø¹éÀ¸·Î ±¸ºÐÇÏ¿© ÁöÁ¤ÇÑ´Ù. ÀÌ - Áö½Ã¾î´Â ISAPI .dll ÆÄÀϺ°·Î ¿©·¯¹ø »ç¿ëÇÒ ¼ö ÀÖ´Ù. ÆÄÀÏÀÇ - Àüü °æ·Î¸¦ Àû´Â´Ù. Àý´ë °æ·Î°¡ ¾Æ´Ï¸é ServerRoot¿¡ »ó´ë °æ·Î·Î ¹Þ¾ÆµéÀδÙ.

    - -
    -
    top
    -

    ISAPIFakeAsync Áö½Ã¾î

    - - - - - - - - -
    ¼³¸í:ºñµ¿±â ISAPI ÄݹéÀ» Áö¿øÇϴ ôÇÑ´Ù
    ¹®¹ý:ISAPIFakeAsync on|off
    ±âº»°ª:ISAPIFakeAsync off
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    Override ¿É¼Ç:FileInfo
    »óÅÂ:Base
    ¸ðµâ:mod_isapi
    -

    onÀ¸·Î ¼³Á¤ÇÏ¸é ºñµ¿±â ISAPI Äݹé Áö¿øÀ» Èä³»³½´Ù.

    - -
    -
    top
    -

    ISAPILogNotSupported Áö½Ã¾î

    - - - - - - - - -
    ¼³¸í:ISAPI extensionÀÌ Áö¿øÇÏÁö ¾Ê´Â ±â´ÉÀ» ¿äûÇϸé -·Î±×¿¡ ±â·ÏÇÑ´Ù
    ¹®¹ý:ISAPILogNotSupported on|off
    ±âº»°ª:ISAPILogNotSupported off
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    Override ¿É¼Ç:FileInfo
    »óÅÂ:Base
    ¸ðµâ:mod_isapi
    -

    ISAPI extensionÀÌ Áö¿øÇÏÁö ¾Ê´Â ±â´ÉÀ» ¿äûÇÏ¸é ¼­¹ö - ¿À·ù ·Î±×¿¡ ±â·ÏÇÑ´Ù. ³ªÁß¿¡ °ü¸®ÀÚ°¡ ¹®Á¦¸¦ ÃßÀûÇϴµ¥ - µµ¿òÀÌ µÈ´Ù. ¿øÇÏ´Â ¸ðµç ISAPI ¸ðµâÀÌ Á¤»óÀûÀ¸·Î µ¿ÀÛÇϸé - ´Ù½Ã off·Î µÇµ¹·Á¾ß ÇÑ´Ù.

    - -
    -
    top
    -

    ISAPIReadAheadBuffer Áö½Ã¾î

    - - - - - - - - -
    ¼³¸í:ISAPI extensionÀÇ ¹Ì¸®Àбâ¹öÆÛ(read ahead buffer) -Å©±â
    ¹®¹ý:ISAPIReadAheadBuffer size
    ±âº»°ª:ISAPIReadAheadBuffer 49152
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    Override ¿É¼Ç:FileInfo
    »óÅÂ:Base
    ¸ðµâ:mod_isapi
    -

    ISAPI extensionÀ» óÀ½ È£ÃâÇÒ¶§ ¹Ì¸®Àбâ¹öÆÛÀÇ ÃÖ´ë Å©±â¸¦ - ÁöÁ¤ÇÑ´Ù. (ÀÌ Å©±âº¸´Ù Å«) ³ª¸ÓÁö ÀÚ·á´Â ReadClient - ÄݹéÀ» »ç¿ëÇÏ¿© Àоî¾ß ÇÑ´Ù. ¾î¶² ISAPI extensionÀº - ReadClient ±â´ÉÀ» Áö¿øÇÏÁö ¾Ê´Â´Ù. ÀÌ °æ¿ì - ISAPI extension Á¦ÀÛÀÚ¿¡°Ô ¹®ÀÇÇ϶ó.

    - -

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_lbmethod_heartbeat.html.en b/docs/manual/mod/mod_lbmethod_heartbeat.html.en index 83c839e4c1a..80ec10490e4 100644 --- a/docs/manual/mod/mod_lbmethod_heartbeat.html.en +++ b/docs/manual/mod/mod_lbmethod_heartbeat.html.en @@ -53,7 +53,6 @@ assumption that they are not fully initialized.

  • mod_heartbeat
  • mod_heartmonitor
    • -
    top

    HeartbeatStorage Directive

    @@ -69,6 +68,7 @@ assumption that they are not fully initialized.

    mod_slotmem_shm is not loaded.

    +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_lbmethod_heartbeat.html.fr b/docs/manual/mod/mod_lbmethod_heartbeat.html.fr index e48ad1df5ee..5225d278af8 100644 --- a/docs/manual/mod/mod_lbmethod_heartbeat.html.fr +++ b/docs/manual/mod/mod_lbmethod_heartbeat.html.fr @@ -58,7 +58,6 @@ comme non enti

  • mod_heartbeat
  • mod_heartmonitor
    • -
    top

    Directive HeartbeatStorage

    @@ -76,6 +75,7 @@ heartbeat n'est pas chargé.

    +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_ldap.html.en b/docs/manual/mod/mod_ldap.html.en index 9092d58f57e..8136f64d27e 100644 --- a/docs/manual/mod/mod_ldap.html.en +++ b/docs/manual/mod/mod_ldap.html.en @@ -85,6 +85,421 @@ by other LDAP modules

  • SSL/TLS Certificates
    • top
    +

    LDAPCacheEntries Directive

    +
    + + + + + + +
    Description:Maximum number of entries in the primary LDAP cache
    Syntax:LDAPCacheEntries number
    Default:LDAPCacheEntries 1024
    Context:server config
    Status:Extension
    Module:mod_ldap
    +

    Specifies the maximum size of the primary LDAP cache. This + cache contains successful search/binds. Set it to 0 to turn off + search/bind caching. The default size is 1024 cached + searches.

    + +
    +
    top
    +

    LDAPCacheTTL Directive

    + + + + + + + +
    Description:Time that cached items remain valid
    Syntax:LDAPCacheTTL seconds
    Default:LDAPCacheTTL 600
    Context:server config
    Status:Extension
    Module:mod_ldap
    +

    Specifies the time (in seconds) that an item in the + search/bind cache remains valid. The default is 600 seconds (10 + minutes).

    + +
    +
    top
    +

    LDAPConnectionPoolTTL Directive

    + + + + + + + + +
    Description:Discard backend connections that have been sitting in the connection pool too long
    Syntax:LDAPConnectionPoolTTL n
    Default:LDAPConnectionPoolTTL -1
    Context:server config, virtual host
    Status:Extension
    Module:mod_ldap
    Compatibility:Apache HTTP Server 2.3.12 and later
    +

    Specifies the maximum age, in seconds, that a pooled LDAP connection can remain idle + and still be available for use. Connections are cleaned up when they are next needed, + not asynchronously.

    + +

    A setting of 0 causes connections to never be saved in the backend + connection pool. The default value of -1, and any other negative value, + allows connections of any age to be reused.

    + +

    For performance reasons, the reference time used by this directive is + based on when the LDAP connection is returned to the pool, not the time + of the last successful I/O with the LDAP server.

    + +

    Since 2.4.10, new measures are in place to avoid the reference time + from being inflated by cache hits or slow requests. First, the reference + time is not updated if no backend LDAP conncetions were needed. Second, + the reference time uses the time the HTTP request was received instead + of the time the request is completed.

    + +

    This timeout defaults to units of seconds, but accepts + suffixes for milliseconds (ms), minutes (min), and hours (h). +

    + +
    +
    top
    +

    LDAPConnectionTimeout Directive

    + + + + + + +
    Description:Specifies the socket connection timeout in seconds
    Syntax:LDAPConnectionTimeout seconds
    Context:server config
    Status:Extension
    Module:mod_ldap
    +

    This directive configures the LDAP_OPT_NETWORK_TIMEOUT (or LDAP_OPT_CONNECT_TIMEOUT) + option in the underlying LDAP client library, when available. This value + typically controls how long the LDAP client library will wait for the TCP + connection to the LDAP server to complete.

    + +

    If a connection is not successful with the timeout period, either an error will be + returned or the LDAP client library will attempt to connect to a secondary LDAP + server if one is specified (via a space-separated list of hostnames in the + AuthLDAPURL).

    + +

    The default is 10 seconds, if the LDAP client library linked with the + server supports the LDAP_OPT_NETWORK_TIMEOUT option.

    + +
    LDAPConnectionTimeout is only available when the LDAP client library linked + with the server supports the LDAP_OPT_NETWORK_TIMEOUT + (or LDAP_OPT_CONNECT_TIMEOUT) option, and the ultimate behavior is + dictated entirely by the LDAP client library. +
    + +
    +
    top
    +

    LDAPLibraryDebug Directive

    + + + + + + + +
    Description:Enable debugging in the LDAP SDK
    Syntax:LDAPLibraryDebug 7
    Default:disabled
    Context:server config
    Status:Extension
    Module:mod_ldap
    +

    Turns on SDK-specific LDAP debug options that generally cause the LDAP + SDK to log verbose trace information to the main Apache error log. + The trace messages from the LDAP SDK provide gory details that + can be useful during debugging of connectivity problems with backend LDAP servers

    + +

    This option is only configurable when Apache HTTP Server is linked with + an LDAP SDK that implements LDAP_OPT_DEBUG or + LDAP_OPT_DEBUG_LEVEL, such as OpenLDAP (a value of 7 is verbose) + or Tivoli Directory Server (a value of 65535 is verbose).

    + +
    +

    The logged information will likely contain plaintext credentials being used or + validated by LDAP authentication, so care should be taken in protecting and purging + the error log when this directive is used.

    +
    + + +
    +
    top
    +

    LDAPOpCacheEntries Directive

    + + + + + + + +
    Description:Number of entries used to cache LDAP compare +operations
    Syntax:LDAPOpCacheEntries number
    Default:LDAPOpCacheEntries 1024
    Context:server config
    Status:Extension
    Module:mod_ldap
    +

    This specifies the number of entries mod_ldap + will use to cache LDAP compare operations. The default is 1024 + entries. Setting it to 0 disables operation caching.

    + +
    +
    top
    +

    LDAPOpCacheTTL Directive

    + + + + + + + +
    Description:Time that entries in the operation cache remain +valid
    Syntax:LDAPOpCacheTTL seconds
    Default:LDAPOpCacheTTL 600
    Context:server config
    Status:Extension
    Module:mod_ldap
    +

    Specifies the time (in seconds) that entries in the + operation cache remain valid. The default is 600 seconds.

    + +
    +
    top
    +

    LDAPReferralHopLimit Directive

    + + + + + + + + +
    Description:The maximum number of referral hops to chase before terminating an LDAP query.
    Syntax:LDAPReferralHopLimit number
    Default:SDK dependent, typically between 5 and 10
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_ldap
    +

    This directive, if enabled by the LDAPReferrals directive, + limits the number of referral hops that are followed before terminating an + LDAP query.

    + +
    +

    Support for this tunable is uncommon in LDAP SDKs.

    +
    + +
    +
    top
    +

    LDAPReferrals Directive

    + + + + + + + + + +
    Description:Enable referral chasing during queries to the LDAP server.
    Syntax:LDAPReferrals On|Off|default
    Default:LDAPReferrals On
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_ldap
    Compatibility:The default parameter is available in Apache 2.4.7 and later
    +

    Some LDAP servers divide their directory among multiple domains and use referrals + to direct a client when a domain boundary is crossed. This is similar to a HTTP redirect. + LDAP client libraries may or may not chase referrals by default. This directive + explicitly configures the referral chasing in the underlying SDK.

    + + +

    LDAPReferrals takes the following values:

    +
    +
    "on"
    +

    When set to "on", the underlying SDK's referral chasing state + is enabled, LDAPReferralHopLimit is used to + override the SDK's hop limit, and an LDAP rebind callback is + registered.

    +
    "off"
    +

    When set to "off", the underlying SDK's referral chasing state + is disabled completely.

    +
    "default"
    +

    When set to "default", the underlying SDK's referral chasing state + is not changed, LDAPReferralHopLimit is not + used to overide the SDK's hop limit, and no LDAP rebind callback is + registered.

    +
    + +

    The directive LDAPReferralHopLimit works in conjunction with + this directive to limit the number of referral hops to follow before terminating the LDAP query. + When referral processing is enabled by a value of "On", client credentials will be provided, + via a rebind callback, for any LDAP server requiring them.

    + +
    +
    top
    +

    LDAPRetries Directive

    + + + + + + + +
    Description:Configures the number of LDAP server retries.
    Syntax:LDAPRetries number-of-retries
    Default:LDAPRetries 3
    Context:server config
    Status:Extension
    Module:mod_ldap
    +

    The server will retry failed LDAP requests up to + LDAPRetries times. Setting this + directive to 0 disables retries.

    +

    LDAP errors such as timeouts and refused connections are retryable.

    + +
    +
    top
    +

    LDAPRetryDelay Directive

    + + + + + + + +
    Description:Configures the delay between LDAP server retries.
    Syntax:LDAPRetryDelay seconds
    Default:LDAPRetryDelay 0
    Context:server config
    Status:Extension
    Module:mod_ldap
    +

    If LDAPRetryDelay is set to a non-zero + value, the server will delay retrying an LDAP request for the + specified amount of time. Setting this directive to 0 will + result in any retry to occur without delay.

    + +

    LDAP errors such as timeouts and refused connections are retryable.

    + +
    +
    top
    +

    LDAPSharedCacheFile Directive

    + + + + + + +
    Description:Sets the shared memory cache file
    Syntax:LDAPSharedCacheFile directory-path/filename
    Context:server config
    Status:Extension
    Module:mod_ldap
    +

    Specifies the directory path and file name of the shared memory + cache file. If not set, anonymous shared memory will be used if the + platform supports it.

    + +
    +
    top
    +

    LDAPSharedCacheSize Directive

    + + + + + + + +
    Description:Size in bytes of the shared-memory cache
    Syntax:LDAPSharedCacheSize bytes
    Default:LDAPSharedCacheSize 500000
    Context:server config
    Status:Extension
    Module:mod_ldap
    +

    Specifies the number of bytes to allocate for the shared + memory cache. The default is 500kb. If set to 0, shared memory + caching will not be used and every HTTPD process will create its + own cache.

    + +
    +
    top
    +

    LDAPTimeout Directive

    + + + + + + + + +
    Description:Specifies the timeout for LDAP search and bind operations, in seconds
    Syntax:LDAPTimeout seconds
    Default:LDAPTimeout 60
    Context:server config
    Status:Extension
    Module:mod_ldap
    Compatibility:Apache HTTP Server 2.3.5 and later
    +

    This directive configures the timeout for bind and search operations, as well as + the LDAP_OPT_TIMEOUT option in the underlying LDAP client library, when available.

    + +

    If the timeout expires, httpd will retry in case an existing connection has + been silently dropped by a firewall. However, performance will be much better if + the firewall is configured to send TCP RST packets instead of silently dropping + packets.

    + +
    +

    Timeouts for ldap compare operations requires an SDK with LDAP_OPT_TIMEOUT, such as OpenLDAP >= 2.4.4.

    +
    + + +
    +
    top
    +

    LDAPTrustedClientCert Directive

    + + + + + + +
    Description:Sets the file containing or nickname referring to a per +connection client certificate. Not all LDAP toolkits support per +connection client certificates.
    Syntax:LDAPTrustedClientCert type directory-path/filename/nickname [password]
    Context:directory, .htaccess
    Status:Extension
    Module:mod_ldap
    +

    It specifies the directory path, file name or nickname of a + per connection client certificate used when establishing an SSL + or TLS connection to an LDAP server. Different locations or + directories may have their own independent client certificate + settings. Some LDAP toolkits (notably Novell) + do not support per connection client certificates, and will throw an + error on LDAP server connection if you try to use this directive + (Use the LDAPTrustedGlobalCert directive instead for Novell client + certificates - See the SSL/TLS certificate guide above for details). + The type specifies the kind of certificate parameter being + set, depending on the LDAP toolkit being used. Supported types are:

    +
      +
    • CA_DER - binary DER encoded CA certificate
      • +
    • CA_BASE64 - PEM encoded CA certificate
      • +
    • CERT_DER - binary DER encoded client certificate
      • +
    • CERT_BASE64 - PEM encoded client certificate
      • +
    • CERT_NICKNAME - Client certificate "nickname" (Netscape SDK)
      • +
    • KEY_DER - binary DER encoded private key
      • +
    • KEY_BASE64 - PEM encoded private key
      • +
    + +
    +
    top
    +

    LDAPTrustedGlobalCert Directive

    + + + + + + +
    Description:Sets the file or database containing global trusted +Certificate Authority or global client certificates
    Syntax:LDAPTrustedGlobalCert type directory-path/filename [password]
    Context:server config
    Status:Extension
    Module:mod_ldap
    +

    It specifies the directory path and file name of the trusted CA + certificates and/or system wide client certificates mod_ldap + should use when establishing an SSL or TLS connection to an LDAP + server. Note that all certificate information specified using this directive + is applied globally to the entire server installation. Some LDAP toolkits + (notably Novell) require all client certificates to be set globally using + this directive. Most other toolkits require clients certificates to be set + per Directory or per Location using LDAPTrustedClientCert. If you get this + wrong, an error may be logged when an attempt is made to contact the LDAP + server, or the connection may silently fail (See the SSL/TLS certificate + guide above for details). + The type specifies the kind of certificate parameter being + set, depending on the LDAP toolkit being used. Supported types are:

    +
      +
    • CA_DER - binary DER encoded CA certificate
      • +
    • CA_BASE64 - PEM encoded CA certificate
      • +
    • CA_CERT7_DB - Netscape cert7.db CA certificate database file
      • +
    • CA_SECMOD - Netscape secmod database file
      • +
    • CERT_DER - binary DER encoded client certificate
      • +
    • CERT_BASE64 - PEM encoded client certificate
      • +
    • CERT_KEY3_DB - Netscape key3.db client certificate database file
      • +
    • CERT_NICKNAME - Client certificate "nickname" (Netscape SDK)
      • +
    • CERT_PFX - PKCS#12 encoded client certificate (Novell SDK)
      • +
    • KEY_DER - binary DER encoded private key
      • +
    • KEY_BASE64 - PEM encoded private key
      • +
    • KEY_PFX - PKCS#12 encoded private key (Novell SDK)
      • +
    + +
    +
    top
    +

    LDAPTrustedMode Directive

    + + + + + + +
    Description:Specifies the SSL/TLS mode to be used when connecting to an LDAP server.
    Syntax:LDAPTrustedMode type
    Context:server config, virtual host
    Status:Extension
    Module:mod_ldap
    +

    The following modes are supported:

    +
      +
    • NONE - no encryption
      • +
    • SSL - ldaps:// encryption on default port 636
      • +
    • TLS - STARTTLS encryption on default port 389
      • +
    + +

    Not all LDAP toolkits support all the above modes. An error message + will be logged at runtime if a mode is not supported, and the + connection to the LDAP server will fail. +

    + +

    If an ldaps:// URL is specified, the mode becomes SSL and the setting + of LDAPTrustedMode is ignored.

    + +
    +
    top
    +

    LDAPVerifyServerCert Directive

    + + + + + + + +
    Description:Force server certificate verification
    Syntax:LDAPVerifyServerCert On|Off
    Default:LDAPVerifyServerCert On
    Context:server config
    Status:Extension
    Module:mod_ldap
    +

    Specifies whether to force the verification of a + server certificate when establishing an SSL connection to the + LDAP server.

    + +
    +
    top

    Example Configuration

    The following is an example configuration that uses @@ -252,590 +667,175 @@ LDAPTrustedGlobalCert CA_DER "/certs/certfile.der" AuthBasicProvider ldap AuthLDAPURL "ldaps://127.0.0.1/dc=example,dc=com?uid?one" Require valid-user -</Location> - - - 

    # Establish a TLS LDAP connection on port 389. Requires that
-# mod_ldap and mod_authnz_ldap be loaded. Change the
-# "yourdomain.example.com" to match your domain.
-
-LDAPTrustedGlobalCert CA_DER "/certs/certfile.der:
-
-<Location "/ldap-status">
-    SetHandler ldap-status
-
-    Require host yourdomain.example.com
-
-    Satisfy any
-    AuthType Basic
-    AuthName "LDAP Protected"
-    AuthBasicProvider ldap
-    AuthLDAPURL "ldap://127.0.0.1/dc=example,dc=com?uid?one" TLS
-    Require valid-user
-</Location>
    - - -
    top
    -
    -

    SSL/TLS Certificates

    - -

    The different LDAP SDKs have widely different methods of setting - and handling both CA and client side certificates.

    - -

    If you intend to use SSL or TLS, read this section CAREFULLY so as to - understand the differences between configurations on the different LDAP - toolkits supported.

    - -

    Netscape/Mozilla/iPlanet SDK

    -

    CA certificates are specified within a file called cert7.db. - The SDK will not talk to any LDAP server whose certificate was - not signed by a CA specified in this file. If - client certificates are required, an optional key3.db file may - be specified with an optional password. The secmod file can be - specified if required. These files are in the same format as - used by the Netscape Communicator or Mozilla web browsers. The easiest - way to obtain these files is to grab them from your browser - installation.

    - -

    Client certificates are specified per connection using the - LDAPTrustedClientCert directive by referring - to the certificate "nickname". An optional password may be - specified to unlock the certificate's private key.

    - -

    The SDK supports SSL only. An attempt to use STARTTLS will cause - an error when an attempt is made to contact the LDAP server at - runtime.

    - - 
    # Specify a Netscape CA certificate file
-LDAPTrustedGlobalCert CA_CERT7_DB "/certs/cert7.db"
-# Specify an optional key3.db file for client certificate support
-LDAPTrustedGlobalCert CERT_KEY3_DB "/certs/key3.db"
-# Specify the secmod file if required
-LDAPTrustedGlobalCert CA_SECMOD "/certs/secmod"
-<Location "/ldap-status">
-    SetHandler ldap-status
-
-    Require host yourdomain.example.com
-
-    Satisfy any
-    AuthType Basic
-    AuthName "LDAP Protected"
-    AuthBasicProvider ldap
-    LDAPTrustedClientCert CERT_NICKNAME <nickname> [password]
-    AuthLDAPURL "ldaps://127.0.0.1/dc=example,dc=com?uid?one"
-    Require valid-user
-</Location>
    - - - - -

    Novell SDK

    - -

    One or more CA certificates must be specified for the Novell - SDK to work correctly. These certificates can be specified as - binary DER or Base64 (PEM) encoded files.

    - -

    Note: Client certificates are specified globally rather than per - connection, and so must be specified with the LDAPTrustedGlobalCert - directive as below. Trying to set client certificates via the - LDAPTrustedClientCert directive will cause an error to be logged - when an attempt is made to connect to the LDAP server..

    - -

    The SDK supports both SSL and STARTTLS, set using the - LDAPTrustedMode parameter. If an ldaps:// URL is specified, - SSL mode is forced, override this directive.

    - - 
    # Specify two CA certificate files
-LDAPTrustedGlobalCert CA_DER "/certs/cacert1.der"
-LDAPTrustedGlobalCert CA_BASE64 "/certs/cacert2.pem"
-# Specify a client certificate file and key
-LDAPTrustedGlobalCert CERT_BASE64 "/certs/cert1.pem"
-LDAPTrustedGlobalCert KEY_BASE64 "/certs/key1.pem" [password]
-# Do not use this directive, as it will throw an error
-#LDAPTrustedClientCert CERT_BASE64 "/certs/cert1.pem"
    - - - - -

    OpenLDAP SDK

    - -

    One or more CA certificates must be specified for the OpenLDAP - SDK to work correctly. These certificates can be specified as - binary DER or Base64 (PEM) encoded files.

    - -

    Both CA and client certificates may be specified globally - (LDAPTrustedGlobalCert) or per-connection (LDAPTrustedClientCert). - When any settings are specified per-connection, the global - settings are superceded.

    - -

    The documentation for the SDK claims to support both SSL and - STARTTLS, however STARTTLS does not seem to work on all versions - of the SDK. The SSL/TLS mode can be set using the - LDAPTrustedMode parameter. If an ldaps:// URL is specified, - SSL mode is forced. The OpenLDAP documentation notes that SSL - (ldaps://) support has been deprecated to be replaced with TLS, - although the SSL functionality still works.

    - - 
    # Specify two CA certificate files
-LDAPTrustedGlobalCert CA_DER "/certs/cacert1.der"
-LDAPTrustedGlobalCert CA_BASE64 "/certs/cacert2.pem"
-<Location "/ldap-status">
-    SetHandler ldap-status
-
-    Require host yourdomain.example.com
-
-    LDAPTrustedClientCert CERT_BASE64 "/certs/cert1.pem"
-    LDAPTrustedClientCert KEY_BASE64 "/certs/key1.pem"
-    # CA certs respecified due to per-directory client certs
-    LDAPTrustedClientCert CA_DER "/certs/cacert1.der"
-    LDAPTrustedClientCert CA_BASE64 "/certs/cacert2.pem"
-    Satisfy any
-    AuthType Basic
-    AuthName "LDAP Protected"
-    AuthBasicProvider ldap
-    AuthLDAPURL "ldaps://127.0.0.1/dc=example,dc=com?uid?one"
-    Require valid-user
-</Location>
    - - - - -

    Solaris SDK

    - -

    SSL/TLS for the native Solaris LDAP libraries is not yet - supported. If required, install and use the OpenLDAP libraries - instead.

    - - - -

    Microsoft SDK

    - -

    SSL/TLS certificate configuration for the native Microsoft - LDAP libraries is done inside the system registry, and no - configuration directives are required.

    +</Location> -

    Both SSL and TLS are supported by using the ldaps:// URL - format, or by using the LDAPTrustedMode directive accordingly.

    -

    Note: The status of support for client certificates is not yet known - for this toolkit.

    + 
    # Establish a TLS LDAP connection on port 389. Requires that
+# mod_ldap and mod_authnz_ldap be loaded. Change the
+# "yourdomain.example.com" to match your domain.
 
-    
+LDAPTrustedGlobalCert CA_DER "/certs/certfile.der:
 
-
    -
    top
    -

    LDAPCacheEntries Directive

    - - - - - - - -
    Description:Maximum number of entries in the primary LDAP cache
    Syntax:LDAPCacheEntries number
    Default:LDAPCacheEntries 1024
    Context:server config
    Status:Extension
    Module:mod_ldap
    -

    Specifies the maximum size of the primary LDAP cache. This - cache contains successful search/binds. Set it to 0 to turn off - search/bind caching. The default size is 1024 cached - searches.

    +<Location "/ldap-status"> + SetHandler ldap-status -
    -
    top
    -

    LDAPCacheTTL Directive

    - - - - - - - -
    Description:Time that cached items remain valid
    Syntax:LDAPCacheTTL seconds
    Default:LDAPCacheTTL 600
    Context:server config
    Status:Extension
    Module:mod_ldap
    -

    Specifies the time (in seconds) that an item in the - search/bind cache remains valid. The default is 600 seconds (10 - minutes).

    + Require host yourdomain.example.com -
    -
    top
    -

    LDAPConnectionPoolTTL Directive

    - - - - - - - - -
    Description:Discard backend connections that have been sitting in the connection pool too long
    Syntax:LDAPConnectionPoolTTL n
    Default:LDAPConnectionPoolTTL -1
    Context:server config, virtual host
    Status:Extension
    Module:mod_ldap
    Compatibility:Apache HTTP Server 2.3.12 and later
    -

    Specifies the maximum age, in seconds, that a pooled LDAP connection can remain idle - and still be available for use. Connections are cleaned up when they are next needed, - not asynchronously.

    + Satisfy any + AuthType Basic + AuthName "LDAP Protected" + AuthBasicProvider ldap + AuthLDAPURL "ldap://127.0.0.1/dc=example,dc=com?uid?one" TLS + Require valid-user +</Location> -

    A setting of 0 causes connections to never be saved in the backend - connection pool. The default value of -1, and any other negative value, - allows connections of any age to be reused.

    -

    For performance reasons, the reference time used by this directive is - based on when the LDAP connection is returned to the pool, not the time - of the last successful I/O with the LDAP server.

    +
    top
    +
    +

    SSL/TLS Certificates

    -

    Since 2.4.10, new measures are in place to avoid the reference time - from being inflated by cache hits or slow requests. First, the reference - time is not updated if no backend LDAP conncetions were needed. Second, - the reference time uses the time the HTTP request was received instead - of the time the request is completed.

    - -

    This timeout defaults to units of seconds, but accepts - suffixes for milliseconds (ms), minutes (min), and hours (h). -

    +

    The different LDAP SDKs have widely different methods of setting + and handling both CA and client side certificates.

    -
    -
    top
    -

    LDAPConnectionTimeout Directive

    - - - - - - -
    Description:Specifies the socket connection timeout in seconds
    Syntax:LDAPConnectionTimeout seconds
    Context:server config
    Status:Extension
    Module:mod_ldap
    -

    This directive configures the LDAP_OPT_NETWORK_TIMEOUT (or LDAP_OPT_CONNECT_TIMEOUT) - option in the underlying LDAP client library, when available. This value - typically controls how long the LDAP client library will wait for the TCP - connection to the LDAP server to complete.

    +

    If you intend to use SSL or TLS, read this section CAREFULLY so as to + understand the differences between configurations on the different LDAP + toolkits supported.

    -

    If a connection is not successful with the timeout period, either an error will be - returned or the LDAP client library will attempt to connect to a secondary LDAP - server if one is specified (via a space-separated list of hostnames in the - AuthLDAPURL).

    +

    Netscape/Mozilla/iPlanet SDK

    +

    CA certificates are specified within a file called cert7.db. + The SDK will not talk to any LDAP server whose certificate was + not signed by a CA specified in this file. If + client certificates are required, an optional key3.db file may + be specified with an optional password. The secmod file can be + specified if required. These files are in the same format as + used by the Netscape Communicator or Mozilla web browsers. The easiest + way to obtain these files is to grab them from your browser + installation.

    -

    The default is 10 seconds, if the LDAP client library linked with the - server supports the LDAP_OPT_NETWORK_TIMEOUT option.

    +

    Client certificates are specified per connection using the + LDAPTrustedClientCert directive by referring + to the certificate "nickname". An optional password may be + specified to unlock the certificate's private key.

    -
    LDAPConnectionTimeout is only available when the LDAP client library linked - with the server supports the LDAP_OPT_NETWORK_TIMEOUT - (or LDAP_OPT_CONNECT_TIMEOUT) option, and the ultimate behavior is - dictated entirely by the LDAP client library. -
    +

    The SDK supports SSL only. An attempt to use STARTTLS will cause + an error when an attempt is made to contact the LDAP server at + runtime.

    -
    -
    top
    -

    LDAPLibraryDebug Directive

    - - - - - - - -
    Description:Enable debugging in the LDAP SDK
    Syntax:LDAPLibraryDebug 7
    Default:disabled
    Context:server config
    Status:Extension
    Module:mod_ldap
    -

    Turns on SDK-specific LDAP debug options that generally cause the LDAP - SDK to log verbose trace information to the main Apache error log. - The trace messages from the LDAP SDK provide gory details that - can be useful during debugging of connectivity problems with backend LDAP servers

    + 
    # Specify a Netscape CA certificate file
+LDAPTrustedGlobalCert CA_CERT7_DB "/certs/cert7.db"
+# Specify an optional key3.db file for client certificate support
+LDAPTrustedGlobalCert CERT_KEY3_DB "/certs/key3.db"
+# Specify the secmod file if required
+LDAPTrustedGlobalCert CA_SECMOD "/certs/secmod"
+<Location "/ldap-status">
+    SetHandler ldap-status
 
-    
    This option is only configurable when Apache HTTP Server is linked with
-    an LDAP SDK that implements LDAP_OPT_DEBUG or
-    LDAP_OPT_DEBUG_LEVEL, such as OpenLDAP (a value of 7 is verbose)
-    or Tivoli Directory Server (a value of 65535 is verbose).
    
+    Require host yourdomain.example.com
 
-    
    
-    
    The logged information will likely contain plaintext credentials being used or
-    validated by LDAP authentication, so care should be taken in protecting and purging
-    the error log when this directive is used.
    
-    
    
+    Satisfy any
+    AuthType Basic
+    AuthName "LDAP Protected"
+    AuthBasicProvider ldap
+    LDAPTrustedClientCert CERT_NICKNAME <nickname> [password]
+    AuthLDAPURL "ldaps://127.0.0.1/dc=example,dc=com?uid?one"
+    Require valid-user
+</Location>
    -
    -
    top
    -

    LDAPOpCacheEntries Directive

    - - - - - - - -
    Description:Number of entries used to cache LDAP compare -operations
    Syntax:LDAPOpCacheEntries number
    Default:LDAPOpCacheEntries 1024
    Context:server config
    Status:Extension
    Module:mod_ldap
    -

    This specifies the number of entries mod_ldap - will use to cache LDAP compare operations. The default is 1024 - entries. Setting it to 0 disables operation caching.

    + -
    -
    top
    -

    LDAPOpCacheTTL Directive

    - - - - - - - -
    Description:Time that entries in the operation cache remain -valid
    Syntax:LDAPOpCacheTTL seconds
    Default:LDAPOpCacheTTL 600
    Context:server config
    Status:Extension
    Module:mod_ldap
    -

    Specifies the time (in seconds) that entries in the - operation cache remain valid. The default is 600 seconds.

    +

    Novell SDK

    -
    -
    top
    -

    LDAPReferralHopLimit Directive

    - - - - - - - - -
    Description:The maximum number of referral hops to chase before terminating an LDAP query.
    Syntax:LDAPReferralHopLimit number
    Default:SDK dependent, typically between 5 and 10
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_ldap
    -

    This directive, if enabled by the LDAPReferrals directive, - limits the number of referral hops that are followed before terminating an - LDAP query.

    +

    One or more CA certificates must be specified for the Novell + SDK to work correctly. These certificates can be specified as + binary DER or Base64 (PEM) encoded files.

    -
    -

    Support for this tunable is uncommon in LDAP SDKs.

    -
    +

    Note: Client certificates are specified globally rather than per + connection, and so must be specified with the LDAPTrustedGlobalCert + directive as below. Trying to set client certificates via the + LDAPTrustedClientCert directive will cause an error to be logged + when an attempt is made to connect to the LDAP server..

    -
    -
    top
    -

    LDAPReferrals Directive

    - - - - - - - - - -
    Description:Enable referral chasing during queries to the LDAP server.
    Syntax:LDAPReferrals On|Off|default
    Default:LDAPReferrals On
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_ldap
    Compatibility:The default parameter is available in Apache 2.4.7 and later
    -

    Some LDAP servers divide their directory among multiple domains and use referrals - to direct a client when a domain boundary is crossed. This is similar to a HTTP redirect. - LDAP client libraries may or may not chase referrals by default. This directive - explicitly configures the referral chasing in the underlying SDK.

    +

    The SDK supports both SSL and STARTTLS, set using the + LDAPTrustedMode parameter. If an ldaps:// URL is specified, + SSL mode is forced, override this directive.

    + + 
    # Specify two CA certificate files
+LDAPTrustedGlobalCert CA_DER "/certs/cacert1.der"
+LDAPTrustedGlobalCert CA_BASE64 "/certs/cacert2.pem"
+# Specify a client certificate file and key
+LDAPTrustedGlobalCert CERT_BASE64 "/certs/cert1.pem"
+LDAPTrustedGlobalCert KEY_BASE64 "/certs/key1.pem" [password]
+# Do not use this directive, as it will throw an error
+#LDAPTrustedClientCert CERT_BASE64 "/certs/cert1.pem"
    -

    LDAPReferrals takes the following values:

    -
    -
    "on"
    -

    When set to "on", the underlying SDK's referral chasing state - is enabled, LDAPReferralHopLimit is used to - override the SDK's hop limit, and an LDAP rebind callback is - registered.

    -
    "off"
    -

    When set to "off", the underlying SDK's referral chasing state - is disabled completely.

    -
    "default"
    -

    When set to "default", the underlying SDK's referral chasing state - is not changed, LDAPReferralHopLimit is not - used to overide the SDK's hop limit, and no LDAP rebind callback is - registered.

    -
    + -

    The directive LDAPReferralHopLimit works in conjunction with - this directive to limit the number of referral hops to follow before terminating the LDAP query. - When referral processing is enabled by a value of "On", client credentials will be provided, - via a rebind callback, for any LDAP server requiring them.

    +

    OpenLDAP SDK

    -
    -
    top
    -

    LDAPRetries Directive

    - - - - - - - -
    Description:Configures the number of LDAP server retries.
    Syntax:LDAPRetries number-of-retries
    Default:LDAPRetries 3
    Context:server config
    Status:Extension
    Module:mod_ldap
    -

    The server will retry failed LDAP requests up to - LDAPRetries times. Setting this - directive to 0 disables retries.

    -

    LDAP errors such as timeouts and refused connections are retryable.

    +

    One or more CA certificates must be specified for the OpenLDAP + SDK to work correctly. These certificates can be specified as + binary DER or Base64 (PEM) encoded files.

    -
    -
    top
    -

    LDAPRetryDelay Directive

    - - - - - - - -
    Description:Configures the delay between LDAP server retries.
    Syntax:LDAPRetryDelay seconds
    Default:LDAPRetryDelay 0
    Context:server config
    Status:Extension
    Module:mod_ldap
    -

    If LDAPRetryDelay is set to a non-zero - value, the server will delay retrying an LDAP request for the - specified amount of time. Setting this directive to 0 will - result in any retry to occur without delay.

    +

    Both CA and client certificates may be specified globally + (LDAPTrustedGlobalCert) or per-connection (LDAPTrustedClientCert). + When any settings are specified per-connection, the global + settings are superceded.

    -

    LDAP errors such as timeouts and refused connections are retryable.

    +

    The documentation for the SDK claims to support both SSL and + STARTTLS, however STARTTLS does not seem to work on all versions + of the SDK. The SSL/TLS mode can be set using the + LDAPTrustedMode parameter. If an ldaps:// URL is specified, + SSL mode is forced. The OpenLDAP documentation notes that SSL + (ldaps://) support has been deprecated to be replaced with TLS, + although the SSL functionality still works.

    -
    -
    top
    -

    LDAPSharedCacheFile Directive

    - - - - - - -
    Description:Sets the shared memory cache file
    Syntax:LDAPSharedCacheFile directory-path/filename
    Context:server config
    Status:Extension
    Module:mod_ldap
    -

    Specifies the directory path and file name of the shared memory - cache file. If not set, anonymous shared memory will be used if the - platform supports it.

    + 
    # Specify two CA certificate files
+LDAPTrustedGlobalCert CA_DER "/certs/cacert1.der"
+LDAPTrustedGlobalCert CA_BASE64 "/certs/cacert2.pem"
+<Location "/ldap-status">
+    SetHandler ldap-status
 
-
    -
    top
    -

    LDAPSharedCacheSize Directive

    - - - - - - - -
    Description:Size in bytes of the shared-memory cache
    Syntax:LDAPSharedCacheSize bytes
    Default:LDAPSharedCacheSize 500000
    Context:server config
    Status:Extension
    Module:mod_ldap
    -

    Specifies the number of bytes to allocate for the shared - memory cache. The default is 500kb. If set to 0, shared memory - caching will not be used and every HTTPD process will create its - own cache.

    + Require host yourdomain.example.com -
    -
    top
    -

    LDAPTimeout Directive

    - - - - - - - - -
    Description:Specifies the timeout for LDAP search and bind operations, in seconds
    Syntax:LDAPTimeout seconds
    Default:LDAPTimeout 60
    Context:server config
    Status:Extension
    Module:mod_ldap
    Compatibility:Apache HTTP Server 2.3.5 and later
    -

    This directive configures the timeout for bind and search operations, as well as - the LDAP_OPT_TIMEOUT option in the underlying LDAP client library, when available.

    + LDAPTrustedClientCert CERT_BASE64 "/certs/cert1.pem" + LDAPTrustedClientCert KEY_BASE64 "/certs/key1.pem" + # CA certs respecified due to per-directory client certs + LDAPTrustedClientCert CA_DER "/certs/cacert1.der" + LDAPTrustedClientCert CA_BASE64 "/certs/cacert2.pem" + Satisfy any + AuthType Basic + AuthName "LDAP Protected" + AuthBasicProvider ldap + AuthLDAPURL "ldaps://127.0.0.1/dc=example,dc=com?uid?one" + Require valid-user +</Location> -

    If the timeout expires, httpd will retry in case an existing connection has - been silently dropped by a firewall. However, performance will be much better if - the firewall is configured to send TCP RST packets instead of silently dropping - packets.

    -
    -

    Timeouts for ldap compare operations requires an SDK with LDAP_OPT_TIMEOUT, such as OpenLDAP >= 2.4.4.

    -
    + +

    Solaris SDK

    -
    -
    top
    -

    LDAPTrustedClientCert Directive

    - - - - - - -
    Description:Sets the file containing or nickname referring to a per -connection client certificate. Not all LDAP toolkits support per -connection client certificates.
    Syntax:LDAPTrustedClientCert type directory-path/filename/nickname [password]
    Context:directory, .htaccess
    Status:Extension
    Module:mod_ldap
    -

    It specifies the directory path, file name or nickname of a - per connection client certificate used when establishing an SSL - or TLS connection to an LDAP server. Different locations or - directories may have their own independent client certificate - settings. Some LDAP toolkits (notably Novell) - do not support per connection client certificates, and will throw an - error on LDAP server connection if you try to use this directive - (Use the LDAPTrustedGlobalCert directive instead for Novell client - certificates - See the SSL/TLS certificate guide above for details). - The type specifies the kind of certificate parameter being - set, depending on the LDAP toolkit being used. Supported types are:

    -
      -
    • CA_DER - binary DER encoded CA certificate
      • -
    • CA_BASE64 - PEM encoded CA certificate
      • -
    • CERT_DER - binary DER encoded client certificate
      • -
    • CERT_BASE64 - PEM encoded client certificate
      • -
    • CERT_NICKNAME - Client certificate "nickname" (Netscape SDK)
      • -
    • KEY_DER - binary DER encoded private key
      • -
    • KEY_BASE64 - PEM encoded private key
      • -
    +

    SSL/TLS for the native Solaris LDAP libraries is not yet + supported. If required, install and use the OpenLDAP libraries + instead.

    -
    -
    top
    -

    LDAPTrustedGlobalCert Directive

    - - - - - - -
    Description:Sets the file or database containing global trusted -Certificate Authority or global client certificates
    Syntax:LDAPTrustedGlobalCert type directory-path/filename [password]
    Context:server config
    Status:Extension
    Module:mod_ldap
    -

    It specifies the directory path and file name of the trusted CA - certificates and/or system wide client certificates mod_ldap - should use when establishing an SSL or TLS connection to an LDAP - server. Note that all certificate information specified using this directive - is applied globally to the entire server installation. Some LDAP toolkits - (notably Novell) require all client certificates to be set globally using - this directive. Most other toolkits require clients certificates to be set - per Directory or per Location using LDAPTrustedClientCert. If you get this - wrong, an error may be logged when an attempt is made to contact the LDAP - server, or the connection may silently fail (See the SSL/TLS certificate - guide above for details). - The type specifies the kind of certificate parameter being - set, depending on the LDAP toolkit being used. Supported types are:

    -
      -
    • CA_DER - binary DER encoded CA certificate
      • -
    • CA_BASE64 - PEM encoded CA certificate
      • -
    • CA_CERT7_DB - Netscape cert7.db CA certificate database file
      • -
    • CA_SECMOD - Netscape secmod database file
      • -
    • CERT_DER - binary DER encoded client certificate
      • -
    • CERT_BASE64 - PEM encoded client certificate
      • -
    • CERT_KEY3_DB - Netscape key3.db client certificate database file
      • -
    • CERT_NICKNAME - Client certificate "nickname" (Netscape SDK)
      • -
    • CERT_PFX - PKCS#12 encoded client certificate (Novell SDK)
      • -
    • KEY_DER - binary DER encoded private key
      • -
    • KEY_BASE64 - PEM encoded private key
      • -
    • KEY_PFX - PKCS#12 encoded private key (Novell SDK)
      • -
    + -
    -
    top
    -

    LDAPTrustedMode Directive

    - - - - - - -
    Description:Specifies the SSL/TLS mode to be used when connecting to an LDAP server.
    Syntax:LDAPTrustedMode type
    Context:server config, virtual host
    Status:Extension
    Module:mod_ldap
    -

    The following modes are supported:

    -
      -
    • NONE - no encryption
      • -
    • SSL - ldaps:// encryption on default port 636
      • -
    • TLS - STARTTLS encryption on default port 389
      • -
    +

    Microsoft SDK

    -

    Not all LDAP toolkits support all the above modes. An error message - will be logged at runtime if a mode is not supported, and the - connection to the LDAP server will fail. -

    +

    SSL/TLS certificate configuration for the native Microsoft + LDAP libraries is done inside the system registry, and no + configuration directives are required.

    -

    If an ldaps:// URL is specified, the mode becomes SSL and the setting - of LDAPTrustedMode is ignored.

    +

    Both SSL and TLS are supported by using the ldaps:// URL + format, or by using the LDAPTrustedMode directive accordingly.

    -
    -
    top
    -

    LDAPVerifyServerCert Directive

    - - - - - - - -
    Description:Force server certificate verification
    Syntax:LDAPVerifyServerCert On|Off
    Default:LDAPVerifyServerCert On
    Context:server config
    Status:Extension
    Module:mod_ldap
    -

    Specifies whether to force the verification of a - server certificate when establishing an SSL connection to the - LDAP server.

    +

    Note: The status of support for client certificates is not yet known + for this toolkit.

    + +
    diff --git a/docs/manual/mod/mod_ldap.html.fr b/docs/manual/mod/mod_ldap.html.fr index 36d930f1f9c..3406c352101 100644 --- a/docs/manual/mod/mod_ldap.html.fr +++ b/docs/manual/mod/mod_ldap.html.fr @@ -86,848 +86,848 @@ cache du r
  • Certificats SSL/TLS
    • top
    -
    -

    Exemple de configuration

    -

    Ce qui suit est un exemple de configuration qui utilise - mod_ldap pour améliorer les performances de - l'authentification HTTP de base fournie par - mod_authnz_ldap.

    - - 
    # Active la conservation des connexions LDAP et le cache partagé en
-# mémoire. Active le gestionnaire de statut du cache LDAP.
-# Nécessite le chargement de mod_ldap et de mod_authnz_ldap.
-# Remplacez "votre-domaine.example.com" par le nom de votre
-# domaine.
+
    Directive LDAPCacheEntries
    
+
+
+
+
+
+
+
+
    Description:Nombre maximum d'entrées dans le cache LDAP
+primaire
    Syntaxe:LDAPCacheEntries nombre
    Défaut:LDAPCacheEntries 1024
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    
+    
    Cette directive permet de spécifier la taille maximale du cache
+    LDAP primaire. Ce cache contient les résultats de
+    recherche/identification positifs. Définissez-la à 0 pour désactiver
+    la mise en cache des résultats de recherche/identification positifs.
+    La taille par défaut est de 1024 recherches en cache.
    
 
-LDAPSharedCacheSize 500000
-LDAPCacheEntries 1024
-LDAPCacheTTL 600
-LDAPOpCacheEntries 1024
-LDAPOpCacheTTL 600
+
    
+
    top
    
+
    Directive LDAPCacheTTL
    
+
+
+
+
+
+
+
+
    Description:Durée pendant laquelle les entrées du cache restent
+valides.
    Syntaxe:LDAPCacheTTL secondes
    Défaut:LDAPCacheTTL 600
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    
+    
    Cette directive permet de spécifier la durée (en secondes)
+    pendant laquelle une entrée du cache de recherche/identification
+    reste valide. La valeur par défaut est de 600 secondes (10
+    minutes).
    
 
-<Location /ldap-status>
-    SetHandler ldap-status
-    
-    Require host yourdomain.example.com
-    
-    Satisfy any
-    AuthType Basic
-    AuthName "LDAP Protected"
-    AuthBasicProvider ldap
-    AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one
-    Require valid-user
-</Location>
    +
    +
    top
    +

    Directive LDAPConnectionPoolTTL

    + + + + + + + + +
    Description:Désactive les connexions d'arrière-plan qui sont restées +inactives trop longtemps au sein du jeu de connexions.
    Syntaxe:LDAPConnectionPoolTTL n
    Défaut:LDAPConnectionPoolTTL -1
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ldap
    Compatibilité:Disponible à partir de la version 2.3.12 du serveur HTTP +Apache
    +

    Cette directive permet de spécifier la durée maximale, en + secondes, pendant laquelle une connexion LDAP du jeu de connexions + peut demeurer inactive, mais rester quand-même disponible pour une + utilisation éventuelle. Le jeu de connexions est nettoyé au fur et à + mesure des besoins, de manière non asynchrone.

    -
    top
    -
    -

    Conservation des connexions LDAP

    +

    Si cette directive est définie à 0, les connexions ne sont jamais + sauvegardées dans le jeu de connexions d'arrière-plan. Avec la + valeur par défaut -1, ou toute autre valeur négative, les connexions + peuvent être réutilisées sans limite de durée.

    -

    Les connexions LDAP sont conservées de requête en requête. Ceci - permet de rester connecté et identifié au serveur LDAP, ce dernier - étant ainsi prêt pour la prochaine requête, sans avoir à se - déconnecter, reconnecter et réidentifier. Le gain en performances - est similaire à celui des connexions persistantes (keepalives) - HTTP.

    +

    Dans le but d'améliorer les performances, le temps de référence + qu'utilise cette directive correspond au moment où la connexion LDAP + est enregistrée ou remise dans le jeu de connexions, et non au + moment du dernier échange réussi avec le serveur LDAP.

    -

    Sur un serveur très sollicité, il est possible que de nombreuses - requêtes tentent d'accéder simultanément à la même connexion au - serveur LDAP. Lorsqu'une connexion LDAP est utilisée, Apache en crée - une deuxième en parallèle à la première, ce qui permet d'éviter que - le système de conservation des connexions ne devienne un goulot - d'étranglement.

    +

    La version 2.4.10 a introduit de nouvelles mesures permettant + d'éviter une augmentation excessive du temps de référence due à des + correspondances positives dans le cache ou des requêtes lentes. A + cet effet, le temps de référence n'est pas réactualisé si aucune + connexion LDAP d'arrière-plan n'est requise ; d'autre part, le temps + de référence se base sur le moment où la requête HTTP est reçue, et + non sur le moment où la requête a été traitée.

    -

    Il n'est pas nécessaire d'activer explicitement la conservation - des connexions dans la configuration d'Apache. Tout module utilisant - le module ldap pour accéder aux services LDAP partagera le jeu de - connexions.

    +

    Cette durée de vie s'exprime par défaut en secondes, mais + il est possible d'utiliser d'autres unités en ajoutant un suffixe : + millisecondes (ms), minutes (min), ou heures (h). +

    -

    Les connexions LDAP peuvent garder la trace des données - d'identification du client ldap utilisées pour l'identification - auprès du serveur LDAP. Ces données peuvent être fournies aux - serveurs LDAP qui ne permettent pas les connexions anonymes au cours - lors des tentatives de sauts vers des serveurs alternatifs. Pour - contrôler cette fonctionnalité, voir les directives LDAPReferrals et LDAPReferralHopLimit. Cette - fonctionnalité est activée par défaut.

    -
    top
    -
    -

    Cache LDAP

    +
    +
    top
    +

    Directive LDAPConnectionTimeout

    + + + + + + +
    Description:Spécifie le délai d'attente en secondes de la socket de +connexion
    Syntaxe:LDAPConnectionTimeout secondes
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    +

    Cette directive configure l'option LDAP_OPT_NETWORK_TIMEOUT (ou + LDAP_OPT_CONNECT_TIMEOUT) dans la bibliothèque client LDAP + sous-jacente, si elle est disponible. Cette valeur représente la + durée pendant laquelle la bibliothèque client LDAP va attendre que + le processus de connexion TCP au serveur LDAP soit achevé.

    -

    Pour améliorer les performances, mod_ldap met en - oeuvre une stratégie de mise en cache agressive visant à minimiser - le nombre de fois que le serveur LDAP doit être contacté. La mise en - cache peut facilement doubler et même tripler le débit d'Apache - lorsqu'il sert des pages protégées par mod_authnz_ldap. De plus, le - serveur LDAP verra lui-même sa charge sensiblement diminuée.

    +

    Si la connexion n'a pas réussi avant ce délai, une erreur sera + renvoyée, ou la bibliothèque client LDAP tentera de se connecter à + un second serveur LDAP, s'il en a été défini un (via une liste de + noms d'hôtes séparés par des espaces dans la directive AuthLDAPURL).

    -

    mod_ldap supporte deux types de mise en cache - LDAP : un cache recherche/identification durant la phase - de recherche/identification et deux caches d'opérations - durant la phase de comparaison. Chaque URL LDAP utilisée par le - serveur a son propre jeu d'instances dans ces trois caches.

    +

    La valeur par défaut est 10 secondes, si la bibliothèque client + LDAP liée avec le serveur supporte l'option + LDAP_OPT_NETWORK_TIMEOUT.

    -

    Le cache - recherche/identification

    -

    Les processus de recherche et d'identification sont les - opérations LDAP les plus consommatrices en temps, en particulier - si l'annuaire est de grande taille. Le cache de - recherche/identification met en cache toutes les recherches qui - ont abouti à une identification positive. Les résultats négatifs - (c'est à dire les recherches sans succès, ou les recherches qui - n'ont pas abouti à une identification positive) ne sont pas mis en - cache. La raison de cette décision réside dans le fait que les - connexions avec des données d'identification invalides ne - représentent qu'un faible pourcentage du nombre total de - connexions, et ainsi, le fait de ne pas mettre en cache les - données d'identification invalides réduira d'autant la taille du - cache.

    +
    LDAPConnectionTimeout n'est disponible que si la bibliothèque client + LDAP liée avec le serveur supporte l'option + LDAP_OPT_NETWORK_TIMEOUT (ou LDAP_OPT_CONNECT_TIMEOUT), et le + comportement final est entièrement dicté par la bibliothèque client + LDAP. +
    -

    mod_ldap met en cache le nom d'utilisateur, le - DN extrait, le mot de passe utilisé pour l'identification, ainsi - que l'heure de l'identification. Chaque fois qu'une nouvelle - connexion est initialisée avec le même nom d'utilisateur, - mod_ldap compare le mot de passe de la nouvelle - connexion avec le mot de passe enregistré dans le cache. Si les - mots de passe correspondent, et si l'entrée du cache n'est pas - trop ancienne, mod_ldap court-circuite la phase - de recherche/identification.

    +
    +
    top
    +

    Directive LDAPLibraryDebug

    + + + + + + + +
    Description:Active le débogage dans le SDK LDAP
    Syntaxe:LDAPLibraryDebug 7
    Défaut:disabled
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    +

    Active les options de débogage LDAP spécifiques au SDK, qui + entraînent en général une journalisation d'informations verbeuses du + SDK LDAP dans le journal principal des erreurs d'Apache. Les + messages de traces en provenance du SDK LDAP fournissent des + informations très détaillées qui peuvent s'avérer utiles lors du + débogage des problèmes de connexion avec des serveurs LDAP + d'arrière-plan.

    -

    Le cache de recherche/identification est contrôlé par les - directives LDAPCacheEntries et LDAPCacheTTL.

    - +

    Cette option n'est configurable que lorsque le serveur HTTP + Apache est lié avec un SDK LDAP qui implémente + LDAP_OPT_DEBUG ou LDAP_OPT_DEBUG_LEVEL, + comme OpenLDAP (une valeur de 7 est verbeuse) ou Tivoli Directory + Server (une valeur de 65535 est verbeuse).

    -

    Les caches d'opérations

    -

    Au cours des opérations de comparaison d'attributs et de noms - distinctifs (DN), mod_ldap utilise deux caches - d'opérations pour mettre en cache les opérations de comparaison. - Le premier cache de comparaison sert à mettre en cache les - résultats de comparaisons effectuées pour vérifier l'appartenance - à un groupe LDAP. Le second cache de comparaison sert à mettre en - cache les résultats de comparaisons entre DNs.

    +
    +

    Les informations journalisées peuvent contenir des données + d'authentification en clair utilisées ou validées lors de + l'authentification LDAP ; vous devez donc prendre soin de protéger + et de purger le journal des erreurs lorsque cette directive est + utilisée.

    +
    -

    Notez que, lorsque l'appartenance à un groupe est vérifiée, - toute comparaison de sous-groupes est mise en cache afin - d'accélérer les comparaisons de sous-groupes ultérieures.

    -

    Le comportement de ces deux caches est contrôlé par les - directives LDAPOpCacheEntries et LDAPOpCacheTTL.

    - +
    +
    top
    +

    Directive LDAPOpCacheEntries

    + + + + + + + +
    Description:Nombre d'entrées utilisées pour mettre en cache les +opérations de comparaison LDAP
    Syntaxe:LDAPOpCacheEntries nombre
    Défaut:LDAPOpCacheEntries 1024
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    +

    Cette directive permet de spécifier le nombre d'entrées que + mod_ldap va utiliser pour mettre en cache les + opérations de comparaison LDAP. La valeur par défaut est de 1024 + entrées. Si elle est définie à 0, la mise en cache des opérations de + comparaison LDAP est désactivée.

    -

    Superviser le cache

    -

    mod_ldap possède un gestionnaire de contenu - qui permet aux administrateurs de superviser les performances du - cache. Le nom du gestionnaire de contenu est - ldap-status, et on peut utiliser les directives - suivantes pour accéder aux informations du cache de - mod_ldap :

    +
    +
    top
    +

    Directive LDAPOpCacheTTL

    + + + + + + + +
    Description:Durée pendant laquelle les entrées du cache d'opérations +restent valides
    Syntaxe:LDAPOpCacheTTL secondes
    Défaut:LDAPOpCacheTTL 600
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    +

    Cette directive permet de spécifier la durée (en secondes) + pendant laquelle les entrées du cache d'opérations restent valides. + La valeur par défaut est de 600 secondes.

    - 
    <Location /server/cache-info>
-    SetHandler ldap-status
-</Location>
    +
    +
    top
    +

    Directive LDAPReferralHopLimit

    + + + + + + + + +
    Description:Le nombre maximum de redirections vers des serveurs +alternatifs (referrals) avant l'abandon de la requête +LDAP.
    Syntaxe:LDAPReferralHopLimit nombre
    Défaut:Dépend du SDK, en général entre 5 et 10
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_ldap
    +

    Si elle est activée par la directive LDAPReferrals, + cette directive permet de définir le nombre maximum de sauts vers + des serveurs alternatifs (referrals) avant l'abandon de la requête + LDAP.

    +
    +

    L'ajustement de ce paramètre n'est pas commun à tous les SDKs LDAP.

    +
    -

    En se connectant à l'URL - http://nom-serveur/infos-cache, l'administrateur peut - obtenir un rapport sur le statut de chaque cache qu'utilise - mod_ldap. Notez que si Apache ne supporte pas la - mémoire partagée, chaque instance de httpd - possèdera son propre cache, et chaque fois que l'URL sera - rechargée, un résultat différent pourra être affiché, en fonction - de l'instance de httpd qui traitera la - requête.

    - -
    top
    -
    -

    Utiliser SSL/TLS

    +
    +
    top
    +

    Directive LDAPReferrals

    + + + + + + + + + +
    Description:Active la redirection vers des serveurs alternatifs au +cours des requêtes vers le serveur LDAP.
    Syntaxe:LDAPReferrals On|Off|default
    Défaut:LDAPReferrals On
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_ldap
    Compatibilité:Le paramètre default est disponible depuis la +version 2.4.7 du serveur HTTP Apache.
    +

    Certains serveurs LDAP partagent leur annuaire en plusieurs + domaines et utilisent le système des redirections (referrals) pour + aiguiller un client lorsque les limites d'un domaine doivent être + franchies. Ce processus est similaire à une redirection HTTP. Les + bibliothèques client LDAP ne respectent pas forcément ces + redirections par défaut. Cette directive permet de configurer + explicitement les redirections LDAP dans le SDK sous-jacent.

    -

    La possibilité de créer des connexions SSL et TLS avec un serveur - LDAP est définie par les directives - LDAPTrustedGlobalCert, - LDAPTrustedClientCert et - LDAPTrustedMode. Ces directives permettent de spécifier - l'autorité de certification (CA), les certificats clients éventuels, - ainsi que le type de chiffrement à utiliser pour la connexion (none, - SSL ou TLS/STARTTLS).

    +

    La directive LDAPReferrals accepte les + valeurs suivantes :

    - 
    # Etablissement d'une connexion SSL LDAP sur le port 636.
-# Nécessite le chargement de mod_ldap et mod_authnz_ldap.
-# Remplacez "votre-domaine.example.com" par le nom de votre
-# domaine.
+    
    
+     
    "on"
    
+     
     
    Avec la valeur "on", la prise en compte des redirections
+     LDAP par le SDK sous-jacent est activée, la directive
+     LDAPReferralHopLimit permet de surcharger la
+     "hop limit" du SDK, et un "LDAP rebind callback" est enregistré.
    
+     
    "off"
    
+     
     
    Avec la valeur "off", la prise en compte des redirections
+     LDAP par le SDK sous-jacent est complètement désactivée.
    
+     
    "default"
    
+     
     
    Avec la valeur "default", la prise en compte des redirections
+     LDAP par le SDK sous-jacent n'est pas modifiée, la directive
+     LDAPReferralHopLimit ne permet pas de surcharger la
+     "hop limit" du SDK, et aucun "LDAP rebind callback" n'est enregistré.
    
+    
    
+    
+    
    La directive LDAPReferralHopLimit travaille en
+    conjonction avec cette directive pour limiter le nombre de
+    redirections à suivre pour achever le traitement de la requête LDAP.
+    Lorsque le processus de redirection est activé par la valeur "On",
+    les données d'authentification du client sont transmises via un
+    "rebind callback" à tout serveur LDAP qui en fait la demande.
    
 
-LDAPTrustedGlobalCert CA_DER /certs/certfile.der
+
    +
    top
    +

    Directive LDAPRetries

    + + + + + + + +
    Description:Définit le nombre maximum de tentatives de connexions au +serveur LDAP.
    Syntaxe:LDAPRetries nombre d'essais
    Défaut:LDAPRetries 3
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    +

    Suite à des échecs de connexion au serveur LDAP, le serveur + tentera de se connecter autant de fois qu'indiqué par la directive + LDAPRetries. Si cette directive est définie à + 0, le serveur ne tentera pas d'autre connexion après un échec.

    +

    Il est possible d'effectuer une autre tentative de connexion en + cas d'erreurs LDAP du type délai dépassé ou connexion refusée.

    -<Location /ldap-status> - SetHandler ldap-status - - Require host yourdomain.example.com - - Satisfy any - AuthType Basic - AuthName "LDAP Protected" - AuthBasicProvider ldap - AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one - Require valid-user -</Location> +
    +
    top
    +

    Directive LDAPRetryDelay

    + + + + + + + +
    Description:Définit le temps d'attente avant un autre essai de connexion au +serveur LDAP.
    Syntaxe:LDAPRetryDelay secondes
    Défaut:LDAPRetryDelay 0
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    +

    Si la directive LDAPRetryDelay est définie + à une valeur différente de 0, le serveur attendra pendant la durée + spécifiée pour envoyer à nouveau sa requête LDAP. Une valeur de 0 + implique une absence de délai pour les essais successifs.

    +

    Il est possible d'effectuer une autre tentative de connexion en + cas d'erreurs LDAP du type délai dépassé ou connexion refusée.

    - 
    # Etablissement d'une connexion TLS LDAP sur le port 389.
-# Nécessite le chargement de mod_ldap et mod_authnz_ldap.
-# Remplacez "votre-domaine.example.com" par le nom de votre
-# domaine.
+
    +
    top
    +

    Directive LDAPSharedCacheFile

    + + + + + + +
    Description:Définit le fichier du cache en mémoire +partagée
    Syntaxe:LDAPSharedCacheFile chemin/fichier
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    +

    Cette directive permet de spécifier le chemin du + fichier du cache en mémoire partagée. Si elle n'est pas définie, la + mémoire partagée anonyme sera utilisée si la plate-forme la + supporte.

    -LDAPTrustedGlobalCert CA_DER /certs/certfile.der -<Location /ldap-status> - SetHandler ldap-status - - Require host yourdomain.example.com - - Satisfy any - AuthType Basic - AuthName "LDAP Protected" - AuthBasicProvider ldap - AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one TLS - Require valid-user -</Location> +
    +
    top
    +

    Directive LDAPSharedCacheSize

    + + + + + + + +
    Description:Taille en octets du cache en mémoire partagée
    Syntaxe:LDAPSharedCacheSize octets
    Défaut:LDAPSharedCacheSize 500000
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    +

    Cette directive permet de spécifier le nombre d'octets à allouer + pour le cache en mémoire partagée. La valeur par + défaut est 500kb. + Si elle est définie à 0, le cache en mémoire partagée ne sera pas + utilisé et chaque processus HTTPD va créer son propre cache.

    +
    +
    top
    +

    Directive LDAPTimeout

    + + + + + + + + +
    Description:Spécifie le délai d'attente pour les opérations de +recherche et d'identification LDAP en secondes
    Syntaxe:LDAPTimeout secondes
    Défaut:LDAPTimeout 60
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    Compatibilité:Disponible à partir de la version 2.3.5 du serveur HTTP +Apache
    +

    Cette directive permet de spécifier le délai d'attente pour les + opérations de recherche et d'identification, ainsi que l'option + LDAP_OPT_TIMEOUT dans la bibliothèque LDAP client sous-jacente, + lorsqu'elle est disponible.

    -
    top
    -
    -

    Certificats SSL/TLS

    +

    Lorsque le délai est atteint, httpd va refaire un essai dans le + cas où une connexion existante a été silencieusement fermée par un + pare-feu. Les performances seront cependant bien meilleures si le + pare-feu est configuré pour envoyer des paquets TCP RST au lieu de + rejeter silencieusement les paquets.

    -

    Les différents SDKs LDAP disposent de nombreuses méthodes pour - définir et gérer les certificats des clients et des autorités de - certification (CA).

    +
    +

    Les délais pour les opérations de comparaison LDAP nécessitent un + SDK avec LDAP_OPT_TIMEOUT, comme OpenLDAP >= 2.4.4.

    +
    -

    Si vous avez l'intention d'utiliser SSL ou TLS, lisez cette - section ATTENTIVEMENT de façon à bien comprendre les différences de - configurations entre les différents SDKs LDAP supportés.

    -

    SDK Netscape/Mozilla/iPlanet

    -

    Les certificat de CA sont enregistrés dans un fichier nommé - cert7.db. Le SDK ne dialoguera avec aucun serveur LDAP dont le - certificat n'a pas été signé par une CA spécifiée dans ce - fichier. Si des certificats clients sont requis, un fichier - key3.db ainsi qu'un mot de passe optionnels peuvent être - spécifiés. On peut aussi spécifier le fichier secmod si - nécessaire. Ces fichiers sont du même format que celui utilisé - par les navigateurs web Netscape Communicator ou Mozilla. Le - moyen le plus simple pour obtenir ces fichiers consiste à les - extraire de l'installation de votre navigateur.

    - -

    Les certificats clients sont spécifiés pour chaque connexion - en utilisant la directive LDAPTrustedClientCert et en se - référant au certificat "nickname". On peut éventuellement - spécifier un mot de passe pour déverrouiller la clé privée du - certificat.

    - -

    Le SDK supporte seulement SSL. Toute tentative d'utilisation - de STARTTLS engendrera une erreur lors des tentatives de - contacter le serveur LDAP pendant l'exécution.

    - - 
    # Spécifie un fichier de certificats de CA Netscape
-LDAPTrustedGlobalCert CA_CERT7_DB /certs/cert7.db
-# Spécifie un fichier key3db optionnel pour le support des
-# certificats clients
-LDAPTrustedGlobalCert CERT_KEY3_DB /certs/key3.db
-# Spécifie le fichier secmod si nécessaire
-LDAPTrustedGlobalCert CA_SECMOD /certs/secmod
-<Location /ldap-status>
-    SetHandler ldap-status
-
-    Require host yourdomain.example.com
-
-    Satisfy any
-    AuthType Basic
-    AuthName "LDAP Protected"
-    AuthBasicProvider ldap
-    LDAPTrustedClientCert CERT_NICKNAME <nickname> [password]
-    AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one
-    Require valid-user
-</Location>
    - - - - -

    SDK Novell

    - -

    Un ou plusieurs certificats de CA doivent être spécifiés pour - que le SDK Novell fonctionne correctement. Ces certificats - peuvent être spécifiés sous forme de fichiers au format binaire - DER ou codés en Base64 (PEM).

    - -

    Note: Les certificats clients sont spécifiés globalement - plutôt qu'à chaque connexion, et doivent être spécifiés à l'aide - de la directive LDAPTrustedGlobalCert comme ci-dessous. Définir - des certificats clients via la directive LDAPTrustedClientCert - engendrera une erreur qui sera journalisée, au moment de la - tentative de connexion avec le serveur LDAP.

    +
    +
    top
    +

    Directive LDAPTrustedClientCert

    + + + + + + +
    Description:Définit le nom de fichier contenant un certificat client ou +un alias renvoyant vers un certificat client spécifique à une connexion. +Tous les SDK LDAP ne supportent pas les certificats clients par +connexion.
    Syntaxe:LDAPTrustedClientCert type +chemin/nom-fichier/alias [mot de passe]
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    Statut:Extension
    Module:mod_ldap
    +

    Cette directive permet de spécifier le chemin et le nom de + fichier ou l'alias d'un certificat client par connexion utilisé lors + de l'établissement d'une connexion SSL ou TLS avec un serveur LDAP. + Les sections directory ou location peuvent posséder leurs propres + configurations de certificats clients. Certains SDK LDAP (en + particulier Novell) ne supportent pas les certificats clients par + connexion, et renvoient une erreur lors de la connexion au serveur + LDAP si vous tenter d'utiliser cette directive (Utilisez à la place + la directive LDAPTrustedGlobalCert pour les certificats clients sous + Novell - Voir plus haut le guide des certificats SSL/TLS pour plus + de détails). Le paramètre type spécifie le type du certificat en + cours de définition, en fonction du SDK LDAP utilisé. Les types + supportés sont :

    +
      +
    • CA_DER - certificat de CA codé en binaire DER
      • +
    • CA_BASE64 - certificat de CA codé en PEM
      • +
    • CERT_DER - certificat client codé en binaire DER
      • +
    • CERT_BASE64 - certificat client codé en PEM
      • +
    • CERT_NICKNAME - certificat client "nickname" (SDK Netscape)
      • +
    • KEY_DER - clé privée codée en binaire DER
      • +
    • KEY_BASE64 - clé privée codée en PEM
      • +
    -

    Le SDK supporte SSL et STARTTLS, le choix étant défini par le - paramètre de la directive LDAPTrustedMode. Si une URL de type - ldaps:// est spécifiée, le mode SSL est forcé, et l'emporte sur - cette directive.

    +
    +
    top
    +

    Directive LDAPTrustedGlobalCert

    + + + + + + +
    Description:Définit le nom de fichier ou la base de données contenant +les Autorités de Certification de confiance globales ou les certificats +clients globaux
    Syntaxe:LDAPTrustedGlobalCert type +chemin/nom-fichier [mot de passe]
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    +

    Cette directive permet de spécifier le chemin et le nom du + fichier contenant les certificats des CA de confiance et/ou les + certificats clients du système global que mod_ldap + utilisera pour établir une connexion SSL ou TLS avec un serveur + LDAP. Notez que toute information relative aux certificats spécifiée + en utilisant cette directive s'applique globalement à l'ensemble de + l'installation du serveur. Certains SDK LDAP (en particulier Novell) + nécessitent la définition globale de tous les certificats clients en + utilisant cette directive. La plupart des autres SDK nécessitent la + définition des certificats clients dans une section Directory ou + Location en utilisant la directive LDAPTrustedClientCert. Si vous ne + définissez pas ces directives correctement, une erreur sera générée + lors des tentatives de contact avec un serveur LDAP, ou la connexion + échouera silencieusement (Voir plus haut le guide des certificats + SSL/TLS pour plus de détails). Le paramètre type spécifie le type de + certificat en cours de définition, en fonction du SDK LDAP utilisé. + Les types supportés sont :

    +
      +
    • CA_DER - certificat de CA codé en binaire DER
      • +
    • CA_BASE64 - certificat de CA codé en PEM
      • +
    • CA_CERT7_DB - fichier de base de données des certificats de CA + de Netscape cert7.db
      • +
    • CA_SECMOD - fichier de base de données secmod de Netscape
      • +
    • CERT_DER - certificat client codé en binaire DER
      • +
    • CERT_BASE64 - certificat client codé en PEM
      • +
    • CERT_KEY3_DB - fichier de base de données des certificats + clients de Netscape key3.db
      • +
    • CERT_NICKNAME - certificat client "nickname" (SDK Netscape)
      • +
    • CERT_PFX - certificat client codé en PKCS#12 (SDK Novell)
      • +
    • KEY_DER - clé privée codée en binaire DER
      • +
    • KEY_BASE64 - clé privée codée en PEM
      • +
    • KEY_PFX - clé privée codée en PKCS#12 (SDK Novell)
      • +
    - 
    # Spécifie deux fichiers contenant des certificats de CA
-LDAPTrustedGlobalCert CA_DER /certs/cacert1.der
-LDAPTrustedGlobalCert CA_BASE64 /certs/cacert2.pem
-# Spécifie un fichier contenant des certificats clients
-# ainsi qu'une clé
-LDAPTrustedGlobalCert CERT_BASE64 /certs/cert1.pem
-LDAPTrustedGlobalCert KEY_BASE64 /certs/key1.pem [password]
-# N'utilisez pas cette directive, sous peine de provoquer
-# une erreur
-#LDAPTrustedClientCert CERT_BASE64 /certs/cert1.pem
    +
    +
    top
    +

    Directive LDAPTrustedMode

    + + + + + + +
    Description:Spécifie le mode (SSL ou TLS) à utiliser lors de la +connexion à un serveur LDAP.
    Syntaxe:LDAPTrustedMode type
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ldap
    +

    Les modes suivants sont supportés :

    +
      +
    • NONE - aucun chiffrement
      • +
    • SSL - chiffrement ldaps:// sur le port par défaut 636
      • +
    • TLS - chiffrement STARTTLS sur le port par défaut 389
      • +
    +

    Les modes ci-dessus ne sont pas supportés par tous les SDK LDAP. + Un message d'erreur sera généré à l'exécution si un mode n'est pas + supporté, et la connexion au serveur LDAP échouera. +

    - +

    Si une URL de type ldaps:// est spécifiée, le mode est forcé à + SSL et la définition de LDAPTrustedMode est ignorée.

    -

    SDK OpenLDAP

    +
    +
    top
    +

    Directive LDAPVerifyServerCert

    + + + + + + + +
    Description:Force la vérification du certificat du +serveur
    Syntaxe:LDAPVerifyServerCert On|Off
    Défaut:LDAPVerifyServerCert On
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    +

    Cette directive permet de spécifier s'il faut forcer la + vérification d'un certificat de serveur lors de l'établissement + d'une connexion SSL avec un serveur LDAP.

    -

    Un ou plusieurs certificats de CA doivent être spécifiés pour - que le SDK OpenLDAP fonctionne correctement. Ces certificats - peuvent être spécifiés sous forme de fichiers au format binaire - DER ou codés en Base64 (PEM).

    +
    +
    top
    +
    +

    Exemple de configuration

    +

    Ce qui suit est un exemple de configuration qui utilise + mod_ldap pour améliorer les performances de + l'authentification HTTP de base fournie par + mod_authnz_ldap.

    -

    Les certificats clients sont spécifiés pour chaque connexion - à l'aide de la directive LDAPTrustedClientCert.

    + 
    # Active la conservation des connexions LDAP et le cache partagé en
+# mémoire. Active le gestionnaire de statut du cache LDAP.
+# Nécessite le chargement de mod_ldap et de mod_authnz_ldap.
+# Remplacez "votre-domaine.example.com" par le nom de votre
+# domaine.
 
-        
    La documentation du SDK prétend que SSL et STARTTLS sont
-	supportés ; cependant, STARTTLS semble ne pas fonctionner avec
-	toutes les versions du SDK. Le mode SSL/TLS peut être défini en
-	utilisant le paramètre de la directive LDAPTrustedMode. Si une
-	URL de type
-	ldaps:// est spécifiée, le mode SSL est forcé. La documentation
-	OpenLDAP indique que le support SSL (ldaps://) tend à être
-	remplacé par TLS, bien que le mode SSL fonctionne toujours.
    
+LDAPSharedCacheSize 500000
+LDAPCacheEntries 1024
+LDAPCacheTTL 600
+LDAPOpCacheEntries 1024
+LDAPOpCacheTTL 600
 
-        
    # Spécifie deux fichiers contenant des certificats de CA
-LDAPTrustedGlobalCert CA_DER /certs/cacert1.der
-LDAPTrustedGlobalCert CA_BASE64 /certs/cacert2.pem
 <Location /ldap-status>
     SetHandler ldap-status
     
     Require host yourdomain.example.com
     
-    LDAPTrustedClientCert CERT_BASE64 /certs/cert1.pem
-    LDAPTrustedClientCert KEY_BASE64 /certs/key1.pem
-    # CA certs respecified due to per-directory client certs
-    LDAPTrustedClientCert CA_DER /certs/cacert1.der
-    LDAPTrustedClientCert CA_BASE64 /certs/cacert2.pem
     Satisfy any
     AuthType Basic
     AuthName "LDAP Protected"
     AuthBasicProvider ldap
-    AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one
+    AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one
     Require valid-user
 </Location>
    
 
+
    top
    +
    +

    Conservation des connexions LDAP

    - - -

    SDK Solaris

    +

    Les connexions LDAP sont conservées de requête en requête. Ceci + permet de rester connecté et identifié au serveur LDAP, ce dernier + étant ainsi prêt pour la prochaine requête, sans avoir à se + déconnecter, reconnecter et réidentifier. Le gain en performances + est similaire à celui des connexions persistantes (keepalives) + HTTP.

    -

    SSL/TLS pour les bibliothèques LDAP propres à Solaris n'est - pas encore supporté. Si nécessaire, installez et utilisez plutôt - les bibliothèques OpenLDAP.

    +

    Sur un serveur très sollicité, il est possible que de nombreuses + requêtes tentent d'accéder simultanément à la même connexion au + serveur LDAP. Lorsqu'une connexion LDAP est utilisée, Apache en crée + une deuxième en parallèle à la première, ce qui permet d'éviter que + le système de conservation des connexions ne devienne un goulot + d'étranglement.

    - +

    Il n'est pas nécessaire d'activer explicitement la conservation + des connexions dans la configuration d'Apache. Tout module utilisant + le module ldap pour accéder aux services LDAP partagera le jeu de + connexions.

    -

    SDK Microsoft

    +

    Les connexions LDAP peuvent garder la trace des données + d'identification du client ldap utilisées pour l'identification + auprès du serveur LDAP. Ces données peuvent être fournies aux + serveurs LDAP qui ne permettent pas les connexions anonymes au cours + lors des tentatives de sauts vers des serveurs alternatifs. Pour + contrôler cette fonctionnalité, voir les directives LDAPReferrals et LDAPReferralHopLimit. Cette + fonctionnalité est activée par défaut.

    +
    top
    +
    +

    Cache LDAP

    -

    La configuration des certificats SSL/TLS pour les - bibliothèques LDAP propres à Microsoft s'effectue à l'intérieur - du registre système, et aucune directive de configuration n'est - requise.

    +

    Pour améliorer les performances, mod_ldap met en + oeuvre une stratégie de mise en cache agressive visant à minimiser + le nombre de fois que le serveur LDAP doit être contacté. La mise en + cache peut facilement doubler et même tripler le débit d'Apache + lorsqu'il sert des pages protégées par mod_authnz_ldap. De plus, le + serveur LDAP verra lui-même sa charge sensiblement diminuée.

    -

    SSL et TLS sont tous deux supportés en utilisant des URLs de - type ldaps://, ou en définissant la directive LDAPTrustedMode à - cet effet.

    +

    mod_ldap supporte deux types de mise en cache + LDAP : un cache recherche/identification durant la phase + de recherche/identification et deux caches d'opérations + durant la phase de comparaison. Chaque URL LDAP utilisée par le + serveur a son propre jeu d'instances dans ces trois caches.

    -

    Note: L'état du support des certificats clients n'est pas - encore connu pour ce SDK.

    +

    Le cache + recherche/identification

    +

    Les processus de recherche et d'identification sont les + opérations LDAP les plus consommatrices en temps, en particulier + si l'annuaire est de grande taille. Le cache de + recherche/identification met en cache toutes les recherches qui + ont abouti à une identification positive. Les résultats négatifs + (c'est à dire les recherches sans succès, ou les recherches qui + n'ont pas abouti à une identification positive) ne sont pas mis en + cache. La raison de cette décision réside dans le fait que les + connexions avec des données d'identification invalides ne + représentent qu'un faible pourcentage du nombre total de + connexions, et ainsi, le fait de ne pas mettre en cache les + données d'identification invalides réduira d'autant la taille du + cache.

    - +

    mod_ldap met en cache le nom d'utilisateur, le + DN extrait, le mot de passe utilisé pour l'identification, ainsi + que l'heure de l'identification. Chaque fois qu'une nouvelle + connexion est initialisée avec le même nom d'utilisateur, + mod_ldap compare le mot de passe de la nouvelle + connexion avec le mot de passe enregistré dans le cache. Si les + mots de passe correspondent, et si l'entrée du cache n'est pas + trop ancienne, mod_ldap court-circuite la phase + de recherche/identification.

    -
    -
    top
    -

    Directive LDAPCacheEntries

    - - - - - - - -
    Description:Nombre maximum d'entrées dans le cache LDAP -primaire
    Syntaxe:LDAPCacheEntries nombre
    Défaut:LDAPCacheEntries 1024
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    -

    Cette directive permet de spécifier la taille maximale du cache - LDAP primaire. Ce cache contient les résultats de - recherche/identification positifs. Définissez-la à 0 pour désactiver - la mise en cache des résultats de recherche/identification positifs. - La taille par défaut est de 1024 recherches en cache.

    +

    Le cache de recherche/identification est contrôlé par les + directives LDAPCacheEntries et LDAPCacheTTL.

    + -
    -
    top
    -

    Directive LDAPCacheTTL

    - - - - - - - -
    Description:Durée pendant laquelle les entrées du cache restent -valides.
    Syntaxe:LDAPCacheTTL secondes
    Défaut:LDAPCacheTTL 600
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    -

    Cette directive permet de spécifier la durée (en secondes) - pendant laquelle une entrée du cache de recherche/identification - reste valide. La valeur par défaut est de 600 secondes (10 - minutes).

    +

    Les caches d'opérations

    +

    Au cours des opérations de comparaison d'attributs et de noms + distinctifs (DN), mod_ldap utilise deux caches + d'opérations pour mettre en cache les opérations de comparaison. + Le premier cache de comparaison sert à mettre en cache les + résultats de comparaisons effectuées pour vérifier l'appartenance + à un groupe LDAP. Le second cache de comparaison sert à mettre en + cache les résultats de comparaisons entre DNs.

    -
    -
    top
    -

    Directive LDAPConnectionPoolTTL

    - - - - - - - - -
    Description:Désactive les connexions d'arrière-plan qui sont restées -inactives trop longtemps au sein du jeu de connexions.
    Syntaxe:LDAPConnectionPoolTTL n
    Défaut:LDAPConnectionPoolTTL -1
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ldap
    Compatibilité:Disponible à partir de la version 2.3.12 du serveur HTTP -Apache
    -

    Cette directive permet de spécifier la durée maximale, en - secondes, pendant laquelle une connexion LDAP du jeu de connexions - peut demeurer inactive, mais rester quand-même disponible pour une - utilisation éventuelle. Le jeu de connexions est nettoyé au fur et à - mesure des besoins, de manière non asynchrone.

    +

    Notez que, lorsque l'appartenance à un groupe est vérifiée, + toute comparaison de sous-groupes est mise en cache afin + d'accélérer les comparaisons de sous-groupes ultérieures.

    -

    Si cette directive est définie à 0, les connexions ne sont jamais - sauvegardées dans le jeu de connexions d'arrière-plan. Avec la - valeur par défaut -1, ou toute autre valeur négative, les connexions - peuvent être réutilisées sans limite de durée.

    +

    Le comportement de ces deux caches est contrôlé par les + directives LDAPOpCacheEntries et LDAPOpCacheTTL.

    + -

    Dans le but d'améliorer les performances, le temps de référence - qu'utilise cette directive correspond au moment où la connexion LDAP - est enregistrée ou remise dans le jeu de connexions, et non au - moment du dernier échange réussi avec le serveur LDAP.

    +

    Superviser le cache

    +

    mod_ldap possède un gestionnaire de contenu + qui permet aux administrateurs de superviser les performances du + cache. Le nom du gestionnaire de contenu est + ldap-status, et on peut utiliser les directives + suivantes pour accéder aux informations du cache de + mod_ldap :

    -

    La version 2.4.10 a introduit de nouvelles mesures permettant - d'éviter une augmentation excessive du temps de référence due à des - correspondances positives dans le cache ou des requêtes lentes. A - cet effet, le temps de référence n'est pas réactualisé si aucune - connexion LDAP d'arrière-plan n'est requise ; d'autre part, le temps - de référence se base sur le moment où la requête HTTP est reçue, et - non sur le moment où la requête a été traitée.

    + 
    <Location /server/cache-info>
+    SetHandler ldap-status
+</Location>
    -

    Cette durée de vie s'exprime par défaut en secondes, mais - il est possible d'utiliser d'autres unités en ajoutant un suffixe : - millisecondes (ms), minutes (min), ou heures (h). -

    -
    -
    top
    -

    Directive LDAPConnectionTimeout

    - - - - - - -
    Description:Spécifie le délai d'attente en secondes de la socket de -connexion
    Syntaxe:LDAPConnectionTimeout secondes
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    -

    Cette directive configure l'option LDAP_OPT_NETWORK_TIMEOUT (ou - LDAP_OPT_CONNECT_TIMEOUT) dans la bibliothèque client LDAP - sous-jacente, si elle est disponible. Cette valeur représente la - durée pendant laquelle la bibliothèque client LDAP va attendre que - le processus de connexion TCP au serveur LDAP soit achevé.

    +

    En se connectant à l'URL + http://nom-serveur/infos-cache, l'administrateur peut + obtenir un rapport sur le statut de chaque cache qu'utilise + mod_ldap. Notez que si Apache ne supporte pas la + mémoire partagée, chaque instance de httpd + possèdera son propre cache, et chaque fois que l'URL sera + rechargée, un résultat différent pourra être affiché, en fonction + de l'instance de httpd qui traitera la + requête.

    + +
    top
    +
    +

    Utiliser SSL/TLS

    -

    Si la connexion n'a pas réussi avant ce délai, une erreur sera - renvoyée, ou la bibliothèque client LDAP tentera de se connecter à - un second serveur LDAP, s'il en a été défini un (via une liste de - noms d'hôtes séparés par des espaces dans la directive AuthLDAPURL).

    +

    La possibilité de créer des connexions SSL et TLS avec un serveur + LDAP est définie par les directives + LDAPTrustedGlobalCert, + LDAPTrustedClientCert et + LDAPTrustedMode. Ces directives permettent de spécifier + l'autorité de certification (CA), les certificats clients éventuels, + ainsi que le type de chiffrement à utiliser pour la connexion (none, + SSL ou TLS/STARTTLS).

    -

    La valeur par défaut est 10 secondes, si la bibliothèque client - LDAP liée avec le serveur supporte l'option - LDAP_OPT_NETWORK_TIMEOUT.

    + 
    # Etablissement d'une connexion SSL LDAP sur le port 636.
+# Nécessite le chargement de mod_ldap et mod_authnz_ldap.
+# Remplacez "votre-domaine.example.com" par le nom de votre
+# domaine.
 
-    
    LDAPConnectionTimeout n'est disponible que si la bibliothèque client
-    LDAP liée avec le serveur supporte l'option
-    LDAP_OPT_NETWORK_TIMEOUT (ou LDAP_OPT_CONNECT_TIMEOUT), et le
-    comportement final est entièrement dicté par la bibliothèque client
-    LDAP.
-    
    
+LDAPTrustedGlobalCert CA_DER /certs/certfile.der
 
-
    -
    top
    -

    Directive LDAPLibraryDebug

    - - - - - - - -
    Description:Active le débogage dans le SDK LDAP
    Syntaxe:LDAPLibraryDebug 7
    Défaut:disabled
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    -

    Active les options de débogage LDAP spécifiques au SDK, qui - entraînent en général une journalisation d'informations verbeuses du - SDK LDAP dans le journal principal des erreurs d'Apache. Les - messages de traces en provenance du SDK LDAP fournissent des - informations très détaillées qui peuvent s'avérer utiles lors du - débogage des problèmes de connexion avec des serveurs LDAP - d'arrière-plan.

    +<Location /ldap-status> + SetHandler ldap-status + + Require host yourdomain.example.com + + Satisfy any + AuthType Basic + AuthName "LDAP Protected" + AuthBasicProvider ldap + AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one + Require valid-user +</Location> -

    Cette option n'est configurable que lorsque le serveur HTTP - Apache est lié avec un SDK LDAP qui implémente - LDAP_OPT_DEBUG ou LDAP_OPT_DEBUG_LEVEL, - comme OpenLDAP (une valeur de 7 est verbeuse) ou Tivoli Directory - Server (une valeur de 65535 est verbeuse).

    -
    -

    Les informations journalisées peuvent contenir des données - d'authentification en clair utilisées ou validées lors de - l'authentification LDAP ; vous devez donc prendre soin de protéger - et de purger le journal des erreurs lorsque cette directive est - utilisée.

    -
    + 
    # Etablissement d'une connexion TLS LDAP sur le port 389.
+# Nécessite le chargement de mod_ldap et mod_authnz_ldap.
+# Remplacez "votre-domaine.example.com" par le nom de votre
+# domaine.
 
+LDAPTrustedGlobalCert CA_DER /certs/certfile.der
 
-
    -
    top
    -

    Directive LDAPOpCacheEntries

    - - - - - - - -
    Description:Nombre d'entrées utilisées pour mettre en cache les -opérations de comparaison LDAP
    Syntaxe:LDAPOpCacheEntries nombre
    Défaut:LDAPOpCacheEntries 1024
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    -

    Cette directive permet de spécifier le nombre d'entrées que - mod_ldap va utiliser pour mettre en cache les - opérations de comparaison LDAP. La valeur par défaut est de 1024 - entrées. Si elle est définie à 0, la mise en cache des opérations de - comparaison LDAP est désactivée.

    +<Location /ldap-status> + SetHandler ldap-status + + Require host yourdomain.example.com + + Satisfy any + AuthType Basic + AuthName "LDAP Protected" + AuthBasicProvider ldap + AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one TLS + Require valid-user +</Location> -
    -
    top
    -

    Directive LDAPOpCacheTTL

    - - - - - - - -
    Description:Durée pendant laquelle les entrées du cache d'opérations -restent valides
    Syntaxe:LDAPOpCacheTTL secondes
    Défaut:LDAPOpCacheTTL 600
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    -

    Cette directive permet de spécifier la durée (en secondes) - pendant laquelle les entrées du cache d'opérations restent valides. - La valeur par défaut est de 600 secondes.

    -
    -
    top
    -

    Directive LDAPReferralHopLimit

    - - - - - - - - -
    Description:Le nombre maximum de redirections vers des serveurs -alternatifs (referrals) avant l'abandon de la requête -LDAP.
    Syntaxe:LDAPReferralHopLimit nombre
    Défaut:Dépend du SDK, en général entre 5 et 10
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_ldap
    -

    Si elle est activée par la directive LDAPReferrals, - cette directive permet de définir le nombre maximum de sauts vers - des serveurs alternatifs (referrals) avant l'abandon de la requête - LDAP.

    +
    top
    +
    +

    Certificats SSL/TLS

    -
    -

    L'ajustement de ce paramètre n'est pas commun à tous les SDKs LDAP.

    -
    +

    Les différents SDKs LDAP disposent de nombreuses méthodes pour + définir et gérer les certificats des clients et des autorités de + certification (CA).

    -
    -
    top
    -

    Directive LDAPReferrals

    - - - - - - - - - -
    Description:Active la redirection vers des serveurs alternatifs au -cours des requêtes vers le serveur LDAP.
    Syntaxe:LDAPReferrals On|Off|default
    Défaut:LDAPReferrals On
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_ldap
    Compatibilité:Le paramètre default est disponible depuis la -version 2.4.7 du serveur HTTP Apache.
    -

    Certains serveurs LDAP partagent leur annuaire en plusieurs - domaines et utilisent le système des redirections (referrals) pour - aiguiller un client lorsque les limites d'un domaine doivent être - franchies. Ce processus est similaire à une redirection HTTP. Les - bibliothèques client LDAP ne respectent pas forcément ces - redirections par défaut. Cette directive permet de configurer - explicitement les redirections LDAP dans le SDK sous-jacent.

    +

    Si vous avez l'intention d'utiliser SSL ou TLS, lisez cette + section ATTENTIVEMENT de façon à bien comprendre les différences de + configurations entre les différents SDKs LDAP supportés.

    + +

    SDK Netscape/Mozilla/iPlanet

    +

    Les certificat de CA sont enregistrés dans un fichier nommé + cert7.db. Le SDK ne dialoguera avec aucun serveur LDAP dont le + certificat n'a pas été signé par une CA spécifiée dans ce + fichier. Si des certificats clients sont requis, un fichier + key3.db ainsi qu'un mot de passe optionnels peuvent être + spécifiés. On peut aussi spécifier le fichier secmod si + nécessaire. Ces fichiers sont du même format que celui utilisé + par les navigateurs web Netscape Communicator ou Mozilla. Le + moyen le plus simple pour obtenir ces fichiers consiste à les + extraire de l'installation de votre navigateur.

    + +

    Les certificats clients sont spécifiés pour chaque connexion + en utilisant la directive LDAPTrustedClientCert et en se + référant au certificat "nickname". On peut éventuellement + spécifier un mot de passe pour déverrouiller la clé privée du + certificat.

    + +

    Le SDK supporte seulement SSL. Toute tentative d'utilisation + de STARTTLS engendrera une erreur lors des tentatives de + contacter le serveur LDAP pendant l'exécution.

    + + 
    # Spécifie un fichier de certificats de CA Netscape
+LDAPTrustedGlobalCert CA_CERT7_DB /certs/cert7.db
+# Spécifie un fichier key3db optionnel pour le support des
+# certificats clients
+LDAPTrustedGlobalCert CERT_KEY3_DB /certs/key3.db
+# Spécifie le fichier secmod si nécessaire
+LDAPTrustedGlobalCert CA_SECMOD /certs/secmod
+<Location /ldap-status>
+    SetHandler ldap-status
+
+    Require host yourdomain.example.com
+
+    Satisfy any
+    AuthType Basic
+    AuthName "LDAP Protected"
+    AuthBasicProvider ldap
+    LDAPTrustedClientCert CERT_NICKNAME <nickname> [password]
+    AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one
+    Require valid-user
+</Location>
    -

    La directive LDAPReferrals accepte les - valeurs suivantes :

    -
    -
    "on"
    -

    Avec la valeur "on", la prise en compte des redirections - LDAP par le SDK sous-jacent est activée, la directive - LDAPReferralHopLimit permet de surcharger la - "hop limit" du SDK, et un "LDAP rebind callback" est enregistré.

    -
    "off"
    -

    Avec la valeur "off", la prise en compte des redirections - LDAP par le SDK sous-jacent est complètement désactivée.

    -
    "default"
    -

    Avec la valeur "default", la prise en compte des redirections - LDAP par le SDK sous-jacent n'est pas modifiée, la directive - LDAPReferralHopLimit ne permet pas de surcharger la - "hop limit" du SDK, et aucun "LDAP rebind callback" n'est enregistré.

    -
    -

    La directive LDAPReferralHopLimit travaille en - conjonction avec cette directive pour limiter le nombre de - redirections à suivre pour achever le traitement de la requête LDAP. - Lorsque le processus de redirection est activé par la valeur "On", - les données d'authentification du client sont transmises via un - "rebind callback" à tout serveur LDAP qui en fait la demande.

    -
    -
    top
    -

    Directive LDAPRetries

    - - - - - - - -
    Description:Définit le nombre maximum de tentatives de connexions au -serveur LDAP.
    Syntaxe:LDAPRetries nombre d'essais
    Défaut:LDAPRetries 3
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    -

    Suite à des échecs de connexion au serveur LDAP, le serveur - tentera de se connecter autant de fois qu'indiqué par la directive - LDAPRetries. Si cette directive est définie à - 0, le serveur ne tentera pas d'autre connexion après un échec.

    -

    Il est possible d'effectuer une autre tentative de connexion en - cas d'erreurs LDAP du type délai dépassé ou connexion refusée.

    +

    SDK Novell

    -
    -
    top
    -

    Directive LDAPRetryDelay

    - - - - - - - -
    Description:Définit le temps d'attente avant un autre essai de connexion au -serveur LDAP.
    Syntaxe:LDAPRetryDelay secondes
    Défaut:LDAPRetryDelay 0
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    -

    Si la directive LDAPRetryDelay est définie - à une valeur différente de 0, le serveur attendra pendant la durée - spécifiée pour envoyer à nouveau sa requête LDAP. Une valeur de 0 - implique une absence de délai pour les essais successifs.

    +

    Un ou plusieurs certificats de CA doivent être spécifiés pour + que le SDK Novell fonctionne correctement. Ces certificats + peuvent être spécifiés sous forme de fichiers au format binaire + DER ou codés en Base64 (PEM).

    -

    Il est possible d'effectuer une autre tentative de connexion en - cas d'erreurs LDAP du type délai dépassé ou connexion refusée.

    +

    Note: Les certificats clients sont spécifiés globalement + plutôt qu'à chaque connexion, et doivent être spécifiés à l'aide + de la directive LDAPTrustedGlobalCert comme ci-dessous. Définir + des certificats clients via la directive LDAPTrustedClientCert + engendrera une erreur qui sera journalisée, au moment de la + tentative de connexion avec le serveur LDAP.

    -
    -
    top
    -

    Directive LDAPSharedCacheFile

    - - - - - - -
    Description:Définit le fichier du cache en mémoire -partagée
    Syntaxe:LDAPSharedCacheFile chemin/fichier
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    -

    Cette directive permet de spécifier le chemin du - fichier du cache en mémoire partagée. Si elle n'est pas définie, la - mémoire partagée anonyme sera utilisée si la plate-forme la - supporte.

    +

    Le SDK supporte SSL et STARTTLS, le choix étant défini par le + paramètre de la directive LDAPTrustedMode. Si une URL de type + ldaps:// est spécifiée, le mode SSL est forcé, et l'emporte sur + cette directive.

    + + 
    # Spécifie deux fichiers contenant des certificats de CA
+LDAPTrustedGlobalCert CA_DER /certs/cacert1.der
+LDAPTrustedGlobalCert CA_BASE64 /certs/cacert2.pem
+# Spécifie un fichier contenant des certificats clients
+# ainsi qu'une clé
+LDAPTrustedGlobalCert CERT_BASE64 /certs/cert1.pem
+LDAPTrustedGlobalCert KEY_BASE64 /certs/key1.pem [password]
+# N'utilisez pas cette directive, sous peine de provoquer
+# une erreur
+#LDAPTrustedClientCert CERT_BASE64 /certs/cert1.pem
    -
    -
    top
    -

    Directive LDAPSharedCacheSize

    - - - - - - - -
    Description:Taille en octets du cache en mémoire partagée
    Syntaxe:LDAPSharedCacheSize octets
    Défaut:LDAPSharedCacheSize 500000
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    -

    Cette directive permet de spécifier le nombre d'octets à allouer - pour le cache en mémoire partagée. La valeur par - défaut est 500kb. - Si elle est définie à 0, le cache en mémoire partagée ne sera pas - utilisé et chaque processus HTTPD va créer son propre cache.

    + -
    -
    top
    -

    Directive LDAPTimeout

    - - - - - - - - -
    Description:Spécifie le délai d'attente pour les opérations de -recherche et d'identification LDAP en secondes
    Syntaxe:LDAPTimeout secondes
    Défaut:LDAPTimeout 60
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    Compatibilité:Disponible à partir de la version 2.3.5 du serveur HTTP -Apache
    -

    Cette directive permet de spécifier le délai d'attente pour les - opérations de recherche et d'identification, ainsi que l'option - LDAP_OPT_TIMEOUT dans la bibliothèque LDAP client sous-jacente, - lorsqu'elle est disponible.

    +

    SDK OpenLDAP

    -

    Lorsque le délai est atteint, httpd va refaire un essai dans le - cas où une connexion existante a été silencieusement fermée par un - pare-feu. Les performances seront cependant bien meilleures si le - pare-feu est configuré pour envoyer des paquets TCP RST au lieu de - rejeter silencieusement les paquets.

    +

    Un ou plusieurs certificats de CA doivent être spécifiés pour + que le SDK OpenLDAP fonctionne correctement. Ces certificats + peuvent être spécifiés sous forme de fichiers au format binaire + DER ou codés en Base64 (PEM).

    -
    -

    Les délais pour les opérations de comparaison LDAP nécessitent un - SDK avec LDAP_OPT_TIMEOUT, comme OpenLDAP >= 2.4.4.

    -
    +

    Les certificats clients sont spécifiés pour chaque connexion + à l'aide de la directive LDAPTrustedClientCert.

    +

    La documentation du SDK prétend que SSL et STARTTLS sont + supportés ; cependant, STARTTLS semble ne pas fonctionner avec + toutes les versions du SDK. Le mode SSL/TLS peut être défini en + utilisant le paramètre de la directive LDAPTrustedMode. Si une + URL de type + ldaps:// est spécifiée, le mode SSL est forcé. La documentation + OpenLDAP indique que le support SSL (ldaps://) tend à être + remplacé par TLS, bien que le mode SSL fonctionne toujours.

    -
    -
    top
    -

    Directive LDAPTrustedClientCert

    - - - - - - -
    Description:Définit le nom de fichier contenant un certificat client ou -un alias renvoyant vers un certificat client spécifique à une connexion. -Tous les SDK LDAP ne supportent pas les certificats clients par -connexion.
    Syntaxe:LDAPTrustedClientCert type -chemin/nom-fichier/alias [mot de passe]
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    Statut:Extension
    Module:mod_ldap
    -

    Cette directive permet de spécifier le chemin et le nom de - fichier ou l'alias d'un certificat client par connexion utilisé lors - de l'établissement d'une connexion SSL ou TLS avec un serveur LDAP. - Les sections directory ou location peuvent posséder leurs propres - configurations de certificats clients. Certains SDK LDAP (en - particulier Novell) ne supportent pas les certificats clients par - connexion, et renvoient une erreur lors de la connexion au serveur - LDAP si vous tenter d'utiliser cette directive (Utilisez à la place - la directive LDAPTrustedGlobalCert pour les certificats clients sous - Novell - Voir plus haut le guide des certificats SSL/TLS pour plus - de détails). Le paramètre type spécifie le type du certificat en - cours de définition, en fonction du SDK LDAP utilisé. Les types - supportés sont :

    -
      -
    • CA_DER - certificat de CA codé en binaire DER
      • -
    • CA_BASE64 - certificat de CA codé en PEM
      • -
    • CERT_DER - certificat client codé en binaire DER
      • -
    • CERT_BASE64 - certificat client codé en PEM
      • -
    • CERT_NICKNAME - certificat client "nickname" (SDK Netscape)
      • -
    • KEY_DER - clé privée codée en binaire DER
      • -
    • KEY_BASE64 - clé privée codée en PEM
      • -
    + 
    # Spécifie deux fichiers contenant des certificats de CA
+LDAPTrustedGlobalCert CA_DER /certs/cacert1.der
+LDAPTrustedGlobalCert CA_BASE64 /certs/cacert2.pem
+<Location /ldap-status>
+    SetHandler ldap-status
+    
+    Require host yourdomain.example.com
+    
+    LDAPTrustedClientCert CERT_BASE64 /certs/cert1.pem
+    LDAPTrustedClientCert KEY_BASE64 /certs/key1.pem
+    # CA certs respecified due to per-directory client certs
+    LDAPTrustedClientCert CA_DER /certs/cacert1.der
+    LDAPTrustedClientCert CA_BASE64 /certs/cacert2.pem
+    Satisfy any
+    AuthType Basic
+    AuthName "LDAP Protected"
+    AuthBasicProvider ldap
+    AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one
+    Require valid-user
+</Location>
    -
    -
    top
    -

    Directive LDAPTrustedGlobalCert

    - - - - - - -
    Description:Définit le nom de fichier ou la base de données contenant -les Autorités de Certification de confiance globales ou les certificats -clients globaux
    Syntaxe:LDAPTrustedGlobalCert type -chemin/nom-fichier [mot de passe]
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    -

    Cette directive permet de spécifier le chemin et le nom du - fichier contenant les certificats des CA de confiance et/ou les - certificats clients du système global que mod_ldap - utilisera pour établir une connexion SSL ou TLS avec un serveur - LDAP. Notez que toute information relative aux certificats spécifiée - en utilisant cette directive s'applique globalement à l'ensemble de - l'installation du serveur. Certains SDK LDAP (en particulier Novell) - nécessitent la définition globale de tous les certificats clients en - utilisant cette directive. La plupart des autres SDK nécessitent la - définition des certificats clients dans une section Directory ou - Location en utilisant la directive LDAPTrustedClientCert. Si vous ne - définissez pas ces directives correctement, une erreur sera générée - lors des tentatives de contact avec un serveur LDAP, ou la connexion - échouera silencieusement (Voir plus haut le guide des certificats - SSL/TLS pour plus de détails). Le paramètre type spécifie le type de - certificat en cours de définition, en fonction du SDK LDAP utilisé. - Les types supportés sont :

    -
      -
    • CA_DER - certificat de CA codé en binaire DER
      • -
    • CA_BASE64 - certificat de CA codé en PEM
      • -
    • CA_CERT7_DB - fichier de base de données des certificats de CA - de Netscape cert7.db
      • -
    • CA_SECMOD - fichier de base de données secmod de Netscape
      • -
    • CERT_DER - certificat client codé en binaire DER
      • -
    • CERT_BASE64 - certificat client codé en PEM
      • -
    • CERT_KEY3_DB - fichier de base de données des certificats - clients de Netscape key3.db
      • -
    • CERT_NICKNAME - certificat client "nickname" (SDK Netscape)
      • -
    • CERT_PFX - certificat client codé en PKCS#12 (SDK Novell)
      • -
    • KEY_DER - clé privée codée en binaire DER
      • -
    • KEY_BASE64 - clé privée codée en PEM
      • -
    • KEY_PFX - clé privée codée en PKCS#12 (SDK Novell)
      • -
    -
    -
    top
    -

    Directive LDAPTrustedMode

    - - - - - - -
    Description:Spécifie le mode (SSL ou TLS) à utiliser lors de la -connexion à un serveur LDAP.
    Syntaxe:LDAPTrustedMode type
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ldap
    -

    Les modes suivants sont supportés :

    -
      -
    • NONE - aucun chiffrement
      • -
    • SSL - chiffrement ldaps:// sur le port par défaut 636
      • -
    • TLS - chiffrement STARTTLS sur le port par défaut 389
      • -
    + -

    Les modes ci-dessus ne sont pas supportés par tous les SDK LDAP. - Un message d'erreur sera généré à l'exécution si un mode n'est pas - supporté, et la connexion au serveur LDAP échouera. -

    +

    SDK Solaris

    -

    Si une URL de type ldaps:// est spécifiée, le mode est forcé à - SSL et la définition de LDAPTrustedMode est ignorée.

    +

    SSL/TLS pour les bibliothèques LDAP propres à Solaris n'est + pas encore supporté. Si nécessaire, installez et utilisez plutôt + les bibliothèques OpenLDAP.

    -
    -
    top
    -

    Directive LDAPVerifyServerCert

    - - - - - - - -
    Description:Force la vérification du certificat du -serveur
    Syntaxe:LDAPVerifyServerCert On|Off
    Défaut:LDAPVerifyServerCert On
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ldap
    -

    Cette directive permet de spécifier s'il faut forcer la - vérification d'un certificat de serveur lors de l'établissement - d'une connexion SSL avec un serveur LDAP.

    + + +

    SDK Microsoft

    + +

    La configuration des certificats SSL/TLS pour les + bibliothèques LDAP propres à Microsoft s'effectue à l'intérieur + du registre système, et aucune directive de configuration n'est + requise.

    + +

    SSL et TLS sont tous deux supportés en utilisant des URLs de + type ldaps://, ou en définissant la directive LDAPTrustedMode à + cet effet.

    + +

    Note: L'état du support des certificats clients n'est pas + encore connu pour ce SDK.

    + +
    diff --git a/docs/manual/mod/mod_log_config.html.en b/docs/manual/mod/mod_log_config.html.en index 53cd0cd2484..f734a562dc3 100644 --- a/docs/manual/mod/mod_log_config.html.en +++ b/docs/manual/mod/mod_log_config.html.en @@ -66,6 +66,186 @@
  • Apache Log Files
    • top
    +

    BufferedLogs Directive

    + + + + + + + +
    Description:Buffer log entries in memory before writing to disk
    Syntax:BufferedLogs On|Off
    Default:BufferedLogs Off
    Context:server config
    Status:Base
    Module:mod_log_config
    +

    The BufferedLogs directive causes + mod_log_config to store several log entries in + memory and write them together to disk, rather than writing them + after each request. On some systems, this may result in more + efficient disk access and hence higher performance. It may be + set only once for the entire server; it cannot be configured + per virtual-host.

    + +
    This directive should be used with caution as a crash might + cause loss of logging data.
    + +
    +
    top
    +

    CustomLog Directive

    + + + + + + +
    Description:Sets filename and format of log file
    Syntax:CustomLog file|pipe +format|nickname +[env=[!]environment-variable| +expr=expression]
    Context:server config, virtual host
    Status:Base
    Module:mod_log_config
    +

    The CustomLog directive is used to + log requests to the server. A log format is specified, and the + logging can optionally be made conditional on request + characteristics using environment variables.

    + +

    The first argument, which specifies the location to which + the logs will be written, can take one of the following two + types of values:

    + +
    +
    file
    +
    A filename, relative to the ServerRoot.
    + +
    pipe
    +
    The pipe character "|", followed by the path + to a program to receive the log information on its standard + input. See the notes on piped logs + for more information. + +

    Security:

    +

    If a program is used, then it will be run as the user who + started httpd. This will be root if the server was + started by root; be sure that the program is secure.

    +
    +

    Note

    +

    When entering a file path on non-Unix platforms, care should be taken + to make sure that only forward slashed are used even though the platform + may allow the use of back slashes. In general it is a good idea to always + use forward slashes throughout the configuration files.

    +
    +
    + +

    The second argument specifies what will be written to the + log file. It can specify either a nickname defined by + a previous LogFormat + directive, or it can be an explicit format string as + described in the log formats section.

    + +

    For example, the following two sets of directives have + exactly the same effect:

    + + 
    # CustomLog with format nickname
+LogFormat "%h %l %u %t \"%r\" %>s %b" common
+CustomLog "logs/access_log" common
+
+# CustomLog with explicit format string
+CustomLog "logs/access_log" "%h %l %u %t \"%r\" %>s %b"
    + + +

    The third argument is optional and controls whether or + not to log a particular request. The condition can be the + presence or absence (in the case of a 'env=!name' + clause) of a particular variable in the server + environment. Alternatively, the condition + can be expressed as arbitrary boolean expression. If the condition is not satisfied, the request + will not be logged. References to HTTP headers in the expression + will not cause the header names to be added to the Vary header.

    + +

    Environment variables can be set on a per-request + basis using the mod_setenvif + and/or mod_rewrite modules. For + example, if you want to record requests for all GIF + images on your server in a separate logfile but not in your main + log, you can use:

    + + 
    SetEnvIf Request_URI \.gif$ gif-image
+CustomLog "gif-requests.log" common env=gif-image
+CustomLog "nongif-requests.log" common env=!gif-image
    + + +

    Or, to reproduce the behavior of the old RefererIgnore + directive, you might use the following:

    + + 
    SetEnvIf Referer example\.com localreferer
+CustomLog "referer.log" referer env=!localreferer
    + + +
    +
    top
    +

    LogFormat Directive

    + + + + + + + +
    Description:Describes a format for use in a log file
    Syntax:LogFormat format|nickname +[nickname]
    Default:LogFormat "%h %l %u %t \"%r\" %>s %b"
    Context:server config, virtual host
    Status:Base
    Module:mod_log_config
    +

    This directive specifies the format of the access log + file.

    + +

    The LogFormat directive can take one of two + forms. In the first form, where only one argument is specified, + this directive sets the log format which will be used by logs + specified in subsequent TransferLog + directives. The single argument can specify an explicit + format as discussed in the custom log + formats section above. Alternatively, it can use a + nickname to refer to a log format defined in a + previous LogFormat directive as described + below.

    + +

    The second form of the LogFormat + directive associates an explicit format with a + nickname. This nickname can then be used in + subsequent LogFormat or + CustomLog directives + rather than repeating the entire format string. A + LogFormat directive that defines a nickname + does nothing else -- that is, it only + defines the nickname, it doesn't actually apply the format and make + it the default. Therefore, it will not affect subsequent + TransferLog directives. + In addition, LogFormat cannot use one nickname + to define another nickname. Note that the nickname should not contain + percent signs (%).

    + +

    Example

    LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common
    +
    + + +
    +
    top
    +

    TransferLog Directive

    + + + + + + +
    Description:Specify location of a log file
    Syntax:TransferLog file|pipe
    Context:server config, virtual host
    Status:Base
    Module:mod_log_config
    +

    This directive has exactly the same arguments and effect as + the CustomLog + directive, with the exception that it does not allow the log format + to be specified explicitly or for conditional logging of requests. + Instead, the log format is determined by the most recently specified + LogFormat directive + which does not define a nickname. Common Log Format is used if no + other format has been specified.

    + +

    Example

    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
+TransferLog logs/access_log
    +
    + +
    +
    top

    Custom Log Formats

    @@ -348,186 +528,6 @@ document for details on why your security could be compromised if the directory where logfiles are stored is writable by anyone other than the user that starts the server.

    -
    -
    top
    -

    BufferedLogs Directive

    - - - - - - - -
    Description:Buffer log entries in memory before writing to disk
    Syntax:BufferedLogs On|Off
    Default:BufferedLogs Off
    Context:server config
    Status:Base
    Module:mod_log_config
    -

    The BufferedLogs directive causes - mod_log_config to store several log entries in - memory and write them together to disk, rather than writing them - after each request. On some systems, this may result in more - efficient disk access and hence higher performance. It may be - set only once for the entire server; it cannot be configured - per virtual-host.

    - -
    This directive should be used with caution as a crash might - cause loss of logging data.
    - -
    -
    top
    -

    CustomLog Directive

    - - - - - - -
    Description:Sets filename and format of log file
    Syntax:CustomLog file|pipe -format|nickname -[env=[!]environment-variable| -expr=expression]
    Context:server config, virtual host
    Status:Base
    Module:mod_log_config
    -

    The CustomLog directive is used to - log requests to the server. A log format is specified, and the - logging can optionally be made conditional on request - characteristics using environment variables.

    - -

    The first argument, which specifies the location to which - the logs will be written, can take one of the following two - types of values:

    - -
    -
    file
    -
    A filename, relative to the ServerRoot.
    - -
    pipe
    -
    The pipe character "|", followed by the path - to a program to receive the log information on its standard - input. See the notes on piped logs - for more information. - -

    Security:

    -

    If a program is used, then it will be run as the user who - started httpd. This will be root if the server was - started by root; be sure that the program is secure.

    -
    -

    Note

    -

    When entering a file path on non-Unix platforms, care should be taken - to make sure that only forward slashed are used even though the platform - may allow the use of back slashes. In general it is a good idea to always - use forward slashes throughout the configuration files.

    -
    -
    - -

    The second argument specifies what will be written to the - log file. It can specify either a nickname defined by - a previous LogFormat - directive, or it can be an explicit format string as - described in the log formats section.

    - -

    For example, the following two sets of directives have - exactly the same effect:

    - - 
    # CustomLog with format nickname
-LogFormat "%h %l %u %t \"%r\" %>s %b" common
-CustomLog "logs/access_log" common
-
-# CustomLog with explicit format string
-CustomLog "logs/access_log" "%h %l %u %t \"%r\" %>s %b"
    - - -

    The third argument is optional and controls whether or - not to log a particular request. The condition can be the - presence or absence (in the case of a 'env=!name' - clause) of a particular variable in the server - environment. Alternatively, the condition - can be expressed as arbitrary boolean expression. If the condition is not satisfied, the request - will not be logged. References to HTTP headers in the expression - will not cause the header names to be added to the Vary header.

    - -

    Environment variables can be set on a per-request - basis using the mod_setenvif - and/or mod_rewrite modules. For - example, if you want to record requests for all GIF - images on your server in a separate logfile but not in your main - log, you can use:

    - - 
    SetEnvIf Request_URI \.gif$ gif-image
-CustomLog "gif-requests.log" common env=gif-image
-CustomLog "nongif-requests.log" common env=!gif-image
    - - -

    Or, to reproduce the behavior of the old RefererIgnore - directive, you might use the following:

    - - 
    SetEnvIf Referer example\.com localreferer
-CustomLog "referer.log" referer env=!localreferer
    - - -
    -
    top
    -

    LogFormat Directive

    - - - - - - - -
    Description:Describes a format for use in a log file
    Syntax:LogFormat format|nickname -[nickname]
    Default:LogFormat "%h %l %u %t \"%r\" %>s %b"
    Context:server config, virtual host
    Status:Base
    Module:mod_log_config
    -

    This directive specifies the format of the access log - file.

    - -

    The LogFormat directive can take one of two - forms. In the first form, where only one argument is specified, - this directive sets the log format which will be used by logs - specified in subsequent TransferLog - directives. The single argument can specify an explicit - format as discussed in the custom log - formats section above. Alternatively, it can use a - nickname to refer to a log format defined in a - previous LogFormat directive as described - below.

    - -

    The second form of the LogFormat - directive associates an explicit format with a - nickname. This nickname can then be used in - subsequent LogFormat or - CustomLog directives - rather than repeating the entire format string. A - LogFormat directive that defines a nickname - does nothing else -- that is, it only - defines the nickname, it doesn't actually apply the format and make - it the default. Therefore, it will not affect subsequent - TransferLog directives. - In addition, LogFormat cannot use one nickname - to define another nickname. Note that the nickname should not contain - percent signs (%).

    - -

    Example

    LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common
    -
    - - -
    -
    top
    -

    TransferLog Directive

    - - - - - - -
    Description:Specify location of a log file
    Syntax:TransferLog file|pipe
    Context:server config, virtual host
    Status:Base
    Module:mod_log_config
    -

    This directive has exactly the same arguments and effect as - the CustomLog - directive, with the exception that it does not allow the log format - to be specified explicitly or for conditional logging of requests. - Instead, the log format is determined by the most recently specified - LogFormat directive - which does not define a nickname. Common Log Format is used if no - other format has been specified.

    - -

    Example

    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
-TransferLog logs/access_log
    -
    -
    diff --git a/docs/manual/mod/mod_log_config.html.fr b/docs/manual/mod/mod_log_config.html.fr index 24b655ee026..6a5ed7e3d08 100644 --- a/docs/manual/mod/mod_log_config.html.fr +++ b/docs/manual/mod/mod_log_config.html.fr @@ -73,6 +73,198 @@ s d'Apache
    top
    +

    Directive BufferedLogs

    + + + + + + + +
    Description:Enregistre les entrées du journal dans un tampon en mémoire +avant de les écrire sur disque
    Syntaxe:BufferedLogs On|Off
    Défaut:BufferedLogs Off
    Contexte:configuration du serveur
    Statut:Base
    Module:mod_log_config
    +

    Lorsque la directive BufferedLogs est à + "on", mod_log_config stocke de nombreuses entrées + du journal en mémoire, et les écrit d'un seul bloc sur disque, + plutôt que de les écrire après chaque requête. Sur certains + systèmes, ceci peut améliorer l'efficacité des accès disque, et par + conséquent les performances. La directive ne peut être définie + qu'une seule fois pour l'ensemble du serveur ; elle ne peut pas être + définie au niveau d'un serveur virtuel.

    + +
    Cette directive doit être utilisée avec + précautions car un crash peut provoquer la perte de données de + journalisation.
    + +
    +
    top
    +

    Directive CustomLog

    + + + + + + +
    Description:Définit le nom et le format du fichier +journal
    Syntaxe:CustomLog fichier|pipe +format|alias +[env=[!]variable-environnement| +expr=expression]
    Contexte:configuration du serveur, serveur virtuel
    Statut:Base
    Module:mod_log_config
    +

    La directive CustomLog permet de contrôler + la journalisation des requêtes destinées au serveur. Un format de + journal est spécifié, et la journalisation peut s'effectuer de + manière conditionnelle en fonction des caractéristiques de la + requête en utilisant des variables d'environnement.

    + +

    Le premier argument, qui spécifie l'emplacement où les journaux + seront écrits, accepte deux types de valeurs :

    + +
    +
    fichier
    +
    Un nom de fichier, relatif au répertoire défini par la + directive ServerRoot.
    + +
    pipe
    +
    Le caractère pipe "|", suivi du chemin vers un + programme qui recevra les informations de la journalisation sur + son entrée standard. Voir les notes à propos de la journalisation redirigée pour plus + d'informations. + +

    Sécurité :

    +

    Si les journaux sont redirigés vers un programme, ce dernier + s'exécutera sous l'utilisateur qui a démarré + httpd. Ce sera l'utilisateur root si le serveur + a été démarré par root ; vérifiez que le programme est + sécurisé.

    +
    +

    Note

    +

    Lors de la spécification d'un chemin de fichier sur les + plate-formes non-Unix, il faut prendre soin de ne pas oublier + que seuls les slashes directs doivent être utilisés, même si la + plate-forme autorise l'emploi d'anti-slashes. D'une manière + générale, c'est une bonne idée que de n'utiliser que des slashes + directs dans les fichiers de configuration.

    +
    +
    + +

    Le second argument permet de définir ce qui va être écrit dans le + fichier journal. Il peut contenir soit un alias prédéfini + par une directive LogFormat, soit une chaîne de + format explicite comme décrit dans la section formats de journaux.

    + +

    Par exemple, les deux blocs de directives suivants produisent le + même effet :

    + + 
    # Journal personnalisé avec alias de format
+LogFormat "%h %l %u %t \"%r\" %>s %b" common
+CustomLog logs/access_log common
+
+# Journal personnalisé avec chaîne de format explicite
+CustomLog logs/access_log "%h %l %u %t \"%r\" %>s %b"
    + + +

    Le troisième argument est optionnel et permet de contrôler si une + requête doit être ou non journalisée. Dans le cas d'une clause + 'env=!nom', la condition peut être la + présence ou l'absence d'une variable particulière dans + l'environnement du serveur. Dans le cas + d'une clause 'expr=expression', la condition consiste + en une expression booléenne + quelconque. Si la condition n'est pas vérifiée, la requête ne sera + pas journalisée. D'éventuelles références à des en-têtes HTTP dans + l'expression rationnelle n'entraîneront pas l'ajout des noms + d'en-tête correspondants à l'en-tête Vary.

    + +

    Les variables d'environnement peuvent être définies au niveau de + chaque requête en utilisant les modules + mod_setenvif et/ou mod_rewrite. + Par exemple, si vous voulez enregistrer les requêtes pour toutes les + images GIF sur votre serveur dans un fichier journal séparé, et pas + dans votre journal principal, vous pouvez utiliser :

    + + 
    SetEnvIf Request_URI \.gif$ gif-image
+CustomLog gif-requests.log common env=gif-image
+CustomLog nongif-requests.log common env=!gif-image
    + + +

    Ou, pour reproduire le comportement de l'ancienne directive + RefererIgnore, vous pouvez utiliser :

    + + 
    SetEnvIf Referer example\.com localreferer
+CustomLog referer.log referer env=!localreferer
    + + +
    +
    top
    +

    Directive LogFormat

    + + + + + + + +
    Description:Décrit un format utilisable dans un fichier +journal
    Syntaxe:LogFormat format|alias +[alias]
    Défaut:LogFormat "%h %l %u %t \"%r\" %>s %b"
    Contexte:configuration du serveur, serveur virtuel
    Statut:Base
    Module:mod_log_config
    +

    Cette directive permet de spécifier le format du fichier journal + des accès.

    + +

    La directive LogFormat se présente sous + deux formes. Sous la première forme, qui ne possède qu'un seul + argument, la directive définit le format qui sera utilisé dans les + journaux spécifiés par les directives + TransferLog ultérieures. L'argument unique + peut contenir un format explicite comme décrit dans la + section formats de journaux personnalisés + ci-dessus. Il peut aussi contenir un alias faisant + référence à un format de journal prédéfini par une directive + LogFormat comme décrit plus loin.

    + +

    Sous sa seconde forme, la directive + LogFormat associe un format + explicite à un alias. Cet alias peut + ensuite s'utiliser dans les directives + LogFormat ou CustomLog ultérieures, ce qui + évite d'avoir à répéter l'ensemble de la chaîne de format. Une + directive LogFormat qui définit un alias + ne fait rien d'autre -- c'est à dire qu'elle ne + fait que définir l'alias, elle n'applique pas le format et n'en + fait pas le format par défaut. Par conséquent, elle n'affecte pas + les directives TransferLog ultérieures. En + outre, la directive LogFormat ne peut pas + utiliser un alias pour en définir un autre. Notez que l'alias ne + doit pas contenir de caractère pourcent (%).

    + +

    Exemple

    LogFormat "%v %h %l %u %t \"%r\" %>s %b" serveur_virtuel_commun
    +
    + + +
    +
    top
    +

    Directive TransferLog

    + + + + + + +
    Description:Spécifie l'emplacement d'un fichier journal
    Syntaxe:TransferLog fichier|pipe
    Contexte:configuration du serveur, serveur virtuel
    Statut:Base
    Module:mod_log_config
    +

    Cette directive possède exactement les mêmes arguments et produit + les mêmes effets que la directive CustomLog, à l'exception qu'elle + ne permet pas de spécifier un format de journal explicite ou la + journalisation conditionnelle des requêtes. En l'occurrence, le + format de journal est déterminé par la dernière définition d'une + directive LogFormat + qui ne définit pas d'alias. Si aucun format particulier n'a été + spécifié, c'est le Common Log Format qui sera utilisé.

    + +

    Exemple

    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
+TransferLog logs/access_log
    +
    + +
    +
    top

    Formats de journaux personnalisés

    @@ -374,198 +566,6 @@ s votre sécurité pourrait être compromise, si le répertoire où sont stockés les fichiers journaux sont inscriptibles par tout autre utilisateur que celui qui démarre le serveur.

    -
    -
    top
    -

    Directive BufferedLogs

    - - - - - - - -
    Description:Enregistre les entrées du journal dans un tampon en mémoire -avant de les écrire sur disque
    Syntaxe:BufferedLogs On|Off
    Défaut:BufferedLogs Off
    Contexte:configuration du serveur
    Statut:Base
    Module:mod_log_config
    -

    Lorsque la directive BufferedLogs est à - "on", mod_log_config stocke de nombreuses entrées - du journal en mémoire, et les écrit d'un seul bloc sur disque, - plutôt que de les écrire après chaque requête. Sur certains - systèmes, ceci peut améliorer l'efficacité des accès disque, et par - conséquent les performances. La directive ne peut être définie - qu'une seule fois pour l'ensemble du serveur ; elle ne peut pas être - définie au niveau d'un serveur virtuel.

    - -
    Cette directive doit être utilisée avec - précautions car un crash peut provoquer la perte de données de - journalisation.
    - -
    -
    top
    -

    Directive CustomLog

    - - - - - - -
    Description:Définit le nom et le format du fichier -journal
    Syntaxe:CustomLog fichier|pipe -format|alias -[env=[!]variable-environnement| -expr=expression]
    Contexte:configuration du serveur, serveur virtuel
    Statut:Base
    Module:mod_log_config
    -

    La directive CustomLog permet de contrôler - la journalisation des requêtes destinées au serveur. Un format de - journal est spécifié, et la journalisation peut s'effectuer de - manière conditionnelle en fonction des caractéristiques de la - requête en utilisant des variables d'environnement.

    - -

    Le premier argument, qui spécifie l'emplacement où les journaux - seront écrits, accepte deux types de valeurs :

    - -
    -
    fichier
    -
    Un nom de fichier, relatif au répertoire défini par la - directive ServerRoot.
    - -
    pipe
    -
    Le caractère pipe "|", suivi du chemin vers un - programme qui recevra les informations de la journalisation sur - son entrée standard. Voir les notes à propos de la journalisation redirigée pour plus - d'informations. - -

    Sécurité :

    -

    Si les journaux sont redirigés vers un programme, ce dernier - s'exécutera sous l'utilisateur qui a démarré - httpd. Ce sera l'utilisateur root si le serveur - a été démarré par root ; vérifiez que le programme est - sécurisé.

    -
    -

    Note

    -

    Lors de la spécification d'un chemin de fichier sur les - plate-formes non-Unix, il faut prendre soin de ne pas oublier - que seuls les slashes directs doivent être utilisés, même si la - plate-forme autorise l'emploi d'anti-slashes. D'une manière - générale, c'est une bonne idée que de n'utiliser que des slashes - directs dans les fichiers de configuration.

    -
    -
    - -

    Le second argument permet de définir ce qui va être écrit dans le - fichier journal. Il peut contenir soit un alias prédéfini - par une directive LogFormat, soit une chaîne de - format explicite comme décrit dans la section formats de journaux.

    - -

    Par exemple, les deux blocs de directives suivants produisent le - même effet :

    - - 
    # Journal personnalisé avec alias de format
-LogFormat "%h %l %u %t \"%r\" %>s %b" common
-CustomLog logs/access_log common
-
-# Journal personnalisé avec chaîne de format explicite
-CustomLog logs/access_log "%h %l %u %t \"%r\" %>s %b"
    - - -

    Le troisième argument est optionnel et permet de contrôler si une - requête doit être ou non journalisée. Dans le cas d'une clause - 'env=!nom', la condition peut être la - présence ou l'absence d'une variable particulière dans - l'environnement du serveur. Dans le cas - d'une clause 'expr=expression', la condition consiste - en une expression booléenne - quelconque. Si la condition n'est pas vérifiée, la requête ne sera - pas journalisée. D'éventuelles références à des en-têtes HTTP dans - l'expression rationnelle n'entraîneront pas l'ajout des noms - d'en-tête correspondants à l'en-tête Vary.

    - -

    Les variables d'environnement peuvent être définies au niveau de - chaque requête en utilisant les modules - mod_setenvif et/ou mod_rewrite. - Par exemple, si vous voulez enregistrer les requêtes pour toutes les - images GIF sur votre serveur dans un fichier journal séparé, et pas - dans votre journal principal, vous pouvez utiliser :

    - - 
    SetEnvIf Request_URI \.gif$ gif-image
-CustomLog gif-requests.log common env=gif-image
-CustomLog nongif-requests.log common env=!gif-image
    - - -

    Ou, pour reproduire le comportement de l'ancienne directive - RefererIgnore, vous pouvez utiliser :

    - - 
    SetEnvIf Referer example\.com localreferer
-CustomLog referer.log referer env=!localreferer
    - - -
    -
    top
    -

    Directive LogFormat

    - - - - - - - -
    Description:Décrit un format utilisable dans un fichier -journal
    Syntaxe:LogFormat format|alias -[alias]
    Défaut:LogFormat "%h %l %u %t \"%r\" %>s %b"
    Contexte:configuration du serveur, serveur virtuel
    Statut:Base
    Module:mod_log_config
    -

    Cette directive permet de spécifier le format du fichier journal - des accès.

    - -

    La directive LogFormat se présente sous - deux formes. Sous la première forme, qui ne possède qu'un seul - argument, la directive définit le format qui sera utilisé dans les - journaux spécifiés par les directives - TransferLog ultérieures. L'argument unique - peut contenir un format explicite comme décrit dans la - section formats de journaux personnalisés - ci-dessus. Il peut aussi contenir un alias faisant - référence à un format de journal prédéfini par une directive - LogFormat comme décrit plus loin.

    - -

    Sous sa seconde forme, la directive - LogFormat associe un format - explicite à un alias. Cet alias peut - ensuite s'utiliser dans les directives - LogFormat ou CustomLog ultérieures, ce qui - évite d'avoir à répéter l'ensemble de la chaîne de format. Une - directive LogFormat qui définit un alias - ne fait rien d'autre -- c'est à dire qu'elle ne - fait que définir l'alias, elle n'applique pas le format et n'en - fait pas le format par défaut. Par conséquent, elle n'affecte pas - les directives TransferLog ultérieures. En - outre, la directive LogFormat ne peut pas - utiliser un alias pour en définir un autre. Notez que l'alias ne - doit pas contenir de caractère pourcent (%).

    - -

    Exemple

    LogFormat "%v %h %l %u %t \"%r\" %>s %b" serveur_virtuel_commun
    -
    - - -
    -
    top
    -

    Directive TransferLog

    - - - - - - -
    Description:Spécifie l'emplacement d'un fichier journal
    Syntaxe:TransferLog fichier|pipe
    Contexte:configuration du serveur, serveur virtuel
    Statut:Base
    Module:mod_log_config
    -

    Cette directive possède exactement les mêmes arguments et produit - les mêmes effets que la directive CustomLog, à l'exception qu'elle - ne permet pas de spécifier un format de journal explicite ou la - journalisation conditionnelle des requêtes. En l'occurrence, le - format de journal est déterminé par la dernière définition d'une - directive LogFormat - qui ne définit pas d'alias. Si aucun format particulier n'a été - spécifié, c'est le Common Log Format qui sera utilisé.

    - -

    Exemple

    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
-TransferLog logs/access_log
    -
    -
    diff --git a/docs/manual/mod/mod_log_config.html.ja.utf8 b/docs/manual/mod/mod_log_config.html.ja.utf8 index 1da183293f9..952334ba762 100644 --- a/docs/manual/mod/mod_log_config.html.ja.utf8 +++ b/docs/manual/mod/mod_log_config.html.ja.utf8 @@ -72,6 +72,185 @@
  • Apache ログファイル
    • top
    +

    BufferedLogs ディレクティブ

    + + + + + + + + +
    説明:ディスクに書き出す前にメモリにログエントリをバッファする
    構文:BufferedLogs On|Off
    デフォルト:BufferedLogs Off
    コンテキスト:サーバ設定ファイル
    ステータス:Base
    モジュール:mod_log_config
    互換性:2.0.41 以降
    +

    BufferedLogs ディレクティブを使うと + mod_log_config の挙動が変化して、 + 複数のログを書き出す際に、それぞれのリクエスト処理後毎に + 書き出すのではなく、いったんメモリに蓄えてから、 + まとめてディスクに書き出すようになります。 + この結果ディスクアクセスがより効率的になり、 + 高いパフォーマンスの得られるシステムもあるでしょう。 + このディレクティブはサーバ全体で一度だけ設定できます; + バーチャルホストごとに設定することはできません。

    + +
    このディレクティブは実験的なものですので、 + 使用する際は注意してください。
    + +
    +
    top
    +

    CustomLog ディレクティブ

    + + + + + + +
    説明:ログファイルの名前と書式を設定する
    構文:CustomLog file|pipe +format|nickname +[env=[!]environment-variable]
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Base
    モジュール:mod_log_config
    +

    CustomLog ディレクティブはサーバへのリクエストを + ログ収集するために使われます。ログの書式が指定され、 + 環境変数を使ってロギングが条件に応じて行なわれるようにすることもできます。

    + +

    ログが書かれる場所を指定する最初の引数は以下の二つの形式の値を + とることができます:

    + +
    +
    file
    +
    ServerRoot + からの相対パスで表されるファイル名。
    + +
    pipe
    +
    パイプ文字 "|" と、その後に標準入力からログの + 情報を受けとるプログラムへのパスが続いたもの。 + +

    セキュリティ

    +

    もしプログラムが使用された場合、 + httpd が起動されたユーザとして実行されます。これはサーバが + root によって起動された場合は root になります。プログラムが + 安全であるように留意してください。

    +
    +

    注

    +

    Unix でないプラットフォームでファイルのパスを入力しているときは、 + 使用しているプラットフォームがバックスラッシュの使用を許可していた + として、通常のスラッシュだけを使うように気をつけてください。 + 一般的に、設定ファイル中では常に普通のスラッシュのみを使うようにする + 方が良いです。

    +
    +
    + +

    二つめの引数はログファイルに何が書かれるかを指定します。 + 前にある LogFormat ディレクティブにより + 定義された nickname か、ログの書式 + のところで説明されている、明示的な format 文字列の + どちらかを指定することができます。

    + +

    例えば、以下の二つのディレクティブ群は全く同じ効果をもたらします:

    + +

    + # CustomLog with format nickname
    + LogFormat "%h %l %u %t \"%r\" %>s %b" common
    + CustomLog logs/access_log common
    +
    + # CustomLog with explicit format string
    + CustomLog logs/access_log "%h %l %u %t \"%r\" %>s %b" +

    + +

    三つ目の引数は省略可能で、サーバの環境にある変数があるかないかに + 応じてリクエストをログ収集するかどうかを制御するために使うことができます。 + 指定された環境変数がリクエストに対して + 設定されていた場合 ('env=!name' 文が使われたときは + 設定されていない場合)、リクエストがログ収集されます。

    + +

    環境変数は mod_setenvif モジュールと + mod_rewrite モジュールの両方もしくは + 片方を用いてリクエストごとに設定することができます。 + 例えば、サーバにあるすべての GIF 画像へのリクエストを別のログファイル + には記録したいけれど、メインログには記録したくない、というときは + 以下のものを使うことができます:

    + +

    + SetEnvIf Request_URI \.gif$ gif-image
    + CustomLog gif-requests.log common env=gif-image
    + CustomLog nongif-requests.log common env=!gif-image +

    + +

    古い RefererIgnore ディレクティブと同じ挙動をさせたい場合は、 + 次のようにします:

    + +

    + SetEnvIf Referer example\.com localreferer
    + CustomLog referer.log referer env=!localreferer +

    + +
    +
    top
    +

    LogFormat ディレクティブ

    + + + + + + + +
    説明:ログファイルで使用する書式を設定する
    構文:LogFormat format|nickname +[nickname]
    デフォルト:LogFormat "%h %l %u %t \"%r\" %>s %b"
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Base
    モジュール:mod_log_config
    +

    このディレクティブはアクセスログファイルの書式を指定します。

    + +

    LogFormat ディレクティブは二つの形式のどちらかを + とることができます。最初の形式では一つの引数のみが指定され、 + 続く TransferLog + で指定されたログで使われるログの書式を設定します。この単独の引数では + 上のカスタムログ書式で説明されているように + format を明示的に指定することができます。 + もしくは、下で説明されているように前に LogFormat + ディレクティブで定義されたログの書式を nicknameを使って + 参照することもできます。

    + +

    LogFormat ディレクティブの二つめの形式は + format に nickname を与えます。 + フォーマット文字列全体を再び書くかわりに、 + この nickname を続きの LogFormat ディレクティブや + CustomLog ディレクティブで使うことができます。 + Nickname を定義する LogFormat ディレクティブは + 他には何もしません -- すなわち、ニックネームを定義 + するだけで、実際に書式を適用してデフォルトにするということは行ないません。 + ですから、これは続く TransferLog + ディレクティブには影響を与えません。 + さらに、LogFormat ディレクティブは既存の nickname を + 使って別の nickname を定義することはできません。Nickname には + パーセント記号 (%) が含まれていてはいけないことにも注意 + してください。

    + +

    例

    + LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common +

    + +
    +
    top
    +

    TransferLog ディレクティブ

    + + + + + + +
    説明:ログファイルの位置を指定
    構文:TransferLog file|pipe
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Base
    モジュール:mod_log_config
    +

    このディレクティブは、ログ書式を直接指定できないことと、 + 条件付きロギングが無いことを除くと、CustomLog と全く同じ引数と効果があります。 + 直接ログ書式を指定する代わりに、ログの書式はそこまでで一番最後に指定された + ニックネームを定義しない + LogFormat ディレクティブ + で定義されたものを使います。 + もし他の書式が全く指定されていないときは Common Log Format + が使われます。

    + +

    例

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

    + +
    +
    top

    カスタムログ書式

    @@ -279,185 +458,6 @@ 書き込み可能なときにセキュリティの問題が発生する理由の詳細はセキュリティのこつ を参照してください。

    -
    top
    -

    BufferedLogs ディレクティブ

    - - - - - - - - -
    説明:ディスクに書き出す前にメモリにログエントリをバッファする
    構文:BufferedLogs On|Off
    デフォルト:BufferedLogs Off
    コンテキスト:サーバ設定ファイル
    ステータス:Base
    モジュール:mod_log_config
    互換性:2.0.41 以降
    -

    BufferedLogs ディレクティブを使うと - mod_log_config の挙動が変化して、 - 複数のログを書き出す際に、それぞれのリクエスト処理後毎に - 書き出すのではなく、いったんメモリに蓄えてから、 - まとめてディスクに書き出すようになります。 - この結果ディスクアクセスがより効率的になり、 - 高いパフォーマンスの得られるシステムもあるでしょう。 - このディレクティブはサーバ全体で一度だけ設定できます; - バーチャルホストごとに設定することはできません。

    - -
    このディレクティブは実験的なものですので、 - 使用する際は注意してください。
    - -
    -
    top
    -

    CustomLog ディレクティブ

    - - - - - - -
    説明:ログファイルの名前と書式を設定する
    構文:CustomLog file|pipe -format|nickname -[env=[!]environment-variable]
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Base
    モジュール:mod_log_config
    -

    CustomLog ディレクティブはサーバへのリクエストを - ログ収集するために使われます。ログの書式が指定され、 - 環境変数を使ってロギングが条件に応じて行なわれるようにすることもできます。

    - -

    ログが書かれる場所を指定する最初の引数は以下の二つの形式の値を - とることができます:

    - -
    -
    file
    -
    ServerRoot - からの相対パスで表されるファイル名。
    - -
    pipe
    -
    パイプ文字 "|" と、その後に標準入力からログの - 情報を受けとるプログラムへのパスが続いたもの。 - -

    セキュリティ

    -

    もしプログラムが使用された場合、 - httpd が起動されたユーザとして実行されます。これはサーバが - root によって起動された場合は root になります。プログラムが - 安全であるように留意してください。

    -
    -

    注

    -

    Unix でないプラットフォームでファイルのパスを入力しているときは、 - 使用しているプラットフォームがバックスラッシュの使用を許可していた - として、通常のスラッシュだけを使うように気をつけてください。 - 一般的に、設定ファイル中では常に普通のスラッシュのみを使うようにする - 方が良いです。

    -
    -
    - -

    二つめの引数はログファイルに何が書かれるかを指定します。 - 前にある LogFormat ディレクティブにより - 定義された nickname か、ログの書式 - のところで説明されている、明示的な format 文字列の - どちらかを指定することができます。

    - -

    例えば、以下の二つのディレクティブ群は全く同じ効果をもたらします:

    - -

    - # CustomLog with format nickname
    - LogFormat "%h %l %u %t \"%r\" %>s %b" common
    - CustomLog logs/access_log common
    -
    - # CustomLog with explicit format string
    - CustomLog logs/access_log "%h %l %u %t \"%r\" %>s %b" -

    - -

    三つ目の引数は省略可能で、サーバの環境にある変数があるかないかに - 応じてリクエストをログ収集するかどうかを制御するために使うことができます。 - 指定された環境変数がリクエストに対して - 設定されていた場合 ('env=!name' 文が使われたときは - 設定されていない場合)、リクエストがログ収集されます。

    - -

    環境変数は mod_setenvif モジュールと - mod_rewrite モジュールの両方もしくは - 片方を用いてリクエストごとに設定することができます。 - 例えば、サーバにあるすべての GIF 画像へのリクエストを別のログファイル - には記録したいけれど、メインログには記録したくない、というときは - 以下のものを使うことができます:

    - -

    - SetEnvIf Request_URI \.gif$ gif-image
    - CustomLog gif-requests.log common env=gif-image
    - CustomLog nongif-requests.log common env=!gif-image -

    - -

    古い RefererIgnore ディレクティブと同じ挙動をさせたい場合は、 - 次のようにします:

    - -

    - SetEnvIf Referer example\.com localreferer
    - CustomLog referer.log referer env=!localreferer -

    - -
    -
    top
    -

    LogFormat ディレクティブ

    - - - - - - - -
    説明:ログファイルで使用する書式を設定する
    構文:LogFormat format|nickname -[nickname]
    デフォルト:LogFormat "%h %l %u %t \"%r\" %>s %b"
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Base
    モジュール:mod_log_config
    -

    このディレクティブはアクセスログファイルの書式を指定します。

    - -

    LogFormat ディレクティブは二つの形式のどちらかを - とることができます。最初の形式では一つの引数のみが指定され、 - 続く TransferLog - で指定されたログで使われるログの書式を設定します。この単独の引数では - 上のカスタムログ書式で説明されているように - format を明示的に指定することができます。 - もしくは、下で説明されているように前に LogFormat - ディレクティブで定義されたログの書式を nicknameを使って - 参照することもできます。

    - -

    LogFormat ディレクティブの二つめの形式は - format に nickname を与えます。 - フォーマット文字列全体を再び書くかわりに、 - この nickname を続きの LogFormat ディレクティブや - CustomLog ディレクティブで使うことができます。 - Nickname を定義する LogFormat ディレクティブは - 他には何もしません -- すなわち、ニックネームを定義 - するだけで、実際に書式を適用してデフォルトにするということは行ないません。 - ですから、これは続く TransferLog - ディレクティブには影響を与えません。 - さらに、LogFormat ディレクティブは既存の nickname を - 使って別の nickname を定義することはできません。Nickname には - パーセント記号 (%) が含まれていてはいけないことにも注意 - してください。

    - -

    例

    - LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common -

    - -
    -
    top
    -

    TransferLog ディレクティブ

    - - - - - - -
    説明:ログファイルの位置を指定
    構文:TransferLog file|pipe
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Base
    モジュール:mod_log_config
    -

    このディレクティブは、ログ書式を直接指定できないことと、 - 条件付きロギングが無いことを除くと、CustomLog と全く同じ引数と効果があります。 - 直接ログ書式を指定する代わりに、ログの書式はそこまでで一番最後に指定された - ニックネームを定義しない - LogFormat ディレクティブ - で定義されたものを使います。 - もし他の書式が全く指定されていないときは Common Log Format - が使われます。

    - -

    例

    - LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
    - TransferLog logs/access_log -

    - -

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_log_config.html.ko.euc-kr b/docs/manual/mod/mod_log_config.html.ko.euc-kr index 18ba763fa10..3c117c64e98 100644 --- a/docs/manual/mod/mod_log_config.html.ko.euc-kr +++ b/docs/manual/mod/mod_log_config.html.ko.euc-kr @@ -66,6 +66,153 @@

  • ¾ÆÆÄÄ¡ ·Î±×ÆÄÀÏ
    • top
    +

    BufferedLogs Áö½Ã¾î

    + + + + + + +
    ¼³¸í:Buffer log entries in memory before writing to disk
    ¹®¹ý:
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤
    »óÅÂ:Base
    ¸ðµâ:mod_log_config

    Documentation not yet translated. Please see English version of document.

    +
    +
    top
    +

    CustomLog Áö½Ã¾î

    + + + + + + +
    ¼³¸í:·Î±×ÆÄÀÏ À̸§°ú Çü½ÄÀ» ÁöÁ¤ÇÑ´Ù
    ¹®¹ý:CustomLog file|pipe +format|nickname +[env=[!]environment-variable]
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Base
    ¸ðµâ:mod_log_config
    +

    ¼­¹ö°¡ ¿äûÀ» ·Î±×¿¡ ³²±æ¶§ CustomLog + Áö½Ã¾î¸¦ »ç¿ëÇÑ´Ù. ·Î±× Çü½ÄÀ» ÁöÁ¤ÇÏ°í, ȯ°æº¯¼ö¸¦ »ç¿ëÇÏ¿© + ¿äûÀÇ Æ¯Â¡¿¡ µû¶ó ¼±ÅÃÀûÀ¸·Î ·Î±×¸¦ ³²±æ ¼öµµ ÀÖ´Ù.

    + +

    ·Î±×¸¦ ±â·ÏÇÒ Àå¼Ò¸¦ ÁöÁ¤Çϴ ù¹ø° ¾Æ±Ô¸ÕÆ®¿¡´Â ´ÙÀ½ + µÑÁß Çϳª¸¦ »ç¿ëÇÑ´Ù.

    + +
    +
    file
    +
    ServerRoot¿¡ + »ó´ëÀûÀÎ ÆÄÀϸí.
    + +
    pipe
    +
    ÆÄÀÌÇÁ¹®ÀÚ "|"µÚ¿¡ ·Î±× Á¤º¸¸¦ Ç¥ÁØÀÔ·ÂÀ¸·Î + ¹ÞÀ» ÇÁ·Î±×·¥ °æ·Î¸¦ Àû´Â´Ù. + +

    º¸¾È:

    +

    ÇÁ·Î±×·¥À» »ç¿ëÇÑ´Ù¸é ÇÁ·Î±×·¥Àº À¥¼­¹ö¸¦ ½ÃÀÛÇÑ »ç¿ëÀÚ + ±ÇÇÑÀ¸·Î ½ÇÇàµÈ´Ù. ¼­¹ö¸¦ root·Î ½ÃÀÛÇÑ´Ù¸é ÇÁ·Î±×·¥µµ + root·Î ½ÇÇàÇϹǷΠÇÁ·Î±×·¥ÀÌ ¾ÈÀüÇÑÁö È®ÀÎÇ϶ó.

    +
    +

    ÁÖÀÇ

    +

    À¯´Ð½º°¡ ¾Æ´Ñ Ç÷¡Æû¿¡¼­ ÆÄÀÏ°æ·Î¸¦ ÀÔ·ÂÇÒ¶§ Ç÷¡ÆûÀÌ + ¹é½½·¡½¬¸¦ »ç¿ëÇÏ´õ¶óµµ ¹Ýµå½Ã ½½·¡½¬¸¦ »ç¿ëÇØ¾ß ÇÑ´Ù. + ÀϹÝÀûÀ¸·Î ¼³Á¤ÆÄÀÏ¿¡¼­´Â Ç×»ó ½½·¡½¬¸¦ »ç¿ëÇÏ´Â °ÍÀÌ + ÁÁ´Ù.

    +
    +
    + +

    µÎ¹ø° ¾Æ±Ô¸ÕÆ®´Â ·Î±×ÆÄÀÏ¿¡ ±â·ÏÇÒ ³»¿ëÀ» ÁöÁ¤ÇÑ´Ù. + Àü¿¡ LogFormatÀ¸·Î + Á¤ÀÇÇÑ nicknameÀ» »ç¿ëÇϰųª Á÷Á¢ ·Î±× Çü½Ä Àý¿¡¼­ ¼³¸íÇÑ format + ¹®ÀÚ¿­À» »ç¿ëÇÒ ¼ö ÀÖ´Ù.

    + +

    ¿¹¸¦ µé¾î, ´ÙÀ½ µÎ Áö½Ã¾î´Â ¶È°°Àº ÀÏÀ» ÇÑ´Ù.

    + +

    + # Çü½Ä º°ÄªÀ» »ç¿ëÇÑ CustomLog
    + LogFormat "%h %l %u %t \"%r\" %>s %b" common
    + CustomLog logs/access_log common
    +
    + # Á÷Á¢ Çü½Ä ¹®ÀÚ¿­À» »ç¿ëÇÑ CustomLog
    + CustomLog logs/access_log "%h %l %u %t \"%r\" %>s %b" +

    + +

    ¼¼¹ø° ¾Æ±Ô¸ÕÆ®´Â ¾ø¾îµµ µÇ¸ç, ƯÁ¤ ¼­¹ö ȯ°æº¯¼ö À¯¹«¿¡ + µû¶ó ¿äûÀ» ·Î±×¿¡ ±â·ÏÇÒÁö ¿©ºÎ¸¦ °áÁ¤ÇÑ´Ù. ¿äû¿¡ ÁöÁ¤ÇÑ + ȯ°æº¯¼ö°¡ Á¤ÀǵÇÀÖ´Ù¸é (ȤÀº + 'env=!name'¸¦ »ç¿ëÇÑ °æ¿ì ¾ø´Ù¸é) + ¿äûÀ» ·Î±×¿¡ ±â·ÏÇÑ´Ù.

    + +

    mod_setenvif³ª mod_rewrite + ¸ðµâÀ» »ç¿ëÇÏ¿© ¿äûº°·Î ȯ°æº¯¼ö¸¦ ¼³Á¤ÇÒ ¼ö ÀÖ´Ù. ¿¹¸¦ + µé¾î, ¼­¹ö°¡ GIF ±×¸²¿¡ ´ëÇÑ ¸ðµç ¿äûÀ» ÁÖ¼­¹ö ·Î±×°¡ ¾Æ´Ñ + ´Ù¸¥ ·Î±×ÆÄÀÏ¿¡ ±â·ÏÇÏ·Á¸é,

    + +

    + SetEnvIf Request_URI \.gif$ gif-image
    + CustomLog gif-requests.log common env=gif-image
    + CustomLog nongif-requests.log common env=!gif-image +

    + +
    +
    top
    +

    LogFormat Áö½Ã¾î

    + + + + + + + +
    ¼³¸í:·Î±×ÆÄÀÏ¿¡ »ç¿ëÇÒ Çü½ÄÀ» ±â¼úÇÑ´Ù
    ¹®¹ý:LogFormat format|nickname +[nickname]
    ±âº»°ª:LogFormat "%h %l %u %t \"%r\" %>s %b"
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Base
    ¸ðµâ:mod_log_config
    +

    ÀÌ Áö½Ã¾î´Â Á¢±Ù ·Î±×ÆÄÀÏÀÇ Çü½ÄÀ» ÁöÁ¤ÇÑ´Ù.

    + +

    LogFormat Áö½Ã¾î´Â µÎ°¡Áö Çü½ÄÀ¸·Î + »ç¿ëÇÑ´Ù. ù¹ø° Çü½ÄÀº ¾Æ±Ô¸ÕÆ®¸¦ ÇÑ°³¸¸ »ç¿ëÇÏ¿© ´ÙÀ½ + TransferLog Áö½Ã¾îµéÀÌ »ç¿ëÇÒ ·Î±× + Çü½ÄÀ» ÁöÁ¤ÇÑ´Ù. ÀÌ ¾Æ±Ô¸ÕÆ®¿¡ À§ÀÇ ·Î±× + Çü½Ä ÁöÁ¤Çϱâ Àý¿¡¼­ ¼³¸íÇÑ formatÀ» Á÷Á¢ + »ç¿ëÇϰųª, ´ÙÀ½¿¡ ¼³¸íÇÒ LogFormat + Áö½Ã¾î·Î ¹Ì¸® Á¤ÀÇÇÑ (·Î±× Çü½ÄÀ» ÁöĪÇÏ´Â) nicknameÀ» + »ç¿ëÇÒ ¼ö ÀÖ´Ù.

    + +

    LogFormat Áö½Ã¾îÀÇ µÎ¹ø° Çü½ÄÀº + format°ú nicknameÀ» ¿¬°áÇÑ´Ù. ±×·¯¸é + µÚ¿¡¼­ »ç¿ëÇÏ´Â LogFormatÀ̳ª CustomLog Áö½Ã¾î¿¡ ¹Ýº¹Çؼ­ + Çü½Ä ¹®ÀÚ¿­À» ¸ðµÎ ÀÔ·ÂÇÏ´Â ´ë½Å nicknameÀ» »ç¿ëÇÒ + ¼ö ÀÖ´Ù. º°ÄªÀ» Á¤ÀÇÇÏ´Â LogFormat + Áö½Ã¾î´Â ÀÌ ¿Ü¿¡´Â ¾Æ¹« ±â´ÉÀ» ÇÏÁö ¾Ê´Â´Ù. + Áï, º°Äª¸¸À» Á¤ÀÇÇϸç, ½ÇÁ¦·Î Çü½ÄÀ» Àû¿ëÇϰųª + Çü½ÄÀ» ±âº»°ªÀ¸·Î ¸¸µéÁö ¾Ê´Â´Ù. ±×·¯¹Ç·Î ´ÙÀ½¿¡ ³ª¿À´Â + TransferLog + Áö½Ã¾î¿¡ ¿µÇâÀ» ÁÖÁö ¾Ê´Â´Ù. ¶Ç, + LogFormatÀº º°ÄªÀ¸·Î ´Ù¸¥ º°ÄªÀ» + Á¤ÀÇÇÒ ¼ö ÀÖ´Ù. º°Äª À̸§¿¡´Â ÆÛ¼¾Æ® ±âÈ£(%)¸¦ + »ç¿ëÇÒ ¼ö ¾øÀ½À» ÁÖÀÇÇ϶ó.

    + +

    ¿¹Á¦

    + LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common +

    + +
    +
    top
    +

    TransferLog Áö½Ã¾î

    + + + + + + +
    ¼³¸í:·Î±×ÆÄÀÏ À§Ä¡¸¦ ¼³Á¤ÇÑ´Ù
    ¹®¹ý:TransferLog file|pipe
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Base
    ¸ðµâ:mod_log_config
    +

    ÀÌ Áö½Ã¾î´Â CustomLog Áö½Ã¾î¿Í ¾Æ±Ô¸ÕÆ®¿Í + ±â´ÉÀÌ ºñ½ÁÇÏÁö¸¸, ·Î±× Çü½ÄÀ» Á÷Á¢ ÁöÁ¤Çϰųª ¿äûÀ» Á¶°Ç¿¡ + µû¶ó ·Î±×¿¡ ³²±æ ¼ö ¾ø´Ù. ´ë½Å °¡Àå ÃÖ±Ù »ç¿ëÇÑ (º°ÄªÀ» + Á¤ÀÇÇÏÁö ¾ÊÀº) LogFormat Áö½Ã¾î°¡ ÁöÁ¤ÇÑ + ·Î±× Çü½ÄÀ» »ç¿ëÇÑ´Ù. ¹Ì¸® Çü½ÄÀ» ÁöÁ¤ÇÏÁö ¾Ê¾Ò´Ù¸é Common + Log FormatÀ» »ç¿ëÇÑ´Ù.

    + +

    ¿¹Á¦

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

    + +
    +
    top

    ·Î±× Çü½Ä ÁöÁ¤Çϱâ

    @@ -242,153 +389,6 @@ º¸¾È ÆÁ ¹®¼­¸¦ Âü°íÇ϶ó.

    -
    top
    -

    BufferedLogs Áö½Ã¾î

    - - - - - - -
    ¼³¸í:Buffer log entries in memory before writing to disk
    ¹®¹ý:
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤
    »óÅÂ:Base
    ¸ðµâ:mod_log_config

    Documentation not yet translated. Please see English version of document.

    -
    -
    top
    -

    CustomLog Áö½Ã¾î

    - - - - - - -
    ¼³¸í:·Î±×ÆÄÀÏ À̸§°ú Çü½ÄÀ» ÁöÁ¤ÇÑ´Ù
    ¹®¹ý:CustomLog file|pipe -format|nickname -[env=[!]environment-variable]
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Base
    ¸ðµâ:mod_log_config
    -

    ¼­¹ö°¡ ¿äûÀ» ·Î±×¿¡ ³²±æ¶§ CustomLog - Áö½Ã¾î¸¦ »ç¿ëÇÑ´Ù. ·Î±× Çü½ÄÀ» ÁöÁ¤ÇÏ°í, ȯ°æº¯¼ö¸¦ »ç¿ëÇÏ¿© - ¿äûÀÇ Æ¯Â¡¿¡ µû¶ó ¼±ÅÃÀûÀ¸·Î ·Î±×¸¦ ³²±æ ¼öµµ ÀÖ´Ù.

    - -

    ·Î±×¸¦ ±â·ÏÇÒ Àå¼Ò¸¦ ÁöÁ¤Çϴ ù¹ø° ¾Æ±Ô¸ÕÆ®¿¡´Â ´ÙÀ½ - µÑÁß Çϳª¸¦ »ç¿ëÇÑ´Ù.

    - -
    -
    file
    -
    ServerRoot¿¡ - »ó´ëÀûÀÎ ÆÄÀϸí.
    - -
    pipe
    -
    ÆÄÀÌÇÁ¹®ÀÚ "|"µÚ¿¡ ·Î±× Á¤º¸¸¦ Ç¥ÁØÀÔ·ÂÀ¸·Î - ¹ÞÀ» ÇÁ·Î±×·¥ °æ·Î¸¦ Àû´Â´Ù. - -

    º¸¾È:

    -

    ÇÁ·Î±×·¥À» »ç¿ëÇÑ´Ù¸é ÇÁ·Î±×·¥Àº À¥¼­¹ö¸¦ ½ÃÀÛÇÑ »ç¿ëÀÚ - ±ÇÇÑÀ¸·Î ½ÇÇàµÈ´Ù. ¼­¹ö¸¦ root·Î ½ÃÀÛÇÑ´Ù¸é ÇÁ·Î±×·¥µµ - root·Î ½ÇÇàÇϹǷΠÇÁ·Î±×·¥ÀÌ ¾ÈÀüÇÑÁö È®ÀÎÇ϶ó.

    -
    -

    ÁÖÀÇ

    -

    À¯´Ð½º°¡ ¾Æ´Ñ Ç÷¡Æû¿¡¼­ ÆÄÀÏ°æ·Î¸¦ ÀÔ·ÂÇÒ¶§ Ç÷¡ÆûÀÌ - ¹é½½·¡½¬¸¦ »ç¿ëÇÏ´õ¶óµµ ¹Ýµå½Ã ½½·¡½¬¸¦ »ç¿ëÇØ¾ß ÇÑ´Ù. - ÀϹÝÀûÀ¸·Î ¼³Á¤ÆÄÀÏ¿¡¼­´Â Ç×»ó ½½·¡½¬¸¦ »ç¿ëÇÏ´Â °ÍÀÌ - ÁÁ´Ù.

    -
    -
    - -

    µÎ¹ø° ¾Æ±Ô¸ÕÆ®´Â ·Î±×ÆÄÀÏ¿¡ ±â·ÏÇÒ ³»¿ëÀ» ÁöÁ¤ÇÑ´Ù. - Àü¿¡ LogFormatÀ¸·Î - Á¤ÀÇÇÑ nicknameÀ» »ç¿ëÇϰųª Á÷Á¢ ·Î±× Çü½Ä Àý¿¡¼­ ¼³¸íÇÑ format - ¹®ÀÚ¿­À» »ç¿ëÇÒ ¼ö ÀÖ´Ù.

    - -

    ¿¹¸¦ µé¾î, ´ÙÀ½ µÎ Áö½Ã¾î´Â ¶È°°Àº ÀÏÀ» ÇÑ´Ù.

    - -

    - # Çü½Ä º°ÄªÀ» »ç¿ëÇÑ CustomLog
    - LogFormat "%h %l %u %t \"%r\" %>s %b" common
    - CustomLog logs/access_log common
    -
    - # Á÷Á¢ Çü½Ä ¹®ÀÚ¿­À» »ç¿ëÇÑ CustomLog
    - CustomLog logs/access_log "%h %l %u %t \"%r\" %>s %b" -

    - -

    ¼¼¹ø° ¾Æ±Ô¸ÕÆ®´Â ¾ø¾îµµ µÇ¸ç, ƯÁ¤ ¼­¹ö ȯ°æº¯¼ö À¯¹«¿¡ - µû¶ó ¿äûÀ» ·Î±×¿¡ ±â·ÏÇÒÁö ¿©ºÎ¸¦ °áÁ¤ÇÑ´Ù. ¿äû¿¡ ÁöÁ¤ÇÑ - ȯ°æº¯¼ö°¡ Á¤ÀǵÇÀÖ´Ù¸é (ȤÀº - 'env=!name'¸¦ »ç¿ëÇÑ °æ¿ì ¾ø´Ù¸é) - ¿äûÀ» ·Î±×¿¡ ±â·ÏÇÑ´Ù.

    - -

    mod_setenvif³ª mod_rewrite - ¸ðµâÀ» »ç¿ëÇÏ¿© ¿äûº°·Î ȯ°æº¯¼ö¸¦ ¼³Á¤ÇÒ ¼ö ÀÖ´Ù. ¿¹¸¦ - µé¾î, ¼­¹ö°¡ GIF ±×¸²¿¡ ´ëÇÑ ¸ðµç ¿äûÀ» ÁÖ¼­¹ö ·Î±×°¡ ¾Æ´Ñ - ´Ù¸¥ ·Î±×ÆÄÀÏ¿¡ ±â·ÏÇÏ·Á¸é,

    - -

    - SetEnvIf Request_URI \.gif$ gif-image
    - CustomLog gif-requests.log common env=gif-image
    - CustomLog nongif-requests.log common env=!gif-image -

    - -
    -
    top
    -

    LogFormat Áö½Ã¾î

    - - - - - - - -
    ¼³¸í:·Î±×ÆÄÀÏ¿¡ »ç¿ëÇÒ Çü½ÄÀ» ±â¼úÇÑ´Ù
    ¹®¹ý:LogFormat format|nickname -[nickname]
    ±âº»°ª:LogFormat "%h %l %u %t \"%r\" %>s %b"
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Base
    ¸ðµâ:mod_log_config
    -

    ÀÌ Áö½Ã¾î´Â Á¢±Ù ·Î±×ÆÄÀÏÀÇ Çü½ÄÀ» ÁöÁ¤ÇÑ´Ù.

    - -

    LogFormat Áö½Ã¾î´Â µÎ°¡Áö Çü½ÄÀ¸·Î - »ç¿ëÇÑ´Ù. ù¹ø° Çü½ÄÀº ¾Æ±Ô¸ÕÆ®¸¦ ÇÑ°³¸¸ »ç¿ëÇÏ¿© ´ÙÀ½ - TransferLog Áö½Ã¾îµéÀÌ »ç¿ëÇÒ ·Î±× - Çü½ÄÀ» ÁöÁ¤ÇÑ´Ù. ÀÌ ¾Æ±Ô¸ÕÆ®¿¡ À§ÀÇ ·Î±× - Çü½Ä ÁöÁ¤Çϱâ Àý¿¡¼­ ¼³¸íÇÑ formatÀ» Á÷Á¢ - »ç¿ëÇϰųª, ´ÙÀ½¿¡ ¼³¸íÇÒ LogFormat - Áö½Ã¾î·Î ¹Ì¸® Á¤ÀÇÇÑ (·Î±× Çü½ÄÀ» ÁöĪÇÏ´Â) nicknameÀ» - »ç¿ëÇÒ ¼ö ÀÖ´Ù.

    - -

    LogFormat Áö½Ã¾îÀÇ µÎ¹ø° Çü½ÄÀº - format°ú nicknameÀ» ¿¬°áÇÑ´Ù. ±×·¯¸é - µÚ¿¡¼­ »ç¿ëÇÏ´Â LogFormatÀ̳ª CustomLog Áö½Ã¾î¿¡ ¹Ýº¹Çؼ­ - Çü½Ä ¹®ÀÚ¿­À» ¸ðµÎ ÀÔ·ÂÇÏ´Â ´ë½Å nicknameÀ» »ç¿ëÇÒ - ¼ö ÀÖ´Ù. º°ÄªÀ» Á¤ÀÇÇÏ´Â LogFormat - Áö½Ã¾î´Â ÀÌ ¿Ü¿¡´Â ¾Æ¹« ±â´ÉÀ» ÇÏÁö ¾Ê´Â´Ù. - Áï, º°Äª¸¸À» Á¤ÀÇÇϸç, ½ÇÁ¦·Î Çü½ÄÀ» Àû¿ëÇϰųª - Çü½ÄÀ» ±âº»°ªÀ¸·Î ¸¸µéÁö ¾Ê´Â´Ù. ±×·¯¹Ç·Î ´ÙÀ½¿¡ ³ª¿À´Â - TransferLog - Áö½Ã¾î¿¡ ¿µÇâÀ» ÁÖÁö ¾Ê´Â´Ù. ¶Ç, - LogFormatÀº º°ÄªÀ¸·Î ´Ù¸¥ º°ÄªÀ» - Á¤ÀÇÇÒ ¼ö ÀÖ´Ù. º°Äª À̸§¿¡´Â ÆÛ¼¾Æ® ±âÈ£(%)¸¦ - »ç¿ëÇÒ ¼ö ¾øÀ½À» ÁÖÀÇÇ϶ó.

    - -

    ¿¹Á¦

    - LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common -

    - -
    -
    top
    -

    TransferLog Áö½Ã¾î

    - - - - - - -
    ¼³¸í:·Î±×ÆÄÀÏ À§Ä¡¸¦ ¼³Á¤ÇÑ´Ù
    ¹®¹ý:TransferLog file|pipe
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Base
    ¸ðµâ:mod_log_config
    -

    ÀÌ Áö½Ã¾î´Â CustomLog Áö½Ã¾î¿Í ¾Æ±Ô¸ÕÆ®¿Í - ±â´ÉÀÌ ºñ½ÁÇÏÁö¸¸, ·Î±× Çü½ÄÀ» Á÷Á¢ ÁöÁ¤Çϰųª ¿äûÀ» Á¶°Ç¿¡ - µû¶ó ·Î±×¿¡ ³²±æ ¼ö ¾ø´Ù. ´ë½Å °¡Àå ÃÖ±Ù »ç¿ëÇÑ (º°ÄªÀ» - Á¤ÀÇÇÏÁö ¾ÊÀº) LogFormat Áö½Ã¾î°¡ ÁöÁ¤ÇÑ - ·Î±× Çü½ÄÀ» »ç¿ëÇÑ´Ù. ¹Ì¸® Çü½ÄÀ» ÁöÁ¤ÇÏÁö ¾Ê¾Ò´Ù¸é Common - Log FormatÀ» »ç¿ëÇÑ´Ù.

    - -

    ¿¹Á¦

    - LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
    - TransferLog logs/access_log -

    - -

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_log_config.html.tr.utf8 b/docs/manual/mod/mod_log_config.html.tr.utf8 index cd8ec9a3191..1c77b2efd56 100644 --- a/docs/manual/mod/mod_log_config.html.tr.utf8 +++ b/docs/manual/mod/mod_log_config.html.tr.utf8 @@ -68,6 +68,176 @@

  • Apache Günlük Dosyaları
    • top
    +

    BufferedLogs Yönergesi

    + + + + + + + + +
    Açıklama:Günlük girdilerini diske yazmadan önce bellekte tamponlar +
    Sözdizimi:BufferedLogs On|Off
    Öntanımlı:BufferedLogs Off
    Bağlam:sunucu geneli
    Durum:Temel
    Modül:mod_log_config
    Uyumluluk:2.0.41 ve sonrasında mevcuttur.
    +

    BufferedLogs yönergesi, + mod_log_config modülünün çeşitli günlük girdilerini her + isteğin hemen ardından tek tek değil, bir bütün halinde diske yazılmak + üzere bellekte saklanmasını sağlar. Bu, bazı sistemlerde daha verimli + disk erişimi, dolayısıyla daha yüksek başarım sağlayabilir. Sadece + sunucu geneli için belirtilebilir, sanal konaklar için ayrı ayrı + yapılandırılamaz.

    + +
    Bir çökme günlük verisi kaybına sebep olacağından bu yönerge + dikkatli kullanılmalıdır.
    + +
    +
    top
    +

    CustomLog Yönergesi

    + + + + + + +
    Açıklama:Günlük dosyasın ismini ve girdi biçemini belirler.
    Sözdizimi:CustomLog dosya|borulu-süreç +biçem|takma-ad +[env=[!]ortam-değişkeni]| +expr=ifade]
    Bağlam:sunucu geneli, sanal konak
    Durum:Temel
    Modül:mod_log_config
    +

    CustomLog yönergesi istekleri günlüğe kaydetmek + için kullanılır. Yönerge ile bir günlük biçemi belirtilebilir ve günlük + kaydı isteğin özelliklerine bağlı olarak ortam değişkenleri vasıtasıyla + şarta bağlı kılınabilir.

    + +

    İlk argümanda günlüğün yazılacağı yer belirtilir. İki tür yer + belirtilebilir:

    + +
    +
    dosya
    +
    ServerRoot yönergesinin + değerine göreli bir dosya ismi.
    + +
    borulu-süreç
    +
    "|" boru karakteri ile öncelenmiş olarak günlük + bilgisini standart girdisinden kabul edecek sürecin ismi (veya komut + satırı) Daha fazla bilgi için borulu + günlüklere bakınız. + +

    Güvenlik:

    +

    Bir borulu süreç kullanılmışsa, süreç httpd’yi + başlatan kullanıcı tarafından başlatılacaktır. Sunucu root tarafından + başlatılıyorsa bu root olacaktır; bu bakımdan günlük kaydını alacak + programın güvenilir olması önemlidir.

    +
    +

    Bilginize

    +

    Dosya yolunu belirtirken tersbölü çizgisi kullanılan Unix dışı + platformlarda bile yapılandırma dosyasında bu amaçla normal bölü + çizgilerini kullanmaya özen gösterilmelidir.

    +
    +
    + +

    İkinci argümanda günlüğe ne yazılacağı belirtilir. Ya evvelce + LogFormat yönergesi ile + tanımlanmış bir takma-ad ya da içeriği Günlük Girdilerinin Kişiselleştirilmesi bölümünde + açıklanmış bir biçem dizgesi olabilir.

    + +

    Örneğin, aşağıdaki iki yönerge kümesi aynı etkiye sahiptir:

    + + 
    # Biçem dizgesi yerine takma ad içeren CustomLog
+LogFormat "%h %l %u %t \"%r\" %>s %b" common
+CustomLog logs/access_log common
+
+# Biçem dizgesinin kendisini içeren CustomLog
+CustomLog logs/access_log "%h %l %u %t \"%r\" %>s %b"
    + + +

    Üçüncü argüman isteğe bağlı olup,belli bir isteğin günlüğe kaydedilip + kaydedilmeyeceğini belirler. Koşul, sunucu ortamında belli bir değişkenin varlığı veya + yokluğu olabilir (bir 'env=!isim' durumu). + İstenirse koşul keyfi bir mantıksal ifade + olarak da belirtilebilir. Eğer koşul sağlanmazsa istek günlüğe + kaydedilmez. İfadede bulunan HTTP başlıklarına başvurular bu başlık + isimlerinin Vary başlığına eklenmesine sebep olmaz.

    + +

    Ortam değişkenleri mod_setenvif + ve/veya mod_rewrite modülleri kullanılarak her istek + için ayrı ayrı atanabilir. Örneğin, GIF biçemli resimler için yapılan + istekleri ana günlük dosyasına değil de başka bir dosyaya kaydetmek + isterseniz:

    + + 
    SetEnvIf Request_URI \.gif$ gif-image
+CustomLog gif-requests.log common env=gif-image
+CustomLog nongif-requests.log common env=!gif-image
    + + +

    Veya eski RefererIgnore yönergesinin davranışını taklit + etmek isterseniz:

    + + 
    SetEnvIf Referer example\.com localreferer
+CustomLog referer.log referer env=!localreferer
    + + +
    +
    top
    +

    LogFormat Yönergesi

    + + + + + + + +
    Açıklama:Bir günlük dosyasında kullanılmak üzere girdi biçemi tanımlar. +
    Sözdizimi:LogFormat biçem|takma-ad +[takma-ad]
    Öntanımlı:LogFormat "%h %l %u %t \"%r\" %>s %b"
    Bağlam:sunucu geneli, sanal konak
    Durum:Temel
    Modül:mod_log_config
    +

    Bu yönerge erişim günlüğü dosyasının girdi biçemini belirler.

    + +

    LogFormat yönergesi iki şekilde kullanılabilir. + Tek argüman belirtilebilen ilkinde daha sonra + TransferLog yönergelerinde belirtilen günlüklerde + kullanılmak üzere günlük biçemini belirler. Bu günlük biçemi yukarıda + açıklanan biçem belirteçlerinden + oluşur. Bu tek argüman yerine aşağıda açıklandığı gibi önceki bir + LogFormat yönergesinde tanımlanmış bir günlük + biçemine atıf yapan bir takma-ad da belirtilebilir.

    + +

    LogFormat yönergesinin ikinci kullanım şeklinde + biçem bir takma-ad için tanımlanır. Bu takma ad + daha sonraki LogFormat veya CustomLog yönergelerinde aynı biçem + dizgesini uzun uzadıya yazmamak için takma-ad olarak + kullanılır. Bir LogFormat yönergesi bir takma ad + tanımlamaktan başka bir şey yapmaz; yani, yaptığı iş + sadece bir takma ad tanımlamaktan ibarettir, biçemi uygulamaz veya + biçemi öntanımlı hale getirmez. Bu bakımdan sonraki TransferLog yönergelerini de + etkilemeyecektir. Ayrıca, LogFormat yönergesi bir + takma ada başka bir takma ad tanımlamakta da kullanılamaz. Bir takma + adın yüzde imi (%) içeremeyeceğine de dikkat ediniz.

    + + 
    LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common
    + + +
    +
    top
    +

    TransferLog Yönergesi

    + + + + + + +
    Açıklama:Bir günlük dosyasının yerini belirtir.
    Sözdizimi:TransferLog dosya|borulu-süreç +[takma-ad]
    Bağlam:sunucu geneli, sanal konak
    Durum:Temel
    Modül:mod_log_config
    +

    Bir günlük biçemi tanımlanmasını ve şarta bağlı günlük kaydını mümkün + kılmaması haricinde CustomLog yönergesi gibidir. Günlük biçemi yerine kendinden + önce yer alan bir LogFormat yönergesinde tanımlanan + bir takma ad kullanılır. Açıkça bir günlük biçemi takma adı + belirtilmedikçe Ortak Günlük Biçemi öntanımlıdır.

    + + 
    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
+TransferLog logs/access_log
    + + +
    +
    top

    Günlük Girdilerinin Kişiselleştirilmesi

    @@ -337,176 +507,6 @@ dışında diğer kullanıcılar tarafından yazılabiliyor olması halinde güvenliğinizden nasıl feragat etmiş olacağınız güvenlik ipuçları belgesinde açıklanmıştır.

    -
    -
    top
    -

    BufferedLogs Yönergesi

    - - - - - - - - -
    Açıklama:Günlük girdilerini diske yazmadan önce bellekte tamponlar -
    Sözdizimi:BufferedLogs On|Off
    Öntanımlı:BufferedLogs Off
    Bağlam:sunucu geneli
    Durum:Temel
    Modül:mod_log_config
    Uyumluluk:2.0.41 ve sonrasında mevcuttur.
    -

    BufferedLogs yönergesi, - mod_log_config modülünün çeşitli günlük girdilerini her - isteğin hemen ardından tek tek değil, bir bütün halinde diske yazılmak - üzere bellekte saklanmasını sağlar. Bu, bazı sistemlerde daha verimli - disk erişimi, dolayısıyla daha yüksek başarım sağlayabilir. Sadece - sunucu geneli için belirtilebilir, sanal konaklar için ayrı ayrı - yapılandırılamaz.

    - -
    Bir çökme günlük verisi kaybına sebep olacağından bu yönerge - dikkatli kullanılmalıdır.
    - -
    -
    top
    -

    CustomLog Yönergesi

    - - - - - - -
    Açıklama:Günlük dosyasın ismini ve girdi biçemini belirler.
    Sözdizimi:CustomLog dosya|borulu-süreç -biçem|takma-ad -[env=[!]ortam-değişkeni]| -expr=ifade]
    Bağlam:sunucu geneli, sanal konak
    Durum:Temel
    Modül:mod_log_config
    -

    CustomLog yönergesi istekleri günlüğe kaydetmek - için kullanılır. Yönerge ile bir günlük biçemi belirtilebilir ve günlük - kaydı isteğin özelliklerine bağlı olarak ortam değişkenleri vasıtasıyla - şarta bağlı kılınabilir.

    - -

    İlk argümanda günlüğün yazılacağı yer belirtilir. İki tür yer - belirtilebilir:

    - -
    -
    dosya
    -
    ServerRoot yönergesinin - değerine göreli bir dosya ismi.
    - -
    borulu-süreç
    -
    "|" boru karakteri ile öncelenmiş olarak günlük - bilgisini standart girdisinden kabul edecek sürecin ismi (veya komut - satırı) Daha fazla bilgi için borulu - günlüklere bakınız. - -

    Güvenlik:

    -

    Bir borulu süreç kullanılmışsa, süreç httpd’yi - başlatan kullanıcı tarafından başlatılacaktır. Sunucu root tarafından - başlatılıyorsa bu root olacaktır; bu bakımdan günlük kaydını alacak - programın güvenilir olması önemlidir.

    -
    -

    Bilginize

    -

    Dosya yolunu belirtirken tersbölü çizgisi kullanılan Unix dışı - platformlarda bile yapılandırma dosyasında bu amaçla normal bölü - çizgilerini kullanmaya özen gösterilmelidir.

    -
    -
    - -

    İkinci argümanda günlüğe ne yazılacağı belirtilir. Ya evvelce - LogFormat yönergesi ile - tanımlanmış bir takma-ad ya da içeriği Günlük Girdilerinin Kişiselleştirilmesi bölümünde - açıklanmış bir biçem dizgesi olabilir.

    - -

    Örneğin, aşağıdaki iki yönerge kümesi aynı etkiye sahiptir:

    - - 
    # Biçem dizgesi yerine takma ad içeren CustomLog
-LogFormat "%h %l %u %t \"%r\" %>s %b" common
-CustomLog logs/access_log common
-
-# Biçem dizgesinin kendisini içeren CustomLog
-CustomLog logs/access_log "%h %l %u %t \"%r\" %>s %b"
    - - -

    Üçüncü argüman isteğe bağlı olup,belli bir isteğin günlüğe kaydedilip - kaydedilmeyeceğini belirler. Koşul, sunucu ortamında belli bir değişkenin varlığı veya - yokluğu olabilir (bir 'env=!isim' durumu). - İstenirse koşul keyfi bir mantıksal ifade - olarak da belirtilebilir. Eğer koşul sağlanmazsa istek günlüğe - kaydedilmez. İfadede bulunan HTTP başlıklarına başvurular bu başlık - isimlerinin Vary başlığına eklenmesine sebep olmaz.

    - -

    Ortam değişkenleri mod_setenvif - ve/veya mod_rewrite modülleri kullanılarak her istek - için ayrı ayrı atanabilir. Örneğin, GIF biçemli resimler için yapılan - istekleri ana günlük dosyasına değil de başka bir dosyaya kaydetmek - isterseniz:

    - - 
    SetEnvIf Request_URI \.gif$ gif-image
-CustomLog gif-requests.log common env=gif-image
-CustomLog nongif-requests.log common env=!gif-image
    - - -

    Veya eski RefererIgnore yönergesinin davranışını taklit - etmek isterseniz:

    - - 
    SetEnvIf Referer example\.com localreferer
-CustomLog referer.log referer env=!localreferer
    - - -
    -
    top
    -

    LogFormat Yönergesi

    - - - - - - - -
    Açıklama:Bir günlük dosyasında kullanılmak üzere girdi biçemi tanımlar. -
    Sözdizimi:LogFormat biçem|takma-ad -[takma-ad]
    Öntanımlı:LogFormat "%h %l %u %t \"%r\" %>s %b"
    Bağlam:sunucu geneli, sanal konak
    Durum:Temel
    Modül:mod_log_config
    -

    Bu yönerge erişim günlüğü dosyasının girdi biçemini belirler.

    - -

    LogFormat yönergesi iki şekilde kullanılabilir. - Tek argüman belirtilebilen ilkinde daha sonra - TransferLog yönergelerinde belirtilen günlüklerde - kullanılmak üzere günlük biçemini belirler. Bu günlük biçemi yukarıda - açıklanan biçem belirteçlerinden - oluşur. Bu tek argüman yerine aşağıda açıklandığı gibi önceki bir - LogFormat yönergesinde tanımlanmış bir günlük - biçemine atıf yapan bir takma-ad da belirtilebilir.

    - -

    LogFormat yönergesinin ikinci kullanım şeklinde - biçem bir takma-ad için tanımlanır. Bu takma ad - daha sonraki LogFormat veya CustomLog yönergelerinde aynı biçem - dizgesini uzun uzadıya yazmamak için takma-ad olarak - kullanılır. Bir LogFormat yönergesi bir takma ad - tanımlamaktan başka bir şey yapmaz; yani, yaptığı iş - sadece bir takma ad tanımlamaktan ibarettir, biçemi uygulamaz veya - biçemi öntanımlı hale getirmez. Bu bakımdan sonraki TransferLog yönergelerini de - etkilemeyecektir. Ayrıca, LogFormat yönergesi bir - takma ada başka bir takma ad tanımlamakta da kullanılamaz. Bir takma - adın yüzde imi (%) içeremeyeceğine de dikkat ediniz.

    - - 
    LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common
    - - -
    -
    top
    -

    TransferLog Yönergesi

    - - - - - - -
    Açıklama:Bir günlük dosyasının yerini belirtir.
    Sözdizimi:TransferLog dosya|borulu-süreç -[takma-ad]
    Bağlam:sunucu geneli, sanal konak
    Durum:Temel
    Modül:mod_log_config
    -

    Bir günlük biçemi tanımlanmasını ve şarta bağlı günlük kaydını mümkün - kılmaması haricinde CustomLog yönergesi gibidir. Günlük biçemi yerine kendinden - önce yer alan bir LogFormat yönergesinde tanımlanan - bir takma ad kullanılır. Açıkça bir günlük biçemi takma adı - belirtilmedikçe Ortak Günlük Biçemi öntanımlıdır.

    - - 
    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
-TransferLog logs/access_log
    - -
    diff --git a/docs/manual/mod/mod_log_debug.html.en b/docs/manual/mod/mod_log_debug.html.en index 8d617d30f92..2c113674544 100644 --- a/docs/manual/mod/mod_log_debug.html.en +++ b/docs/manual/mod/mod_log_debug.html.en @@ -42,53 +42,6 @@
  • Examples
    • top
    -
    -

    Examples

    - -
      -
    1. - Log message after request to /foo/* is processed: - - 
      <Location "/foo/">
-  LogMessage "/foo/ has been requested"
-</Location>
      - -
      2. - -
    2. - Log message if request to /foo/* is processed in a sub-request: - 
      <Location "/foo/">
-  LogMessage "subrequest to /foo/" hook=type_checker expr=%{IS_SUBREQ}
-</Location>
      - - - The default log_transaction hook is not executed for sub-requests, - therefore we have to use a different hook. -
      3. - - -
    3. - Log message if an IPv6 client causes a request timeout: - 
      LogMessage "IPv6 timeout from %{REMOTE_ADDR}" "expr=-T %{IPV6} && %{REQUEST_STATUS} = 408"
      - - Note the placing of the double quotes for the expr= argument. -
      4. - -
    4. - Log the value of the "X-Foo" request environment variable in each - stage of the request: - 
      <Location "/">
-  LogMessage "%{reqenv:X-Foo}" hook=all
-</Location>
      - - Together with microsecond time stamps in the error log, - hook=all also lets you determine the times spent - in the different parts of the request processing. -
      5. - -
    -
    -
    top

    LogMessage Directive

    Description:Log user-defined message to error log @@ -135,6 +88,53 @@ headers will not cause the header names to be added to the Vary header.

    + +
    top
    +
    +

    Examples

    + +
      +
    1. + Log message after request to /foo/* is processed: + + 
      <Location "/foo/">
+  LogMessage "/foo/ has been requested"
+</Location>
      + +
      2. + +
    2. + Log message if request to /foo/* is processed in a sub-request: + 
      <Location "/foo/">
+  LogMessage "subrequest to /foo/" hook=type_checker expr=%{IS_SUBREQ}
+</Location>
      + + + The default log_transaction hook is not executed for sub-requests, + therefore we have to use a different hook. +
      3. + + +
    3. + Log message if an IPv6 client causes a request timeout: + 
      LogMessage "IPv6 timeout from %{REMOTE_ADDR}" "expr=-T %{IPV6} && %{REQUEST_STATUS} = 408"
      + + Note the placing of the double quotes for the expr= argument. +
      4. + +
    4. + Log the value of the "X-Foo" request environment variable in each + stage of the request: + 
      <Location "/">
+  LogMessage "%{reqenv:X-Foo}" hook=all
+</Location>
      + + Together with microsecond time stamps in the error log, + hook=all also lets you determine the times spent + in the different parts of the request processing. +
      5. + +
    diff --git a/docs/manual/mod/mod_log_debug.html.fr b/docs/manual/mod/mod_log_debug.html.fr index 42b7ec2a61d..826448bb04a 100644 --- a/docs/manual/mod/mod_log_debug.html.fr +++ b/docs/manual/mod/mod_log_debug.html.fr @@ -44,58 +44,6 @@
  • Exemples
    • top
    -
    -

    Exemples

    - -
      -
    1. - Enregistre un message après le traitement d'une requête pour - /foo/* : - - 
      <Location /foo/>
-  LogMessage "/foo/ has been requested"
-</Location>
      - -
      2. - -
    2. - Enregistre un message si une requête pour /foo/* est traitée - dans une sous-requête : - 
      <Location /foo/>
-  LogMessage "subrequest to /foo/" hook=type_checker expr=%{IS_SUBREQ}
-</Location>
      - - - Le branchement (hook) par défaut log_transaction n'est pas - exécuté pour les sous-requêtes ; nous devons donc en utiliser un - autre. -
      3. - - -
    3. - Enregistre un message si un client IPv6 est à l'origine d'un - dépassement de délai pour une requête : - 
      LogMessage "IPv6 timeout from %{REMOTE_ADDR}" "expr=-T %{IPV6} && %{REQUEST_STATUS} = 408"
      - - Notez l'emplacement des guillemets pour l'argument - expr=. -
      4. - -
    4. - Enregistre la valeur de la variable d'environnement de requête - "X-Foo" à chaque étape du traitement : - 
      <Location />
-  LogMessage "%{reqenv:X-Foo}" hook=all
-</Location>
      - - En association avec les repères de temps en microsecondes du journal des erreurs, - hook=all permet aussi de déterminer la durée d'exécution des - différentes phases du traitement de la requête. -
      5. - -
    -
    -
    top

    Directive LogMessage

    correspondants à l'en-tête Vary.

    + +
    top
    +
    +

    Exemples

    + +
      +
    1. + Enregistre un message après le traitement d'une requête pour + /foo/* : + + 
      <Location /foo/>
+  LogMessage "/foo/ has been requested"
+</Location>
      + +
      2. + +
    2. + Enregistre un message si une requête pour /foo/* est traitée + dans une sous-requête : + 
      <Location /foo/>
+  LogMessage "subrequest to /foo/" hook=type_checker expr=%{IS_SUBREQ}
+</Location>
      + + + Le branchement (hook) par défaut log_transaction n'est pas + exécuté pour les sous-requêtes ; nous devons donc en utiliser un + autre. +
      3. + + +
    3. + Enregistre un message si un client IPv6 est à l'origine d'un + dépassement de délai pour une requête : + 
      LogMessage "IPv6 timeout from %{REMOTE_ADDR}" "expr=-T %{IPV6} && %{REQUEST_STATUS} = 408"
      + + Notez l'emplacement des guillemets pour l'argument + expr=. +
      4. + +
    4. + Enregistre la valeur de la variable d'environnement de requête + "X-Foo" à chaque étape du traitement : + 
      <Location />
+  LogMessage "%{reqenv:X-Foo}" hook=all
+</Location>
      + + En association avec les repères de temps en microsecondes du journal des erreurs, + hook=all permet aussi de déterminer la durée d'exécution des + différentes phases du traitement de la requête. +
      5. + +
    diff --git a/docs/manual/mod/mod_log_forensic.html.en b/docs/manual/mod/mod_log_forensic.html.en index 9c66c025261..1b8f56cce6c 100644 --- a/docs/manual/mod/mod_log_forensic.html.en +++ b/docs/manual/mod/mod_log_forensic.html.en @@ -69,6 +69,52 @@ version 2.1
    Description:Enregistre des messages personnalisés dans le journal des @@ -148,6 +96,58 @@ erreurs
  • mod_log_config
    • top
    +

    ForensicLog Directive

    + + + + + + +
    Description:Sets filename of the forensic log
    Syntax:ForensicLog filename|pipe
    Context:server config, virtual host
    Status:Extension
    Module:mod_log_forensic
    +

    The ForensicLog directive is used to + log requests to the server for forensic analysis. Each log entry + is assigned a unique ID which can be associated with the request + using the normal CustomLog + directive. mod_log_forensic creates a token called + forensic-id, which can be added to the transfer log + using the %{forensic-id}n format string.

    + +

    The argument, which specifies the location to which + the logs will be written, can take one of the following two + types of values:

    + +
    +
    filename
    +
    A filename, relative to the ServerRoot.
    + +
    pipe
    +
    The pipe character "|", followed by the path + to a program to receive the log information on its standard + input. The program name can be specified relative to the ServerRoot directive. + +

    Security:

    +

    If a program is used, then it will be run as the user who + started httpd. This will be root if the server was + started by root; be sure that the program is secure or switches to a + less privileged user.

    +
    + +

    Note

    +

    When entering a file path on non-Unix platforms, care should be taken + to make sure that only forward slashes are used even though the platform + may allow the use of back slashes. In general it is a good idea to always + use forward slashes throughout the configuration files.

    +
    +
    + +
    +
    top

    Forensic Log Format

    Each request is logged two times. The first time is before it's @@ -115,52 +161,6 @@ version 2.1

    they should not be readable by anyone except the user that starts the server.

    -
    top
    -

    ForensicLog Directive

    - - - - - - -
    Description:Sets filename of the forensic log
    Syntax:ForensicLog filename|pipe
    Context:server config, virtual host
    Status:Extension
    Module:mod_log_forensic
    -

    The ForensicLog directive is used to - log requests to the server for forensic analysis. Each log entry - is assigned a unique ID which can be associated with the request - using the normal CustomLog - directive. mod_log_forensic creates a token called - forensic-id, which can be added to the transfer log - using the %{forensic-id}n format string.

    - -

    The argument, which specifies the location to which - the logs will be written, can take one of the following two - types of values:

    - -
    -
    filename
    -
    A filename, relative to the ServerRoot.
    - -
    pipe
    -
    The pipe character "|", followed by the path - to a program to receive the log information on its standard - input. The program name can be specified relative to the ServerRoot directive. - -

    Security:

    -

    If a program is used, then it will be run as the user who - started httpd. This will be root if the server was - started by root; be sure that the program is secure or switches to a - less privileged user.

    -
    - -

    Note

    -

    When entering a file path on non-Unix platforms, care should be taken - to make sure that only forward slashes are used even though the platform - may allow the use of back slashes. In general it is a good idea to always - use forward slashes throughout the configuration files.

    -
    -
    - -

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_log_forensic.html.fr b/docs/manual/mod/mod_log_forensic.html.fr index 4943af22757..276d75f964d 100644 --- a/docs/manual/mod/mod_log_forensic.html.fr +++ b/docs/manual/mod/mod_log_forensic.html.fr @@ -76,6 +76,59 @@ d'Apache

  • mod_log_config
    • top
    +

    Directive ForensicLog

    + + + + + + +
    Description:Définit le nom de fichier du journal légal
    Syntaxe:ForensicLog nom-fichier|pipe
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_log_forensic
    +

    La directive ForensicLog permet de + contrôler la journalisation des requêtes à des fins d'analyse + légale. Chaque entrée du journal se voit assigner un identifiant + unique qui peut être associé à la requête en utilisant la directive + CustomLog habituelle. + mod_log_forensic crée un élément nommé + forensic-id, qui peut être ajouté au journal standard + en utilisant l'élément de format %{forensic-id}n.

    + +

    L'argument, qui permet de spécifier l'emplacement vers lequel le + journal légal sera écrit, peut contenir les deux types de valeurs + suivants :

    + +
    +
    nom-fichier
    +
    Un nom de fichier relatif au répertoire défini par la + directive ServerRoot.
    + +
    pipe
    +
    Le caractère pipe "|", suivi du chemin vers un + programme qui recevra les informations de la journalisation sur + son entrée standard. Le nom du programme peut être relatif au + répertoire défini par la directive ServerRoot. + +

    Sécurité :

    +

    Si les journaux sont redirigés vers un programme, ce dernier + s'exécutera sous l'utilisateur qui a démarré + httpd. Ce sera l'utilisateur root si le serveur + a été démarré par root ; vérifiez que le programme est + sécurisé ou passe sous le contrôle d'un utilisateur possédant des + droits restreints.

    +
    + +

    Note

    +

    Lors de la spécification d'un chemin de fichier sur les + plate-formes non-Unix, il faut prendre soin de ne pas oublier + que seuls les slashes directs doivent être utilisés, même si la + plate-forme autorise l'emploi d'anti-slashes. D'une manière + générale, c'est une bonne idée que de n'utiliser que des slashes + directs dans les fichiers de configuration.

    +
    +
    + +
    +
    top

    Format du journal Forensic

    Chaque requête fait l'objet d'une double journalisation. La @@ -130,59 +183,6 @@ s peuvent contenir des mots de passe) ; ils ne doivent donc être lisibles que par l'utilisateur qui démarre le serveur.

    -
    top
    -

    Directive ForensicLog

    - - - - - - -
    Description:Définit le nom de fichier du journal légal
    Syntaxe:ForensicLog nom-fichier|pipe
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_log_forensic
    -

    La directive ForensicLog permet de - contrôler la journalisation des requêtes à des fins d'analyse - légale. Chaque entrée du journal se voit assigner un identifiant - unique qui peut être associé à la requête en utilisant la directive - CustomLog habituelle. - mod_log_forensic crée un élément nommé - forensic-id, qui peut être ajouté au journal standard - en utilisant l'élément de format %{forensic-id}n.

    - -

    L'argument, qui permet de spécifier l'emplacement vers lequel le - journal légal sera écrit, peut contenir les deux types de valeurs - suivants :

    - -
    -
    nom-fichier
    -
    Un nom de fichier relatif au répertoire défini par la - directive ServerRoot.
    - -
    pipe
    -
    Le caractère pipe "|", suivi du chemin vers un - programme qui recevra les informations de la journalisation sur - son entrée standard. Le nom du programme peut être relatif au - répertoire défini par la directive ServerRoot. - -

    Sécurité :

    -

    Si les journaux sont redirigés vers un programme, ce dernier - s'exécutera sous l'utilisateur qui a démarré - httpd. Ce sera l'utilisateur root si le serveur - a été démarré par root ; vérifiez que le programme est - sécurisé ou passe sous le contrôle d'un utilisateur possédant des - droits restreints.

    -
    - -

    Note

    -

    Lors de la spécification d'un chemin de fichier sur les - plate-formes non-Unix, il faut prendre soin de ne pas oublier - que seuls les slashes directs doivent être utilisés, même si la - plate-forme autorise l'emploi d'anti-slashes. D'une manière - générale, c'est une bonne idée que de n'utiliser que des slashes - directs dans les fichiers de configuration.

    -
    -
    - -

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_log_forensic.html.ja.utf8 b/docs/manual/mod/mod_log_forensic.html.ja.utf8 index 80cecdcd87e..85eb3274008 100644 --- a/docs/manual/mod/mod_log_forensic.html.ja.utf8 +++ b/docs/manual/mod/mod_log_forensic.html.ja.utf8 @@ -71,50 +71,6 @@

  • mod_log_config
    • top
    -
    -

    Forensic ログフォーマット

    -

    各リクエストは2回ログ収集されます。最初はリクエストが処理される - 前 (つまり、ヘッダを受け取った後) です。2度目のログは - リクエストが処理された後、通常のログ収集と同じときに - 行なわれます。

    - -

    各リクエストを識別するために、リクエストには - 一意なリクエスト ID が割り当てられます。この forensic ID は - フォーマット文字列 %{forensic-id}n を使うことで - 通常の transfer ログにログ収集することもできます。 - mod_unique_id を使っている場合は、それが生成する - ID が使われます。

    - -

    最初の行は forensic ID、リクエスト行と受け取ったすべてのヘッダを - パイプ文字 (|) で分離してログ収集します。 - 例えば以下のようになります (実際はすべて同じ行になります):

    - -

    - +yQtJf8CoAB4AAFNXBIEAAAAA|GET /manual/de/images/down.gif - HTTP/1.1|Host:localhost%3a8080|User-Agent:Mozilla/5.0 (X11; - U; Linux i686; en-US; rv%3a1.6) Gecko/20040216 - Firefox/0.8|Accept:image/png, etc... -

    - -

    最初のプラス文字がこのログは最初のログであることを示します。 - 二番目の行はマイナス文字と ID のみです:

    - -

    - -yQtJf8CoAB4AAFNXBIEAAAAA -

    - -

    check_forensic スクリプトは引数としてログファイルの名前を - 取ります。+/- の ID の組を調べ、完了していない - リクエストがある場合は警告を発します。

    -
    top
    -
    -

    セキュリティの問題

    -

    ログファイルが保存されるディレクトリがサーバを起動したユーザ - 以外で書き込み可能になっているときにセキュリティが破られる可能性が - あることについての詳細はセキュリティのこつを - 参照してください。

    -
    -
    top

    ForensicLog ディレクティブ

    @@ -162,6 +118,50 @@ +
    top
    +
    +

    Forensic ログフォーマット

    +

    各リクエストは2回ログ収集されます。最初はリクエストが処理される + 前 (つまり、ヘッダを受け取った後) です。2度目のログは + リクエストが処理された後、通常のログ収集と同じときに + 行なわれます。

    + +

    各リクエストを識別するために、リクエストには + 一意なリクエスト ID が割り当てられます。この forensic ID は + フォーマット文字列 %{forensic-id}n を使うことで + 通常の transfer ログにログ収集することもできます。 + mod_unique_id を使っている場合は、それが生成する + ID が使われます。

    + +

    最初の行は forensic ID、リクエスト行と受け取ったすべてのヘッダを + パイプ文字 (|) で分離してログ収集します。 + 例えば以下のようになります (実際はすべて同じ行になります):

    + +

    + +yQtJf8CoAB4AAFNXBIEAAAAA|GET /manual/de/images/down.gif + HTTP/1.1|Host:localhost%3a8080|User-Agent:Mozilla/5.0 (X11; + U; Linux i686; en-US; rv%3a1.6) Gecko/20040216 + Firefox/0.8|Accept:image/png, etc... +

    + +

    最初のプラス文字がこのログは最初のログであることを示します。 + 二番目の行はマイナス文字と ID のみです:

    + +

    + -yQtJf8CoAB4AAFNXBIEAAAAA +

    + +

    check_forensic スクリプトは引数としてログファイルの名前を + 取ります。+/- の ID の組を調べ、完了していない + リクエストがある場合は警告を発します。

    +
    top
    +
    +

    セキュリティの問題

    +

    ログファイルが保存されるディレクトリがサーバを起動したユーザ + 以外で書き込み可能になっているときにセキュリティが破られる可能性が + あることについての詳細はセキュリティのこつを + 参照してください。

    +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_log_forensic.html.tr.utf8 b/docs/manual/mod/mod_log_forensic.html.tr.utf8 index 4a8e40695b4..171b28cb8ec 100644 --- a/docs/manual/mod/mod_log_forensic.html.tr.utf8 +++ b/docs/manual/mod/mod_log_forensic.html.tr.utf8 @@ -66,6 +66,53 @@

  • mod_log_config
    • top
    +

    ForensicLog Yönergesi

    +
    説明:Forensic ログのファイル名を設定する
    + + + + + +
    Açıklama:Adli günlük için dosya ismini belirler.
    Sözdizimi:ForensicLog dosya-adı|borulu-süreç
    Bağlam:sunucu geneli, sanal konak
    Durum:Eklenti
    Modül:mod_log_forensic
    +

    ForensicLog yönergesi adli inceleme için + sunucuya yapılan istekleri günlüğe kaydetmekte kullanılır. Her günlük + girdisine, normal CustomLog yönergesinde kullanılarak istekle + ilişkilendirilebilen eşsiz bir kimlik atanır. + mod_log_forensic modülü, aktarım günlüğünün biçem + dizgesinde %{forensic-id}n şeklinde kullanılmak üzere + forensic-id adı verilen bir dizgecik oluşturur.

    + +

    Günlüğün yazılacağı yeri belirleyen argüman şu iki değerden birini + alabilir:

    + +
    +
    dosya-adı
    +
    ServerRoot yönergesinin + değerine göreli bir dosya ismi.
    + +
    borulu-süreç
    +
    "|" boru karakteri ile öncelenmiş olarak günlük + bilgisini standart girdisinden kabul edecek sürecin ismi (veya komut + satırı). Program adının ServerRoot yönergesinin değerine göre belirtildiği + varsayılır. + +

    Güvenlik:

    +

    Bir borulu süreç kullanılmışsa, süreç httpd’yi + başlatan kullanıcı tarafından başlatılacaktır. Sunucu root tarafından + başlatılıyorsa bu root olacaktır; bu bakımdan günlük kaydını alacak + programın güvenilir olması veya daha az yetkili bir kullanıcıya geçiş + yapması önemlidir.

    +
    + +

    Bilginize

    +

    Dosya yolunu belirtirken tersbölü çizgisi kullanılan Unix dışı + platformlarda bile yapılandırma dosyasında bu amaçla normal bölü + çizgilerini kullanmaya özen gösterilmelidir.

    +
    +
    + +
    +
    top

    Adli Günlük Biçemi

    Her istek günlüğe iki defa kaydedilir. İlki, işlemin başlangıcında @@ -113,53 +160,6 @@ sunucuyu başlatan kullanıcıdan başkası tarafından okunamaması sağlanmış olmalıdır.

    -
    top
    -

    ForensicLog Yönergesi

    - - - - - - -
    Açıklama:Adli günlük için dosya ismini belirler.
    Sözdizimi:ForensicLog dosya-adı|borulu-süreç
    Bağlam:sunucu geneli, sanal konak
    Durum:Eklenti
    Modül:mod_log_forensic
    -

    ForensicLog yönergesi adli inceleme için - sunucuya yapılan istekleri günlüğe kaydetmekte kullanılır. Her günlük - girdisine, normal CustomLog yönergesinde kullanılarak istekle - ilişkilendirilebilen eşsiz bir kimlik atanır. - mod_log_forensic modülü, aktarım günlüğünün biçem - dizgesinde %{forensic-id}n şeklinde kullanılmak üzere - forensic-id adı verilen bir dizgecik oluşturur.

    - -

    Günlüğün yazılacağı yeri belirleyen argüman şu iki değerden birini - alabilir:

    - -
    -
    dosya-adı
    -
    ServerRoot yönergesinin - değerine göreli bir dosya ismi.
    - -
    borulu-süreç
    -
    "|" boru karakteri ile öncelenmiş olarak günlük - bilgisini standart girdisinden kabul edecek sürecin ismi (veya komut - satırı). Program adının ServerRoot yönergesinin değerine göre belirtildiği - varsayılır. - -

    Güvenlik:

    -

    Bir borulu süreç kullanılmışsa, süreç httpd’yi - başlatan kullanıcı tarafından başlatılacaktır. Sunucu root tarafından - başlatılıyorsa bu root olacaktır; bu bakımdan günlük kaydını alacak - programın güvenilir olması veya daha az yetkili bir kullanıcıya geçiş - yapması önemlidir.

    -
    - -

    Bilginize

    -

    Dosya yolunu belirtirken tersbölü çizgisi kullanılan Unix dışı - platformlarda bile yapılandırma dosyasında bu amaçla normal bölü - çizgilerini kullanmaya özen gösterilmelidir.

    -
    -
    - -

    Mevcut Diller:  en  | diff --git a/docs/manual/mod/mod_lua.html.en b/docs/manual/mod/mod_lua.html.en index 9f32118b281..93bc7e0f9b9 100644 --- a/docs/manual/mod/mod_lua.html.en +++ b/docs/manual/mod/mod_lua.html.en @@ -95,279 +95,906 @@ trust, as it can be abused to change the internal workings of httpd.

  • Database connectivity
    • top
    -
    -

    Basic Configuration

    - -

    The basic module loading directive is

    +

    LuaAuthzProvider Directive

    + + + + + + + +
    Description:Plug an authorization provider function into mod_authz_core +
    Syntax:LuaAuthzProvider provider_name /path/to/lua/script.lua function_name
    Context:server config
    Status:Experimental
    Module:mod_lua
    Compatibility:2.4.3 and later
    +

    After a lua function has been registered as authorization provider, it can be used +with the Require directive:

    -
    LoadModule lua_module modules/mod_lua.so
    +
    LuaRoot "/usr/local/apache2/lua"
+LuaAuthzProvider foo authz.lua authz_check_foo
+<Location "/">
+  Require foo johndoe
+</Location>
    +
    require "apache2"
+function authz_check_foo(r, who)
+    if r.user ~= who then return apache2.AUTHZ_DENIED
+    return apache2.AUTHZ_GRANTED
+end
    -

    -mod_lua provides a handler named lua-script, -which can be used with a SetHandler or -AddHandler directive:

    -
    <Files "*.lua">
-    SetHandler lua-script
-</Files>
    -

    -This will cause mod_lua to handle requests for files -ending in .lua by invoking that file's -handle function. -

    +
    +
    top
    +

    LuaCodeCache Directive

    + + + + + + + + +
    Description:Configure the compiled code cache.
    Syntax:LuaCodeCache stat|forever|never
    Default:LuaCodeCache stat
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua

    + Specify the behavior of the in-memory code cache. The default + is stat, which stats the top level script (not any included + ones) each time that file is needed, and reloads it if the + modified time indicates it is newer than the one it has + already loaded. The other values cause it to keep the file + cached forever (don't stat and replace) or to never cache the + file.

    -

    For more flexibility, see LuaMapHandler. -

    +

    In general stat or forever is good for production, and stat or never + for development.

    -
    top
    -
    -

    Writing Handlers

    -

    In the Apache HTTP Server API, the handler is a specific kind of hook -responsible for generating the response. Examples of modules that include a -handler are mod_proxy, mod_cgi, -and mod_status.

    +

    Examples:

    LuaCodeCache stat
+LuaCodeCache forever
+LuaCodeCache never
    +
    -

    mod_lua always looks to invoke a Lua function for the handler, rather than -just evaluating a script body CGI style. A handler function looks -something like this:

    +
    +
    top
    +

    LuaHookAccessChecker Directive

    + + + + + + + + +
    Description:Provide a hook for the access_checker phase of request processing
    Syntax:LuaHookAccessChecker /path/to/lua/script.lua hook_function_name [early|late]
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua
    Compatibility:The optional third argument is supported in 2.3.15 and later
    +

    Add your hook to the access_checker phase. An access checker +hook function usually returns OK, DECLINED, or HTTP_FORBIDDEN.

    +

    Ordering

    The optional arguments "early" or "late" + control when this script runs relative to other modules.

    -
    -example.lua
    
--- example handler
+
    +
    top
    +

    LuaHookAuthChecker Directive

    + + + + + + + + +
    Description:Provide a hook for the auth_checker phase of request processing
    Syntax:LuaHookAuthChecker /path/to/lua/script.lua hook_function_name [early|late]
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua
    Compatibility:The optional third argument is supported in 2.3.15 and later
    +

    Invoke a lua function in the auth_checker phase of processing +a request. This can be used to implement arbitrary authentication +and authorization checking. A very simple example: +

    +
    require 'apache2'
 
-require "string"
+-- fake authcheck hook
+-- If request has no auth info, set the response header and
+-- return a 401 to ask the browser for basic auth info.
+-- If request has auth info, don't actually look at it, just
+-- pretend we got userid 'foo' and validated it.
+-- Then check if the userid is 'foo' and accept the request.
+function authcheck_hook(r)
 
---[[
-     This is the default method name for Lua handlers, see the optional
-     function-name in the LuaMapHandler directive to choose a different
-     entry point.
---]]
-function handle(r)
-    r.content_type = "text/plain"
+   -- look for auth info
+   auth = r.headers_in['Authorization']
+   if auth ~= nil then
+     -- fake the user
+     r.user = 'foo'
+   end
 
-    if r.method == 'GET' then
-        r:puts("Hello Lua World!\n")
-        for k, v in pairs( r:parseargs() ) do
-            r:puts( string.format("%s: %s\n", k, v) )
-        end
-    elseif r.method == 'POST' then
-        r:puts("Hello Lua World!\n")
-        for k, v in pairs( r:parsebody() ) do
-            r:puts( string.format("%s: %s\n", k, v) )
-        end
-    elseif r.method == 'PUT' then
--- use our own Error contents
-        r:puts("Unsupported HTTP method " .. r.method)
-        r.status = 405
-        return apache2.ok
-    else
--- use the ErrorDocument
-        return 501
-    end
-    return apache2.OK
+   if r.user == nil then
+      r:debug("authcheck: user is nil, returning 401")
+      r.err_headers_out['WWW-Authenticate'] = 'Basic realm="WallyWorld"'
+      return 401
+   elseif r.user == "foo" then
+      r:debug('user foo: OK')
+   else
+      r:debug("authcheck: user='" .. r.user .. "'")
+      r.err_headers_out['WWW-Authenticate'] = 'Basic realm="WallyWorld"'
+      return 401
+   end
+   return apache2.OK
 end
    +

    Ordering

    The optional arguments "early" or "late" + control when this script runs relative to other modules.

    + +
    +
    top
    +

    LuaHookCheckUserID Directive

    + + + + + + + + +
    Description:Provide a hook for the check_user_id phase of request processing
    Syntax:LuaHookCheckUserID /path/to/lua/script.lua hook_function_name [early|late]
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua
    Compatibility:The optional third argument is supported in 2.3.15 and later

    ...

    +

    Ordering

    The optional arguments "early" or "late" + control when this script runs relative to other modules.

    +
    +
    top
    +

    LuaHookFixups Directive

    + + + + + + + +
    Description:Provide a hook for the fixups phase of a request +processing
    Syntax:LuaHookFixups /path/to/lua/script.lua hook_function_name
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua

    -This handler function just prints out the uri or form encoded -arguments to a plaintext page. + Just like LuaHookTranslateName, but executed at the fixups phase

    +
    +
    top
    +

    LuaHookInsertFilter Directive

    + + + + + + + +
    Description:Provide a hook for the insert_filter phase of request processing
    Syntax:LuaHookInsertFilter /path/to/lua/script.lua hook_function_name
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua

    Not Yet Implemented

    +
    +
    top
    +

    LuaHookLog Directive

    + + + + + + + +
    Description:Provide a hook for the access log phase of a request +processing
    Syntax:LuaHookLog /path/to/lua/script.lua log_function_name
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua

    -This means (and in fact encourages) that you can have multiple -handlers (or hooks, or filters) in the same script. + This simple logging hook allows you to run a function when httpd enters the + logging phase of a request. With it, you can append data to your own logs, + manipulate data before the regular log is written, or prevent a log entry + from being created. To prevent the usual logging from happening, simply return + apache2.DONE in your logging handler, otherwise return + apache2.OK to tell httpd to log as normal.

    +

    Example:

    +
    LuaHookLog "/path/to/script.lua" logger
    -
    top
    -
    -

    Writing Authorization Providers

    +
    -- /path/to/script.lua --
+function logger(r)
+    -- flip a coin:
+    -- If 1, then we write to our own Lua log and tell httpd not to log
+    -- in the main log.
+    -- If 2, then we just sanitize the output a bit and tell httpd to 
+    -- log the sanitized bits.
 
+    if math.random(1,2) == 1 then
+        -- Log stuff ourselves and don't log in the regular log
+        local f = io.open("/foo/secret.log", "a")
+        if f then
+            f:write("Something secret happened at " .. r.uri .. "\n")
+            f:close()
+        end
+        return apache2.DONE -- Tell httpd not to use the regular logging functions
+    else
+        r.uri = r.uri:gsub("somesecretstuff", "") -- sanitize the URI
+        return apache2.OK -- tell httpd to log it.
+    end
+end
    -

    mod_authz_core provides a high-level interface to -authorization that is much easier to use than using into the relevant -hooks directly. The first argument to the -Require directive gives -the name of the responsible authorization provider. For any -Require line, -mod_authz_core will call the authorization provider -of the given name, passing the rest of the line as parameters. The -provider will then check authorization and pass the result as return -value.

    - -

    The authz provider is normally called before authentication. If it needs to -know the authenticated user name (or if the user will be authenticated at -all), the provider must return apache2.AUTHZ_DENIED_NO_USER. -This will cause authentication to proceed and the authz provider to be -called a second time.

    -

    The following authz provider function takes two arguments, one ip -address and one user name. It will allow access from the given ip address -without authentication, or if the authenticated user matches the second -argument:

    +
    +
    top
    +

    LuaHookMapToStorage Directive

    + + + + + + + +
    Description:Provide a hook for the map_to_storage phase of request processing
    Syntax:LuaHookMapToStorage /path/to/lua/script.lua hook_function_name
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua
    +

    Like LuaHookTranslateName but executed at the + map-to-storage phase of a request. Modules like mod_cache run at this phase, + which makes for an interesting example on what to do here:

    + 
    LuaHookMapToStorage "/path/to/lua/script.lua" check_cache
    -
    -authz_provider.lua
    
+    
    require"apache2"
+cached_files = {}
 
-require 'apache2'
+function read_file(filename) 
+    local input = io.open(filename, "r")
+    if input then
+        local data = input:read("*a")
+        cached_files[filename] = data
+        file = cached_files[filename]
+        input:close()
+    end
+    return cached_files[filename]
+end
 
-function authz_check_foo(r, ip, user)
-    if r.useragent_ip == ip then
-        return apache2.AUTHZ_GRANTED
-    elseif r.user == nil then
-        return apache2.AUTHZ_DENIED_NO_USER
-    elseif r.user == user then
-        return apache2.AUTHZ_GRANTED
-    else
-        return apache2.AUTHZ_DENIED
+function check_cache(r)
+    if r.filename:match("%.png$") then -- Only match PNG files
+        local file = cached_files[r.filename] -- Check cache entries
+        if not file then
+            file = read_file(r.filename)  -- Read file into cache
+        end
+        if file then -- If file exists, write it out
+            r.status = 200
+            r:write(file)
+            r:info(("Sent %s to client from cache"):format(r.filename))
+            return apache2.DONE -- skip default handler for PNG files
+        end
     end
+    return apache2.DECLINED -- If we had nothing to do, let others serve this.
 end
    
 
 
-
    The following configuration registers this function as provider
-foo and configures it for URL /:
    
-
    LuaAuthzProvider foo authz_provider.lua authz_check_foo
-<Location "/">
-  Require foo 10.1.2.3 john_doe
-</Location>
    
-
-
-
    top
    -
    -

    Writing Hooks

    - -

    Hook functions are how modules (and Lua scripts) participate in the -processing of requests. Each type of hook exposed by the server exists for -a specific purpose, such as mapping requests to the file system, -performing access control, or setting mime types:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Hook phasemod_lua directiveDescription
    Quick handlerLuaQuickHandlerThis is the first hook that will be called after a request has - been mapped to a host or virtual host
    Translate nameLuaHookTranslateNameThis phase translates the requested URI into a filename on the - system. Modules such as mod_alias and - mod_rewrite operate in this phase.
    Map to storageLuaHookMapToStorageThis phase maps files to their physical, cached or external/proxied storage. - It can be used by proxy or caching modules
    Check AccessLuaHookAccessCheckerThis phase checks whether a client has access to a resource. This - phase is run before the user is authenticated, so beware. -
    Check User IDLuaHookCheckUserIDThis phase it used to check the negotiated user ID
    Check AuthorizationLuaHookAuthChecker or - LuaAuthzProviderThis phase authorizes a user based on the negotiated credentials, such as - user ID, client certificate etc. -
    Check TypeLuaHookTypeCheckerThis phase checks the requested file and assigns a content type and - a handler to it
    FixupsLuaHookFixupsThis is the final "fix anything" phase before the content handlers - are run. Any last-minute changes to the request should be made here.
    Content handlerfx. .lua files or through LuaMapHandlerThis is where the content is handled. Files are read, parsed, some are run, - and the result is sent to the client
    LoggingLuaHookLogOnce a request has been handled, it enters several logging phases, - which logs the request in either the error or access log. Mod_lua - is able to hook into the start of this and control logging output.
    + +
    +
    top
    +

    LuaHookTranslateName Directive

    + + + + + + + + +
    Description:Provide a hook for the translate name phase of request processing
    Syntax:LuaHookTranslateName /path/to/lua/script.lua hook_function_name [early|late]
    Context:server config, virtual host
    Override:All
    Status:Experimental
    Module:mod_lua
    Compatibility:The optional third argument is supported in 2.3.15 and later

    + Add a hook (at APR_HOOK_MIDDLE) to the translate name phase of + request processing. The hook function receives a single + argument, the request_rec, and should return a status code, + which is either an HTTP error code, or the constants defined + in the apache2 module: apache2.OK, apache2.DECLINED, or + apache2.DONE.

    -

    Hook functions are passed the request object as their only argument -(except for LuaAuthzProvider, which also gets passed the arguments from -the Require directive). -They can return any value, depending on the hook, but most commonly -they'll return OK, DONE, or DECLINED, which you can write in Lua as -apache2.OK, apache2.DONE, or -apache2.DECLINED, or else an HTTP status code.

    +

    For those new to hooks, basically each hook will be invoked + until one of them returns apache2.OK. If your hook doesn't + want to do the translation it should just return + apache2.DECLINED. If the request should stop processing, then + return apache2.DONE.

    +

    Example:

    -
    -translate_name.lua
    
--- example hook that rewrites the URI to a filesystem path.
+
    # httpd.conf
+LuaHookTranslateName "/scripts/conf/hooks.lua" silly_mapper
    
 
-require 'apache2'
 
-function translate_name(r)
-    if r.uri == "/translate-name" then
-        r.filename = r.document_root .. "/find_me.txt"
+
    -- /scripts/conf/hooks.lua --
+require "apache2"
+function silly_mapper(r)
+    if r.uri == "/" then
+        r.filename = "/var/www/home.lua"
         return apache2.OK
+    else
+        return apache2.DECLINED
     end
-    -- we don't care about this URL, give another module a chance
-    return apache2.DECLINED
 end
    
 
 
+   
    Context
    This directive is not valid in <Directory>, <Files>, or htaccess
+   context.
    
 
-
    -translate_name2.lua
    
---[[ example hook that rewrites one URI to another URI. It returns a
-     apache2.DECLINED to give other URL mappers a chance to work on the
-     substitution, including the core translate_name hook which maps based
-     on the DocumentRoot.
+   
    Ordering
    The optional arguments "early" or "late" 
+   control when this script runs relative to other modules.
    
 
-     Note: Use the early/late flags in the directive to make it run before
-           or after mod_alias.
---]]
 
-require 'apache2'
+
    +
    top
    +

    LuaHookTypeChecker Directive

    + + + + + + + +
    Description:Provide a hook for the type_checker phase of request processing
    Syntax:LuaHookTypeChecker /path/to/lua/script.lua hook_function_name
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua

    + This directive provides a hook for the type_checker phase of the request processing. + This phase is where requests are assigned a content type and a handler, and thus can + be used to modify the type and handler based on input: +

    + 
    LuaHookTypeChecker "/path/to/lua/script.lua" type_checker
    + + 
        function type_checker(r)
+        if r.uri:match("%.to_gif$") then -- match foo.png.to_gif
+            r.content_type = "image/gif" -- assign it the image/gif type
+            r.handler = "gifWizard"      -- tell the gifWizard module to handle this
+            r.filename = r.uri:gsub("%.to_gif$", "") -- fix the filename requested
+            return apache2.OK
+        end
 
-function translate_name(r)
-    if r.uri == "/translate-name" then
-        r.uri = "/find_me.txt"
         return apache2.DECLINED
-    end
-    return apache2.DECLINED
-end
    + end -
    top
    -
    -

    Data Structures

    -
    -
    request_rec
    +
    +
    top
    +

    LuaInherit Directive

    + + + + + + + + + +
    Description:Controls how parent configuration sections are merged into children
    Syntax:LuaInherit none|parent-first|parent-last
    Default:LuaInherit parent-first
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua
    Compatibility:2.4.0 and later

    By default, if LuaHook* directives are used in overlapping + Directory or Location configuration sections, the scripts defined in the + more specific section are run after those defined in the more + generic section (LuaInherit parent-first). You can reverse this order, or + make the parent context not apply at all.

    + +

    In previous 2.3.x releases, the default was effectively to ignore LuaHook* + directives from parent configuration sections.

    +
    +
    top
    +

    LuaInputFilter Directive

    + + + + + + + +
    Description:Provide a Lua function for content input filtering
    Syntax:LuaInputFilter filter_name /path/to/lua/script.lua function_name
    Context:server config
    Status:Experimental
    Module:mod_lua
    Compatibility:2.4.5 and later
    +

    Provides a means of adding a Lua function as an input filter. +As with output filters, input filters work as coroutines, +first yielding before buffers are sent, then yielding whenever +a bucket needs to be passed down the chain, and finally (optionally) +yielding anything that needs to be appended to the input data. The +global variable bucket holds the buckets as they are passed +onto the Lua script: +

    + +
    LuaInputFilter myInputFilter "/www/filter.lua" input_filter
+<Files "*.lua">
+  SetInputFilter myInputFilter
+</Files>
    + +
    --[[
+    Example input filter that converts all POST data to uppercase.
+]]--
+function input_filter(r)
+    print("luaInputFilter called") -- debug print
+    coroutine.yield() -- Yield and wait for buckets
+    while bucket do -- For each bucket, do...
+        local output = string.upper(bucket) -- Convert all POST data to uppercase
+        coroutine.yield(output) -- Send converted data down the chain
+    end
+    -- No more buckets available.
+    coroutine.yield("&filterSignature=1234") -- Append signature at the end
+end
    + +

    +The input filter supports denying/skipping a filter if it is deemed unwanted: +

    +
    function input_filter(r)
+    if not good then
+        return -- Simply deny filtering, passing on the original content instead
+    end
+    coroutine.yield() -- wait for buckets
+    ... -- insert filter stuff here
+end
    + +

    +See "Modifying contents with Lua +filters" for more information. +

    + +
    +
    top
    +

    LuaMapHandler Directive

    + + + + + + + +
    Description:Map a path to a lua handler
    Syntax:LuaMapHandler uri-pattern /path/to/lua/script.lua [function-name]
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua
    +

    This directive matches a uri pattern to invoke a specific + handler function in a specific file. It uses PCRE regular + expressions to match the uri, and supports interpolating + match groups into both the file path and the function name. + Be careful writing your regular expressions to avoid security + issues.

    +

    Examples:

    LuaMapHandler "/(\w+)/(\w+)" "/scripts/$1.lua" "handle_$2"
    +
    +

    This would match uri's such as /photos/show?id=9 + to the file /scripts/photos.lua and invoke the + handler function handle_show on the lua vm after + loading that file.

    + +
    LuaMapHandler "/bingo" "/scripts/wombat.lua"
    + +

    This would invoke the "handle" function, which + is the default if no specific function name is + provided.

    + +
    +
    top
    +

    LuaOutputFilter Directive

    + + + + + + + +
    Description:Provide a Lua function for content output filtering
    Syntax:LuaOutputFilter filter_name /path/to/lua/script.lua function_name
    Context:server config
    Status:Experimental
    Module:mod_lua
    Compatibility:2.4.5 and later
    +

    Provides a means of adding a Lua function as an output filter. +As with input filters, output filters work as coroutines, +first yielding before buffers are sent, then yielding whenever +a bucket needs to be passed down the chain, and finally (optionally) +yielding anything that needs to be appended to the input data. The +global variable bucket holds the buckets as they are passed +onto the Lua script: +

    + +
    LuaOutputFilter myOutputFilter "/www/filter.lua" output_filter
+<Files "*.lua">
+  SetOutputFilter myOutputFilter
+</Files>
    + +
    --[[
+    Example output filter that escapes all HTML entities in the output
+]]--
+function output_filter(r)
+    coroutine.yield("(Handled by myOutputFilter)<br/>\n") -- Prepend some data to the output,
+                                                          -- yield and wait for buckets.
+    while bucket do -- For each bucket, do...
+        local output = r:escape_html(bucket) -- Escape all output
+        coroutine.yield(output) -- Send converted data down the chain
+    end
+    -- No more buckets available.
+end
    + +

    +As with the input filter, the output filter supports denying/skipping a filter +if it is deemed unwanted: +

    +
    function output_filter(r)
+    if not r.content_type:match("text/html") then
+        return -- Simply deny filtering, passing on the original content instead
+    end
+    coroutine.yield() -- wait for buckets
+    ... -- insert filter stuff here
+end
    + +

    Lua filters with mod_filter

    +

    When a Lua filter is used as the underlying provider via the +FilterProvider directive, filtering +will only work when the filter-name is identical to the provider-name. +

    + +

    +See "Modifying contents with Lua filters" for more +information. +

    + + +
    +
    top
    +

    LuaPackageCPath Directive

    + + + + + + + +
    Description:Add a directory to lua's package.cpath
    Syntax:LuaPackageCPath /path/to/include/?.soa
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua
    +

    Add a path to lua's shared library search path. Follows the same + conventions as lua. This just munges the package.cpath in the + lua vms.

    + + +
    +
    top
    +

    LuaPackagePath Directive

    + + + + + + + +
    Description:Add a directory to lua's package.path
    Syntax:LuaPackagePath /path/to/include/?.lua
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua

    Add a path to lua's module search path. Follows the same + conventions as lua. This just munges the package.path in the + lua vms.

    + +

    Examples:

    LuaPackagePath "/scripts/lib/?.lua"
+LuaPackagePath "/scripts/lib/?/init.lua"
    +
    + +
    +
    top
    +

    LuaQuickHandler Directive

    + + + + + + + +
    Description:Provide a hook for the quick handler of request processing
    Syntax:LuaQuickHandler /path/to/script.lua hook_function_name
    Context:server config, virtual host
    Override:All
    Status:Experimental
    Module:mod_lua
    +

    + This phase is run immediately after the request has been mapped to a virtal host, + and can be used to either do some request processing before the other phases kick + in, or to serve a request without the need to translate, map to storage et cetera. + As this phase is run before anything else, directives such as <Location> or <Directory> are void in this phase, just as + URIs have not been properly parsed yet. +

    +

    Context

    This directive is not valid in <Directory>, <Files>, or htaccess + context.

    + +
    +
    top
    +

    LuaRoot Directive

    + + + + + + + +
    Description:Specify the base path for resolving relative paths for mod_lua directives
    Syntax:LuaRoot /path/to/a/directory
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua
    +

    Specify the base path which will be used to evaluate all + relative paths within mod_lua. If not specified they + will be resolved relative to the current working directory, + which may not always work well for a server.

    + +
    +
    top
    +

    LuaScope Directive

    + + + + + + + + +
    Description:One of once, request, conn, thread -- default is once
    Syntax:LuaScope once|request|conn|thread|server [min] [max]
    Default:LuaScope once
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua
    +

    Specify the life cycle scope of the Lua interpreter which will + be used by handlers in this "Directory." The default is "once"

    + +
    +
    once:
    use the interpreter once and throw it away.
    + +
    request:
    use the interpreter to handle anything based on + the same file within this request, which is also + request scoped.
    + +
    conn:
    Same as request but attached to the connection_rec
    + +
    thread:
    Use the interpreter for the lifetime of the thread + handling the request (only available with threaded MPMs).
    + +
    server:
    This one is different than others because the + server scope is quite long lived, and multiple threads + will have the same server_rec. To accommodate this, + server scoped Lua states are stored in an apr + resource list. The min and max arguments + specify the minimum and maximum number of Lua states to keep in the + pool.
    +
    +

    + Generally speaking, the thread and server scopes + execute roughly 2-3 times faster than the rest, because they don't have to + spawn new Lua states on every request (especially with the event MPM, as + even keepalive requests will use a new thread for each request). If you are + satisfied that your scripts will not have problems reusing a state, then + the thread or server scopes should be used for + maximum performance. While the thread scope will provide the + fastest responses, the server scope will use less memory, as + states are pooled, allowing f.x. 1000 threads to share only 100 Lua states, + thus using only 10% of the memory required by the thread scope. +

    + +
    +
    top
    +
    +

    Basic Configuration

    + +

    The basic module loading directive is

    + +
    LoadModule lua_module modules/mod_lua.so
    + + +

    +mod_lua provides a handler named lua-script, +which can be used with a SetHandler or +AddHandler directive:

    + +
    <Files "*.lua">
+    SetHandler lua-script
+</Files>
    + + +

    +This will cause mod_lua to handle requests for files +ending in .lua by invoking that file's +handle function. +

    + +

    For more flexibility, see LuaMapHandler. +

    + +
    top
    +
    +

    Writing Handlers

    +

    In the Apache HTTP Server API, the handler is a specific kind of hook +responsible for generating the response. Examples of modules that include a +handler are mod_proxy, mod_cgi, +and mod_status.

    + +

    mod_lua always looks to invoke a Lua function for the handler, rather than +just evaluating a script body CGI style. A handler function looks +something like this:

    + + +
    +example.lua
    
+-- example handler
+
+require "string"
+
+--[[
+     This is the default method name for Lua handlers, see the optional
+     function-name in the LuaMapHandler directive to choose a different
+     entry point.
+--]]
+function handle(r)
+    r.content_type = "text/plain"
+
+    if r.method == 'GET' then
+        r:puts("Hello Lua World!\n")
+        for k, v in pairs( r:parseargs() ) do
+            r:puts( string.format("%s: %s\n", k, v) )
+        end
+    elseif r.method == 'POST' then
+        r:puts("Hello Lua World!\n")
+        for k, v in pairs( r:parsebody() ) do
+            r:puts( string.format("%s: %s\n", k, v) )
+        end
+    elseif r.method == 'PUT' then
+-- use our own Error contents
+        r:puts("Unsupported HTTP method " .. r.method)
+        r.status = 405
+        return apache2.ok
+    else
+-- use the ErrorDocument
+        return 501
+    end
+    return apache2.OK
+end
    + + +

    +This handler function just prints out the uri or form encoded +arguments to a plaintext page. +

    + +

    +This means (and in fact encourages) that you can have multiple +handlers (or hooks, or filters) in the same script. +

    + +
    top
    +
    +

    Writing Authorization Providers

    + + +

    mod_authz_core provides a high-level interface to +authorization that is much easier to use than using into the relevant +hooks directly. The first argument to the +Require directive gives +the name of the responsible authorization provider. For any +Require line, +mod_authz_core will call the authorization provider +of the given name, passing the rest of the line as parameters. The +provider will then check authorization and pass the result as return +value.

    + +

    The authz provider is normally called before authentication. If it needs to +know the authenticated user name (or if the user will be authenticated at +all), the provider must return apache2.AUTHZ_DENIED_NO_USER. +This will cause authentication to proceed and the authz provider to be +called a second time.

    + +

    The following authz provider function takes two arguments, one ip +address and one user name. It will allow access from the given ip address +without authentication, or if the authenticated user matches the second +argument:

    + +
    +authz_provider.lua
    
+
+require 'apache2'
+
+function authz_check_foo(r, ip, user)
+    if r.useragent_ip == ip then
+        return apache2.AUTHZ_GRANTED
+    elseif r.user == nil then
+        return apache2.AUTHZ_DENIED_NO_USER
+    elseif r.user == user then
+        return apache2.AUTHZ_GRANTED
+    else
+        return apache2.AUTHZ_DENIED
+    end
+end
    + + +

    The following configuration registers this function as provider +foo and configures it for URL /:

    +
    LuaAuthzProvider foo authz_provider.lua authz_check_foo
+<Location "/">
+  Require foo 10.1.2.3 john_doe
+</Location>
    + + +
    top
    +
    +

    Writing Hooks

    + +

    Hook functions are how modules (and Lua scripts) participate in the +processing of requests. Each type of hook exposed by the server exists for +a specific purpose, such as mapping requests to the file system, +performing access control, or setting mime types:

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Hook phasemod_lua directiveDescription
    Quick handlerLuaQuickHandlerThis is the first hook that will be called after a request has + been mapped to a host or virtual host
    Translate nameLuaHookTranslateNameThis phase translates the requested URI into a filename on the + system. Modules such as mod_alias and + mod_rewrite operate in this phase.
    Map to storageLuaHookMapToStorageThis phase maps files to their physical, cached or external/proxied storage. + It can be used by proxy or caching modules
    Check AccessLuaHookAccessCheckerThis phase checks whether a client has access to a resource. This + phase is run before the user is authenticated, so beware. +
    Check User IDLuaHookCheckUserIDThis phase it used to check the negotiated user ID
    Check AuthorizationLuaHookAuthChecker or + LuaAuthzProviderThis phase authorizes a user based on the negotiated credentials, such as + user ID, client certificate etc. +
    Check TypeLuaHookTypeCheckerThis phase checks the requested file and assigns a content type and + a handler to it
    FixupsLuaHookFixupsThis is the final "fix anything" phase before the content handlers + are run. Any last-minute changes to the request should be made here.
    Content handlerfx. .lua files or through LuaMapHandlerThis is where the content is handled. Files are read, parsed, some are run, + and the result is sent to the client
    LoggingLuaHookLogOnce a request has been handled, it enters several logging phases, + which logs the request in either the error or access log. Mod_lua + is able to hook into the start of this and control logging output.
    + +

    Hook functions are passed the request object as their only argument +(except for LuaAuthzProvider, which also gets passed the arguments from +the Require directive). +They can return any value, depending on the hook, but most commonly +they'll return OK, DONE, or DECLINED, which you can write in Lua as +apache2.OK, apache2.DONE, or +apache2.DECLINED, or else an HTTP status code.

    + + +
    +translate_name.lua
    
+-- example hook that rewrites the URI to a filesystem path.
+
+require 'apache2'
+
+function translate_name(r)
+    if r.uri == "/translate-name" then
+        r.filename = r.document_root .. "/find_me.txt"
+        return apache2.OK
+    end
+    -- we don't care about this URL, give another module a chance
+    return apache2.DECLINED
+end
    + + + +
    +translate_name2.lua
    
+--[[ example hook that rewrites one URI to another URI. It returns a
+     apache2.DECLINED to give other URL mappers a chance to work on the
+     substitution, including the core translate_name hook which maps based
+     on the DocumentRoot.
+
+     Note: Use the early/late flags in the directive to make it run before
+           or after mod_alias.
+--]]
+
+require 'apache2'
+
+function translate_name(r)
+    if r.uri == "/translate-name" then
+        r.uri = "/find_me.txt"
+        return apache2.DECLINED
+    end
+    return apache2.DECLINED
+end
    + +
    top
    +
    +

    Data Structures

    + +
    +
    request_rec

    The request_rec is mapped in as a userdata. It has a metatable which lets you do useful things with it. For the most part it @@ -650,1215 +1277,588 @@ end useragent_ip string - no - The IP of the user agent making the request - - -

    -
    -
    top
    -
    -

    Built in functions

    - -

    The request_rec object has (at least) the following methods:

    - -
    r:flush()   -- flushes the output buffer.
-            -- Returns true if the flush was successful, false otherwise.
-
-while we_have_stuff_to_send do
-    r:puts("Bla bla bla\n") -- print something to client
-    r:flush() -- flush the buffer (send to client)
-    r.usleep(500000) -- fake processing time for 0.5 sec. and repeat
-end
    - - -
    r:addoutputfilter(name|function) -- add an output filter:
-
-r:addoutputfilter("fooFilter") -- add the fooFilter to the output stream
    - - -
    r:sendfile(filename) -- sends an entire file to the client, using sendfile if supported by the current platform:
-
-if use_sendfile_thing then
-    r:sendfile("/var/www/large_file.img")
-end
    - - -
    r:parseargs() -- returns two tables; one standard key/value table for regular GET data, 
-              -- and one for multi-value data (fx. foo=1&foo=2&foo=3):
-
-local GET, GETMULTI = r:parseargs()
-r:puts("Your name is: " .. GET['name'] or "Unknown")
    - - -
    r:parsebody([sizeLimit]) -- parse the request body as a POST and return two lua tables,
-                         -- just like r:parseargs().
-                         -- An optional number may be passed to specify the maximum number 
-                         -- of bytes to parse. Default is 8192 bytes:
-                 
-local POST, POSTMULTI = r:parsebody(1024*1024)
-r:puts("Your name is: " .. POST['name'] or "Unknown")
    - - -
    r:puts("hello", " world", "!") -- print to response body, self explanatory
    - - -
    r:write("a single string") -- print to response body, self explanatory
    - - -
    r:escape_html("<html>test</html>") -- Escapes HTML code and returns the escaped result
    - - -
    r:base64_encode(string) -- Encodes a string using the Base64 encoding standard:
-
-local encoded = r:base64_encode("This is a test") -- returns VGhpcyBpcyBhIHRlc3Q=
    - - -
    r:base64_decode(string) -- Decodes a Base64-encoded string:
-
-local decoded = r:base64_decode("VGhpcyBpcyBhIHRlc3Q=") -- returns 'This is a test'
    - - -
    r:md5(string) -- Calculates and returns the MD5 digest of a string (binary safe):
-
-local hash = r:md5("This is a test") -- returns ce114e4501d2f4e2dcea3e17b546f339
    - - -
    r:sha1(string) -- Calculates and returns the SHA1 digest of a string (binary safe):
-
-local hash = r:sha1("This is a test") -- returns a54d88e06612d820bc3be72877c74f257b561b19
    - - -
    r:escape(string) -- URL-Escapes a string:
-
-local url = "http://foo.bar/1 2 3 & 4 + 5"
-local escaped = r:escape(url) -- returns 'http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5'
    - - -
    r:unescape(string) -- Unescapes an URL-escaped string:
-
-local url = "http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5"
-local unescaped = r:unescape(url) -- returns 'http://foo.bar/1 2 3 & 4 + 5'
    - - -
    r:construct_url(string) -- Constructs an URL from an URI
-
-local url = r:construct_url(r.uri)
    - - -
    r.mpm_query(number) -- Queries the server for MPM information using ap_mpm_query:
-
-local mpm = r.mpm_query(14)
-if mpm == 1 then
-    r:puts("This server uses the Event MPM")
-end
    - - -
    r:expr(string) -- Evaluates an expr string.
-
-if r:expr("%{HTTP_HOST} =~ /^www/") then
-    r:puts("This host name starts with www")
-end
    - - -
    r:scoreboard_process(a) -- Queries the server for information about the process at position a:
-
-local process = r:scoreboard_process(1)
-r:puts("Server 1 has PID " .. process.pid)
    - - -
    r:scoreboard_worker(a, b) -- Queries for information about the worker thread, b, in process a:
-
-local thread = r:scoreboard_worker(1, 1)
-r:puts("Server 1's thread 1 has thread ID " .. thread.tid .. " and is in " .. thread.status .. " status")
    - - - -
    r:clock() -- Returns the current time with microsecond precision
    - - -
    r:requestbody(filename) -- Reads and returns the request body of a request.
-                -- If 'filename' is specified, it instead saves the
-                -- contents to that file:
-                
-local input = r:requestbody()
-r:puts("You sent the following request body to me:\n")
-r:puts(input)
    - - -
    r:add_input_filter(filter_name) -- Adds 'filter_name' as an input filter
    - - -
    r.module_info(module_name) -- Queries the server for information about a module
-
-local mod = r.module_info("mod_lua.c")
-if mod then
-    for k, v in pairs(mod.commands) do
-       r:puts( ("%s: %s\n"):format(k,v)) -- print out all directives accepted by this module
-    end
-end
    - - -
    r:loaded_modules() -- Returns a list of modules loaded by httpd:
-
-for k, module in pairs(r:loaded_modules()) do
-    r:puts("I have loaded module " .. module .. "\n")
-end
    - - -
    r:runtime_dir_relative(filename) -- Compute the name of a run-time file (e.g., shared memory "file") 
-                         -- relative to the appropriate run-time directory.
    - - -
    r:server_info() -- Returns a table containing server information, such as 
-                -- the name of the httpd executable file, mpm used etc.
    - - -
    r:set_document_root(file_path) -- Sets the document root for the request to file_path
    - - - - -
    r:set_context_info(prefix, docroot) -- Sets the context prefix and context document root for a request
    - - -
    r:os_escape_path(file_path) -- Converts an OS path to a URL in an OS dependent way
    - - -
    r:escape_logitem(string) -- Escapes a string for logging
    - - -
    r.strcmp_match(string, pattern) -- Checks if 'string' matches 'pattern' using strcmp_match (globs).
-                        -- fx. whether 'www.example.com' matches '*.example.com':
-                        
-local match = r.strcmp_match("foobar.com", "foo*.com")
-if match then 
-    r:puts("foobar.com matches foo*.com")
-end
    - - -
    r:set_keepalive() -- Sets the keepalive status for a request. Returns true if possible, false otherwise.
    - - -
    r:make_etag() -- Constructs and returns the etag for the current request.
    - - -
    r:send_interim_response(clear) -- Sends an interim (1xx) response to the client.
-                       -- if 'clear' is true, available headers will be sent and cleared.
    - - -
    r:custom_response(status_code, string) -- Construct and set a custom response for a given status code.
-                               -- This works much like the ErrorDocument directive:
-                               
-r:custom_response(404, "Baleted!")
    - - -
    r.exists_config_define(string) -- Checks whether a configuration definition exists or not:
-
-if r.exists_config_define("FOO") then
-    r:puts("httpd was probably run with -DFOO, or it was defined in the configuration")
-end
    - - -
    r:state_query(string) -- Queries the server for state information
    + no + The IP of the user agent making the request + + + + +
    top
    +
    +

    Built in functions

    +

    The request_rec object has (at least) the following methods:

    -
    r:stat(filename [,wanted]) -- Runs stat() on a file, and returns a table with file information:
+
    r:flush()   -- flushes the output buffer.
+            -- Returns true if the flush was successful, false otherwise.
 
-local info = r:stat("/var/www/foo.txt")
-if info then
-    r:puts("This file exists and was last modified at: " .. info.modified)
+while we_have_stuff_to_send do
+    r:puts("Bla bla bla\n") -- print something to client
+    r:flush() -- flush the buffer (send to client)
+    r.usleep(500000) -- fake processing time for 0.5 sec. and repeat
 end
    
 
 
-
    r:regex(string, pattern [,flags]) -- Runs a regular expression match on a string, returning captures if matched:
+
    r:addoutputfilter(name|function) -- add an output filter:
 
-local matches = r:regex("foo bar baz", [[foo (\w+) (\S*)]])
-if matches then
-    r:puts("The regex matched, and the last word captured ($2) was: " .. matches[2])
-end
+r:addoutputfilter("fooFilter") -- add the fooFilter to the output stream
    
 
--- Example ignoring case sensitivity:
-local matches = r:regex("FOO bar BAz", [[(foo) bar]], 1)
 
--- Flags can be a bitwise combination of:
--- 0x01: Ignore case
--- 0x02: Multiline search
    
+
    r:sendfile(filename) -- sends an entire file to the client, using sendfile if supported by the current platform:
 
+if use_sendfile_thing then
+    r:sendfile("/var/www/large_file.img")
+end
    
 
-
    r.usleep(number_of_microseconds) -- Puts the script to sleep for a given number of microseconds.
    
 
+
    r:parseargs() -- returns two tables; one standard key/value table for regular GET data, 
+              -- and one for multi-value data (fx. foo=1&foo=2&foo=3):
 
-
    r:dbacquire(dbType[, dbParams]) -- Acquires a connection to a database and returns a database class.
-                        -- See 'Database connectivity' for details.
    
+local GET, GETMULTI = r:parseargs()
+r:puts("Your name is: " .. GET['name'] or "Unknown")
    
 
 
-
    r:ivm_set("key", value) -- Set an Inter-VM variable to hold a specific value.
-                        -- These values persist even though the VM is gone or not being used,
-                        -- and so should only be used if MaxConnectionsPerChild is > 0
-                        -- Values can be numbers, strings and booleans, and are stored on a 
-                        -- per process basis (so they won't do much good with a prefork mpm)
-                        
-r:ivm_get("key")        -- Fetches a variable set by ivm_set. Returns the contents of the variable
-                        -- if it exists or nil if no such variable exists.
-                        
--- An example getter/setter that saves a global variable outside the VM:
-function handle(r)
-    -- First VM to call this will get no value, and will have to create it
-    local foo = r:ivm_get("cached_data")
-    if not foo then
-        foo = do_some_calcs() -- fake some return value
-        r:ivm_set("cached_data", foo) -- set it globally
-    end
-    r:puts("Cached data is: ", foo)
-end
    
+
    r:parsebody([sizeLimit]) -- parse the request body as a POST and return two lua tables,
+                         -- just like r:parseargs().
+                         -- An optional number may be passed to specify the maximum number 
+                         -- of bytes to parse. Default is 8192 bytes:
+                 
+local POST, POSTMULTI = r:parsebody(1024*1024)
+r:puts("Your name is: " .. POST['name'] or "Unknown")
    
 
 
-
    r:htpassword(string [,algorithm [,cost]]) -- Creates a password hash from a string.
-                                          -- algorithm: 0 = APMD5 (default), 1 = SHA, 2 = BCRYPT, 3 = CRYPT.
-                                          -- cost: only valid with BCRYPT algorithm (default = 5).
    
+
    r:puts("hello", " world", "!") -- print to response body, self explanatory
    
 
 
-
    r:mkdir(dir [,mode]) -- Creates a directory and sets mode to optional mode paramter.
    
+
    r:write("a single string") -- print to response body, self explanatory
    
 
 
-
    r:mkrdir(dir [,mode]) -- Creates directories recursive and sets mode to optional mode paramter.
    
+
    r:escape_html("<html>test</html>") -- Escapes HTML code and returns the escaped result
    
 
 
-
    r:rmdir(dir) -- Removes a directory.
    
+
    r:base64_encode(string) -- Encodes a string using the Base64 encoding standard:
 
+local encoded = r:base64_encode("This is a test") -- returns VGhpcyBpcyBhIHRlc3Q=
    
 
-
    r:touch(file [,mtime]) -- Sets the file modification time to current time or to optional mtime msec value.
    
 
+
    r:base64_decode(string) -- Decodes a Base64-encoded string:
 
-
    r:get_direntries(dir) -- Returns a table with all directory entries.
+local decoded = r:base64_decode("VGhpcyBpcyBhIHRlc3Q=") -- returns 'This is a test'
    
 
-function handle(r)
-  local dir = r.context_document_root
-  for _, f in ipairs(r:get_direntries(dir)) do
-    local info = r:stat(dir .. "/" .. f)
-    if info then
-      local mtime = os.date(fmt, info.mtime / 1000000)
-      local ftype = (info.filetype == 2) and "[dir] " or "[file]"
-      r:puts( ("%s %s %10i %s\n"):format(ftype, mtime, info.size, f) )
-    end
-  end
-end
    
 
+
    r:md5(string) -- Calculates and returns the MD5 digest of a string (binary safe):
 
-
    r.date_parse_rfc(string) -- Parses a date/time string and returns seconds since epoche.
    
+local hash = r:md5("This is a test") -- returns ce114e4501d2f4e2dcea3e17b546f339
    
 
 
-
    r:getcookie(key) -- Gets a HTTP cookie
    
+
    r:sha1(string) -- Calculates and returns the SHA1 digest of a string (binary safe):
 
+local hash = r:sha1("This is a test") -- returns a54d88e06612d820bc3be72877c74f257b561b19
    
 
-
    r:setcookie{
-  key = [key],
-  value = [value],
-  expires = [expiry],
-  secure = [boolean],
-  httponly = [boolean],
-  path = [path],
-  domain = [domain]
-} -- Sets a HTTP cookie, for instance:
 
-r:setcookie{
-  key = "cookie1",
-  value = "HDHfa9eyffh396rt",
-  expires = os.time() + 86400,
-  secure = true
-}
    
+
    r:escape(string) -- URL-Escapes a string:
 
+local url = "http://foo.bar/1 2 3 & 4 + 5"
+local escaped = r:escape(url) -- returns 'http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5'
    
 
-
    r:wsupgrade() -- Upgrades a connection to WebSockets if possible (and requested):
-if r:wsupgrade() then -- if we can upgrade:
-    r:wswrite("Welcome to websockets!") -- write something to the client
-    r:wsclose()  -- goodbye!
-end
    
 
+
    r:unescape(string) -- Unescapes an URL-escaped string:
 
-
    r:wsread() -- Reads a WebSocket frame from a WebSocket upgraded connection (see above):
+local url = "http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5"
+local unescaped = r:unescape(url) -- returns 'http://foo.bar/1 2 3 & 4 + 5'
    
 
-local line, isFinal = r:wsread() -- isFinal denotes whether this is the final frame.
-                                 -- If it isn't, then more frames can be read
-r:wswrite("You wrote: " .. line)
    
 
+
    r:construct_url(string) -- Constructs an URL from an URI
 
-
    r:wswrite(line) -- Writes a frame to a WebSocket client:
-r:wswrite("Hello, world!")
    
+local url = r:construct_url(r.uri)
    
 
 
-
    r:wsclose() -- Closes a WebSocket request and terminates it for httpd:
+
    r.mpm_query(number) -- Queries the server for MPM information using ap_mpm_query:
 
-if r:wsupgrade() then
-    r:wswrite("Write something: ")
-    local line = r:wsread() or "nothing"
-    r:wswrite("You wrote: " .. line);
-    r:wswrite("Goodbye!")
-    r:wsclose()
+local mpm = r.mpm_query(14)
+if mpm == 1 then
+    r:puts("This server uses the Event MPM")
 end
    
 
 
-
    top
    -
    -

    Logging Functions

    - -
            -- examples of logging messages
    
-        r:trace1("This is a trace log message") -- trace1 through trace8 can be used 
    
-        r:debug("This is a debug log message")
    
-        r:info("This is an info log message")
    
-        r:notice("This is a notice log message")
    
-        r:warn("This is a warn log message")
    
-        r:err("This is an err log message")
    
-        r:alert("This is an alert log message")
    
-        r:crit("This is a crit log message")
    
-        r:emerg("This is an emerg log message")
    
-
    - +
    r:expr(string) -- Evaluates an expr string.
 
-
    top
    -
    -

    apache2 Package

    -

    A package named apache2 is available with (at least) the following contents.

    -
    -
    apache2.OK
    -
    internal constant OK. Handlers should return this if they've - handled the request.
    -
    apache2.DECLINED
    -
    internal constant DECLINED. Handlers should return this if - they are not going to handle the request.
    -
    apache2.DONE
    -
    internal constant DONE.
    -
    apache2.version
    -
    Apache HTTP server version string
    -
    apache2.HTTP_MOVED_TEMPORARILY
    -
    HTTP status code
    -
    apache2.PROXYREQ_NONE, apache2.PROXYREQ_PROXY, apache2.PROXYREQ_REVERSE, apache2.PROXYREQ_RESPONSE
    -
    internal constants used by mod_proxy
    -
    apache2.AUTHZ_DENIED, apache2.AUTHZ_GRANTED, apache2.AUTHZ_NEUTRAL, apache2.AUTHZ_GENERAL_ERROR, apache2.AUTHZ_DENIED_NO_USER
    -
    internal constants used by mod_authz_core
    +if r:expr("%{HTTP_HOST} =~ /^www/") then + r:puts("This host name starts with www") +end -
    -

    (Other HTTP status codes are not yet implemented.)

    -
    top
    -
    -

    Modifying contents with Lua filters

    - -

    - Filter functions implemented via LuaInputFilter - or LuaOutputFilter are designed as - three-stage non-blocking functions using coroutines to suspend and resume a - function as buckets are sent down the filter chain. The core structure of - such a function is: -

    - 
    function filter(r)
-    -- Our first yield is to signal that we are ready to receive buckets.
-    -- Before this yield, we can set up our environment, check for conditions,
-    -- and, if we deem it necessary, decline filtering a request alltogether:
-    if something_bad then
-        return -- This would skip this filter.
-    end
-    -- Regardless of whether we have data to prepend, a yield MUST be called here.
-    -- Note that only output filters can prepend data. Input filters must use the 
-    -- final stage to append data to the content.
-    coroutine.yield([optional header to be prepended to the content])
-    
-    -- After we have yielded, buckets will be sent to us, one by one, and we can 
-    -- do whatever we want with them and then pass on the result.
-    -- Buckets are stored in the global variable 'bucket', so we create a loop
-    -- that checks if 'bucket' is not nil:
-    while bucket ~= nil do
-        local output = mangle(bucket) -- Do some stuff to the content
-        coroutine.yield(output) -- Return our new content to the filter chain
-    end
 
-    -- Once the buckets are gone, 'bucket' is set to nil, which will exit the 
-    -- loop and land us here. Anything extra we want to append to the content
-    -- can be done by doing a final yield here. Both input and output filters 
-    -- can append data to the content in this phase.
-    coroutine.yield([optional footer to be appended to the content])
-end
    +
    r:scoreboard_process(a) -- Queries the server for information about the process at position a:
 
-
    top
    -
    -

    Database connectivity

    - -

    - Mod_lua implements a simple database feature for querying and running commands - on the most popular database engines (mySQL, PostgreSQL, FreeTDS, ODBC, SQLite, Oracle) - as well as mod_dbd. -

    -

    The example below shows how to acquire a database handle and return information from a table:

    - 
    function handle(r)
-    -- Acquire a database handle
-    local database, err = r:dbacquire("mysql", "server=localhost,user=someuser,pass=somepass,dbname=mydb")
-    if not err then
-        -- Select some information from it
-        local results, err = database:select(r, "SELECT `name`, `age` FROM `people` WHERE 1")
-        if not err then
-            local rows = results(0) -- fetch all rows synchronously
-            for k, row in pairs(rows) do
-                r:puts( string.format("Name: %s, Age: %s<br/>", row[1], row[2]) )
-            end
-        else
-            r:puts("Database query error: " .. err)
-        end
-        database:close()
-    else
-        r:puts("Could not connect to the database: " .. err)
-    end
-end
    +local process = r:scoreboard_process(1) +r:puts("Server 1 has PID " .. process.pid) -

    - To utilize mod_dbd, specify mod_dbd - as the database type, or leave the field blank: -

    - 
    local database = r:dbacquire("mod_dbd")
    -

    Database object and contained functions

    - -

    The database object returned by dbacquire has the following methods:

    -

    Normal select and query from a database:

    - 
    -- Run a statement and return the number of rows affected:
-local affected, errmsg = database:query(r, "DELETE FROM `tbl` WHERE 1")
+
    r:scoreboard_worker(a, b) -- Queries for information about the worker thread, b, in process a:
 
--- Run a statement and return a result set that can be used synchronously or async:
-local result, errmsg = database:select(r, "SELECT * FROM `people` WHERE 1")
    
+local thread = r:scoreboard_worker(1, 1)
+r:puts("Server 1's thread 1 has thread ID " .. thread.tid .. " and is in " .. thread.status .. " status")
    -

    Using prepared statements (recommended):

    - 
    -- Create and run a prepared statement:
-local statement, errmsg = database:prepare(r, "DELETE FROM `tbl` WHERE `age` > %u")
-if not errmsg then
-    local result, errmsg = statement:query(20) -- run the statement with age > 20
-end
 
--- Fetch a prepared statement from a DBDPrepareSQL directive:
-local statement, errmsg = database:prepared(r, "someTag")
-if not errmsg then
-    local result, errmsg = statement:select("John Doe", 123) -- inject the values "John Doe" and 123 into the statement
-end
    -

    Escaping values, closing databases etc:

    - 
    -- Escape a value for use in a statement:
-local escaped = database:escape(r, [["'|blabla]])
+
    r:clock() -- Returns the current time with microsecond precision
    
 
--- Close a database connection and free up handles:
-database:close()
 
--- Check whether a database connection is up and running:
-local connected = database:active()
    +
    r:requestbody(filename) -- Reads and returns the request body of a request.
+                -- If 'filename' is specified, it instead saves the
+                -- contents to that file:
+                
+local input = r:requestbody()
+r:puts("You sent the following request body to me:\n")
+r:puts(input)
    - -

    Working with result sets

    - -

    The result set returned by db:select or by the prepared statement functions - created through db:prepare can be used to - fetch rows synchronously or asynchronously, depending on the row number specified:
    - result(0) fetches all rows in a synchronous manner, returning a table of rows.
    - result(-1) fetches the next available row in the set, asynchronously.
    - result(N) fetches row number N, asynchronously: -

    - 
    -- fetch a result set using a regular query:
-local result, err = db:select(r, "SELECT * FROM `tbl` WHERE 1")
 
-local rows = result(0) -- Fetch ALL rows synchronously
-local row = result(-1) -- Fetch the next available row, asynchronously
-local row = result(1234) -- Fetch row number 1234, asynchronously
-local row = result(-1, true) -- Fetch the next available row, using row names as key indexes.
    +
    r:add_input_filter(filter_name) -- Adds 'filter_name' as an input filter
    -

    One can construct a function that returns an iterative function to iterate over all rows - in a synchronous or asynchronous way, depending on the async argument: -

    - 
    function rows(resultset, async)
-    local a = 0
-    local function getnext()
-        a = a + 1
-        local row = resultset(-1)
-        return row and a or nil, row
-    end
-    if not async then
-        return pairs(resultset(0))
-    else
-        return getnext, self
-    end
-end
 
-local statement, err = db:prepare(r, "SELECT * FROM `tbl` WHERE `age` > %u")
-if not err then
-     -- fetch rows asynchronously:
-    local result, err = statement:select(20)
-    if not err then
-        for index, row in rows(result, true) do
-            ....
-        end
-    end
+
    r.module_info(module_name) -- Queries the server for information about a module
 
-     -- fetch rows synchronously:
-    local result, err = statement:select(20)
-    if not err then
-        for index, row in rows(result, false) do
-            ....
-        end
+local mod = r.module_info("mod_lua.c")
+if mod then
+    for k, v in pairs(mod.commands) do
+       r:puts( ("%s: %s\n"):format(k,v)) -- print out all directives accepted by this module
     end
 end
    
 
-    
-    
    Closing a database connection
    
-        
 
-    
    Database handles should be closed using database:close() when they are no longer
-    needed. If you do not close them manually, they will eventually be garbage collected and 
-    closed by mod_lua, but you may end up having too many unused connections to the database 
-    if you leave the closing up to mod_lua. Essentially, the following two measures are
-    the same:
-    
    
-    
    -- Method 1: Manually close a handle
-local database = r:dbacquire("mod_dbd")
-database:close() -- All done
+
    r:loaded_modules() -- Returns a list of modules loaded by httpd:
 
--- Method 2: Letting the garbage collector close it
-local database = r:dbacquire("mod_dbd")
-database = nil -- throw away the reference
-collectgarbage() -- close the handle via GC
    
+for k, module in pairs(r:loaded_modules()) do
+    r:puts("I have loaded module " .. module .. "\n")
+end
    
 
-    
-    
    Precautions when working with databases
    
-    
-    
    Although the standard query and run functions are freely 
-    available, it is recommended that you use prepared statements whenever possible, to 
-    both optimize performance (if your db handle lives on for a long time) and to minimize 
-    the risk of SQL injection attacks. run and query should only
-    be used when there are no variables inserted into a statement (a static statement). 
-    When using dynamic statements, use db:prepare or db:prepared.
-    
    
-    
 
-
    -
    top
    -

    LuaAuthzProvider Directive

    - - - - - - - -
    Description:Plug an authorization provider function into mod_authz_core -
    Syntax:LuaAuthzProvider provider_name /path/to/lua/script.lua function_name
    Context:server config
    Status:Experimental
    Module:mod_lua
    Compatibility:2.4.3 and later
    -

    After a lua function has been registered as authorization provider, it can be used -with the Require directive:

    +
    r:runtime_dir_relative(filename) -- Compute the name of a run-time file (e.g., shared memory "file") 
+                         -- relative to the appropriate run-time directory.
    -
    LuaRoot "/usr/local/apache2/lua"
-LuaAuthzProvider foo authz.lua authz_check_foo
-<Location "/">
-  Require foo johndoe
-</Location>
    -
    require "apache2"
-function authz_check_foo(r, who)
-    if r.user ~= who then return apache2.AUTHZ_DENIED
-    return apache2.AUTHZ_GRANTED
+
    r:server_info() -- Returns a table containing server information, such as 
+                -- the name of the httpd executable file, mpm used etc.
    
+
+
+
    r:set_document_root(file_path) -- Sets the document root for the request to file_path
    
+
+
+
+
+
    r:set_context_info(prefix, docroot) -- Sets the context prefix and context document root for a request
    
+
+
+
    r:os_escape_path(file_path) -- Converts an OS path to a URL in an OS dependent way
    
+
+
+
    r:escape_logitem(string) -- Escapes a string for logging
    
+
+
+
    r.strcmp_match(string, pattern) -- Checks if 'string' matches 'pattern' using strcmp_match (globs).
+                        -- fx. whether 'www.example.com' matches '*.example.com':
+                        
+local match = r.strcmp_match("foobar.com", "foo*.com")
+if match then 
+    r:puts("foobar.com matches foo*.com")
 end
    
 
 
+
    r:set_keepalive() -- Sets the keepalive status for a request. Returns true if possible, false otherwise.
    
 
 
-
    -
    top
    -

    LuaCodeCache Directive

    - - - - - - - - -
    Description:Configure the compiled code cache.
    Syntax:LuaCodeCache stat|forever|never
    Default:LuaCodeCache stat
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua

    - Specify the behavior of the in-memory code cache. The default - is stat, which stats the top level script (not any included - ones) each time that file is needed, and reloads it if the - modified time indicates it is newer than the one it has - already loaded. The other values cause it to keep the file - cached forever (don't stat and replace) or to never cache the - file.

    +
    r:make_etag() -- Constructs and returns the etag for the current request.
    -

    In general stat or forever is good for production, and stat or never - for development.

    -

    Examples:

    LuaCodeCache stat
-LuaCodeCache forever
-LuaCodeCache never
    -
    +
    r:send_interim_response(clear) -- Sends an interim (1xx) response to the client.
+                       -- if 'clear' is true, available headers will be sent and cleared.
    -
    -
    top
    -

    LuaHookAccessChecker Directive

    - - - - - - - - -
    Description:Provide a hook for the access_checker phase of request processing
    Syntax:LuaHookAccessChecker /path/to/lua/script.lua hook_function_name [early|late]
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua
    Compatibility:The optional third argument is supported in 2.3.15 and later
    -

    Add your hook to the access_checker phase. An access checker -hook function usually returns OK, DECLINED, or HTTP_FORBIDDEN.

    -

    Ordering

    The optional arguments "early" or "late" - control when this script runs relative to other modules.

    +
    r:custom_response(status_code, string) -- Construct and set a custom response for a given status code.
+                               -- This works much like the ErrorDocument directive:
+                               
+r:custom_response(404, "Baleted!")
    -
    -
    top
    -

    LuaHookAuthChecker Directive

    - - - - - - - - -
    Description:Provide a hook for the auth_checker phase of request processing
    Syntax:LuaHookAuthChecker /path/to/lua/script.lua hook_function_name [early|late]
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua
    Compatibility:The optional third argument is supported in 2.3.15 and later
    -

    Invoke a lua function in the auth_checker phase of processing -a request. This can be used to implement arbitrary authentication -and authorization checking. A very simple example: -

    -
    require 'apache2'
 
--- fake authcheck hook
--- If request has no auth info, set the response header and
--- return a 401 to ask the browser for basic auth info.
--- If request has auth info, don't actually look at it, just
--- pretend we got userid 'foo' and validated it.
--- Then check if the userid is 'foo' and accept the request.
-function authcheck_hook(r)
+
    r.exists_config_define(string) -- Checks whether a configuration definition exists or not:
+
+if r.exists_config_define("FOO") then
+    r:puts("httpd was probably run with -DFOO, or it was defined in the configuration")
+end
    
+
 
-   -- look for auth info
-   auth = r.headers_in['Authorization']
-   if auth ~= nil then
-     -- fake the user
-     r.user = 'foo'
-   end
+
    r:state_query(string) -- Queries the server for state information
    
 
-   if r.user == nil then
-      r:debug("authcheck: user is nil, returning 401")
-      r.err_headers_out['WWW-Authenticate'] = 'Basic realm="WallyWorld"'
-      return 401
-   elseif r.user == "foo" then
-      r:debug('user foo: OK')
-   else
-      r:debug("authcheck: user='" .. r.user .. "'")
-      r.err_headers_out['WWW-Authenticate'] = 'Basic realm="WallyWorld"'
-      return 401
-   end
-   return apache2.OK
+
+
    r:stat(filename [,wanted]) -- Runs stat() on a file, and returns a table with file information:
+
+local info = r:stat("/var/www/foo.txt")
+if info then
+    r:puts("This file exists and was last modified at: " .. info.modified)
 end
    
 
-   
    Ordering
    The optional arguments "early" or "late" 
-   control when this script runs relative to other modules.
    
 
-
    -
    top
    -

    LuaHookCheckUserID Directive

    - - - - - - - - -
    Description:Provide a hook for the check_user_id phase of request processing
    Syntax:LuaHookCheckUserID /path/to/lua/script.lua hook_function_name [early|late]
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua
    Compatibility:The optional third argument is supported in 2.3.15 and later

    ...

    -

    Ordering

    The optional arguments "early" or "late" - control when this script runs relative to other modules.

    +
    r:regex(string, pattern [,flags]) -- Runs a regular expression match on a string, returning captures if matched:
 
-
    -
    top
    -

    LuaHookFixups Directive

    - - - - - - - -
    Description:Provide a hook for the fixups phase of a request -processing
    Syntax:LuaHookFixups /path/to/lua/script.lua hook_function_name
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua
    -

    - Just like LuaHookTranslateName, but executed at the fixups phase -

    +local matches = r:regex("foo bar baz", [[foo (\w+) (\S*)]]) +if matches then + r:puts("The regex matched, and the last word captured ($2) was: " .. matches[2]) +end -
    -
    top
    -

    LuaHookInsertFilter Directive

    - - - - - - - -
    Description:Provide a hook for the insert_filter phase of request processing
    Syntax:LuaHookInsertFilter /path/to/lua/script.lua hook_function_name
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua

    Not Yet Implemented

    -
    -
    top
    -

    LuaHookLog Directive

    - - - - - - - -
    Description:Provide a hook for the access log phase of a request -processing
    Syntax:LuaHookLog /path/to/lua/script.lua log_function_name
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua
    -

    - This simple logging hook allows you to run a function when httpd enters the - logging phase of a request. With it, you can append data to your own logs, - manipulate data before the regular log is written, or prevent a log entry - from being created. To prevent the usual logging from happening, simply return - apache2.DONE in your logging handler, otherwise return - apache2.OK to tell httpd to log as normal. -

    -

    Example:

    -
    LuaHookLog "/path/to/script.lua" logger
    +-- Example ignoring case sensitivity: +local matches = r:regex("FOO bar BAz", [[(foo) bar]], 1) -
    -- /path/to/script.lua --
-function logger(r)
-    -- flip a coin:
-    -- If 1, then we write to our own Lua log and tell httpd not to log
-    -- in the main log.
-    -- If 2, then we just sanitize the output a bit and tell httpd to 
-    -- log the sanitized bits.
+-- Flags can be a bitwise combination of:
+-- 0x01: Ignore case
+-- 0x02: Multiline search
    - if math.random(1,2) == 1 then - -- Log stuff ourselves and don't log in the regular log - local f = io.open("/foo/secret.log", "a") - if f then - f:write("Something secret happened at " .. r.uri .. "\n") - f:close() - end - return apache2.DONE -- Tell httpd not to use the regular logging functions - else - r.uri = r.uri:gsub("somesecretstuff", "") -- sanitize the URI - return apache2.OK -- tell httpd to log it. - end -end +
    r.usleep(number_of_microseconds) -- Puts the script to sleep for a given number of microseconds.
    -
    -
    top
    -

    LuaHookMapToStorage Directive

    - - - - - - - -
    Description:Provide a hook for the map_to_storage phase of request processing
    Syntax:LuaHookMapToStorage /path/to/lua/script.lua hook_function_name
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua
    -

    Like LuaHookTranslateName but executed at the - map-to-storage phase of a request. Modules like mod_cache run at this phase, - which makes for an interesting example on what to do here:

    - 
    LuaHookMapToStorage "/path/to/lua/script.lua" check_cache
    - 
    require"apache2"
-cached_files = {}
+
    r:dbacquire(dbType[, dbParams]) -- Acquires a connection to a database and returns a database class.
+                        -- See 'Database connectivity' for details.
    
 
-function read_file(filename) 
-    local input = io.open(filename, "r")
-    if input then
-        local data = input:read("*a")
-        cached_files[filename] = data
-        file = cached_files[filename]
-        input:close()
-    end
-    return cached_files[filename]
-end
 
-function check_cache(r)
-    if r.filename:match("%.png$") then -- Only match PNG files
-        local file = cached_files[r.filename] -- Check cache entries
-        if not file then
-            file = read_file(r.filename)  -- Read file into cache
-        end
-        if file then -- If file exists, write it out
-            r.status = 200
-            r:write(file)
-            r:info(("Sent %s to client from cache"):format(r.filename))
-            return apache2.DONE -- skip default handler for PNG files
-        end
+
    r:ivm_set("key", value) -- Set an Inter-VM variable to hold a specific value.
+                        -- These values persist even though the VM is gone or not being used,
+                        -- and so should only be used if MaxConnectionsPerChild is > 0
+                        -- Values can be numbers, strings and booleans, and are stored on a 
+                        -- per process basis (so they won't do much good with a prefork mpm)
+                        
+r:ivm_get("key")        -- Fetches a variable set by ivm_set. Returns the contents of the variable
+                        -- if it exists or nil if no such variable exists.
+                        
+-- An example getter/setter that saves a global variable outside the VM:
+function handle(r)
+    -- First VM to call this will get no value, and will have to create it
+    local foo = r:ivm_get("cached_data")
+    if not foo then
+        foo = do_some_calcs() -- fake some return value
+        r:ivm_set("cached_data", foo) -- set it globally
     end
-    return apache2.DECLINED -- If we had nothing to do, let others serve this.
+    r:puts("Cached data is: ", foo)
 end
    
 
 
-    
-
    -
    top
    -

    LuaHookTranslateName Directive

    - - - - - - - - -
    Description:Provide a hook for the translate name phase of request processing
    Syntax:LuaHookTranslateName /path/to/lua/script.lua hook_function_name [early|late]
    Context:server config, virtual host
    Override:All
    Status:Experimental
    Module:mod_lua
    Compatibility:The optional third argument is supported in 2.3.15 and later

    - Add a hook (at APR_HOOK_MIDDLE) to the translate name phase of - request processing. The hook function receives a single - argument, the request_rec, and should return a status code, - which is either an HTTP error code, or the constants defined - in the apache2 module: apache2.OK, apache2.DECLINED, or - apache2.DONE.

    +
    r:htpassword(string [,algorithm [,cost]]) -- Creates a password hash from a string.
+                                          -- algorithm: 0 = APMD5 (default), 1 = SHA, 2 = BCRYPT, 3 = CRYPT.
+                                          -- cost: only valid with BCRYPT algorithm (default = 5).
    -

    For those new to hooks, basically each hook will be invoked - until one of them returns apache2.OK. If your hook doesn't - want to do the translation it should just return - apache2.DECLINED. If the request should stop processing, then - return apache2.DONE.

    -

    Example:

    +
    r:mkdir(dir [,mode]) -- Creates a directory and sets mode to optional mode paramter.
    -
    # httpd.conf
-LuaHookTranslateName "/scripts/conf/hooks.lua" silly_mapper
    +
    r:mkrdir(dir [,mode]) -- Creates directories recursive and sets mode to optional mode paramter.
    -
    -- /scripts/conf/hooks.lua --
-require "apache2"
-function silly_mapper(r)
-    if r.uri == "/" then
-        r.filename = "/var/www/home.lua"
-        return apache2.OK
-    else
-        return apache2.DECLINED
+
+
    r:rmdir(dir) -- Removes a directory.
    
+
+
+
    r:touch(file [,mtime]) -- Sets the file modification time to current time or to optional mtime msec value.
    
+
+
+
    r:get_direntries(dir) -- Returns a table with all directory entries.
+
+function handle(r)
+  local dir = r.context_document_root
+  for _, f in ipairs(r:get_direntries(dir)) do
+    local info = r:stat(dir .. "/" .. f)
+    if info then
+      local mtime = os.date(fmt, info.mtime / 1000000)
+      local ftype = (info.filetype == 2) and "[dir] " or "[file]"
+      r:puts( ("%s %s %10i %s\n"):format(ftype, mtime, info.size, f) )
     end
+  end
 end
    
 
 
-   
    Context
    This directive is not valid in <Directory>, <Files>, or htaccess
-   context.
    
+
    r.date_parse_rfc(string) -- Parses a date/time string and returns seconds since epoche.
    
+
+
+
    r:getcookie(key) -- Gets a HTTP cookie
    
+
+
+
    r:setcookie{
+  key = [key],
+  value = [value],
+  expires = [expiry],
+  secure = [boolean],
+  httponly = [boolean],
+  path = [path],
+  domain = [domain]
+} -- Sets a HTTP cookie, for instance:
+
+r:setcookie{
+  key = "cookie1",
+  value = "HDHfa9eyffh396rt",
+  expires = os.time() + 86400,
+  secure = true
+}
    
+
 
-   
    Ordering
    The optional arguments "early" or "late" 
-   control when this script runs relative to other modules.
    
+
    r:wsupgrade() -- Upgrades a connection to WebSockets if possible (and requested):
+if r:wsupgrade() then -- if we can upgrade:
+    r:wswrite("Welcome to websockets!") -- write something to the client
+    r:wsclose()  -- goodbye!
+end
    
 
 
-
    -
    top
    -

    LuaHookTypeChecker Directive

    - - - - - - - -
    Description:Provide a hook for the type_checker phase of request processing
    Syntax:LuaHookTypeChecker /path/to/lua/script.lua hook_function_name
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua

    - This directive provides a hook for the type_checker phase of the request processing. - This phase is where requests are assigned a content type and a handler, and thus can - be used to modify the type and handler based on input: -

    - 
    LuaHookTypeChecker "/path/to/lua/script.lua" type_checker
    +
    r:wsread() -- Reads a WebSocket frame from a WebSocket upgraded connection (see above):
 
-    
        function type_checker(r)
-        if r.uri:match("%.to_gif$") then -- match foo.png.to_gif
-            r.content_type = "image/gif" -- assign it the image/gif type
-            r.handler = "gifWizard"      -- tell the gifWizard module to handle this
-            r.filename = r.uri:gsub("%.to_gif$", "") -- fix the filename requested
-            return apache2.OK
-        end
+local line, isFinal = r:wsread() -- isFinal denotes whether this is the final frame.
+                                 -- If it isn't, then more frames can be read
+r:wswrite("You wrote: " .. line)
    
 
-        return apache2.DECLINED
-    end
    +
    r:wswrite(line) -- Writes a frame to a WebSocket client:
+r:wswrite("Hello, world!")
    -
    -
    top
    -

    LuaInherit Directive

    - - - - - - - - - -
    Description:Controls how parent configuration sections are merged into children
    Syntax:LuaInherit none|parent-first|parent-last
    Default:LuaInherit parent-first
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua
    Compatibility:2.4.0 and later

    By default, if LuaHook* directives are used in overlapping - Directory or Location configuration sections, the scripts defined in the - more specific section are run after those defined in the more - generic section (LuaInherit parent-first). You can reverse this order, or - make the parent context not apply at all.

    - -

    In previous 2.3.x releases, the default was effectively to ignore LuaHook* - directives from parent configuration sections.

    -
    -
    top
    -

    LuaInputFilter Directive

    - - - - - - - -
    Description:Provide a Lua function for content input filtering
    Syntax:LuaInputFilter filter_name /path/to/lua/script.lua function_name
    Context:server config
    Status:Experimental
    Module:mod_lua
    Compatibility:2.4.5 and later
    -

    Provides a means of adding a Lua function as an input filter. -As with output filters, input filters work as coroutines, -first yielding before buffers are sent, then yielding whenever -a bucket needs to be passed down the chain, and finally (optionally) -yielding anything that needs to be appended to the input data. The -global variable bucket holds the buckets as they are passed -onto the Lua script: -

    -
    LuaInputFilter myInputFilter "/www/filter.lua" input_filter
-<Files "*.lua">
-  SetInputFilter myInputFilter
-</Files>
    +
    r:wsclose() -- Closes a WebSocket request and terminates it for httpd:
 
-
    --[[
-    Example input filter that converts all POST data to uppercase.
-]]--
-function input_filter(r)
-    print("luaInputFilter called") -- debug print
-    coroutine.yield() -- Yield and wait for buckets
-    while bucket do -- For each bucket, do...
-        local output = string.upper(bucket) -- Convert all POST data to uppercase
-        coroutine.yield(output) -- Send converted data down the chain
-    end
-    -- No more buckets available.
-    coroutine.yield("&filterSignature=1234") -- Append signature at the end
+if r:wsupgrade() then
+    r:wswrite("Write something: ")
+    local line = r:wsread() or "nothing"
+    r:wswrite("You wrote: " .. line);
+    r:wswrite("Goodbye!")
+    r:wsclose()
 end
    
 
-
    
-The input filter supports denying/skipping a filter if it is deemed unwanted:
-
    
-
    function input_filter(r)
-    if not good then
-        return -- Simply deny filtering, passing on the original content instead
-    end
-    coroutine.yield() -- wait for buckets
-    ... -- insert filter stuff here
-end
    
 
-
    
-See "Modifying contents with Lua 
-filters" for more information.
-
    
+
    top
    +
    +

    Logging Functions

    -
    -
    top
    -

    LuaMapHandler Directive

    - - - - - - - -
    Description:Map a path to a lua handler
    Syntax:LuaMapHandler uri-pattern /path/to/lua/script.lua [function-name]
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua
    -

    This directive matches a uri pattern to invoke a specific - handler function in a specific file. It uses PCRE regular - expressions to match the uri, and supports interpolating - match groups into both the file path and the function name. - Be careful writing your regular expressions to avoid security - issues.

    -

    Examples:

    LuaMapHandler "/(\w+)/(\w+)" "/scripts/$1.lua" "handle_$2"
    -
    -

    This would match uri's such as /photos/show?id=9 - to the file /scripts/photos.lua and invoke the - handler function handle_show on the lua vm after - loading that file.

    +
            -- examples of logging messages
    
+        r:trace1("This is a trace log message") -- trace1 through trace8 can be used 
    
+        r:debug("This is a debug log message")
    
+        r:info("This is an info log message")
    
+        r:notice("This is a notice log message")
    
+        r:warn("This is a warn log message")
    
+        r:err("This is an err log message")
    
+        r:alert("This is an alert log message")
    
+        r:crit("This is a crit log message")
    
+        r:emerg("This is an emerg log message")
    
+
    -
    LuaMapHandler "/bingo" "/scripts/wombat.lua"
    -

    This would invoke the "handle" function, which - is the default if no specific function name is - provided.

    +
    top
    +
    +

    apache2 Package

    +

    A package named apache2 is available with (at least) the following contents.

    +
    +
    apache2.OK
    +
    internal constant OK. Handlers should return this if they've + handled the request.
    +
    apache2.DECLINED
    +
    internal constant DECLINED. Handlers should return this if + they are not going to handle the request.
    +
    apache2.DONE
    +
    internal constant DONE.
    +
    apache2.version
    +
    Apache HTTP server version string
    +
    apache2.HTTP_MOVED_TEMPORARILY
    +
    HTTP status code
    +
    apache2.PROXYREQ_NONE, apache2.PROXYREQ_PROXY, apache2.PROXYREQ_REVERSE, apache2.PROXYREQ_RESPONSE
    +
    internal constants used by mod_proxy
    +
    apache2.AUTHZ_DENIED, apache2.AUTHZ_GRANTED, apache2.AUTHZ_NEUTRAL, apache2.AUTHZ_GENERAL_ERROR, apache2.AUTHZ_DENIED_NO_USER
    +
    internal constants used by mod_authz_core
    -
    -
    top
    -

    LuaOutputFilter Directive

    - - - - - - - -
    Description:Provide a Lua function for content output filtering
    Syntax:LuaOutputFilter filter_name /path/to/lua/script.lua function_name
    Context:server config
    Status:Experimental
    Module:mod_lua
    Compatibility:2.4.5 and later
    -

    Provides a means of adding a Lua function as an output filter. -As with input filters, output filters work as coroutines, -first yielding before buffers are sent, then yielding whenever -a bucket needs to be passed down the chain, and finally (optionally) -yielding anything that needs to be appended to the input data. The -global variable bucket holds the buckets as they are passed -onto the Lua script: -

    + +

    (Other HTTP status codes are not yet implemented.)

    +
    top
    +
    +

    Modifying contents with Lua filters

    + +

    + Filter functions implemented via LuaInputFilter + or LuaOutputFilter are designed as + three-stage non-blocking functions using coroutines to suspend and resume a + function as buckets are sent down the filter chain. The core structure of + such a function is: +

    + 
    function filter(r)
+    -- Our first yield is to signal that we are ready to receive buckets.
+    -- Before this yield, we can set up our environment, check for conditions,
+    -- and, if we deem it necessary, decline filtering a request alltogether:
+    if something_bad then
+        return -- This would skip this filter.
+    end
+    -- Regardless of whether we have data to prepend, a yield MUST be called here.
+    -- Note that only output filters can prepend data. Input filters must use the 
+    -- final stage to append data to the content.
+    coroutine.yield([optional header to be prepended to the content])
+    
+    -- After we have yielded, buckets will be sent to us, one by one, and we can 
+    -- do whatever we want with them and then pass on the result.
+    -- Buckets are stored in the global variable 'bucket', so we create a loop
+    -- that checks if 'bucket' is not nil:
+    while bucket ~= nil do
+        local output = mangle(bucket) -- Do some stuff to the content
+        coroutine.yield(output) -- Return our new content to the filter chain
+    end
 
-
    LuaOutputFilter myOutputFilter "/www/filter.lua" output_filter
-<Files "*.lua">
-  SetOutputFilter myOutputFilter
-</Files>
    
+    -- Once the buckets are gone, 'bucket' is set to nil, which will exit the 
+    -- loop and land us here. Anything extra we want to append to the content
+    -- can be done by doing a final yield here. Both input and output filters 
+    -- can append data to the content in this phase.
+    coroutine.yield([optional footer to be appended to the content])
+end
    -
    --[[
-    Example output filter that escapes all HTML entities in the output
-]]--
-function output_filter(r)
-    coroutine.yield("(Handled by myOutputFilter)<br/>\n") -- Prepend some data to the output,
-                                                          -- yield and wait for buckets.
-    while bucket do -- For each bucket, do...
-        local output = r:escape_html(bucket) -- Escape all output
-        coroutine.yield(output) -- Send converted data down the chain
+
    top
    +
    +

    Database connectivity

    + +

    + Mod_lua implements a simple database feature for querying and running commands + on the most popular database engines (mySQL, PostgreSQL, FreeTDS, ODBC, SQLite, Oracle) + as well as mod_dbd. +

    +

    The example below shows how to acquire a database handle and return information from a table:

    + 
    function handle(r)
+    -- Acquire a database handle
+    local database, err = r:dbacquire("mysql", "server=localhost,user=someuser,pass=somepass,dbname=mydb")
+    if not err then
+        -- Select some information from it
+        local results, err = database:select(r, "SELECT `name`, `age` FROM `people` WHERE 1")
+        if not err then
+            local rows = results(0) -- fetch all rows synchronously
+            for k, row in pairs(rows) do
+                r:puts( string.format("Name: %s, Age: %s<br/>", row[1], row[2]) )
+            end
+        else
+            r:puts("Database query error: " .. err)
+        end
+        database:close()
+    else
+        r:puts("Could not connect to the database: " .. err)
     end
-    -- No more buckets available.
 end
    -

    -As with the input filter, the output filter supports denying/skipping a filter -if it is deemed unwanted: -

    -
    function output_filter(r)
-    if not r.content_type:match("text/html") then
-        return -- Simply deny filtering, passing on the original content instead
-    end
-    coroutine.yield() -- wait for buckets
-    ... -- insert filter stuff here
-end
    +

    + To utilize mod_dbd, specify mod_dbd + as the database type, or leave the field blank: +

    + 
    local database = r:dbacquire("mod_dbd")
    -

    Lua filters with mod_filter

    -

    When a Lua filter is used as the underlying provider via the -FilterProvider directive, filtering -will only work when the filter-name is identical to the provider-name. -

    +

    Database object and contained functions

    + +

    The database object returned by dbacquire has the following methods:

    +

    Normal select and query from a database:

    + 
    -- Run a statement and return the number of rows affected:
+local affected, errmsg = database:query(r, "DELETE FROM `tbl` WHERE 1")
 
-
    
-See "Modifying contents with Lua filters" for more 
-information.
-
    
+-- Run a statement and return a result set that can be used synchronously or async:
+local result, errmsg = database:select(r, "SELECT * FROM `people` WHERE 1")
    +

    Using prepared statements (recommended):

    + 
    -- Create and run a prepared statement:
+local statement, errmsg = database:prepare(r, "DELETE FROM `tbl` WHERE `age` > %u")
+if not errmsg then
+    local result, errmsg = statement:query(20) -- run the statement with age > 20
+end
 
-
    -
    top
    -

    LuaPackageCPath Directive

    - - - - - - - -
    Description:Add a directory to lua's package.cpath
    Syntax:LuaPackageCPath /path/to/include/?.soa
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua
    -

    Add a path to lua's shared library search path. Follows the same - conventions as lua. This just munges the package.cpath in the - lua vms.

    +-- Fetch a prepared statement from a DBDPrepareSQL directive: +local statement, errmsg = database:prepared(r, "someTag") +if not errmsg then + local result, errmsg = statement:select("John Doe", 123) -- inject the values "John Doe" and 123 into the statement +end +

    Escaping values, closing databases etc:

    + 
    -- Escape a value for use in a statement:
+local escaped = database:escape(r, [["'|blabla]])
 
-
    -
    top
    -

    LuaPackagePath Directive

    - - - - - - - -
    Description:Add a directory to lua's package.path
    Syntax:LuaPackagePath /path/to/include/?.lua
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua

    Add a path to lua's module search path. Follows the same - conventions as lua. This just munges the package.path in the - lua vms.

    +-- Close a database connection and free up handles: +database:close() -

    Examples:

    LuaPackagePath "/scripts/lib/?.lua"
-LuaPackagePath "/scripts/lib/?/init.lua"
    -
    +-- Check whether a database connection is up and running: +local connected = database:active() -
    -
    top
    -

    LuaQuickHandler Directive

    - - - - - - - -
    Description:Provide a hook for the quick handler of request processing
    Syntax:LuaQuickHandler /path/to/script.lua hook_function_name
    Context:server config, virtual host
    Override:All
    Status:Experimental
    Module:mod_lua
    -

    - This phase is run immediately after the request has been mapped to a virtal host, - and can be used to either do some request processing before the other phases kick - in, or to serve a request without the need to translate, map to storage et cetera. - As this phase is run before anything else, directives such as <Location> or <Directory> are void in this phase, just as - URIs have not been properly parsed yet. + +

    Working with result sets

    + +

    The result set returned by db:select or by the prepared statement functions + created through db:prepare can be used to + fetch rows synchronously or asynchronously, depending on the row number specified:
    + result(0) fetches all rows in a synchronous manner, returning a table of rows.
    + result(-1) fetches the next available row in the set, asynchronously.
    + result(N) fetches row number N, asynchronously:

    -

    Context

    This directive is not valid in <Directory>, <Files>, or htaccess - context.

    + 
    -- fetch a result set using a regular query:
+local result, err = db:select(r, "SELECT * FROM `tbl` WHERE 1")
 
-
    -
    top
    -

    LuaRoot Directive

    - - - - - - - -
    Description:Specify the base path for resolving relative paths for mod_lua directives
    Syntax:LuaRoot /path/to/a/directory
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua
    -

    Specify the base path which will be used to evaluate all - relative paths within mod_lua. If not specified they - will be resolved relative to the current working directory, - which may not always work well for a server.

    +local rows = result(0) -- Fetch ALL rows synchronously +local row = result(-1) -- Fetch the next available row, asynchronously +local row = result(1234) -- Fetch row number 1234, asynchronously +local row = result(-1, true) -- Fetch the next available row, using row names as key indexes. -
    -
    top
    -

    LuaScope Directive

    - - - - - - - - -
    Description:One of once, request, conn, thread -- default is once
    Syntax:LuaScope once|request|conn|thread|server [min] [max]
    Default:LuaScope once
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua
    -

    Specify the life cycle scope of the Lua interpreter which will - be used by handlers in this "Directory." The default is "once"

    +

    One can construct a function that returns an iterative function to iterate over all rows + in a synchronous or asynchronous way, depending on the async argument: +

    + 
    function rows(resultset, async)
+    local a = 0
+    local function getnext()
+        a = a + 1
+        local row = resultset(-1)
+        return row and a or nil, row
+    end
+    if not async then
+        return pairs(resultset(0))
+    else
+        return getnext, self
+    end
+end
 
-   
    
-    
    once:
     
    use the interpreter once and throw it away.
    
+local statement, err = db:prepare(r, "SELECT * FROM `tbl` WHERE `age` > %u")
+if not err then
+     -- fetch rows asynchronously:
+    local result, err = statement:select(20)
+    if not err then
+        for index, row in rows(result, true) do
+            ....
+        end
+    end
 
-    
    request:
     
    use the interpreter to handle anything based on
-             the same file within this request, which is also
-             request scoped.
    
+     -- fetch rows synchronously:
+    local result, err = statement:select(20)
+    if not err then
+        for index, row in rows(result, false) do
+            ....
+        end
+    end
+end
    -
    conn:
    Same as request but attached to the connection_rec
    + +

    Closing a database connection

    + -
    thread:
    Use the interpreter for the lifetime of the thread - handling the request (only available with threaded MPMs).
    +

    Database handles should be closed using database:close() when they are no longer + needed. If you do not close them manually, they will eventually be garbage collected and + closed by mod_lua, but you may end up having too many unused connections to the database + if you leave the closing up to mod_lua. Essentially, the following two measures are + the same: +

    + 
    -- Method 1: Manually close a handle
+local database = r:dbacquire("mod_dbd")
+database:close() -- All done
 
-    
    server:
      
    This one is different than others because the
-            server scope is quite long lived, and multiple threads
-            will have the same server_rec. To accommodate this,
-            server scoped Lua states are stored in an apr
-            resource list. The min and max arguments 
-            specify the minimum and maximum number of Lua states to keep in the 
-            pool.
    
-   
-    
    
-    Generally speaking, the thread and server scopes 
-    execute roughly 2-3 times faster than the rest, because they don't have to 
-    spawn new Lua states on every request (especially with the event MPM, as 
-    even keepalive requests will use a new thread for each request). If you are 
-    satisfied that your scripts will not have problems reusing a state, then 
-    the thread or server scopes should be used for 
-    maximum performance. While the thread scope will provide the 
-    fastest responses, the server scope will use less memory, as 
-    states are pooled, allowing f.x. 1000 threads to share only 100 Lua states, 
-    thus using only 10% of the memory required by the thread scope.
+-- Method 2: Letting the garbage collector close it
+local database = r:dbacquire("mod_dbd")
+database = nil -- throw away the reference
+collectgarbage() -- close the handle via GC
    + + +

    Precautions when working with databases

    + +

    Although the standard query and run functions are freely + available, it is recommended that you use prepared statements whenever possible, to + both optimize performance (if your db handle lives on for a long time) and to minimize + the risk of SQL injection attacks. run and query should only + be used when there are no variables inserted into a statement (a static statement). + When using dynamic statements, use db:prepare or db:prepared.

    +
    diff --git a/docs/manual/mod/mod_lua.html.fr b/docs/manual/mod/mod_lua.html.fr index 168976d94f0..0083ee299cf 100644 --- a/docs/manual/mod/mod_lua.html.fr +++ b/docs/manual/mod/mod_lua.html.fr @@ -103,271 +103,935 @@ fonctionnement interne de httpd.

  • Connectivité aux bases de données
    • top
    -
    -

    Configuration de base

    +

    Directive LuaAuthzProvider

    + + + + + + + +
    Description:Branche une fonction fournisseur d'autorisation dans mod_authz_core +
    Syntaxe:LuaAuthzProvider provider_name /path/to/lua/script.lua function_name
    Contexte:configuration du serveur
    Statut:Expérimental
    Module:mod_lua
    Compatibilité:Disponible depuis la version 2.4.3 du serveur HTTP Apache
    +

    Lorsqu'une fonction lua a été enregistrée en tant que fournisseur +d'autorisation, elle peut être appelée via la directive Require :

    -

    La directive de base pour le chargement du module est

    -
    LoadModule lua_module modules/mod_lua.so
    +
    LuaRoot /usr/local/apache2/lua
+LuaAuthzProvider foo authz.lua authz_check_foo
+<Location />
+  Require foo johndoe
+</Location>
    +
    require "apache2"
+function authz_check_foo(r, who)
+    if r.user ~= who then return apache2.AUTHZ_DENIED
+    return apache2.AUTHZ_GRANTED
+end
    -

    -mod_lua fournit un gestionnaire nommé -lua-script qui peut être utilisé avec une directive -AddHandler ou SetHandler :

    -
    <Files *.lua>
-    SetHandler lua-script
-</Files>
    +
    +
    top
    +

    Directive LuaCodeCache

    + + + + + + + + +
    Description:Configure le cache de code compilé.
    Syntaxe:LuaCodeCache stat|forever|never
    Défaut:LuaCodeCache stat
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua

    + Cette directive permet de définir le comportement du cache de code + en mémoire. La valeur par défaut est stat ; dans ce cas, le script + du niveau le plus haut (et pas les scripts inclus) est vérifié à + chaque fois que ce fichier est nécessaire, et est rechargé si la + date de modification est plus récente que celle du script déjà + chargé. Les autres valeurs permettent respectivement de garder le + fichier en cache perpétuellement (forever - jamais vérifié ni + remplacé), ou de ne jamais le mettre en cache (never).

    -

    -Ceci aura pour effet de faire traiter les requêtes pour les fichiers -dont l'extension est .lua par mod_lua en -invoquant cette fonction de gestion de fichier. -

    +

    En général, les valeurs stat et forever sont utilisées pour un + serveur en production, et les valeurs stat ou never pour un serveur + en développement.

    -

    Pour plus de détails, voir la directive -LuaMapHandler. -

    -
    top
    -
    -

    Ecrire des gestionnaires

    -

    Dans l'API du serveur HTTP Apache, un gestionnaire est une sorte de -point d'accroche (hook) spécifique responsable de la génération de la -réponse. mod_proxy, mod_cgi et -mod_status sont des exemples de modules comportant un -gestionnaire.

    +

    Exemples :

    LuaCodeCache stat
+LuaCodeCache forever
+LuaCodeCache never
    +
    -

    mod_lua cherche toujours à invoquer une fonction Lua pour le -gestionnaire, plutôt que de simplement évaluer le corps d'un script dans -le style de CGI. Une fonction de gestionnaire se présente comme suit :

    +
    +
    top
    +

    Directive LuaHookAccessChecker

    + + + + + + + + +
    Description:Fournit un point d'entrée pour la phase access_checker du +traitement de la requête
    Syntaxe:LuaHookAccessChecker /chemin/vers/lua/script.lua hook_function_name [early|late]
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    Compatibilité:Le troisième argument optionnel est disponible depuis la +version 2.3.15 du serveur HTTP Apache.
    +

    Ajoute votre fonction d'accroche à la phase access_checker. Une +fonction d'accroche access checker renvoie en général OK, DECLINED, ou +HTTP_FORBIDDEN.

    +

    Ordonnancement

    Les arguments optionnels + "early" ou "late" permettent de contrôler le moment auquel ce script + s'exécute par rapport aux autres modules.

    -
    -example.lua
    
--- exemple de gestionnaire
+
    +
    top
    +

    Directive LuaHookAuthChecker

    + + + + + + + + +
    Description:Fournit un point d'entrée pour la phase auth_checker du +traitement de la requête
    Syntaxe:LuaHookAuthChecker /chemin/vers/lua/script.lua hook_function_name [early|late]
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    Compatibilité:Le troisième argument optionnel est disponible depuis la +version 2.3.15 du serveur HTTP Apache.
    +

    Invoque une fonction lua au cours de la phase auth_checker du +traitement de la requête. Cette directive peut s'utiliser pour +implémenter une vérification arbitraire de l'authentification et de +l'autorisation. Voici un exemple très simple : +

    +
    require 'apache2'
 
-require "string"
+-- fonction d'accroche authcheck fictive
+-- Si la requête ne contient aucune donnée d'authentification, l'en-tête
+-- de la réponse est défini et un code 401 est renvoyé afin de demander au
+-- navigateur d'effectuer une authentification basique. Si la requête
+-- comporte des données d'authentification, elles ne sont pas vraiment
+-- consultées, mais on admet la prise en compte de l'utilisateur 'foo' et
+-- on la valide. On vérifie ensuite si l'utilisateur est bien 'foo' et on
+-- accepte la requête.
+function authcheck_hook(r)
 
---[[
-     Il s'agit du nom de méthode par défaut pour les gestionnaires Lua ;
-     voir les noms de fonctions optionnels dans la directive
-     LuaMapHandler pour choisir un point d'entrée différent.
---]]
-function handle(r)
-    r.content_type = "text/plain"
+   -- recherche des informations d'authentification
+   auth = r.headers_in['Authorization']
+   if auth ~= nil then
+     -- définition d'un utilisateur par défaut
+     r.user = 'foo'
+   end
 
-    if r.method == 'GET' then
-    	r:puts("Hello Lua World!\n")
-        for k, v in pairs( r:parseargs() ) do
-            r:puts( string.format("%s: %s\n", k, v) )
-        end
-    elseif r.method == 'POST' then
-    	r:puts("Hello Lua World!\n")
-        for k, v in pairs( r:parsebody() ) do
-            r:puts( string.format("%s: %s\n", k, v) )
-        end
-    else
-    elseif r.method == 'PUT' then
--- message d'erreur personnalisé
-        r:puts("Unsupported HTTP method " .. r.method)
-	r.status = 405
-        return apache2.ok
-    else
--- message d'erreur ErrorDocument
-        return 501
-    end
-    return apache2.OK
+   if r.user == nil then
+      r:debug("authcheck: user is nil, returning 401")
+      r.err_headers_out['WWW-Authenticate'] = 'Basic realm="WallyWorld"'
+      return 401
+   elseif r.user == "foo" then
+      r:debug('user foo: OK')
+   else
+      r:debug("authcheck: user='" .. r.user .. "'")
+      r.err_headers_out['WWW-Authenticate'] = 'Basic realm="WallyWorld"'
+      return 401
+   end
+   return apache2.OK
 end
    +

    Ordonnancement

    Les arguments optionnels + "early" ou "late" permettent de contrôler le moment auquel ce script + s'exécute par rapport aux autres modules.

    + +
    +
    top
    +

    Directive LuaHookCheckUserID

    + + + + + + + + +
    Description:Fournit un point d'entrée pour la phase check_user_id du +traitement de la requête
    Syntaxe:LuaHookCheckUserID /chemin/vers/lua/script.lua hook_function_name [early|late]
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    Compatibilité:Le troisième argument optionnel est disponible depuis la +version 2.3.15 du serveur HTTP Apache.

    ...

    +

    Ordonnancement

    Les arguments optionnels + "early" ou "late" permettent de contrôler le moment auquel ce script + s'exécute par rapport aux autres modules.

    +
    +
    top
    +

    Directive LuaHookFixups

    + + + + + + + +
    Description:Fournit un point d'entrée pour la phase de correction du +traitement de la requête
    Syntaxe:LuaHookFixups /chemin/vers/lua/script.lua hook_function_name
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua

    -Ce gestionnaire se contente d'afficher les arguments codés d'un uri ou -d'un formulaire dans un page au format texte. + Idem LuaHookTranslateName, mais s'exécute durant la phase de + correction.

    +
    +
    top
    +

    Directive LuaHookInsertFilter

    + + + + + + + +
    Description:Fournit un point d'entrée pour la phase insert_filter du +traitement de la requête
    Syntaxe:LuaHookInsertFilter /chemin/vers/lua/script.lua hook_function_name
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua

    Non encore implémenté

    +
    +
    top
    +

    Directive LuaHookLog

    + + + + + + + +
    Description:Permet une insertion dans la phase de journalisation du +traitement d'une requête
    Syntaxe:LuaHookLog /path/to/lua/script.lua log_function_name
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua

    -Cela signifie que vous pouvez (et êtes encouragé à) avoir plusieurs -gestionnaires (ou points d'entrée, ou filtres) dans le même script. + Ce dispositif d'insertion simple permet d'exécuter une fonction + lorsque httpd entre dans la phase de journalisation du traitement + d'une requête. Vous pouvez ainsi ajouter des données à vos propres + entrées de journalisation, manipuler les entrées du journal standard + avant leur enregistrement ou empêcher l'enregistrement d'une entrée + dans le journal. Pour empêcher l'enregistrement normal des entrées + du journal, renvoyez simplement apache2.DONE dans votre + gestionnaire de journalisation, ou au contraire, renvoyez + apache2.OK pour que httpd effectue une journalisation + normale.

    +

    Exemple :

    +
    LuaHookLog /path/to/script.lua logger
    -
    top
    -
    -

    Ecriture de fournisseurs d'autorisation

    - - -

    mod_authz_core fournit une interface d'autorisation -de haut niveau bien plus facile à utiliser que dans les hooks -correspondants. Le premier argument de la directive Require permet de spécifier le -fournisseur d'autorisation à utiliser. Pour chaque directive Require, -mod_authz_core appellera le fournisseur d'autorisation -spécifié, le reste de la ligne constituant les paramètres. Le -fournisseur considéré va alors vérifier les autorisations et fournir le -résultat dans une valeur de retour.

    - -

    En général, le fournisseur authz est appelé avant l'authentification. -S'il doit connaître le nom d'utilisateur authentifié (ou si -l'utilisateur est appelé à être authentifié), le fournisseur doit -renvoyer apache2.AUTHZ_DENIED_NO_USER, ce qui va -déclancher le processus d'authentification et un deuxième appel du -fournisseur authz.

    - -

    La fonction du fournisseur authz ci-dessous accepte deux arguments, -une adresse IP et un nom d'utilisateur. Elle autorise l'accès dans le -cas où la requête provient de l'adresse IP spécifiée, ou si -l'utilisateur authentifié correspond au second argument :

    - -
    -authz_provider.lua
    
-
-require 'apache2'
+
    -- /path/to/script.lua --
+function logger(r)
+    -- on joue à pile ou face :
+    -- Si on obtient 1, on écrit dans notre propre journal Lua et on dit
+    -- à httpd de ne pas enregistrer d'entrée dans le journal standard..
+    -- Si on obtient 2, on nettoie un peu les données avant que httpd ne
+    -- les enregistre dans le journal standard.
 
-function authz_check_foo(r, ip, user)
-    if r.useragent_ip == ip then
-        return apache2.AUTHZ_GRANTED
-    elseif r.user == nil then
-        return apache2.AUTHZ_DENIED_NO_USER
-    elseif r.user == user then
-        return apache2.AUTHZ_GRANTED
+    if math.random(1,2) == 1 then
+        -- On effectue notre propre journalisation et le journal
+	-- standard n'est pas alimenté
+        local f = io.open("/foo/secret.log", "a")
+        if f then
+            f:write("Quelque chose de secret est arrivé à " .. r.uri .. "\n")
+            f:close()
+        end
+        return apache2.DONE -- On dit à httpd de ne rien enregistrer
+			    --dans le journal standard
     else
-        return apache2.AUTHZ_DENIED
+        r.uri = r.uri:gsub("somesecretstuff", "") -- nettoie les données
+        return apache2.OK -- et httpd doit alors les enregistrer.
     end
 end
    
 
 
-
    La configuration suivante enregistre cette fonction en tant que
-fournisseur foo, et la configure por l'URL / :
    
-
    LuaAuthzProvider foo authz_provider.lua authz_check_foo
-<Location />
-  Require foo 10.1.2.3 john_doe
-</Location>
    
+
    +
    top
    +

    Directive LuaHookMapToStorage

    + + + + + + + +
    Description:Fournit un point d'entrée pour la phase map_to_storage du +traitement de la requête
    Syntaxe:LuaHookMapToStorage /chemin/vers/lua/script.lua hook_function_name
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    +

    Identique à la directive + LuaHookTranslateName, mais s'exécute à la + phase map-to-storage du traitement de la requête. Les modules comme + mod_cache agissent pendant cette phase, ce qui permet de présenter + un exemple intéressant de ce que l'on peut faire ici :

    + 
    LuaHookMapToStorage /path/to/lua/script.lua check_cache
    + 
    require"apache2"
+cached_files = {}
 
-
    top
    -
    -

    Ecriture de fonctions d'accroche -(hooks)

    +function read_file(filename) + local input = io.open(filename, "r") + if input then + local data = input:read("*a") + cached_files[filename] = data + file = cached_files[filename] + input:close() + end + return cached_files[filename] +end -

    Les fonctions d'accroche déterminent la manière dont les modules (et -les scripts Lua) participent au traitement des requêtes. Chaque type -d'accroche proposé par le serveur a un rôle spécifique, comme -l'association de requêtes au système de fichiers, le contrôle d'accès, -ou la définition de types MIME :

    +function check_cache(r) + if r.filename:match("%.png$") then -- Ne concerne que les fichiers PNG + local file = cached_files[r.filename] -- Vérifie les entrées du cache + if not file then + file = read_file(r.filename) -- Lit le fichier vers le cache + end + if file then -- Si le fichier existe, on l'envoie + r.status = 200 + r:write(file) + r:info(("%s a été envoyé au client depuis le cache"):format(r.filename)) + return apache2.DONE -- cout-circuite le gestionnaire par défaut des fichiers PNG + end + end + return apache2.DECLINED -- Si nous n'avons rien eu à faire, nous laissons les autres s'en charger +end - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Phase d'accrocheDirective mod_luaDescription
    Gestionnaire rapideLuaQuickHandlerIl s'agit de la première accroche appelée lorsqu'une requête - a été associée à un serveur ou un serveur virtuel.
    Phase de traductionLuaHookTranslateNameCette phase traduit l'URI de la requête en nom de fichier - sur le système. Ce sont des modules comme - mod_alias et mod_rewrite qui - interviennent au cours de cette phase.
    Choix du lieu de stockage de la ressourceLuaHookMapToStorageCette phase définit le lieu de stockage de la ressource : - physique, en cache ou externe/mandaté. Elle est assurée par les - modules de mandat ou de mise en cache.
    Autorisation d'accèsLuaHookAccessCheckerCette phase vérifie si un client a l'autorisation d'accès à - la ressource. Elle s'exécute avant l'authentification de - l'utisateur ; il faut donc être prudent. -
    Vérification de l'identifiant utilisateurLuaHookCheckUserIDCette phase vérifie l'identifiant de l'utilisateur ayant - fait l'objet d'une négociation.
    Vérification de l'autorisation d'accèsLuaHookAuthChecker - ou - LuaAuthzProviderCette phase vérifie l'autorisation d'accès d'un utilisateur - en fonction des ses paramètres de connexion, comme - l'identifiant, le certificat, etc... -
    Vérification du type de la ressourceLuaHookTypeCheckerCette phase assigne un type de contenu et un gestionnaire à - la ressource.
    Derniers réglagesLuaHookFixupsC'est la dernière phase avant l'activation des gestionnaires - de contenu. Toute modification de dernière minute à la requête - doit être effectuée ici.
    Gestionnaire de contenufichiers fx. .lua ou directive LuaMapHandlerC'est durant cette phase que le contenu est traité. Les - fichiers sont lus, interprétés, certains sont exécutés, et le - résultat obtenu est envoyé au client.
    JournalisationLuaHookLogLorsqu'une requête a été traitée, plusieurs phases de - journalisation interviennent, et enregistrent leurs résultats - dans les fichiers d'erreur ou d'accès. Mod_lua peut - s'intercaler au départ de ce processus et ainsi contrôler la - journalisation.
    -

    Les fonctions d'accroche reçoivent l'objet de la requête comme seul -argument (sauf LuaAuthzProvider qui reçoit aussi des arguments en -provenance de la directive Require). Elles peuvent renvoyer une valeur, -selon la fonction, mais il s'agit en général d'un -code d'état HTTP ou des valeurs OK, DONE, ou DECLINED, -que vous pouvez écrire dans Lua sous la forme apache2.OK, -apache2.DONE, ou apache2.DECLINED.

    + +
    +
    top
    +

    Directive LuaHookTranslateName

    + + + + + + + + +
    Description:Fournit un point d'entrée à la phase du nom de +traduction du traitement de la requête
    Syntaxe:LuaHookTranslateName /chemin/vers/lua/script.lua nom_fonction_hook [early|late]
    Contexte:configuration du serveur, serveur virtuel
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    Compatibilité:Le troisième argument optionnel est disponible depuis la +version 2.3.15 du serveur HTTP Apache.

    + Cette directive permet d'ajouter un point d'entrée (à + APR_HOOK_MIDDLE) à la phase du nom de traduction du traitement de la + requête. La fonction hook accepte un seul argument, le request_rec, + et doit renvoyer un code d'état qui est soit un code d'erreur HTTP, + ou une constante définie dans le module apache2 : apache2.OK, + apache2.DECLINED, ou apache2.DONE.

    + +

    Pour ceux qui ne sont pas familiers avec les points d'entrée + (hook), en gros, chaque hook sera invoqué jusqu'à ce que l'un + d'entre eux renvoie apache2.OK. Si un hook n'effectuer pas la + traduction, il doit juste renvoyer apache2.DECLINED. Si le + traitement de la requête doit être interrompu, la valeur renvoyée + doit être apache2.DONE.

    +

    Exemple :

    -
    -translate_name.lua
    
--- exemple d'accroche qui réécrit un URI en chemin du système de fichiers.
+
    # httpd.conf
+LuaHookTranslateName /scripts/conf/hooks.lua silly_mapper
    
 
-require 'apache2'
 
-function translate_name(r)
-    if r.uri == "/translate-name" then
-        r.filename = r.document_root .. "/find_me.txt"
+
    -- /scripts/conf/hooks.lua --
+require "apache2"
+function silly_mapper(r)
+    if r.uri == "/" then
+        r.filename = "/var/www/home.lua"
         return apache2.OK
+    else
+        return apache2.DECLINED
     end
-    -- on ne gère pas cette URL et on donne sa chance à un autre module
-    return apache2.DECLINED
 end
    
 
 
+   
    Contexte
    Cette directive ne peut être
+   utilisée ni à l'intérieur d'une section <Directory> ou <Files>, ni dans un fichier htaccess.
    
 
-
    -translate_name2.lua
    
---[[ exemple d'accroche qui réécrit un URI vers un autre URI. Il renvoie
-	un apache2.DECLINED pour permettre à un autre interpréteur d'URL de
-	travailler sur la substitution, y compris l'accroche translate_name
-	de base dont les tables de correspondances se basent sur DocumentRoot.
+   
    Ordonnancement
    Les arguments optionnels
+   "early" ou "late" permettent de contrôler le moment auquel ce script
+   s'exécute par rapport aux autres modules.
    
+
+
    +
    top
    +

    Directive LuaHookTypeChecker

    + + + + + + + +
    Description:Fournit un point d'entrée pour la phase type_checker du +traitement de la requête
    Syntaxe:LuaHookTypeChecker /chemin/vers/lua/script.lua hook_function_name
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua

    ...

    +
    +
    top
    +

    Directive LuaInherit

    + + + + + + + + + +
    Description:Contrôle la manière dont les sections de configuration +parentes sont fusionnées dans les enfants
    Syntaxe:LuaInherit none|parent-first|parent-last
    Défaut:LuaInherit parent-first
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    Compatibilité:Versions 2.4.0 et supérieures

    Par défaut, si des directives LuaHook* se trouvent dans + des sections de configuration Directory ou Location qui se + chevauchent, les scripts + définis dans les sections les plus spécifiques s'exécutent + après ceux définis dans les sections plus génériques + (LuaInherit parent-first). Vous pouvez inverser cet ordre, ou faire + en sorte que le contexte parent ne s'applique pas du tout.

    + +

    Jusqu'aux versions 2.3.x, le comportement par défaut consistait à + ignorer les directives LuaHook* situées dans les sections de + configuration parentes.

    +
    +
    top
    +

    Directive LuaInputFilter

    + + + + + + + +
    Description:Fournit une fonction Lua pour le filtrage en entrée
    Syntaxe:LuaInputFilter filter_name /path/to/lua/script.lua function_name
    Contexte:configuration du serveur
    Statut:Expérimental
    Module:mod_lua
    Compatibilité:Disponible depuis la version 2.4.5 du serveur HTTP +Apache
    +

    Cette directive permet d'ajouter un filtre en entrée sous la forme +d'une fonction Lua. A l'instar des filtres en sorties, les filtres en +entrée fonctionnent comme des sous-routines, intervenant dans un premier +temps avant l'envoi du contenu des tampons, puis chaque fois qu'un +paquet de données doit être transmis à la chaîne, et éventuellement +produisant toute donnée à ajouter aux données en entrée. La variable +globale bucket contient les paquets de données tels qu'ils +sont transmis au script Lua : +

    + +
    LuaInputFilter myInputFilter /www/filter.lua input_filter
+<Files *.lua>
+  SetInputFilter myInputFilter
+</Files>
    + +
    --[[
+    Exemple de filtre en entrée qui convertit toutes les données POST en
+    majuscules.
+]]--
+function input_filter(r)
+    print("luaInputFilter called") -- pour débogage
+    coroutine.yield() -- attend des paquets de données
+    while bucket do -- Pour chaque paquet, faire ...
+        local output = string.upper(bucket) -- Convertit toutes les données POST en majuscules
+        coroutine.yield(output) -- Envoie les données traitées à la chaîne de filtrage
+    end
+    -- plus aucune donnée à traiter.
+    coroutine.yield("&filterSignature=1234") -- Ajoute une signature à la fin
+end
    + +

    +Le filtre en entrée peut interdire ou sauter un filtre s'il est +considéré comme indésirable : +

    +
    function input_filter(r)
+    if not good then
+        return -- Empêche tout simplement le filtrage et transmet le contenu original
+    end
+    coroutine.yield() -- attend des paquets de données
+    ...               -- insert les filtres ici
+end
    + +

    +Voir "Modification de contenu avec les +filtres Lua" pour plus de détails. +

    + +
    +
    top
    +

    Directive LuaMapHandler

    + + + + + + + +
    Description:Met en correspondance un chemin avec un gestionnaire lua
    Syntaxe:LuaMapHandler modele-uri /chemin/vers/lua/script.lua +[nom-fonction]
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    +

    Cette directive permet de faire correspondre un modèle d'uri avec + une fonction de gestionnaire située dans un fichier spécifique. Elle + utilise les expressions rationnelles PCRE pour mettre en + correspondance l'uri, et supporte les groupes de correspondance + d'interpolation dans le chemin du fichier et le nom de la fonction. + Prenez garde aux problèmes de sécurité en écrivant vos expressions + rationnelles.

    +

    Exemples :

    LuaMapHandler /(\w+)/(\w+) /scripts/$1.lua handle_$2
    +
    +

    Cette directive va faire correspondre des uri comme + /photos/show?id=9 au fichier /scripts/photos.lua, et invoquera la + fonction de gestionnaire handle_show au niveau de la vm lua + après chargement de ce fichier.

    + +
    LuaMapHandler /bingo /scripts/wombat.lua
    + +

    Cette directive invoquera la fonction "handle" qui est la + valeur par défaut si aucun nom de fonction spécifique n'est + spécifié.

    + +
    +
    top
    +

    Directive LuaOutputFilter

    + + + + + + + +
    Description:Fournit une fonction Lua pour le filtrage de contenu en +sortie
    Syntaxe:LuaOutputFilter filter_name /path/to/lua/script.lua function_name
    Contexte:configuration du serveur
    Statut:Expérimental
    Module:mod_lua
    Compatibilité:Disponible à partir de la version 2.4.5 du serveur HTTP +Apache
    +

    >Cette directive permet d'ajouter un filtre en sortie sous la forme +d'une fonction Lua. A l'instar des filtres en sorties, les filtres en +entrée fonctionnent comme des sous-routines, intervenant dans un premier +temps avant l'envoi du contenu des tampons, puis chaque fois qu'un +paquet de données doit être transmis à la chaîne, et éventuellement +produisant toute donnée à ajouter aux données en sortie. La variable +globale bucket contient les paquets de données tels qu'ils +sont transmis au script Lua : +

    + +
    LuaOutputFilter myOutputFilter /www/filter.lua output_filter
+<Files *.lua>
+  SetOutputFilter myOutputFilter
+</Files>
    + +
    --[[
+    Exemple de filtre en sortie qui échappe toutes les entités HTML en
+    sortie
+]]--
+function output_filter(r)
+    coroutine.yield("(Handled by myOutputFilter)<br/>\n") -- Ajoute des données au début de la sortie,
+                                                                -- puis attend des paquets de données à traiter
+    while bucket do -- Pour chaque paquet, faire ...
+        local output = r:escape_html(bucket) -- Echappe les données en sortie
+        coroutine.yield(output) -- Envoie les données traitées à la chaîne
+    end
+    -- plus aucune donnée à traiter.
+end
    + +

    +Comme les filres en entrée, le filtre en sortie peut interdire ou sauter un filtre s'il est +considéré comme indésirable : +

    +
    function output_filter(r)
+    if not r.content_type:match("text/html") then
+        return -- Empêche tout simplement le filtrage et transmet le contenu original
+    end
+    coroutine.yield() -- attend des paquets de données
+    ...               -- insert les filtres ici
+end
    + +

    Les filtres Lua avec mod_filter

    +

    Lorsqu'on utilise un filtre Lua comme fournisseur sous-jacent via la +directive FilterProvider, le +filtrage ne fonctionnera que si filter-name est identique à +provider-name. +

    + +

    +Voir "Modification de contenu avec les +filtres Lua" pour plus de détails. +

    + + +
    +
    top
    +

    Directive LuaPackageCPath

    + + + + + + + +
    Description:Ajoute un répertoire au package.cpath de lua
    Syntaxe:LuaPackageCPath /chemin/vers/include/?.soa
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    +

    Cette directive permet d'ajouter un chemin à la liste des chemins + de recherche des bibliothèques partagées de lua. Ceci modifie le + package.cpath dans les vms lua.

    + + +
    +
    top
    +

    Directive LuaPackagePath

    + + + + + + + +
    Description:Ajoute un répertoire au package.path de lua
    Syntaxe:LuaPackagePath /chemin/vers/include/?.lua
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua

    Cette directive permet d'ajouter un chemin à la liste des + chemins de recherche du module lua. Elle suit les mêmes conventions + que lua. Ceci modifie le package.path dans les vms lua.

    + +

    Exemples :

    LuaPackagePath /scripts/lib/?.lua
+LuaPackagePath /scripts/lib/?/init.lua
    +
    + +
    +
    top
    +

    Directive LuaQuickHandler

    + + + + + + + +
    Description:Fournit un point d'entrée pour la gestion rapide du +traitement de la requête
    Syntaxe:LuaQuickHandler /path/to/script.lua hook_function_name
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    +

    Cette phase s'exécute juste après l'attribution de la requête à + un serveur virtuel, et permet d'effectuer certains traitements avant + le déroulement des autres phases, ou de servir une requête sans + avoir à la traduire, l'associer à un espace de stockage, etc... + Comme cette phase s'exécute avant toute autre, les directives telles + que <Location> ou + <Directory> ne + sont pas encore prises en compte, car Les URI n'ont pas encore été + entièrement interprétés. +

    +

    Contexte

    Cette directive ne peut être + utilisée ni à l'intérieur d'une section <Directory> ou <Files>, ni dans un fichier htaccess.

    + +
    +
    top
    +

    Directive LuaRoot

    + + + + + + + +
    Description:Spécifie le chemin de base pour la résolution des chemins +relatifs dans les directives de mod_lua
    Syntaxe:LuaRoot /chemin/vers/un/répertoire
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    +

    Cette directive permet de spécifier le chemin de base qui sera + utilisé pour évaluer tous les chemins relatifs dans mod_lua. En + l'absence de cette directive, les chemins relatifs sont résolus par + rapport au répertoire de travail courant, ce qui ne sera pas + toujours approprié pour un serveur.

    + +
    +
    top
    +

    Directive LuaScope

    + + + + + + + + +
    Description:Une valeur parmi once, request, conn, thread -- la valeur par défaut est once
    Syntaxe:LuaScope once|request|conn|thread|server [min] [max]
    Défaut:LuaScope once
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    +

    Cette directive permet de spécifier la durée de vie de + l'interpréteur Lua qui sera utilisé dans ce "répertoire". La valeur + par défaut est "once".

    + +
    +
    once:
    utilise l'interpréteur une fois.
    + +
    request:
    utilise l'interpréteur pour traiter tout ce + qui est basé sur le même fichier dans la requête, et qui se trouve + aussi dans la portée de la requête.
    + +
    conn:
    idem request, mais attaché à connection_rec
    + +
    thread:
    Utilise l'interpréteur pendant toute la durée + de vie du thread qui traite la requête (disponible seulement avec + les MPMs threadés).
    + +
    server:
    Le comportement est ici différent, car la + portée du serveur présente une durée de vie assez longue, et + plusieurs threads vont partager le même server_rec. Pour gérer tout + ceci, les états lua du serveur sont stockés dans une liste de ressources + apr. Les arguments min et max permettent + de spécifier les nombres minimaux et maximaux d'états lua à stocker + dans la liste.
    +
    +

    En général, les portées thread et server + sont 2 à 3 fois plus rapides que les autres, car elles n'ont pas besoin + de régénérer de nouveaux états Lua à chaque requête (comme c'est le + cas avec le MPM event, où même les connexions persistantes utilisent un + nouveau thread pour chaque requête). Si vous pensez que vos scripts + n'auront pas de problème s'il réutilisent un état, alors les portées + thread ou server doivent être utilisées car + elles présenteront de meilleures performances. Alors que la portée + thread fournira les réponses les plus rapides, la portée + server utilisera moins de mémoire car les états sont + rassemblés dans des jeux, permettant par exemple à 1000 threads de + partager 100 états Lua, ne nécessitant ainsi que 10% de la mémoire + requise par la portée thread. +

    + +
    +
    top
    +
    +

    Configuration de base

    + +

    La directive de base pour le chargement du module est

    + +
    LoadModule lua_module modules/mod_lua.so
    + + +

    +mod_lua fournit un gestionnaire nommé +lua-script qui peut être utilisé avec une directive +AddHandler ou SetHandler :

    + +
    <Files *.lua>
+    SetHandler lua-script
+</Files>
    + + +

    +Ceci aura pour effet de faire traiter les requêtes pour les fichiers +dont l'extension est .lua par mod_lua en +invoquant cette fonction de gestion de fichier. +

    + +

    Pour plus de détails, voir la directive +LuaMapHandler. +

    +
    top
    +
    +

    Ecrire des gestionnaires

    +

    Dans l'API du serveur HTTP Apache, un gestionnaire est une sorte de +point d'accroche (hook) spécifique responsable de la génération de la +réponse. mod_proxy, mod_cgi et +mod_status sont des exemples de modules comportant un +gestionnaire.

    + +

    mod_lua cherche toujours à invoquer une fonction Lua pour le +gestionnaire, plutôt que de simplement évaluer le corps d'un script dans +le style de CGI. Une fonction de gestionnaire se présente comme suit :

    + + +
    +example.lua
    
+-- exemple de gestionnaire
+
+require "string"
+
+--[[
+     Il s'agit du nom de méthode par défaut pour les gestionnaires Lua ;
+     voir les noms de fonctions optionnels dans la directive
+     LuaMapHandler pour choisir un point d'entrée différent.
+--]]
+function handle(r)
+    r.content_type = "text/plain"
+
+    if r.method == 'GET' then
+    	r:puts("Hello Lua World!\n")
+        for k, v in pairs( r:parseargs() ) do
+            r:puts( string.format("%s: %s\n", k, v) )
+        end
+    elseif r.method == 'POST' then
+    	r:puts("Hello Lua World!\n")
+        for k, v in pairs( r:parsebody() ) do
+            r:puts( string.format("%s: %s\n", k, v) )
+        end
+    else
+    elseif r.method == 'PUT' then
+-- message d'erreur personnalisé
+        r:puts("Unsupported HTTP method " .. r.method)
+	r.status = 405
+        return apache2.ok
+    else
+-- message d'erreur ErrorDocument
+        return 501
+    end
+    return apache2.OK
+end
    + + +

    +Ce gestionnaire se contente d'afficher les arguments codés d'un uri ou +d'un formulaire dans un page au format texte. +

    + +

    +Cela signifie que vous pouvez (et êtes encouragé à) avoir plusieurs +gestionnaires (ou points d'entrée, ou filtres) dans le même script. +

    + +
    top
    +
    +

    Ecriture de fournisseurs d'autorisation

    + + +

    mod_authz_core fournit une interface d'autorisation +de haut niveau bien plus facile à utiliser que dans les hooks +correspondants. Le premier argument de la directive Require permet de spécifier le +fournisseur d'autorisation à utiliser. Pour chaque directive Require, +mod_authz_core appellera le fournisseur d'autorisation +spécifié, le reste de la ligne constituant les paramètres. Le +fournisseur considéré va alors vérifier les autorisations et fournir le +résultat dans une valeur de retour.

    + +

    En général, le fournisseur authz est appelé avant l'authentification. +S'il doit connaître le nom d'utilisateur authentifié (ou si +l'utilisateur est appelé à être authentifié), le fournisseur doit +renvoyer apache2.AUTHZ_DENIED_NO_USER, ce qui va +déclancher le processus d'authentification et un deuxième appel du +fournisseur authz.

    + +

    La fonction du fournisseur authz ci-dessous accepte deux arguments, +une adresse IP et un nom d'utilisateur. Elle autorise l'accès dans le +cas où la requête provient de l'adresse IP spécifiée, ou si +l'utilisateur authentifié correspond au second argument :

    + +
    +authz_provider.lua
    
+
+require 'apache2'
+
+function authz_check_foo(r, ip, user)
+    if r.useragent_ip == ip then
+        return apache2.AUTHZ_GRANTED
+    elseif r.user == nil then
+        return apache2.AUTHZ_DENIED_NO_USER
+    elseif r.user == user then
+        return apache2.AUTHZ_GRANTED
+    else
+        return apache2.AUTHZ_DENIED
+    end
+end
    + + +

    La configuration suivante enregistre cette fonction en tant que +fournisseur foo, et la configure por l'URL / :

    +
    LuaAuthzProvider foo authz_provider.lua authz_check_foo
+<Location />
+  Require foo 10.1.2.3 john_doe
+</Location>
    + + +
    top
    +
    +

    Ecriture de fonctions d'accroche +(hooks)

    + +

    Les fonctions d'accroche déterminent la manière dont les modules (et +les scripts Lua) participent au traitement des requêtes. Chaque type +d'accroche proposé par le serveur a un rôle spécifique, comme +l'association de requêtes au système de fichiers, le contrôle d'accès, +ou la définition de types MIME :

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Phase d'accrocheDirective mod_luaDescription
    Gestionnaire rapideLuaQuickHandlerIl s'agit de la première accroche appelée lorsqu'une requête + a été associée à un serveur ou un serveur virtuel.
    Phase de traductionLuaHookTranslateNameCette phase traduit l'URI de la requête en nom de fichier + sur le système. Ce sont des modules comme + mod_alias et mod_rewrite qui + interviennent au cours de cette phase.
    Choix du lieu de stockage de la ressourceLuaHookMapToStorageCette phase définit le lieu de stockage de la ressource : + physique, en cache ou externe/mandaté. Elle est assurée par les + modules de mandat ou de mise en cache.
    Autorisation d'accèsLuaHookAccessCheckerCette phase vérifie si un client a l'autorisation d'accès à + la ressource. Elle s'exécute avant l'authentification de + l'utisateur ; il faut donc être prudent. +
    Vérification de l'identifiant utilisateurLuaHookCheckUserIDCette phase vérifie l'identifiant de l'utilisateur ayant + fait l'objet d'une négociation.
    Vérification de l'autorisation d'accèsLuaHookAuthChecker + ou + LuaAuthzProviderCette phase vérifie l'autorisation d'accès d'un utilisateur + en fonction des ses paramètres de connexion, comme + l'identifiant, le certificat, etc... +
    Vérification du type de la ressourceLuaHookTypeCheckerCette phase assigne un type de contenu et un gestionnaire à + la ressource.
    Derniers réglagesLuaHookFixupsC'est la dernière phase avant l'activation des gestionnaires + de contenu. Toute modification de dernière minute à la requête + doit être effectuée ici.
    Gestionnaire de contenufichiers fx. .lua ou directive LuaMapHandlerC'est durant cette phase que le contenu est traité. Les + fichiers sont lus, interprétés, certains sont exécutés, et le + résultat obtenu est envoyé au client.
    JournalisationLuaHookLogLorsqu'une requête a été traitée, plusieurs phases de + journalisation interviennent, et enregistrent leurs résultats + dans les fichiers d'erreur ou d'accès. Mod_lua peut + s'intercaler au départ de ce processus et ainsi contrôler la + journalisation.
    + +

    Les fonctions d'accroche reçoivent l'objet de la requête comme seul +argument (sauf LuaAuthzProvider qui reçoit aussi des arguments en +provenance de la directive Require). Elles peuvent renvoyer une valeur, +selon la fonction, mais il s'agit en général d'un +code d'état HTTP ou des valeurs OK, DONE, ou DECLINED, +que vous pouvez écrire dans Lua sous la forme apache2.OK, +apache2.DONE, ou apache2.DECLINED.

    + + +
    +translate_name.lua
    
+-- exemple d'accroche qui réécrit un URI en chemin du système de fichiers.
+
+require 'apache2'
+
+function translate_name(r)
+    if r.uri == "/translate-name" then
+        r.filename = r.document_root .. "/find_me.txt"
+        return apache2.OK
+    end
+    -- on ne gère pas cette URL et on donne sa chance à un autre module
+    return apache2.DECLINED
+end
    + + + +
    +translate_name2.lua
    
+--[[ exemple d'accroche qui réécrit un URI vers un autre URI. Il renvoie
+	un apache2.DECLINED pour permettre à un autre interpréteur d'URL de
+	travailler sur la substitution, y compris l'accroche translate_name
+	de base dont les tables de correspondances se basent sur DocumentRoot.
 
      Note: utilisez le drapeau early/late de la directive pour
      l'exécuter avant ou après mod_alias.
@@ -539,1458 +1203,794 @@ end
    hostname - string - non - Le nom d'hôte, tel que défini par l'en-tête - Host: ou par un URI complet. - - - is_https - boolean - non - Indique si la requête à été faite via HTTPS - - - is_initial_req - boolean - non - Indique si la requête courante est la requête initiale ou - une sous-requête. - - - limit_req_body - number - non - La taille maximale du corps de la requête, ou 0 si aucune - limite. - - - log_id - string - non - L'identifiant de la requête dans les journaux d'accès ou - d'erreur. - - - method - string - non - La méthode de la requête, par exemple GET ou - POST. - - - notes - table - oui - Une liste de notes qui peuvent être transmises d'un module - à l'autre. - - - options - string - non - La valeur de la directive Options pour la requête - courante. - - - path_info - string - non - La valeur de PATH_INFO extraite de la requête. - - - port - number - non - Le port du serveur utilisé par la requête. - - - protocol - string - non - Le protocole utilisé, par exemple HTTP/1.1 - - - proxyreq - string - oui - Indique s'il s'agit d'une requête mandatée ou non. Cette - valeur est en général définie au cours de la phase - post_read_request/translate_name du traitement de la requête. - - - range - string - non - Le contenu de l'en-tête Range:. - - - remaining - number - non - Le nombre d'octets du corps de la requête restant à lire. - - - server_built - string - non - La date de compilation du serveur. - - - server_name - string - non - Le nom du serveur pour cette requête. - - - some_auth_required - boolean + string non - Indique si une autorisation est/était requise pour cette - requête. + Le nom d'hôte, tel que défini par l'en-tête + Host: ou par un URI complet. - subprocess_env - table - oui - Le jeu de variables d'environnement pour cette requête. + is_https + boolean + non + Indique si la requête à été faite via HTTPS - started - number + is_initial_req + boolean non - Le moment où le serveur a été (re)démarré, en secondes - depuis epoch (1er janvier 1970) + Indique si la requête courante est la requête initiale ou + une sous-requête. - status + limit_req_body number - oui - Le code de retour (courant) pour cette requête, par - exemple 200 ou 404. + non + La taille maximale du corps de la requête, ou 0 si aucune + limite. - the_request + log_id string non - La chaîne de la requête telle qu'elle a été envoyée par le - client, par exemple GET /foo/bar HTTP/1.1. + L'identifiant de la requête dans les journaux d'accès ou + d'erreur. - unparsed_uri + method string non - La partie URI non interprétée de la requête + La méthode de la requête, par exemple GET ou + POST. - uri - string + notes + table oui - L'URI après interprétation par httpd + Une liste de notes qui peuvent être transmises d'un module + à l'autre. - user + options string - oui - Si une authentification a été effectuée, nom de - l'utilisateur authentifié. + non + La valeur de la directive Options pour la requête + courante. - useragent_ip + path_info string non - L'adresse IP de l'agent qui a envoyé la requête + La valeur de PATH_INFO extraite de la requête. - - - -
    top
    -
    -

    Méthodes de l'objet request_rec

    - -

    L'objet request_rec possède (au minimum) les méthodes suivantes :

    - -
    r:flush()   -- vide le tampon de sortie
-            -- Renvoie true si le vidage a été effectué avec succès,
-	    -- false dans le cas contraire.
-
-while nous_avons_des_données_à_envoyer do
-    r:puts("Bla bla bla\n") -- envoi des données à envoyer vers le tampon
-    r:flush() -- vidage du tampon (envoi au client)
-    r.usleep(500000) -- mise en attente pendant 0.5 secondes et bouclage
-end
    - - -
    r:addoutputfilter(name|function) -- ajoute un filtre en sortie
-
-r:addoutputfilter("fooFilter") -- insère le filtre fooFilter dans le flux de sortie
    - - -
    r:sendfile(filename) -- envoie un fichier entier au client en utilisant sendfile s'il est
-                     -- supporté par la plateforme :
-
-if use_sendfile_thing then
-    r:sendfile("/var/www/large_file.img")
-end
    - - -
    r:parseargs() -- renvoie deux tables : une table standard de couples
-              -- clé/valeur pour les données GET simples,
-              -- et une autre pour les données
-              -- multivaluées (par exemple foo=1&foo=2&foo=3) :
-
-local GET, GETMULTI = r:parseargs()
-r:puts("Votre nom est : " .. GET['name'] or "Unknown")
    - - - -
    r:parsebody()([sizeLimit]) -- interprète le corps de la
-                           -- requête en tant que POST et renvoie
-                           -- deux tables lua, comme r:parseargs(). Un
-                           -- nombre optionnel peut être fourni
-                           -- pour spécifier le nombre maximal
-                           -- d'octets à interpréter. La
-                           -- valeur par défaut est 8192.
-
-local POST, POSTMULTI = r:parsebody(1024*1024)
-r:puts("Votre nom est : " .. POST['name'] or "Unknown")
    - - - -
    r:puts("bonjour", " le monde", "!") -- affichage dans le corps de la réponse
    - - -
    r:write("une simple chaîne") -- affichage dans le corps de la réponse
    - - -
    r:escape_html("<html>test</html>") -- Echappe le code HTML et renvoie le résultat
    - - -
    r:base64_encode(string) -- Encode une chaîne à l'aide du standard de codage Base64.
-
-local encoded = r:base64_encode("This is a test") -- returns VGhpcyBpcyBhIHRlc3Q=
    - - -
    r:base64_decode(string) -- Décode une chaîne codée en Base64.
-
-local decoded = r:base64_decode("VGhpcyBpcyBhIHRlc3Q=") -- returns 'This is a test'
    - - -
    r:md5(string) -- Calcule et renvoie le condensé MD5 d'une chaîne en mode binaire (binary safe).
-
-local hash = r:md5("This is a test") -- returns ce114e4501d2f4e2dcea3e17b546f339
    - - -
    r:sha1(string) -- Calcule et renvoie le condensé SHA1 d'une chaîne en mode binaire (binary safe).
-
-local hash = r:sha1("This is a test") -- returns a54d88e06612d820bc3be72877c74f257b561b19
    - - -
    r:escape(string) -- Echappe une chaîne de type URL.
-
-local url = "http://foo.bar/1 2 3 & 4 + 5"
-local escaped = r:escape(url) -- renvoie 'http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5'
    - - -
    r:unescape(string) -- Déséchappe une chaîne de type URL.
-
-local url = "http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5"
-local unescaped = r:unescape(url) -- renvoie 'http://foo.bar/1 2 3 & 4 + 5'
    - - -
    r:construct_url(string) -- Construit une URL à partir d'un URI
-
-local url = r:construct_url(r.uri)
    - - -
    r.mpm_query(number) -- Interroge le serveur à propos de son module MPM via la requête ap_mpm_query.
-
-local mpm = r.mpm_query(14)
-if mpm == 1 then
-    r:puts("Ce serveur utilise le MPM Event")
-end
    - - -
    r:expr(string) -- Evalue une chaîne de type expr.
-
-if r:expr("%{HTTP_HOST} =~ /^www/") then
-    r:puts("Ce nom d'hôte commence par www")
-end
    - - -
    r:scoreboard_process(a) -- Interroge le serveur à propos du
-                        -- processus à la position a.
-
-local process = r:scoreboard_process(1)
-r:puts("Le serveur 1 a comme PID " .. process.pid)
    - - -
    r:scoreboard_worker(a, b) -- Interroge le serveur à propos du
-                          -- thread b, dans le processus a.
-
-local thread = r:scoreboard_worker(1, 1)
-r:puts("L'ID du thread 1 du serveur 1 est " .. thread.tid .. " et son
-état est " .. thread.status)
    - - -
    r:clock() -- Renvoie l'heure courante avec une précision d'une microseconde.
    - - -
    r:requestbody(filename) -- Lit et renvoie le corps d'une requête.
-                        -- Si 'filename' est spécifié, le
-                        -- corps de requête n'est pas
-                        -- renvoyé, mais sauvegardé dans
-                        -- le fichier correspondant.
-
-local input = r:requestbody()
-r:puts("Vous m'avez envoyé le corps de requête suivant :\n")
-r:puts(input)
    - - -
    r:add_input_filter(filter_name) -- Ajoute le filtre en entrée 'filter_name'.
    - - -
    r:module_info(module_name) -- Interroge le serveur à propos d'un module.
-
-local mod = r.module_info("mod_lua.c")
-if mod then
-    for k, v in pairs(mod.commands) do
-       r:puts( ("%s: %s\n"):format(k,v)) -- affiche toutes les directives
-                                         -- implémentées par ce module.
-    end
-end
    - - -
    r:loaded_modules() -- Renvoie une liste des modules chargés par httpd.
-
-for k, module in pairs(r:loaded_modules()) do
-    r:puts("J'ai chargé le module " .. module .. "\n")
-end
    - - -
    r:runtime_dir_relative(filename) -- Génère le nom d'un fichier run-time
-                                 -- (par exemple la mémoire partagée
-                                 -- "file") relativement au répertoire de run-time.
    - - -
    r:server_info() -- Renvoie une table contenant des informations à
-                -- propos du serveur, comme le nom de
-                -- l'exécutable httpd, le module mpm utilisé, etc...
    - - -
    r:set_document_root(file_path) -- Définit la racine des documents
-                               -- pour la requête à file_path.
    - - -
    r:add_version_component(component_string) -- Ajoute un élément à
-                                          -- la bannière du serveur.
    - - -
    r:set_context_info(prefix, docroot) -- Définit le préfixe et la
-                                    -- racine des documents du contexte pour une requête.
    - - -
    r:os_escape_path(file_path) -- Convertit un chemin du système de
-                            -- fichiers en URL indépendamment du système d'exploitation.
    - - -
    r:escape_logitem(string) -- Echappe une chaîne pour journalisation.
    + + port + number + non + Le port du serveur utilisé par la requête. + + + protocol + string + non + Le protocole utilisé, par exemple HTTP/1.1 + + + proxyreq + string + oui + Indique s'il s'agit d'une requête mandatée ou non. Cette + valeur est en général définie au cours de la phase + post_read_request/translate_name du traitement de la requête. + + + range + string + non + Le contenu de l'en-tête Range:. + + + remaining + number + non + Le nombre d'octets du corps de la requête restant à lire. + + + server_built + string + non + La date de compilation du serveur. + + + server_name + string + non + Le nom du serveur pour cette requête. + + + some_auth_required + boolean + non + Indique si une autorisation est/était requise pour cette + requête. + + + subprocess_env + table + oui + Le jeu de variables d'environnement pour cette requête. + + + started + number + non + Le moment où le serveur a été (re)démarré, en secondes + depuis epoch (1er janvier 1970) + + + status + number + oui + Le code de retour (courant) pour cette requête, par + exemple 200 ou 404. + + + the_request + string + non + La chaîne de la requête telle qu'elle a été envoyée par le + client, par exemple GET /foo/bar HTTP/1.1. + + + unparsed_uri + string + non + La partie URI non interprétée de la requête + + + uri + string + oui + L'URI après interprétation par httpd + + + user + string + oui + Si une authentification a été effectuée, nom de + l'utilisateur authentifié. + + + useragent_ip + string + non + L'adresse IP de l'agent qui a envoyé la requête + + + + +
    top
    +
    +

    Méthodes de l'objet request_rec

    +

    L'objet request_rec possède (au minimum) les méthodes suivantes :

    -
    r.strcmp_match(string, pattern) -- Vérifie si 'string' correspond à
-                                -- 'pattern' via la fonction strcmp_match (GLOBs). Par exemple, est-ce que
-                                -- 'www.example.com' correspond à '*.example.com' ?
+
    r:flush()   -- vide le tampon de sortie
+            -- Renvoie true si le vidage a été effectué avec succès,
+	    -- false dans le cas contraire.
 
-local match = r.strcmp_match("foobar.com", "foo*.com")
-if match then 
-    r:puts("foobar.com matches foo*.com")
+while nous_avons_des_données_à_envoyer do
+    r:puts("Bla bla bla\n") -- envoi des données à envoyer vers le tampon
+    r:flush() -- vidage du tampon (envoi au client)
+    r.usleep(500000) -- mise en attente pendant 0.5 secondes et bouclage
 end
    
 
 
-
    r:set_keepalive() -- Définit l'état de persistance d'une requête.
-                  -- Renvoie true dans la mesure du possible, false dans le cas contraire.
    
-
-
-
    r:make_etag() -- Génère et renvoie le etag pour la requête courante.
    
-
-
-
    r:send_interim_response(clear) -- Renvoie une réponse d'intérim (1xx) au
-                               -- client. Si 'clear' est vrai, les en-têtes disponibles
-                               -- seront envoyés et effacés.
    
-
-
-
    r:custom_response(status_code, string) -- Génère et définit une réponse
-                                       -- personnalisée pour un code d'état particulier.
-                                       -- Le fonctionnement est très proche de celui de la directive ErrorDocument.
-
-r:custom_response(404, "Baleted!")
    
-
-
-
    r.exists_config_define(string) -- Vérifie si une définition de configuration existe.
-
-if r.exists_config_define("FOO") then
-    r:puts("httpd a probablement été lancé avec l'option -DFOO, ou FOO a
-    été défini dans la configuration")
-end
    
-
+
    r:addoutputfilter(name|function) -- ajoute un filtre en sortie
 
-
    r:state_query(string) -- Interroge le serveur à propos de son état.
    
+r:addoutputfilter("fooFilter") -- insère le filtre fooFilter dans le flux de sortie
    
 
 
-
    r:stat(filename [,wanted]) -- Exécute stat() sur un fichier, et renvoie une table contenant
-                           -- des informations à propos de ce fichier.
+
    r:sendfile(filename) -- envoie un fichier entier au client en utilisant sendfile s'il est
+                     -- supporté par la plateforme :
 
-local info = r:stat("/var/www/foo.txt")
-if info then
-    r:puts("Ce fichier existe et a été modifié pour la dernière fois à : " .. info.modified)
+if use_sendfile_thing then
+    r:sendfile("/var/www/large_file.img")
 end
    
 
 
-
    r:regex(string, pattern [,flags]) -- Exécute une recherche à base d'expression rationnelle
-                                  -- sur une chaîne, et renvoie les éventuelles correspondances trouvées.
-
-local matches = r:regex("foo bar baz", [[foo (\w+) (\S*)]])
-if matches then
-    r:puts("L'expression rationnelle correspond et le dernier mot
-    capturé ($2) est : " .. matches[2])
-end
-
--- Exemple avec insensibilité à la casse :
-local matches = r:regex("FOO bar BAz", [[(foo) bar]], 1)
-
--- les drapeaux peuvent être une combibaison bit à bit de :
--- 0x01: insensibilité à la casse
--- 0x02: recherche multiligne
    
-
-
-
    r.usleep(microsecondes) -- Interrompt l'exécution du script pendant le nombre de microsecondes spécifié.
    
-
-
-
    r:dbacquire(dbType[, dbParams]) -- Acquiert une connexion à une base de données et renvoie une classe database.
-                                -- Voir 'Connectivité aux bases de données'
-				-- pour plus de détails.
    
-
-
-
    r:ivm_set("key", value) -- Défini une variable Inter-VM avec une valeur spécifique.
-                        -- Ces valeurs sont conservées même si la VM est
-			-- arrêtée ou non utilisée, et ne doivent donc être
-			-- utilisées que si MaxConnectionsPerChild > 0.
-			-- Les valeurs peuvent être de type number, string
-			-- ou boolean et sont stockées séparément pour
-			-- chaque processus (elles ne seront donc pas d'une
-			-- grande utilité si l'on utilise le mpm prefork).
-                        
-r:ivm_get("key")        -- Lit le contenu d'une variable définie via ivm_set. Renvoie
-			-- le contenu de la variable si elle existe, ou nil
-			-- dans le cas contraire.
-                        
--- Voici un exemple de lecture/écriture qui sauvegarde une variable
--- globale en dehors de la VM :
-function handle(r)
-    -- La première VM qui effectue l'appel suivant n'obtiendra aucune
-    -- valeur, et devra la créer
-    local foo = r:ivm_get("cached_data")
-    if not foo then
-        foo = do_some_calcs() -- simulation de valeurs de retour
-        r:ivm_set("cached_data", foo) -- définition globale de la variable
-    end
-    r:puts("La donnée en cache est : ", foo)
-end
    
-
-
    r:htpassword(string [,algorithm [,cost]]) -- Génère un hash de mot de passe à partir d'une chaîne.
-                                          -- algorithm: 0 = APMD5 (défaut), 1 = SHA, 2 = BCRYPT, 3 = CRYPT.
-                                          -- cost: ne s'utilise qu'avec l'algorythme BCRYPT (défaut = 5).
    
+
    r:parseargs() -- renvoie deux tables : une table standard de couples
+              -- clé/valeur pour les données GET simples,
+              -- et une autre pour les données
+              -- multivaluées (par exemple foo=1&foo=2&foo=3) :
 
+local GET, GETMULTI = r:parseargs()
+r:puts("Votre nom est : " .. GET['name'] or "Unknown")
    
 
-
    r:mkdir(dir [,mode]) -- Crée un répertoire et définit son mode via le paramètre optionnel mode.
    
 
 
-
    r:mkrdir(dir [,mode]) -- Crée des répertoires de manière récursive et définit
-                      -- leur mode via le paramètre optionnel mode.
    
+
    r:parsebody()([sizeLimit]) -- interprète le corps de la
+                           -- requête en tant que POST et renvoie
+                           -- deux tables lua, comme r:parseargs(). Un
+                           -- nombre optionnel peut être fourni
+                           -- pour spécifier le nombre maximal
+                           -- d'octets à interpréter. La
+                           -- valeur par défaut est 8192.
 
+local POST, POSTMULTI = r:parsebody(1024*1024)
+r:puts("Votre nom est : " .. POST['name'] or "Unknown")
    
 
-
    r:rmdir(dir) -- Supprime un répertoire.
    
 
 
-
    r:touch(file [,mtime]) -- Définit la date de modification d'un fichier à la date courante ou à
-                       -- la valeur optionnelle mtime en msec.
    
+
    r:puts("bonjour", " le monde", "!") -- affichage dans le corps de la réponse
    
 
 
-
    r:get_direntries(dir) -- Renvoie une table contenant toutes les entrées de répertoires.
+
    r:write("une simple chaîne") -- affichage dans le corps de la réponse
    
 
--- Renvoie un chemin sous forme éclatée en chemin, fichier, extension
-function handle(r)
-  local dir = r.context_document_root
-  for _, f in ipairs(r:get_direntries(dir)) do
-    local info = r:stat(dir .. "/" .. f)
-    if info then
-      local mtime = os.date(fmt, info.mtime / 1000000)
-      local ftype = (info.filetype == 2) and "[dir] " or "[file]"
-      r:puts( ("%s %s %10i %s\n"):format(ftype, mtime, info.size, f) )
-    end
-  end
-end
    
 
+
    r:escape_html("<html>test</html>") -- Echappe le code HTML et renvoie le résultat
    
 
-
    r.date_parse_rfc(string) -- Interprète une chaîne date/heure et renvoie l'équivalent en secondes depuis epoche.
    
 
+
    r:base64_encode(string) -- Encode une chaîne à l'aide du standard de codage Base64.
 
-
    r:getcookie(key) -- Obtient un cookie HTTP
    
+local encoded = r:base64_encode("This is a test") -- returns VGhpcyBpcyBhIHRlc3Q=
    
 
 
-
    r:setcookie(key, value, secure, expires) -- Définit un cookie HTTP, par exemple :
-r:setcookie("foo", "bar and stuff", false, os.time() + 86400)
    
+
    r:base64_decode(string) -- Décode une chaîne codée en Base64.
 
+local decoded = r:base64_decode("VGhpcyBpcyBhIHRlc3Q=") -- returns 'This is a test'
    
 
-
    r:wsupgrade() -- Met à jour une connexion vers les WebSockets si possible (et si demandé) :
-if r:wsupgrade() then -- si la mise à jour est possible :
-    r:wswrite("Bienvenue dans les websockets!") -- écrit quelque chose à l'intention du client
-    r:wsclose()  -- Au revoir !
-end
    
 
+
    r:md5(string) -- Calcule et renvoie le condensé MD5 d'une chaîne en mode binaire (binary safe).
 
-
    r:wsread() -- Lit un cadre de websocket depuis une connexion vers websocket mise à jour (voir ci-dessus) :
-           
-local line, isFinal = r:wsread() -- isFinal indique s'il s'agit du cadre final.
-                                 -- dans le cas contraire, on peut lire les cadres suivants
-r:wswrite("Vous avez écrit : " .. line)
    
+local hash = r:md5("This is a test") -- returns ce114e4501d2f4e2dcea3e17b546f339
    
 
 
-
    r:wswrite(line) -- écrit un cadre vers un client WebSocket :
-r:wswrite("Bonjour le Monde !")
    
+
    r:sha1(string) -- Calcule et renvoie le condensé SHA1 d'une chaîne en mode binaire (binary safe).
 
+local hash = r:sha1("This is a test") -- returns a54d88e06612d820bc3be72877c74f257b561b19
    
 
-
    r:wsclose() -- ferme une requête WebSocket et l'achève pour httpd :
 
-if r:wsupgrade() then
-    r:wswrite("Ecrire quelque chose : ")
-    local line = r:wsread() or "nothing"
-    r:wswrite("Vous avez écrit : " .. line);
-    r:wswrite("Au revoir !")
-    r:wsclose()
-end
    
+
    r:escape(string) -- Echappe une chaîne de type URL.
 
-
    top
    -
    -

    Fonctions de journalisation

    +local url = "http://foo.bar/1 2 3 & 4 + 5" +local escaped = r:escape(url) -- renvoie 'http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5' -
    	-- exemples de messages de journalisation
-	r:trace1("Ceci est un message de journalisation de niveau
-	trace") -- les niveaux valides vont de trace1 à trace8 
    
-        r:debug("Ceci est un message de journalisation de niveau debug")
    
-        r:info("Ceci est un message de journalisation de niveau info")
    
-        r:notice("Ceci est un message de journalisation de niveau notice")
    
-        r:warn("Ceci est un message de journalisation de niveau warn")
    
-        r:err("Ceci est un message de journalisation de niveau err")
    
-        r:alert("Ceci est un message de journalisation de niveau alert")
    
-        r:crit("Ceci est un message de journalisation de niveau crit")
    
-        r:emerg("Ceci est un message de journalisation de niveau emerg")
    
-
    +
    r:unescape(string) -- Déséchappe une chaîne de type URL.
 
-
    top
    -
    -

    Paquet apache2

    -

    Le paquet nommé apache2 est fourni avec (au minimum) le -contenu suivant :

    -
    -
    apache2.OK
    -
    Constante interne OK. Les gestionnaires renverront cette valeur - s'ils ont traité la requête.
    -
    apache2.DECLINED
    -
    Constante interne DECLINED. Les gestionnaires renverront cette - valeur s'ils n'ont pas l'intention de traiter la requête.
    -
    apache2.DONE
    -
    Constante interne DONE.
    -
    apache2.version
    -
    Chaîne contenant la version du serveur HTTP Apache
    -
    apache2.HTTP_MOVED_TEMPORARILY
    -
    Code d'état HTTP
    -
    apache2.PROXYREQ_NONE, apache2.PROXYREQ_PROXY, apache2.PROXYREQ_REVERSE, apache2.PROXYREQ_RESPONSE
    -
    Constantes internes utilisées par mod_proxy
    -
    apache2.AUTHZ_DENIED, apache2.AUTHZ_GRANTED, apache2.AUTHZ_NEUTRAL, apache2.AUTHZ_GENERAL_ERROR, apache2.AUTHZ_DENIED_NO_USER
    -
    constantes internes utilisées par mod_authz_core
    +local url = "http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5" +local unescaped = r:unescape(url) -- renvoie 'http://foo.bar/1 2 3 & 4 + 5' -
    -

    Les autres codes d'état HTTP ne sont pas encore implémentés.

    -
    top
    -
    -

    Modification de contenu avec les filtres lua

    - -

    - Les fonctions de filtrage implémentées via les directives LuaInputFilter ou LuaOutputFilter sont conçues comme des - fonctions de 3ème phase non blocantes utilisant des sous-routines - pour suspendre et reprendre l'exécution d'une fonction lorsque des - paquets de données sont envoyés à la chaîne de filtrage. La - structure de base d'une telle fonction est : -

    - 
    function filter(r)
-    -- Nous indiquons tout d'abord que nous sommes prêts à recevoir des
-    -- blocs de données.
-    -- Avant ceci, nous pouvons définir notre environnement, tester
-    -- certaines conditions, et, si nous le jugeons nécessaire, refuser le
-    -- filtrage d'une requête :
-    if something_bad then
-        return -- Le filtrage est sauté
-    end
-    -- Sans se préoccuper des données que nous devons éventuellement ajouter, un arrêt est réalisé ici.
-    -- Noter que les filtres de sortie sont les seuls capables d'ajouter des éléments au début des données.
-    -- Les filtres en entrée peuvent ajouter des éléments à la fin des données au stade final.
 
-    coroutine.yield([optional header to be prepended to the content])
+
    r:construct_url(string) -- Construit une URL à partir d'un URI
 
-    -- Après cet arrêt, nous allons recevoir d'autres blocs de données, un par un ;
-    -- nous pouvons les traiter comme il nous plaît et procéder à la réponse.
-    -- Ces blocs sont conservés dans la variable globale 'bucket', nous réalisons donc
-    -- une boucle pour vérifier que 'bucket' n'est pas vide :
-    while bucket ~= nil do
-        local output = mangle(bucket) -- Do some stuff to the content
-        coroutine.yield(output) -- Return our new content to the filter chain
-    end
+local url = r:construct_url(r.uri)
    
 
-    -- Une fois les blocs de données épuisés, 'bucket' est positionné à une valeur vide ('nil'),
-    -- ce qui va nous faire sortir de cette boucle et nous amener à l'étape suivante.
-    -- On peut ajouter ce qu'on veut à la fin des données à cette étape, qui constitue le dernier
-    -- arrêt. Les filtres d'entrée comme de sortie peuvent servir à ajouter des éléments à la fin
-    --  des données à cette étape.
-    coroutine.yield([optional footer to be appended to the content])
-end
    -
    top
    -
    -

    Connectivité aux bases de données

    - -

    Mod_lua implémente une fonctionnalité basique de connexion aux -bases de données permettant d'envoyer des requêtes ou d'exécuter des -commandes auprès des moteurs de base de données les plus courants -(mySQL, PostgreSQL, FreeTDS, ODBC, SQLite, Oracle), ainsi que mod_dbd. -

    -

    L'exemple suivant montre comment se connecter à une base de -données et extraire des informations d'une table :

    - 
    function handle(r)
-    -- connexion à la base de données
-    local database, err = r:dbacquire("mysql", "server=localhost,user=someuser,pass=somepass,dbname=mydb")
-    if not err then
-        -- Sélection de certaines informations
-        local results, err = database:select(r, "SELECT `name`, `age` FROM `people` WHERE 1")
-        if not err then
-            local rows = results(0) -- extrait tous les enregistrements en mode synchrone
-            for k, row in pairs(rows) do
-                r:puts( string.format("Name: %s, Age: %s<br/>", row[1], row[2]) )
-            end
-        else
-            r:puts("Database query error: " .. err)
-        end
-        database:close()
-    else
-        r:puts("Connexion à la base de données impossible : " .. err)
-    end
+
    r.mpm_query(number) -- Interroge le serveur à propos de son module MPM via la requête ap_mpm_query.
+
+local mpm = r.mpm_query(14)
+if mpm == 1 then
+    r:puts("Ce serveur utilise le MPM Event")
 end
    
 
-    
    
-    Pour utiliser mod_dbd, spécifiez
-mod_dbd comme type de base de données, ou laissez le champ
-vide :
-    
    
-    
    local database = r:dbacquire("mod_dbd")
    
 
-    
    L'objet database et ses méthodes
    
-        
-        
    L'objet database renvoyé par dbacquire possède
-les méthodes suivantes :
    
-        
    Sélection normale et requête vers une base de données
-:
    
-    
    -- Exécution d'une requête et renvoie du nombre d'enregistrements
-affectés :
-local affected, errmsg = database:query(r, "DELETE FROM `tbl` WHERE 1")
+
    r:expr(string) -- Evalue une chaîne de type expr.
 
--- Exécution d'une requête et renvoie du résultat qui peut être utilisé
-en mode synchrone ou asynchrone :
-local result, errmsg = database:select(r, "SELECT * FROM `people` WHERE 1")
    
+if r:expr("%{HTTP_HOST} =~ /^www/") then
+    r:puts("Ce nom d'hôte commence par www")
+end
    
 
-        
    Utilisation de requêtes préparées (recommandé) :
    
-    
    -- Création et exécution d'une requête préparée :
-local statement, errmsg = database:prepare(r, "DELETE FROM `tbl` WHERE `age` > %u")
-if not errmsg then
-    local result, errmsg = statement:query(20) -- exécute la requête pour age > 20
-end
 
--- Extrait une requête préparée depuis une directive DBDPrepareSQL :
-local statement, errmsg = database:prepared(r, "someTag")
-if not errmsg then
-    local result, errmsg = statement:select("John Doe", 123) -- injecte les valeurs "John Doe" et 123 dans la requête
-end
    
+
    r:scoreboard_process(a) -- Interroge le serveur à propos du
+                        -- processus à la position a.
 
-        
    Echappement de valeurs, fermeture de la base données,
-etc...
    
-    
    -- Echappe une valeur pour pouvoir l'utiliser dans une requête :
-local escaped = database:escape(r, [["'|blabla]])
+local process = r:scoreboard_process(1)
+r:puts("Le serveur 1 a comme PID " .. process.pid)
    
 
--- Ferme une base de données et libère les liens vers cette dernière :
-database:close()
 
--- Vérifie si une connexion à une base de données est en service et
-opérationnelle :
-local connected = database:active()
    
+
    r:scoreboard_worker(a, b) -- Interroge le serveur à propos du
+                          -- thread b, dans le processus a.
 
-    
-    
    Travail avec les jeux d'enregistrements renvoyés par les requêtes
    
-    
-    
    Les jeux d'enregistrements renvoyés par db:select ou par des
-requêtes préparées créées par db:prepare permettent de
-sélectionner des enregistrements en mode synchrone ou
-asynchrone, selon le nombre d'enregistrements spécifié :
    
-    result(0) sélectionne tous les enregistrements en mode
-synchrone en renvoyant une table d'enregistrements.
    
-    result(-1) sélectionne le prochain enregistrement disponible en
-mode asynchrone.
    
-    result(N) sélectionne l'enregistrement numéro
-N en mode asynchrone.
-    
    
-    
    -- extrait un jeu d'enregistrements via une requête régulière :
-local result, err = db:select(r, "SELECT * FROM `tbl` WHERE 1")
+local thread = r:scoreboard_worker(1, 1)
+r:puts("L'ID du thread 1 du serveur 1 est " .. thread.tid .. " et son
+état est " .. thread.status)
    
 
-local rows = result(0) -- sélectionne tous les enregistrements en mode synchrone
-local row = result(-1) -- sélectionne le prochain enregistrement disponible en mode asynchrone
-local row = result(1234) -- sélectionne l'enregistrement 1234 en mode asynchrone
-local row = result(-1, true) -- Lit l'enregistrement suivant en utilisant les noms d'enregistrements comme index.
    
 
-    
    Il est possible de construire une fonction qui renvoie une
-fonction itérative permettant de traiter tous les enregistrement en mode
-synchrone ou asynchrone selon la valeur de l'argument async :
-    
    
-    
    function rows(resultset, async)
-    local a = 0
-    local function getnext()
-        a = a + 1
-        local row = resultset(-1)
-        return row and a or nil, row
-    end
-    if not async then
-        return pairs(resultset(0))
-    else
-        return getnext, self
-    end
-end
+
    r:clock() -- Renvoie l'heure courante avec une précision d'une microseconde.
    
 
-local statement, err = db:prepare(r, "SELECT * FROM `tbl` WHERE `age` > %u")
-if not err then
-     -- sélectionne des enregistrements en mode asynchrone :
-    local result, err = statement:select(20)
-    if not err then
-        for index, row in rows(result, true) do
-            ....
-        end
-    end
 
-     -- sélectionne des enregistrements en mode synchrone :
-    local result, err = statement:select(20)
-    if not err then
-        for index, row in rows(result, false) do
-            ....
-        end
-    end
-end
    
+
    r:requestbody(filename) -- Lit et renvoie le corps d'une requête.
+                        -- Si 'filename' est spécifié, le
+                        -- corps de requête n'est pas
+                        -- renvoyé, mais sauvegardé dans
+                        -- le fichier correspondant.
 
-    
-    
    Fermeture d'une connexion à une base de données
    
-        
+local input = r:requestbody()
+r:puts("Vous m'avez envoyé le corps de requête suivant :\n")
+r:puts(input)
    
 
-    
    Lorsqu'elles ne sont plus utilisées, les connexions aux bases de
-données doivent être fermées avec database:close(). Si vous
-ne les fermez pas manuellement, mod_lua les fermera peut-être en tant
-que résidus collectés, mais si ce n'est pas le cas, vous pouvez finir
-pas avoir trop de connexions vers la base de données inutilisées. Les
-deux mesures suivantes sont pratiquement identiques :
-    
    
-    
    -- Méthode 1 : fermeture manuelle de la connexion
-local database = r:dbacquire("mod_dbd")
-database:close() -- c'est tout
 
--- Méthode 2 : on laisse le collecteur de résidus la fermer
-local database = r:dbacquire("mod_dbd")
-database = nil -- on coupe le lien
-collectgarbage() -- fermeture de la connexion par le collecteur de résidus
    
+
    r:add_input_filter(filter_name) -- Ajoute le filtre en entrée 'filter_name'.
    
 
-    
-    
    Précautions à prendre lorsque l'on travaille avec les bases
-de données
    
-    
-    
    Bien que les fonctions query et run
-soient toujours disponibles, il est recommandé d'utiliser des requêtes
-préparées chaque fois que possible, afin d'une part d'optimiser les
-performances (si votre connexion reste longtemps en vie), et d'autre part
-minimiser le risque d'attaques par injection SQL. Les fonctions
-run et query ne doivent être utilisées que
-lorsque la requête ne contient pas de variables (requête statique). Dans
-le cas des requêtes dynamiques, utilisez db:prepare ou
-db:prepared.
-    
    
-    
 
-
    -
    top
    -

    Directive LuaAuthzProvider

    - - - - - - - -
    Description:Branche une fonction fournisseur d'autorisation dans mod_authz_core -
    Syntaxe:LuaAuthzProvider provider_name /path/to/lua/script.lua function_name
    Contexte:configuration du serveur
    Statut:Expérimental
    Module:mod_lua
    Compatibilité:Disponible depuis la version 2.4.3 du serveur HTTP Apache
    -

    Lorsqu'une fonction lua a été enregistrée en tant que fournisseur -d'autorisation, elle peut être appelée via la directive Require :

    +
    r:module_info(module_name) -- Interroge le serveur à propos d'un module.
 
+local mod = r.module_info("mod_lua.c")
+if mod then
+    for k, v in pairs(mod.commands) do
+       r:puts( ("%s: %s\n"):format(k,v)) -- affiche toutes les directives
+                                         -- implémentées par ce module.
+    end
+end
    -
    LuaRoot /usr/local/apache2/lua
-LuaAuthzProvider foo authz.lua authz_check_foo
-<Location />
-  Require foo johndoe
-</Location>
    -
    require "apache2"
-function authz_check_foo(r, who)
-    if r.user ~= who then return apache2.AUTHZ_DENIED
-    return apache2.AUTHZ_GRANTED
-end
    +
    r:loaded_modules() -- Renvoie une liste des modules chargés par httpd.
 
+for k, module in pairs(r:loaded_modules()) do
+    r:puts("J'ai chargé le module " .. module .. "\n")
+end
    -
    -
    top
    -

    Directive LuaCodeCache

    - - - - - - - - -
    Description:Configure le cache de code compilé.
    Syntaxe:LuaCodeCache stat|forever|never
    Défaut:LuaCodeCache stat
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua

    - Cette directive permet de définir le comportement du cache de code - en mémoire. La valeur par défaut est stat ; dans ce cas, le script - du niveau le plus haut (et pas les scripts inclus) est vérifié à - chaque fois que ce fichier est nécessaire, et est rechargé si la - date de modification est plus récente que celle du script déjà - chargé. Les autres valeurs permettent respectivement de garder le - fichier en cache perpétuellement (forever - jamais vérifié ni - remplacé), ou de ne jamais le mettre en cache (never).

    +
    r:runtime_dir_relative(filename) -- Génère le nom d'un fichier run-time
+                                 -- (par exemple la mémoire partagée
+                                 -- "file") relativement au répertoire de run-time.
    -

    En général, les valeurs stat et forever sont utilisées pour un - serveur en production, et les valeurs stat ou never pour un serveur - en développement.

    -

    Exemples :

    LuaCodeCache stat
-LuaCodeCache forever
-LuaCodeCache never
    -
    +
    r:server_info() -- Renvoie une table contenant des informations à
+                -- propos du serveur, comme le nom de
+                -- l'exécutable httpd, le module mpm utilisé, etc...
    -
    -
    top
    -

    Directive LuaHookAccessChecker

    - - - - - - - - -
    Description:Fournit un point d'entrée pour la phase access_checker du -traitement de la requête
    Syntaxe:LuaHookAccessChecker /chemin/vers/lua/script.lua hook_function_name [early|late]
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    Compatibilité:Le troisième argument optionnel est disponible depuis la -version 2.3.15 du serveur HTTP Apache.
    -

    Ajoute votre fonction d'accroche à la phase access_checker. Une -fonction d'accroche access checker renvoie en général OK, DECLINED, ou -HTTP_FORBIDDEN.

    -

    Ordonnancement

    Les arguments optionnels - "early" ou "late" permettent de contrôler le moment auquel ce script - s'exécute par rapport aux autres modules.

    +
    r:set_document_root(file_path) -- Définit la racine des documents
+                               -- pour la requête à file_path.
    -
    -
    top
    -

    Directive LuaHookAuthChecker

    - - - - - - - - -
    Description:Fournit un point d'entrée pour la phase auth_checker du -traitement de la requête
    Syntaxe:LuaHookAuthChecker /chemin/vers/lua/script.lua hook_function_name [early|late]
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    Compatibilité:Le troisième argument optionnel est disponible depuis la -version 2.3.15 du serveur HTTP Apache.
    -

    Invoque une fonction lua au cours de la phase auth_checker du -traitement de la requête. Cette directive peut s'utiliser pour -implémenter une vérification arbitraire de l'authentification et de -l'autorisation. Voici un exemple très simple : -

    -
    require 'apache2'
 
--- fonction d'accroche authcheck fictive
--- Si la requête ne contient aucune donnée d'authentification, l'en-tête
--- de la réponse est défini et un code 401 est renvoyé afin de demander au
--- navigateur d'effectuer une authentification basique. Si la requête
--- comporte des données d'authentification, elles ne sont pas vraiment
--- consultées, mais on admet la prise en compte de l'utilisateur 'foo' et
--- on la valide. On vérifie ensuite si l'utilisateur est bien 'foo' et on
--- accepte la requête.
-function authcheck_hook(r)
+
    r:add_version_component(component_string) -- Ajoute un élément à
+                                          -- la bannière du serveur.
    
 
-   -- recherche des informations d'authentification
-   auth = r.headers_in['Authorization']
-   if auth ~= nil then
-     -- définition d'un utilisateur par défaut
-     r.user = 'foo'
-   end
 
-   if r.user == nil then
-      r:debug("authcheck: user is nil, returning 401")
-      r.err_headers_out['WWW-Authenticate'] = 'Basic realm="WallyWorld"'
-      return 401
-   elseif r.user == "foo" then
-      r:debug('user foo: OK')
-   else
-      r:debug("authcheck: user='" .. r.user .. "'")
-      r.err_headers_out['WWW-Authenticate'] = 'Basic realm="WallyWorld"'
-      return 401
-   end
-   return apache2.OK
-end
    +
    r:set_context_info(prefix, docroot) -- Définit le préfixe et la
+                                    -- racine des documents du contexte pour une requête.
    -

    Ordonnancement

    Les arguments optionnels - "early" ou "late" permettent de contrôler le moment auquel ce script - s'exécute par rapport aux autres modules.

    -
    -
    top
    -

    Directive LuaHookCheckUserID

    - - - - - - - - -
    Description:Fournit un point d'entrée pour la phase check_user_id du -traitement de la requête
    Syntaxe:LuaHookCheckUserID /chemin/vers/lua/script.lua hook_function_name [early|late]
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    Compatibilité:Le troisième argument optionnel est disponible depuis la -version 2.3.15 du serveur HTTP Apache.

    ...

    -

    Ordonnancement

    Les arguments optionnels - "early" ou "late" permettent de contrôler le moment auquel ce script - s'exécute par rapport aux autres modules.

    +
    r:os_escape_path(file_path) -- Convertit un chemin du système de
+                            -- fichiers en URL indépendamment du système d'exploitation.
    -
    -
    top
    -

    Directive LuaHookFixups

    - - - - - - - -
    Description:Fournit un point d'entrée pour la phase de correction du -traitement de la requête
    Syntaxe:LuaHookFixups /chemin/vers/lua/script.lua hook_function_name
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    -

    - Idem LuaHookTranslateName, mais s'exécute durant la phase de - correction. -

    -
    -
    top
    -

    Directive LuaHookInsertFilter

    - - - - - - - -
    Description:Fournit un point d'entrée pour la phase insert_filter du -traitement de la requête
    Syntaxe:LuaHookInsertFilter /chemin/vers/lua/script.lua hook_function_name
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua

    Non encore implémenté

    -
    -
    top
    -

    Directive LuaHookLog

    - - - - - - - -
    Description:Permet une insertion dans la phase de journalisation du -traitement d'une requête
    Syntaxe:LuaHookLog /path/to/lua/script.lua log_function_name
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    -

    - Ce dispositif d'insertion simple permet d'exécuter une fonction - lorsque httpd entre dans la phase de journalisation du traitement - d'une requête. Vous pouvez ainsi ajouter des données à vos propres - entrées de journalisation, manipuler les entrées du journal standard - avant leur enregistrement ou empêcher l'enregistrement d'une entrée - dans le journal. Pour empêcher l'enregistrement normal des entrées - du journal, renvoyez simplement apache2.DONE dans votre - gestionnaire de journalisation, ou au contraire, renvoyez - apache2.OK pour que httpd effectue une journalisation - normale. -

    -

    Exemple :

    -
    LuaHookLog /path/to/script.lua logger
    +
    r:escape_logitem(string) -- Echappe une chaîne pour journalisation.
    -
    -- /path/to/script.lua --
-function logger(r)
-    -- on joue à pile ou face :
-    -- Si on obtient 1, on écrit dans notre propre journal Lua et on dit
-    -- à httpd de ne pas enregistrer d'entrée dans le journal standard..
-    -- Si on obtient 2, on nettoie un peu les données avant que httpd ne
-    -- les enregistre dans le journal standard.
 
-    if math.random(1,2) == 1 then
-        -- On effectue notre propre journalisation et le journal
-	-- standard n'est pas alimenté
-        local f = io.open("/foo/secret.log", "a")
-        if f then
-            f:write("Quelque chose de secret est arrivé à " .. r.uri .. "\n")
-            f:close()
-        end
-        return apache2.DONE -- On dit à httpd de ne rien enregistrer
-			    --dans le journal standard
-    else
-        r.uri = r.uri:gsub("somesecretstuff", "") -- nettoie les données
-        return apache2.OK -- et httpd doit alors les enregistrer.
-    end
+
    r.strcmp_match(string, pattern) -- Vérifie si 'string' correspond à
+                                -- 'pattern' via la fonction strcmp_match (GLOBs). Par exemple, est-ce que
+                                -- 'www.example.com' correspond à '*.example.com' ?
+
+local match = r.strcmp_match("foobar.com", "foo*.com")
+if match then 
+    r:puts("foobar.com matches foo*.com")
 end
    
 
 
-
    -
    top
    -

    Directive LuaHookMapToStorage

    - - - - - - - -
    Description:Fournit un point d'entrée pour la phase map_to_storage du -traitement de la requête
    Syntaxe:LuaHookMapToStorage /chemin/vers/lua/script.lua hook_function_name
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    -

    Identique à la directive - LuaHookTranslateName, mais s'exécute à la - phase map-to-storage du traitement de la requête. Les modules comme - mod_cache agissent pendant cette phase, ce qui permet de présenter - un exemple intéressant de ce que l'on peut faire ici :

    - 
    LuaHookMapToStorage /path/to/lua/script.lua check_cache
    +
    r:set_keepalive() -- Définit l'état de persistance d'une requête.
+                  -- Renvoie true dans la mesure du possible, false dans le cas contraire.
    - 
    require"apache2"
-cached_files = {}
 
-function read_file(filename)
-    local input = io.open(filename, "r")
-    if input then
-        local data = input:read("*a")
-        cached_files[filename] = data
-        file = cached_files[filename]
-        input:close()
-    end
-    return cached_files[filename]
-end
+
    r:make_etag() -- Génère et renvoie le etag pour la requête courante.
    
 
-function check_cache(r)
-    if r.filename:match("%.png$") then -- Ne concerne que les fichiers PNG
-        local file = cached_files[r.filename] -- Vérifie les entrées du cache
-        if not file then
-            file = read_file(r.filename)  -- Lit le fichier vers le cache
-        end
-        if file then -- Si le fichier existe, on l'envoie
-            r.status = 200
-            r:write(file)
-            r:info(("%s a été envoyé au client depuis le cache"):format(r.filename))
-            return apache2.DONE -- cout-circuite le gestionnaire par défaut des fichiers PNG
-        end
-    end
-    return apache2.DECLINED -- Si nous n'avons rien eu à faire, nous laissons les autres s'en charger
+
+
    r:send_interim_response(clear) -- Renvoie une réponse d'intérim (1xx) au
+                               -- client. Si 'clear' est vrai, les en-têtes disponibles
+                               -- seront envoyés et effacés.
    
+
+
+
    r:custom_response(status_code, string) -- Génère et définit une réponse
+                                       -- personnalisée pour un code d'état particulier.
+                                       -- Le fonctionnement est très proche de celui de la directive ErrorDocument.
+
+r:custom_response(404, "Baleted!")
    
+
+
+
    r.exists_config_define(string) -- Vérifie si une définition de configuration existe.
+
+if r.exists_config_define("FOO") then
+    r:puts("httpd a probablement été lancé avec l'option -DFOO, ou FOO a
+    été défini dans la configuration")
 end
    
 
 
-    
-
    -
    top
    -

    Directive LuaHookTranslateName

    - - - - - - - - -
    Description:Fournit un point d'entrée à la phase du nom de -traduction du traitement de la requête
    Syntaxe:LuaHookTranslateName /chemin/vers/lua/script.lua nom_fonction_hook [early|late]
    Contexte:configuration du serveur, serveur virtuel
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    Compatibilité:Le troisième argument optionnel est disponible depuis la -version 2.3.15 du serveur HTTP Apache.

    - Cette directive permet d'ajouter un point d'entrée (à - APR_HOOK_MIDDLE) à la phase du nom de traduction du traitement de la - requête. La fonction hook accepte un seul argument, le request_rec, - et doit renvoyer un code d'état qui est soit un code d'erreur HTTP, - ou une constante définie dans le module apache2 : apache2.OK, - apache2.DECLINED, ou apache2.DONE.

    +
    r:state_query(string) -- Interroge le serveur à propos de son état.
    -

    Pour ceux qui ne sont pas familiers avec les points d'entrée - (hook), en gros, chaque hook sera invoqué jusqu'à ce que l'un - d'entre eux renvoie apache2.OK. Si un hook n'effectuer pas la - traduction, il doit juste renvoyer apache2.DECLINED. Si le - traitement de la requête doit être interrompu, la valeur renvoyée - doit être apache2.DONE.

    -

    Exemple :

    +
    r:stat(filename [,wanted]) -- Exécute stat() sur un fichier, et renvoie une table contenant
+                           -- des informations à propos de ce fichier.
 
-
    # httpd.conf
-LuaHookTranslateName /scripts/conf/hooks.lua silly_mapper
    
+local info = r:stat("/var/www/foo.txt")
+if info then
+    r:puts("Ce fichier existe et a été modifié pour la dernière fois à : " .. info.modified)
+end
    -
    -- /scripts/conf/hooks.lua --
-require "apache2"
-function silly_mapper(r)
-    if r.uri == "/" then
-        r.filename = "/var/www/home.lua"
-        return apache2.OK
-    else
-        return apache2.DECLINED
+
    r:regex(string, pattern [,flags]) -- Exécute une recherche à base d'expression rationnelle
+                                  -- sur une chaîne, et renvoie les éventuelles correspondances trouvées.
+
+local matches = r:regex("foo bar baz", [[foo (\w+) (\S*)]])
+if matches then
+    r:puts("L'expression rationnelle correspond et le dernier mot
+    capturé ($2) est : " .. matches[2])
+end
+
+-- Exemple avec insensibilité à la casse :
+local matches = r:regex("FOO bar BAz", [[(foo) bar]], 1)
+
+-- les drapeaux peuvent être une combibaison bit à bit de :
+-- 0x01: insensibilité à la casse
+-- 0x02: recherche multiligne
    
+
+
+
    r.usleep(microsecondes) -- Interrompt l'exécution du script pendant le nombre de microsecondes spécifié.
    
+
+
+
    r:dbacquire(dbType[, dbParams]) -- Acquiert une connexion à une base de données et renvoie une classe database.
+                                -- Voir 'Connectivité aux bases de données'
+				-- pour plus de détails.
    
+
+
+
    r:ivm_set("key", value) -- Défini une variable Inter-VM avec une valeur spécifique.
+                        -- Ces valeurs sont conservées même si la VM est
+			-- arrêtée ou non utilisée, et ne doivent donc être
+			-- utilisées que si MaxConnectionsPerChild > 0.
+			-- Les valeurs peuvent être de type number, string
+			-- ou boolean et sont stockées séparément pour
+			-- chaque processus (elles ne seront donc pas d'une
+			-- grande utilité si l'on utilise le mpm prefork).
+                        
+r:ivm_get("key")        -- Lit le contenu d'une variable définie via ivm_set. Renvoie
+			-- le contenu de la variable si elle existe, ou nil
+			-- dans le cas contraire.
+                        
+-- Voici un exemple de lecture/écriture qui sauvegarde une variable
+-- globale en dehors de la VM :
+function handle(r)
+    -- La première VM qui effectue l'appel suivant n'obtiendra aucune
+    -- valeur, et devra la créer
+    local foo = r:ivm_get("cached_data")
+    if not foo then
+        foo = do_some_calcs() -- simulation de valeurs de retour
+        r:ivm_set("cached_data", foo) -- définition globale de la variable
     end
+    r:puts("La donnée en cache est : ", foo)
 end
    
 
+
    r:htpassword(string [,algorithm [,cost]]) -- Génère un hash de mot de passe à partir d'une chaîne.
+                                          -- algorithm: 0 = APMD5 (défaut), 1 = SHA, 2 = BCRYPT, 3 = CRYPT.
+                                          -- cost: ne s'utilise qu'avec l'algorythme BCRYPT (défaut = 5).
    
 
-   
    Contexte
    Cette directive ne peut être
-   utilisée ni à l'intérieur d'une section <Directory> ou <Files>, ni dans un fichier htaccess.
    
 
-   
    Ordonnancement
    Les arguments optionnels
-   "early" ou "late" permettent de contrôler le moment auquel ce script
-   s'exécute par rapport aux autres modules.
    
+
    r:mkdir(dir [,mode]) -- Crée un répertoire et définit son mode via le paramètre optionnel mode.
    
 
-
    -
    top
    -

    Directive LuaHookTypeChecker

    - - - - - - - -
    Description:Fournit un point d'entrée pour la phase type_checker du -traitement de la requête
    Syntaxe:LuaHookTypeChecker /chemin/vers/lua/script.lua hook_function_name
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua

    ...

    -
    -
    top
    -

    Directive LuaInherit

    - - - - - - - - - -
    Description:Contrôle la manière dont les sections de configuration -parentes sont fusionnées dans les enfants
    Syntaxe:LuaInherit none|parent-first|parent-last
    Défaut:LuaInherit parent-first
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    Compatibilité:Versions 2.4.0 et supérieures

    Par défaut, si des directives LuaHook* se trouvent dans - des sections de configuration Directory ou Location qui se - chevauchent, les scripts - définis dans les sections les plus spécifiques s'exécutent - après ceux définis dans les sections plus génériques - (LuaInherit parent-first). Vous pouvez inverser cet ordre, ou faire - en sorte que le contexte parent ne s'applique pas du tout.

    -

    Jusqu'aux versions 2.3.x, le comportement par défaut consistait à - ignorer les directives LuaHook* situées dans les sections de - configuration parentes.

    -
    -
    top
    -

    Directive LuaInputFilter

    - - - - - - - -
    Description:Fournit une fonction Lua pour le filtrage en entrée
    Syntaxe:LuaInputFilter filter_name /path/to/lua/script.lua function_name
    Contexte:configuration du serveur
    Statut:Expérimental
    Module:mod_lua
    Compatibilité:Disponible depuis la version 2.4.5 du serveur HTTP -Apache
    -

    Cette directive permet d'ajouter un filtre en entrée sous la forme -d'une fonction Lua. A l'instar des filtres en sorties, les filtres en -entrée fonctionnent comme des sous-routines, intervenant dans un premier -temps avant l'envoi du contenu des tampons, puis chaque fois qu'un -paquet de données doit être transmis à la chaîne, et éventuellement -produisant toute donnée à ajouter aux données en entrée. La variable -globale bucket contient les paquets de données tels qu'ils -sont transmis au script Lua : -

    +
    r:mkrdir(dir [,mode]) -- Crée des répertoires de manière récursive et définit
+                      -- leur mode via le paramètre optionnel mode.
    + + +
    r:rmdir(dir) -- Supprime un répertoire.
    -
    LuaInputFilter myInputFilter /www/filter.lua input_filter
-<Files *.lua>
-  SetInputFilter myInputFilter
-</Files>
    -
    --[[
-    Exemple de filtre en entrée qui convertit toutes les données POST en
-    majuscules.
-]]--
-function input_filter(r)
-    print("luaInputFilter called") -- pour débogage
-    coroutine.yield() -- attend des paquets de données
-    while bucket do -- Pour chaque paquet, faire ...
-        local output = string.upper(bucket) -- Convertit toutes les données POST en majuscules
-        coroutine.yield(output) -- Envoie les données traitées à la chaîne de filtrage
+
    r:touch(file [,mtime]) -- Définit la date de modification d'un fichier à la date courante ou à
+                       -- la valeur optionnelle mtime en msec.
    
+
+
+
    r:get_direntries(dir) -- Renvoie une table contenant toutes les entrées de répertoires.
+
+-- Renvoie un chemin sous forme éclatée en chemin, fichier, extension
+function handle(r)
+  local dir = r.context_document_root
+  for _, f in ipairs(r:get_direntries(dir)) do
+    local info = r:stat(dir .. "/" .. f)
+    if info then
+      local mtime = os.date(fmt, info.mtime / 1000000)
+      local ftype = (info.filetype == 2) and "[dir] " or "[file]"
+      r:puts( ("%s %s %10i %s\n"):format(ftype, mtime, info.size, f) )
     end
-    -- plus aucune donnée à traiter.
-    coroutine.yield("&filterSignature=1234") -- Ajoute une signature à la fin
+  end
 end
    
 
-
    
-Le filtre en entrée peut interdire ou sauter un filtre s'il est
-considéré comme indésirable :
-
    
-
    function input_filter(r)
-    if not good then
-        return -- Empêche tout simplement le filtrage et transmet le contenu original
-    end
-    coroutine.yield() -- attend des paquets de données
-    ...               -- insert les filtres ici
+
+
    r.date_parse_rfc(string) -- Interprète une chaîne date/heure et renvoie l'équivalent en secondes depuis epoche.
    
+
+
+
    r:getcookie(key) -- Obtient un cookie HTTP
    
+
+
+
    r:setcookie(key, value, secure, expires) -- Définit un cookie HTTP, par exemple :
+r:setcookie("foo", "bar and stuff", false, os.time() + 86400)
    
+
+
+
    r:wsupgrade() -- Met à jour une connexion vers les WebSockets si possible (et si demandé) :
+if r:wsupgrade() then -- si la mise à jour est possible :
+    r:wswrite("Bienvenue dans les websockets!") -- écrit quelque chose à l'intention du client
+    r:wsclose()  -- Au revoir !
 end
    
 
-
    
-Voir "Modification de contenu avec les
-filtres Lua" pour plus de détails.
-
    
 
-
    -
    top
    -

    Directive LuaMapHandler

    - - - - - - - -
    Description:Met en correspondance un chemin avec un gestionnaire lua
    Syntaxe:LuaMapHandler modele-uri /chemin/vers/lua/script.lua -[nom-fonction]
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    -

    Cette directive permet de faire correspondre un modèle d'uri avec - une fonction de gestionnaire située dans un fichier spécifique. Elle - utilise les expressions rationnelles PCRE pour mettre en - correspondance l'uri, et supporte les groupes de correspondance - d'interpolation dans le chemin du fichier et le nom de la fonction. - Prenez garde aux problèmes de sécurité en écrivant vos expressions - rationnelles.

    -

    Exemples :

    LuaMapHandler /(\w+)/(\w+) /scripts/$1.lua handle_$2
    -
    -

    Cette directive va faire correspondre des uri comme - /photos/show?id=9 au fichier /scripts/photos.lua, et invoquera la - fonction de gestionnaire handle_show au niveau de la vm lua - après chargement de ce fichier.

    +
    r:wsread() -- Lit un cadre de websocket depuis une connexion vers websocket mise à jour (voir ci-dessus) :
+           
+local line, isFinal = r:wsread() -- isFinal indique s'il s'agit du cadre final.
+                                 -- dans le cas contraire, on peut lire les cadres suivants
+r:wswrite("Vous avez écrit : " .. line)
    -
    LuaMapHandler /bingo /scripts/wombat.lua
    -

    Cette directive invoquera la fonction "handle" qui est la - valeur par défaut si aucun nom de fonction spécifique n'est - spécifié.

    +
    r:wswrite(line) -- écrit un cadre vers un client WebSocket :
+r:wswrite("Bonjour le Monde !")
    -
    -
    top
    -

    Directive LuaOutputFilter

    - - - - - - - -
    Description:Fournit une fonction Lua pour le filtrage de contenu en -sortie
    Syntaxe:LuaOutputFilter filter_name /path/to/lua/script.lua function_name
    Contexte:configuration du serveur
    Statut:Expérimental
    Module:mod_lua
    Compatibilité:Disponible à partir de la version 2.4.5 du serveur HTTP -Apache
    -

    >Cette directive permet d'ajouter un filtre en sortie sous la forme -d'une fonction Lua. A l'instar des filtres en sorties, les filtres en -entrée fonctionnent comme des sous-routines, intervenant dans un premier -temps avant l'envoi du contenu des tampons, puis chaque fois qu'un -paquet de données doit être transmis à la chaîne, et éventuellement -produisant toute donnée à ajouter aux données en sortie. La variable -globale bucket contient les paquets de données tels qu'ils -sont transmis au script Lua : -

    -
    LuaOutputFilter myOutputFilter /www/filter.lua output_filter
-<Files *.lua>
-  SetOutputFilter myOutputFilter
-</Files>
    +
    r:wsclose() -- ferme une requête WebSocket et l'achève pour httpd :
 
-
    --[[
-    Exemple de filtre en sortie qui échappe toutes les entités HTML en
-    sortie
-]]--
-function output_filter(r)
-    coroutine.yield("(Handled by myOutputFilter)<br/>\n") -- Ajoute des données au début de la sortie,
-                                                                -- puis attend des paquets de données à traiter
-    while bucket do -- Pour chaque paquet, faire ...
-        local output = r:escape_html(bucket) -- Echappe les données en sortie
-        coroutine.yield(output) -- Envoie les données traitées à la chaîne
+if r:wsupgrade() then
+    r:wswrite("Ecrire quelque chose : ")
+    local line = r:wsread() or "nothing"
+    r:wswrite("Vous avez écrit : " .. line);
+    r:wswrite("Au revoir !")
+    r:wsclose()
+end
    
+
+
    top
    +
    +

    Fonctions de journalisation

    + +
    	-- exemples de messages de journalisation
+	r:trace1("Ceci est un message de journalisation de niveau
+	trace") -- les niveaux valides vont de trace1 à trace8 
    
+        r:debug("Ceci est un message de journalisation de niveau debug")
    
+        r:info("Ceci est un message de journalisation de niveau info")
    
+        r:notice("Ceci est un message de journalisation de niveau notice")
    
+        r:warn("Ceci est un message de journalisation de niveau warn")
    
+        r:err("Ceci est un message de journalisation de niveau err")
    
+        r:alert("Ceci est un message de journalisation de niveau alert")
    
+        r:crit("Ceci est un message de journalisation de niveau crit")
    
+        r:emerg("Ceci est un message de journalisation de niveau emerg")
    
+
    + + +
    top
    +
    +

    Paquet apache2

    +

    Le paquet nommé apache2 est fourni avec (au minimum) le +contenu suivant :

    +
    +
    apache2.OK
    +
    Constante interne OK. Les gestionnaires renverront cette valeur + s'ils ont traité la requête.
    +
    apache2.DECLINED
    +
    Constante interne DECLINED. Les gestionnaires renverront cette + valeur s'ils n'ont pas l'intention de traiter la requête.
    +
    apache2.DONE
    +
    Constante interne DONE.
    +
    apache2.version
    +
    Chaîne contenant la version du serveur HTTP Apache
    +
    apache2.HTTP_MOVED_TEMPORARILY
    +
    Code d'état HTTP
    +
    apache2.PROXYREQ_NONE, apache2.PROXYREQ_PROXY, apache2.PROXYREQ_REVERSE, apache2.PROXYREQ_RESPONSE
    +
    Constantes internes utilisées par mod_proxy
    +
    apache2.AUTHZ_DENIED, apache2.AUTHZ_GRANTED, apache2.AUTHZ_NEUTRAL, apache2.AUTHZ_GENERAL_ERROR, apache2.AUTHZ_DENIED_NO_USER
    +
    constantes internes utilisées par mod_authz_core
    + +
    +

    Les autres codes d'état HTTP ne sont pas encore implémentés.

    +
    top
    +
    +

    Modification de contenu avec les filtres lua

    + +

    + Les fonctions de filtrage implémentées via les directives LuaInputFilter ou LuaOutputFilter sont conçues comme des + fonctions de 3ème phase non blocantes utilisant des sous-routines + pour suspendre et reprendre l'exécution d'une fonction lorsque des + paquets de données sont envoyés à la chaîne de filtrage. La + structure de base d'une telle fonction est : +

    + 
    function filter(r)
+    -- Nous indiquons tout d'abord que nous sommes prêts à recevoir des
+    -- blocs de données.
+    -- Avant ceci, nous pouvons définir notre environnement, tester
+    -- certaines conditions, et, si nous le jugeons nécessaire, refuser le
+    -- filtrage d'une requête :
+    if something_bad then
+        return -- Le filtrage est sauté
     end
-    -- plus aucune donnée à traiter.
+    -- Sans se préoccuper des données que nous devons éventuellement ajouter, un arrêt est réalisé ici.
+    -- Noter que les filtres de sortie sont les seuls capables d'ajouter des éléments au début des données.
+    -- Les filtres en entrée peuvent ajouter des éléments à la fin des données au stade final.
+
+    coroutine.yield([optional header to be prepended to the content])
+
+    -- Après cet arrêt, nous allons recevoir d'autres blocs de données, un par un ;
+    -- nous pouvons les traiter comme il nous plaît et procéder à la réponse.
+    -- Ces blocs sont conservés dans la variable globale 'bucket', nous réalisons donc
+    -- une boucle pour vérifier que 'bucket' n'est pas vide :
+    while bucket ~= nil do
+        local output = mangle(bucket) -- Do some stuff to the content
+        coroutine.yield(output) -- Return our new content to the filter chain
+    end
+
+    -- Une fois les blocs de données épuisés, 'bucket' est positionné à une valeur vide ('nil'),
+    -- ce qui va nous faire sortir de cette boucle et nous amener à l'étape suivante.
+    -- On peut ajouter ce qu'on veut à la fin des données à cette étape, qui constitue le dernier
+    -- arrêt. Les filtres d'entrée comme de sortie peuvent servir à ajouter des éléments à la fin
+    --  des données à cette étape.
+    coroutine.yield([optional footer to be appended to the content])
 end
    -

    -Comme les filres en entrée, le filtre en sortie peut interdire ou sauter un filtre s'il est -considéré comme indésirable : -

    -
    function output_filter(r)
-    if not r.content_type:match("text/html") then
-        return -- Empêche tout simplement le filtrage et transmet le contenu original
+
    top
    +
    +

    Connectivité aux bases de données

    + +

    Mod_lua implémente une fonctionnalité basique de connexion aux +bases de données permettant d'envoyer des requêtes ou d'exécuter des +commandes auprès des moteurs de base de données les plus courants +(mySQL, PostgreSQL, FreeTDS, ODBC, SQLite, Oracle), ainsi que mod_dbd. +

    +

    L'exemple suivant montre comment se connecter à une base de +données et extraire des informations d'une table :

    + 
    function handle(r)
+    -- connexion à la base de données
+    local database, err = r:dbacquire("mysql", "server=localhost,user=someuser,pass=somepass,dbname=mydb")
+    if not err then
+        -- Sélection de certaines informations
+        local results, err = database:select(r, "SELECT `name`, `age` FROM `people` WHERE 1")
+        if not err then
+            local rows = results(0) -- extrait tous les enregistrements en mode synchrone
+            for k, row in pairs(rows) do
+                r:puts( string.format("Name: %s, Age: %s<br/>", row[1], row[2]) )
+            end
+        else
+            r:puts("Database query error: " .. err)
+        end
+        database:close()
+    else
+        r:puts("Connexion à la base de données impossible : " .. err)
     end
-    coroutine.yield() -- attend des paquets de données
-    ...               -- insert les filtres ici
 end
    -

    Les filtres Lua avec mod_filter

    -

    Lorsqu'on utilise un filtre Lua comme fournisseur sous-jacent via la -directive FilterProvider, le -filtrage ne fonctionnera que si filter-name est identique à -provider-name. -

    +

    + Pour utiliser mod_dbd, spécifiez +mod_dbd comme type de base de données, ou laissez le champ +vide : +

    + 
    local database = r:dbacquire("mod_dbd")
    -

    -Voir "Modification de contenu avec les -filtres Lua" pour plus de détails. -

    +

    L'objet database et ses méthodes

    + +

    L'objet database renvoyé par dbacquire possède +les méthodes suivantes :

    +

    Sélection normale et requête vers une base de données +:

    + 
    -- Exécution d'une requête et renvoie du nombre d'enregistrements
+affectés :
+local affected, errmsg = database:query(r, "DELETE FROM `tbl` WHERE 1")
 
+-- Exécution d'une requête et renvoie du résultat qui peut être utilisé
+en mode synchrone ou asynchrone :
+local result, errmsg = database:select(r, "SELECT * FROM `people` WHERE 1")
    -
    -
    top
    -

    Directive LuaPackageCPath

    - - - - - - - -
    Description:Ajoute un répertoire au package.cpath de lua
    Syntaxe:LuaPackageCPath /chemin/vers/include/?.soa
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    -

    Cette directive permet d'ajouter un chemin à la liste des chemins - de recherche des bibliothèques partagées de lua. Ceci modifie le - package.cpath dans les vms lua.

    +

    Utilisation de requêtes préparées (recommandé) :

    + 
    -- Création et exécution d'une requête préparée :
+local statement, errmsg = database:prepare(r, "DELETE FROM `tbl` WHERE `age` > %u")
+if not errmsg then
+    local result, errmsg = statement:query(20) -- exécute la requête pour age > 20
+end
 
+-- Extrait une requête préparée depuis une directive DBDPrepareSQL :
+local statement, errmsg = database:prepared(r, "someTag")
+if not errmsg then
+    local result, errmsg = statement:select("John Doe", 123) -- injecte les valeurs "John Doe" et 123 dans la requête
+end
    -
    -
    top
    -

    Directive LuaPackagePath

    - - - - - - - -
    Description:Ajoute un répertoire au package.path de lua
    Syntaxe:LuaPackagePath /chemin/vers/include/?.lua
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua

    Cette directive permet d'ajouter un chemin à la liste des - chemins de recherche du module lua. Elle suit les mêmes conventions - que lua. Ceci modifie le package.path dans les vms lua.

    +

    Echappement de valeurs, fermeture de la base données, +etc...

    + 
    -- Echappe une valeur pour pouvoir l'utiliser dans une requête :
+local escaped = database:escape(r, [["'|blabla]])
 
-    
    Exemples :
    LuaPackagePath /scripts/lib/?.lua
-LuaPackagePath /scripts/lib/?/init.lua
    
-
    
+-- Ferme une base de données et libère les liens vers cette dernière :
+database:close()
 
-
    -
    top
    -

    Directive LuaQuickHandler

    - - - - - - - -
    Description:Fournit un point d'entrée pour la gestion rapide du -traitement de la requête
    Syntaxe:LuaQuickHandler /path/to/script.lua hook_function_name
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    -

    Cette phase s'exécute juste après l'attribution de la requête à - un serveur virtuel, et permet d'effectuer certains traitements avant - le déroulement des autres phases, ou de servir une requête sans - avoir à la traduire, l'associer à un espace de stockage, etc... - Comme cette phase s'exécute avant toute autre, les directives telles - que <Location> ou - <Directory> ne - sont pas encore prises en compte, car Les URI n'ont pas encore été - entièrement interprétés. +-- Vérifie si une connexion à une base de données est en service et +opérationnelle : +local connected = database:active() + + +

    Travail avec les jeux d'enregistrements renvoyés par les requêtes

    + +

    Les jeux d'enregistrements renvoyés par db:select ou par des +requêtes préparées créées par db:prepare permettent de +sélectionner des enregistrements en mode synchrone ou +asynchrone, selon le nombre d'enregistrements spécifié :
    + result(0) sélectionne tous les enregistrements en mode +synchrone en renvoyant une table d'enregistrements.
    + result(-1) sélectionne le prochain enregistrement disponible en +mode asynchrone.
    + result(N) sélectionne l'enregistrement numéro +N en mode asynchrone.

    -

    Contexte

    Cette directive ne peut être - utilisée ni à l'intérieur d'une section <Directory> ou <Files>, ni dans un fichier htaccess.

    + 
    -- extrait un jeu d'enregistrements via une requête régulière :
+local result, err = db:select(r, "SELECT * FROM `tbl` WHERE 1")
 
-
    -
    top
    -

    Directive LuaRoot

    - - - - - - - -
    Description:Spécifie le chemin de base pour la résolution des chemins -relatifs dans les directives de mod_lua
    Syntaxe:LuaRoot /chemin/vers/un/répertoire
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    -

    Cette directive permet de spécifier le chemin de base qui sera - utilisé pour évaluer tous les chemins relatifs dans mod_lua. En - l'absence de cette directive, les chemins relatifs sont résolus par - rapport au répertoire de travail courant, ce qui ne sera pas - toujours approprié pour un serveur.

    +local rows = result(0) -- sélectionne tous les enregistrements en mode synchrone +local row = result(-1) -- sélectionne le prochain enregistrement disponible en mode asynchrone +local row = result(1234) -- sélectionne l'enregistrement 1234 en mode asynchrone +local row = result(-1, true) -- Lit l'enregistrement suivant en utilisant les noms d'enregistrements comme index. -
    -
    top
    -

    Directive LuaScope

    - - - - - - - - -
    Description:Une valeur parmi once, request, conn, thread -- la valeur par défaut est once
    Syntaxe:LuaScope once|request|conn|thread|server [min] [max]
    Défaut:LuaScope once
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:All
    Statut:Expérimental
    Module:mod_lua
    -

    Cette directive permet de spécifier la durée de vie de - l'interpréteur Lua qui sera utilisé dans ce "répertoire". La valeur - par défaut est "once".

    +

    Il est possible de construire une fonction qui renvoie une +fonction itérative permettant de traiter tous les enregistrement en mode +synchrone ou asynchrone selon la valeur de l'argument async : +

    + 
    function rows(resultset, async)
+    local a = 0
+    local function getnext()
+        a = a + 1
+        local row = resultset(-1)
+        return row and a or nil, row
+    end
+    if not async then
+        return pairs(resultset(0))
+    else
+        return getnext, self
+    end
+end
 
-   
    
-    
    once:
     
    utilise l'interpréteur une fois.
    
+local statement, err = db:prepare(r, "SELECT * FROM `tbl` WHERE `age` > %u")
+if not err then
+     -- sélectionne des enregistrements en mode asynchrone :
+    local result, err = statement:select(20)
+    if not err then
+        for index, row in rows(result, true) do
+            ....
+        end
+    end
 
-    
    request:
     
    utilise l'interpréteur pour traiter tout ce
-    qui est basé sur le même fichier dans la requête, et qui se trouve
-    aussi dans la portée de la requête.
    
+     -- sélectionne des enregistrements en mode synchrone :
+    local result, err = statement:select(20)
+    if not err then
+        for index, row in rows(result, false) do
+            ....
+        end
+    end
+end
    -
    conn:
    idem request, mais attaché à connection_rec
    + +

    Fermeture d'une connexion à une base de données

    + -
    thread:
    Utilise l'interpréteur pendant toute la durée - de vie du thread qui traite la requête (disponible seulement avec - les MPMs threadés).
    +

    Lorsqu'elles ne sont plus utilisées, les connexions aux bases de +données doivent être fermées avec database:close(). Si vous +ne les fermez pas manuellement, mod_lua les fermera peut-être en tant +que résidus collectés, mais si ce n'est pas le cas, vous pouvez finir +pas avoir trop de connexions vers la base de données inutilisées. Les +deux mesures suivantes sont pratiquement identiques : +

    + 
    -- Méthode 1 : fermeture manuelle de la connexion
+local database = r:dbacquire("mod_dbd")
+database:close() -- c'est tout
 
-    
    server:
      
    Le comportement est ici différent, car la
-    portée du serveur présente une durée de vie assez longue, et
-    plusieurs threads vont partager le même server_rec. Pour gérer tout
-    ceci, les états lua du serveur sont stockés dans une liste de ressources
-    apr. Les arguments min et max permettent
-    de spécifier les nombres minimaux et maximaux d'états lua à stocker
-    dans la liste.
    
-   
-   
    En général, les portées thread et server
-   sont 2 à 3 fois plus rapides que les autres, car elles n'ont pas besoin
-   de régénérer de nouveaux états Lua à chaque requête (comme c'est le
-   cas avec le MPM event, où même les connexions persistantes utilisent un
-   nouveau thread pour chaque requête). Si vous pensez que vos scripts
-   n'auront pas de problème s'il réutilisent un état, alors les portées
-   thread ou server doivent être utilisées car
-   elles présenteront de meilleures performances. Alors que la portée
-   thread fournira les réponses les plus rapides, la portée
-   server utilisera moins de mémoire car les états sont
-   rassemblés dans des jeux, permettant par exemple à 1000 threads de
-   partager 100 états Lua, ne nécessitant ainsi que 10% de la mémoire
-   requise par la portée thread.
+-- Méthode 2 : on laisse le collecteur de résidus la fermer
+local database = r:dbacquire("mod_dbd")
+database = nil -- on coupe le lien
+collectgarbage() -- fermeture de la connexion par le collecteur de résidus
    + + +

    Précautions à prendre lorsque l'on travaille avec les bases +de données

    + +

    Bien que les fonctions query et run +soient toujours disponibles, il est recommandé d'utiliser des requêtes +préparées chaque fois que possible, afin d'une part d'optimiser les +performances (si votre connexion reste longtemps en vie), et d'autre part +minimiser le risque d'attaques par injection SQL. Les fonctions +run et query ne doivent être utilisées que +lorsque la requête ne contient pas de variables (requête statique). Dans +le cas des requêtes dynamiques, utilisez db:prepare ou +db:prepared.

    +
    diff --git a/docs/manual/mod/mod_macro.html.en b/docs/manual/mod/mod_macro.html.en index 81dab30ea96..9a5b3740799 100644 --- a/docs/manual/mod/mod_macro.html.en +++ b/docs/manual/mod/mod_macro.html.en @@ -54,6 +54,81 @@
  • Examples
    • top
    +

    <Macro> Directive

    + + + + + + +
    Description:Define a configuration file macro
    Syntax: +<Macro name [par1 .. parN]> +... </Macro>
    Context:server config, virtual host, directory
    Status:Base
    Module:mod_macro
    +

    The Macro directive controls the definition of + a macro within the server runtime configuration files. + The first argument is the name of the macro. + Other arguments are parameters to the macro. It is good practice to prefix + parameter names with any of '$%@', and not macro names + with such characters. +

    + + 
    <Macro LocalAccessPolicy>
+    Require ip 10.2.16.0/24
+</Macro>
+
+<Macro RestrictedAccessPolicy $ipnumbers>
+    Require ip $ipnumbers
+</Macro>
    + + +
    +
    top
    +

    UndefMacro Directive

    + + + + + + +
    Description:Undefine a macro
    Syntax:UndefMacro name
    Context:server config, virtual host, directory
    Status:Base
    Module:mod_macro
    +

    The UndefMacro directive undefines a macro + which has been defined before hand.

    + + 
    UndefMacro LocalAccessPolicy
+UndefMacro RestrictedAccessPolicy
    + + +
    +
    top
    +

    Use Directive

    + + + + + + +
    Description:Use a macro
    Syntax:Use name [value1 ... valueN] +
    Context:server config, virtual host, directory
    Status:Base
    Module:mod_macro
    +

    The Use directive controls the use of a macro. + The specified macro is expanded. It must be given the same number of + arguments as in the macro definition. The provided values are + associated to their corresponding initial parameters and are substituted + before processing.

    + + 
    Use LocalAccessPolicy
+...
+Use RestrictedAccessPolicy "192.54.172.0/24 192.54.148.0/24"
    + + +

    is equivalent, with the macros defined above, to:

    + + 
    Require ip 10.2.16.0/24
+...
+Require ip 192.54.172.0/24 192.54.148.0/24
    + + +
    +
    top

    Usage

    @@ -190,81 +265,6 @@ UndefMacro DirGroup -
    -
    top
    -

    <Macro> Directive

    - - - - - - -
    Description:Define a configuration file macro
    Syntax: -<Macro name [par1 .. parN]> -... </Macro>
    Context:server config, virtual host, directory
    Status:Base
    Module:mod_macro
    -

    The Macro directive controls the definition of - a macro within the server runtime configuration files. - The first argument is the name of the macro. - Other arguments are parameters to the macro. It is good practice to prefix - parameter names with any of '$%@', and not macro names - with such characters. -

    - - 
    <Macro LocalAccessPolicy>
-    Require ip 10.2.16.0/24
-</Macro>
-
-<Macro RestrictedAccessPolicy $ipnumbers>
-    Require ip $ipnumbers
-</Macro>
    - - -
    -
    top
    -

    UndefMacro Directive

    - - - - - - -
    Description:Undefine a macro
    Syntax:UndefMacro name
    Context:server config, virtual host, directory
    Status:Base
    Module:mod_macro
    -

    The UndefMacro directive undefines a macro - which has been defined before hand.

    - - 
    UndefMacro LocalAccessPolicy
-UndefMacro RestrictedAccessPolicy
    - - -
    -
    top
    -

    Use Directive

    - - - - - - -
    Description:Use a macro
    Syntax:Use name [value1 ... valueN] -
    Context:server config, virtual host, directory
    Status:Base
    Module:mod_macro
    -

    The Use directive controls the use of a macro. - The specified macro is expanded. It must be given the same number of - arguments as in the macro definition. The provided values are - associated to their corresponding initial parameters and are substituted - before processing.

    - - 
    Use LocalAccessPolicy
-...
-Use RestrictedAccessPolicy "192.54.172.0/24 192.54.148.0/24"
    - - -

    is equivalent, with the macros defined above, to:

    - - 
    Require ip 10.2.16.0/24
-...
-Require ip 192.54.172.0/24 192.54.148.0/24
    - -
    diff --git a/docs/manual/mod/mod_macro.html.fr b/docs/manual/mod/mod_macro.html.fr index 6d9718ea68f..3440fc9c9e3 100644 --- a/docs/manual/mod/mod_macro.html.fr +++ b/docs/manual/mod/mod_macro.html.fr @@ -58,6 +58,75 @@ de configuration Apache.
  • Exemples
    • top
    +

    Directive <Macro>

    + + + + + + +
    Description:Définition d'une macro dans un fichier de configuration
    Syntaxe: +<Macro nom [par1 .. parN]> +... </Macro>
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Base
    Module:mod_macro
    +

    La directive Macro permet de définir une macro + dans un fichier de configuration Apache. Le premier argument est le nom + de la macro, et les arguments suivants sont les paramètres. Il + est de bon aloi de préfixer les noms des paramètres d'une macro + avec un caractère parmi '$%@', et d'éviter d'en faire + de même avec les noms de macros. +

    + + 
    <Macro LocalAccessPolicy>
+  Require ip 10.2.16.0/24
+</Macro>
+
+<Macro RestrictedAccessPolicy $ipnumbers>
+   Require ip $ipnumbers
+</Macro>
    + + +
    +
    top
    +

    Directive UndefMacro

    + + + + + + +
    Description:Undefine a macro
    Syntaxe:UndefMacro name
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Base
    Module:mod_macro

    La documentation de cette directive + n'a pas encore t traduite. Veuillez vous reporter la version + en langue anglaise.

    +
    top
    +

    Directive Use

    + + + + + + +
    Description:Utilisation d'une macro
    Syntaxe:Use nom [valeur1 ... valeurN] +
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Base
    Module:mod_macro
    +

    La directive Use permet d'utiliser une macro. + La macro considérée est expansée. Son nombre d'arguments doit être égal au + nombre de paramètres précisés dans sa définition. Les valeurs passées en + argument sont attribuées aux paramètres correspondants et + substituées avant l'interprétation du texte de la macro.

    + + 
    Use LocalAccessPolicy
+...
+Use RestrictedAccessPolicy "192.54.172.0/24 192.54.148.0/24"
    + + +

    est équivalent, avec les macros définies ci-dessus à :

    + + 
    Require ip 10.2.16.0/24
+...
+Require ip 192.54.172.0/24 192.54.148.0/24
    + + +
    +
    top

    Utilisation

    On définit une macro à l'aide des blocs <Macro> qui contiennent la portion de votre @@ -200,75 +269,6 @@ UndefMacro DirGroup -

    -
    top
    -

    Directive <Macro>

    - - - - - - -
    Description:Définition d'une macro dans un fichier de configuration
    Syntaxe: -<Macro nom [par1 .. parN]> -... </Macro>
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Base
    Module:mod_macro
    -

    La directive Macro permet de définir une macro - dans un fichier de configuration Apache. Le premier argument est le nom - de la macro, et les arguments suivants sont les paramètres. Il - est de bon aloi de préfixer les noms des paramètres d'une macro - avec un caractère parmi '$%@', et d'éviter d'en faire - de même avec les noms de macros. -

    - - 
    <Macro LocalAccessPolicy>
-  Require ip 10.2.16.0/24
-</Macro>
-
-<Macro RestrictedAccessPolicy $ipnumbers>
-   Require ip $ipnumbers
-</Macro>
    - - -
    -
    top
    -

    Directive UndefMacro

    - - - - - - -
    Description:Undefine a macro
    Syntaxe:UndefMacro name
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Base
    Module:mod_macro

    La documentation de cette directive - n'a pas encore t traduite. Veuillez vous reporter la version - en langue anglaise.

    -
    top
    -

    Directive Use

    - - - - - - -
    Description:Utilisation d'une macro
    Syntaxe:Use nom [valeur1 ... valeurN] -
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Base
    Module:mod_macro
    -

    La directive Use permet d'utiliser une macro. - La macro considérée est expansée. Son nombre d'arguments doit être égal au - nombre de paramètres précisés dans sa définition. Les valeurs passées en - argument sont attribuées aux paramètres correspondants et - substituées avant l'interprétation du texte de la macro.

    - - 
    Use LocalAccessPolicy
-...
-Use RestrictedAccessPolicy "192.54.172.0/24 192.54.148.0/24"
    - - -

    est équivalent, avec les macros définies ci-dessus à :

    - - 
    Require ip 10.2.16.0/24
-...
-Require ip 192.54.172.0/24 192.54.148.0/24
    - -
    diff --git a/docs/manual/mod/mod_mime.html.en b/docs/manual/mod/mod_mime.html.en index 7837b5f6455..2ae706bc270 100644 --- a/docs/manual/mod/mod_mime.html.en +++ b/docs/manual/mod/mod_mime.html.en @@ -114,139 +114,6 @@
  • SetOutputFilter
    • top
    -
    -

    Files with Multiple Extensions

    -

    Files can have more than one extension; the order of the - extensions is normally irrelevant. For example, if the - file welcome.html.fr maps onto content type - text/html and language French then the file - welcome.fr.html will map onto exactly the same - information. If more than one extension is given that maps onto - the same type of metadata, then the one to the right will - be used, except for languages and content encodings. For example, - if .gif maps to the media-type - image/gif and .html maps to the - media-type text/html, then the file - welcome.gif.html will be associated with the - media-type text/html.

    - -

    Languages and content encodings are treated accumulative, because one can assign - more than one language or encoding to a particular resource. For example, - the file welcome.html.en.de will be delivered with - Content-Language: en, de and Content-Type: - text/html.

    - -

    Care should be taken when a file with multiple extensions - gets associated with both a media-type - and a handler. This will - usually result in the request being handled by the module associated - with the handler. For example, if the .imap - extension is mapped to the handler imap-file (from - mod_imagemap) and the .html extension is - mapped to the media-type text/html, then the file - world.imap.html will be associated with both the - imap-file handler and text/html media-type. - When it is processed, the imap-file handler will be used, - and so it will be treated as a mod_imagemap imagemap - file.

    - -

    If you would prefer only the last dot-separated part of the - filename to be mapped to a particular piece of meta-data, then do - not use the Add* directives. For example, if you wish - to have the file foo.html.cgi processed as a CGI - script, but not the file bar.cgi.html, then instead - of using AddHandler cgi-script .cgi, use

    - -

    Configure handler based on final extension only

    <FilesMatch "\.cgi$">
-  SetHandler cgi-script
-</FilesMatch>
    -
    - -
    top
    -
    -

    Content encoding

    -

    A file of a particular media-type can additionally be encoded a - particular way to simplify transmission over the Internet. - While this usually will refer to compression, such as - gzip, it can also refer to encryption, such a - pgp or to an encoding such as UUencoding, which is - designed for transmitting a binary file in an ASCII (text) - format.

    - -

    The HTTP/1.1 - RFC, section 14.11 puts it this way:

    - -
    -

    The Content-Encoding entity-header field is used as a modifier to - the media-type. When present, its value indicates what additional - content codings have been applied to the entity-body, and thus what - decoding mechanisms must be applied in order to obtain the media-type - referenced by the Content-Type header field. Content-Encoding is - primarily used to allow a document to be compressed without losing - the identity of its underlying media type.

    -
    - -

    By using more than one file extension (see section above about multiple file - extensions), you can indicate that a file is of a - particular type, and also has a particular - encoding.

    - -

    For example, you may have a file which is a Microsoft Word - document, which is pkzipped to reduce its size. If the - .doc extension is associated with the Microsoft - Word file type, and the .zip extension is - associated with the pkzip file encoding, then the file - Resume.doc.zip would be known to be a pkzip'ed Word - document.

    - -

    Apache sends a Content-encoding header with the - resource, in order to tell the client browser about the - encoding method.

    - - 
    Content-encoding: pkzip
    - -
    top
    -
    -

    Character sets and languages

    -

    In addition to file type and the file encoding, - another important piece of information is what language a - particular document is in, and in what character set the file - should be displayed. For example, the document might be written - in the Vietnamese alphabet, or in Cyrillic, and should be - displayed as such. This information, also, is transmitted in - HTTP headers.

    - -

    The character set, language, encoding and mime type are all - used in the process of content negotiation (See - mod_negotiation) to determine - which document to give to the client, when there are - alternative documents in more than one character set, language, - encoding or mime type. All filename extensions associations - created with AddCharset, - AddEncoding, AddLanguage and AddType directives - (and extensions listed in the MimeMagicFile) participate in this select process. - Filename extensions that are only associated using the AddHandler, AddInputFilter or AddOutputFilter directives may be included or excluded - from matching by using the MultiviewsMatch directive.

    - -

    Charset

    -

    To convey this further information, Apache optionally sends - a Content-Language header, to specify the language - that the document is in, and can append additional information - onto the Content-Type header to indicate the - particular character set that should be used to correctly - render the information.

    - -

    -Content-Language: en, fr -Content-Type: text/plain; charset=ISO-8859-1 -

    - -

    The language specification is the two-letter abbreviation - for the language. The charset is the name of the - particular character set which should be used.

    - -
    -
    top

    AddCharset Directive

    + +
    top
    +
    +

    Files with Multiple Extensions

    +

    Files can have more than one extension; the order of the + extensions is normally irrelevant. For example, if the + file welcome.html.fr maps onto content type + text/html and language French then the file + welcome.fr.html will map onto exactly the same + information. If more than one extension is given that maps onto + the same type of metadata, then the one to the right will + be used, except for languages and content encodings. For example, + if .gif maps to the media-type + image/gif and .html maps to the + media-type text/html, then the file + welcome.gif.html will be associated with the + media-type text/html.

    + +

    Languages and content encodings are treated accumulative, because one can assign + more than one language or encoding to a particular resource. For example, + the file welcome.html.en.de will be delivered with + Content-Language: en, de and Content-Type: + text/html.

    + +

    Care should be taken when a file with multiple extensions + gets associated with both a media-type + and a handler. This will + usually result in the request being handled by the module associated + with the handler. For example, if the .imap + extension is mapped to the handler imap-file (from + mod_imagemap) and the .html extension is + mapped to the media-type text/html, then the file + world.imap.html will be associated with both the + imap-file handler and text/html media-type. + When it is processed, the imap-file handler will be used, + and so it will be treated as a mod_imagemap imagemap + file.

    + +

    If you would prefer only the last dot-separated part of the + filename to be mapped to a particular piece of meta-data, then do + not use the Add* directives. For example, if you wish + to have the file foo.html.cgi processed as a CGI + script, but not the file bar.cgi.html, then instead + of using AddHandler cgi-script .cgi, use

    + +

    Configure handler based on final extension only

    <FilesMatch "\.cgi$">
+  SetHandler cgi-script
+</FilesMatch>
    +
    + +
    top
    +
    +

    Content encoding

    +

    A file of a particular media-type can additionally be encoded a + particular way to simplify transmission over the Internet. + While this usually will refer to compression, such as + gzip, it can also refer to encryption, such a + pgp or to an encoding such as UUencoding, which is + designed for transmitting a binary file in an ASCII (text) + format.

    + +

    The HTTP/1.1 + RFC, section 14.11 puts it this way:

    + +
    +

    The Content-Encoding entity-header field is used as a modifier to + the media-type. When present, its value indicates what additional + content codings have been applied to the entity-body, and thus what + decoding mechanisms must be applied in order to obtain the media-type + referenced by the Content-Type header field. Content-Encoding is + primarily used to allow a document to be compressed without losing + the identity of its underlying media type.

    +
    + +

    By using more than one file extension (see section above about multiple file + extensions), you can indicate that a file is of a + particular type, and also has a particular + encoding.

    + +

    For example, you may have a file which is a Microsoft Word + document, which is pkzipped to reduce its size. If the + .doc extension is associated with the Microsoft + Word file type, and the .zip extension is + associated with the pkzip file encoding, then the file + Resume.doc.zip would be known to be a pkzip'ed Word + document.

    + +

    Apache sends a Content-encoding header with the + resource, in order to tell the client browser about the + encoding method.

    + + 
    Content-encoding: pkzip
    + +
    top
    +
    +

    Character sets and languages

    +

    In addition to file type and the file encoding, + another important piece of information is what language a + particular document is in, and in what character set the file + should be displayed. For example, the document might be written + in the Vietnamese alphabet, or in Cyrillic, and should be + displayed as such. This information, also, is transmitted in + HTTP headers.

    + +

    The character set, language, encoding and mime type are all + used in the process of content negotiation (See + mod_negotiation) to determine + which document to give to the client, when there are + alternative documents in more than one character set, language, + encoding or mime type. All filename extensions associations + created with AddCharset, + AddEncoding, AddLanguage and AddType directives + (and extensions listed in the MimeMagicFile) participate in this select process. + Filename extensions that are only associated using the AddHandler, AddInputFilter or AddOutputFilter directives may be included or excluded + from matching by using the MultiviewsMatch directive.

    + +

    Charset

    +

    To convey this further information, Apache optionally sends + a Content-Language header, to specify the language + that the document is in, and can append additional information + onto the Content-Type header to indicate the + particular character set that should be used to correctly + render the information.

    + +

    +Content-Language: en, fr +Content-Type: text/plain; charset=ISO-8859-1 +

    + +

    The language specification is the two-letter abbreviation + for the language. The charset is the name of the + particular character set which should be used.

    +
    diff --git a/docs/manual/mod/mod_mime.html.fr b/docs/manual/mod/mod_mime.html.fr index 3f295748aee..0834c7199d7 100644 --- a/docs/manual/mod/mod_mime.html.fr +++ b/docs/manual/mod/mod_mime.html.fr @@ -123,148 +123,6 @@ multiples
  • SetOutputFilter
    • top
    -
    -

    Fichiers avec extensions -multiples

    -

    Les fichiers peuvent posséder plusieurs extensions dont l'ordre - est normalement sans importance. Par exemple, si - le fichier welcome.html.fr est associé au type de - contenu text/html et à la langue française, le fichier - welcome.fr.html possèdera exactement les même - métadonnées. Si le fichier possède plusieurs extensions associées - au même type de métadonnée, c'est celle de ces extensions la plus à - droite qui sera utilisée, excepté pour ce qui concerne les langues - et les codages de contenu. Par exemple, si .gif est - associé au type de médium - image/gif, et .html au type de médium - text/html, le fichier welcome.gif.html - sera associé au type de médium text/html.

    - -

    Les Languages et les codages de contenu sont traités de - manière cumulative, car il est possible d'assigner plusieurs - langues ou codages à une ressource particulière. Par exemple, le - fichier welcome.html.en.de sera servi avec les en-têtes - Content-Language: en, de et Content-Type: - text/html.

    - -

    Des précautions doivent être prises lorsqu'un fichier avec - extensions multiples est associé à la fois à un type de - médium et à un gestionnaire. En général, cela impliquera - la gestion de la requête par le module associé au gestionnaire. Par - exemple, si l'extension .imap est associée au - gestionnaire imap-file (du module - mod_imagemap), et si l'extension .html - est associée au type de médium text/html, le fichier - world.imap.html sera à la fois associé au gestionnaire - imap-file et au type de médium text/html. - Pour son traitement, c'est le gestionnaire imap-file - qui sera utilisé, et il sera donc traité en tant que fichier - imagemap.

    - -

    Si vous préférez que seule la dernière partie d'un nom de fichier - séparée du reste du nom par un point soit associée à une métadonnée - particulière, n'utilisez pas les directives Add*. Par - exemple, si vous souhaitez que le fichier foo.html.cgi - soit traité en tant que script CGI, mais pas le fichier - bar.cgi.html, alors, au lieu d'utiliser - AddHandler cgi-script .cgi, utilisez plutôt :

    - -

    Configuration du gestionnaire en se basant seulement - sur la dernière extension

    <FilesMatch \.cgi$>
-  SetHandler cgi-script
-</FilesMatch>
    -
    - -
    top
    -
    -

    Codage du contenu

    -

    Un fichier d'un type de médium particulier - peut être également codé d'une certaine manière pour simplifier sa - transmission sur Internet. Alors que cela concerne en général la - compression, comme gzip, il peut aussi s'agir de - chiffrement, comme pgp ou d'un codage comme UUencoding, - qui est conçu pour transmettre un fichier binaire sous un format - ASCII (texte).

    - -

    La RFC - HTTP/1.1, section 14.11 stipule à ce titre :

    - -
    -

    Le champ d'en-tête Content-Encoding de l'entité est utilisé en - tant que modificateur du type de médium. Lorsqu'il est présent, sa - valeur indique quels codages de contenu additionnels ont été - appliqués au corps de l'entité, et ainsi quels mécanismes de - décodage doivent être appliqués afin de retrouver le type de - médium référencé par le champ d'en-tête Content-Type. Le codage de - contenu est principalement utilisé pour permettre la compression - d'un document sans perdre l'information concernant le type de - médium sous-jacent.

    -
    - -

    En utilisant plusieurs extensions (voir la section ci-dessus à propos des extensions de - fichiers multiples), vous pouvez indiquer qu'un fichier est d'un - type, particulier, et possède aussi un codage - particulier.

    - -

    Considérons par exemple un fichier contenant un document - Microsoft Word et compressé par pkzip pour réduire sa taille. Si - l'extension .doc est associée au type de fichier - Microsoft Word, et si l'extension .zip est associée au - codage de fichier pkzip, alors le fichier - Resume.doc.zip sera identifié comme document Word - compressé par pkzip.

    - -

    Apache joint un en-tête Content-encoding à la - ressource afin d'informer le navigateur client à propos de la - méthode de codage.

    - - 
    Content-encoding: pkzip
    - -
    top
    -
    -

    Jeux de caractères et langues

    -

    En plus du type de fichier et du codage, un autre élément - important d'information est la langue dans laquelle le document est - écrit, et avec quel jeu de caractères le contenu du fichier doit - être affiché. Par exemple, un document peut être écrit en alphabet - vietnamien ou cyrillique, et doit être affiché en conséquence. Cette - information est également transmise via des en-têtes HTTP.

    - -

    Les jeu de caractères, langue, codage et type MIME sont tous - utilisés au cours du processus de négociation de contenu (voir - mod_negotiation) afin de déterminer quel document - servir au client, lorsque plusieurs choix sont possibles en fonction - du jeu de caractères, de la langue, du codage ou du type MIME. Toutes - les associations d'extensions de noms de fichiers créées via les - directives AddCharset, - AddEncoding, AddLanguage et AddType (ainsi que les associations - d'extensions listées dans le fichier défini par la directive - MimeMagicFile), - participent à ce processus de sélection. Les extensions de noms de - fichiers qui n'ont été associés que par des directives AddHandler, AddInputFilter ou AddOutputFilter, peuvent être incluses - ou exclues du processus de sélection en utilisant la directive - MultiviewsMatch.

    - -

    Jeu de caractères

    -

    Pour transmettre cette information supplémentaire, Apache peut - ajouter un en-tête Content-Language, afin de - spécifier la langue dans laquelle le document est écrit, et peut - ajouter des informations additionnelles à l'en-tête - Content-Type pour indiquer le jeu de caractères - particulier qui doit être utilisé pour restituer correctement le - document.

    - -

    - Content-Language: en, fr -Content-Type: text/plain; charset=ISO-8859-1 -

    - -

    La langue est spécifiée via son abréviation en deux lettres. Le - jeu de caractères est le nom du jeu de caractères - particulier qui doit être utilisé.

    - -
    -
    top

    Directive AddCharset

    Description:Maps the given filename extensions to the specified content @@ -1002,6 +869,139 @@ extensions
    + +
    top
    +
    +

    Fichiers avec extensions +multiples

    +

    Les fichiers peuvent posséder plusieurs extensions dont l'ordre + est normalement sans importance. Par exemple, si + le fichier welcome.html.fr est associé au type de + contenu text/html et à la langue française, le fichier + welcome.fr.html possèdera exactement les même + métadonnées. Si le fichier possède plusieurs extensions associées + au même type de métadonnée, c'est celle de ces extensions la plus à + droite qui sera utilisée, excepté pour ce qui concerne les langues + et les codages de contenu. Par exemple, si .gif est + associé au type de médium + image/gif, et .html au type de médium + text/html, le fichier welcome.gif.html + sera associé au type de médium text/html.

    + +

    Les Languages et les codages de contenu sont traités de + manière cumulative, car il est possible d'assigner plusieurs + langues ou codages à une ressource particulière. Par exemple, le + fichier welcome.html.en.de sera servi avec les en-têtes + Content-Language: en, de et Content-Type: + text/html.

    + +

    Des précautions doivent être prises lorsqu'un fichier avec + extensions multiples est associé à la fois à un type de + médium et à un gestionnaire. En général, cela impliquera + la gestion de la requête par le module associé au gestionnaire. Par + exemple, si l'extension .imap est associée au + gestionnaire imap-file (du module + mod_imagemap), et si l'extension .html + est associée au type de médium text/html, le fichier + world.imap.html sera à la fois associé au gestionnaire + imap-file et au type de médium text/html. + Pour son traitement, c'est le gestionnaire imap-file + qui sera utilisé, et il sera donc traité en tant que fichier + imagemap.

    + +

    Si vous préférez que seule la dernière partie d'un nom de fichier + séparée du reste du nom par un point soit associée à une métadonnée + particulière, n'utilisez pas les directives Add*. Par + exemple, si vous souhaitez que le fichier foo.html.cgi + soit traité en tant que script CGI, mais pas le fichier + bar.cgi.html, alors, au lieu d'utiliser + AddHandler cgi-script .cgi, utilisez plutôt :

    + +

    Configuration du gestionnaire en se basant seulement + sur la dernière extension

    <FilesMatch \.cgi$>
+  SetHandler cgi-script
+</FilesMatch>
    +
    + +
    top
    +
    +

    Codage du contenu

    +

    Un fichier d'un type de médium particulier + peut être également codé d'une certaine manière pour simplifier sa + transmission sur Internet. Alors que cela concerne en général la + compression, comme gzip, il peut aussi s'agir de + chiffrement, comme pgp ou d'un codage comme UUencoding, + qui est conçu pour transmettre un fichier binaire sous un format + ASCII (texte).

    + +

    La RFC + HTTP/1.1, section 14.11 stipule à ce titre :

    + +
    +

    Le champ d'en-tête Content-Encoding de l'entité est utilisé en + tant que modificateur du type de médium. Lorsqu'il est présent, sa + valeur indique quels codages de contenu additionnels ont été + appliqués au corps de l'entité, et ainsi quels mécanismes de + décodage doivent être appliqués afin de retrouver le type de + médium référencé par le champ d'en-tête Content-Type. Le codage de + contenu est principalement utilisé pour permettre la compression + d'un document sans perdre l'information concernant le type de + médium sous-jacent.

    +
    + +

    En utilisant plusieurs extensions (voir la section ci-dessus à propos des extensions de + fichiers multiples), vous pouvez indiquer qu'un fichier est d'un + type, particulier, et possède aussi un codage + particulier.

    + +

    Considérons par exemple un fichier contenant un document + Microsoft Word et compressé par pkzip pour réduire sa taille. Si + l'extension .doc est associée au type de fichier + Microsoft Word, et si l'extension .zip est associée au + codage de fichier pkzip, alors le fichier + Resume.doc.zip sera identifié comme document Word + compressé par pkzip.

    + +

    Apache joint un en-tête Content-encoding à la + ressource afin d'informer le navigateur client à propos de la + méthode de codage.

    + + 
    Content-encoding: pkzip
    + +
    top
    +
    +

    Jeux de caractères et langues

    +

    En plus du type de fichier et du codage, un autre élément + important d'information est la langue dans laquelle le document est + écrit, et avec quel jeu de caractères le contenu du fichier doit + être affiché. Par exemple, un document peut être écrit en alphabet + vietnamien ou cyrillique, et doit être affiché en conséquence. Cette + information est également transmise via des en-têtes HTTP.

    + +

    Les jeu de caractères, langue, codage et type MIME sont tous + utilisés au cours du processus de négociation de contenu (voir + mod_negotiation) afin de déterminer quel document + servir au client, lorsque plusieurs choix sont possibles en fonction + du jeu de caractères, de la langue, du codage ou du type MIME. Toutes + les associations d'extensions de noms de fichiers créées via les + directives AddCharset, + AddEncoding, AddLanguage et AddType (ainsi que les associations + d'extensions listées dans le fichier défini par la directive + MimeMagicFile), + participent à ce processus de sélection. Les extensions de noms de + fichiers qui n'ont été associés que par des directives AddHandler, AddInputFilter ou AddOutputFilter, peuvent être incluses + ou exclues du processus de sélection en utilisant la directive + MultiviewsMatch.

    + +

    Jeu de caractères

    +

    Pour transmettre cette information supplémentaire, Apache peut + ajouter un en-tête Content-Language, afin de + spécifier la langue dans laquelle le document est écrit, et peut + ajouter des informations additionnelles à l'en-tête + Content-Type pour indiquer le jeu de caractères + particulier qui doit être utilisé pour restituer correctement le + document.

    + +

    + Content-Language: en, fr +Content-Type: text/plain; charset=ISO-8859-1 +

    + +

    La langue est spécifiée via son abréviation en deux lettres. Le + jeu de caractères est le nom du jeu de caractères + particulier qui doit être utilisé.

    +
    diff --git a/docs/manual/mod/mod_mime.html.ja.utf8 b/docs/manual/mod/mod_mime.html.ja.utf8 index 787247b1a91..7e31da77be2 100644 --- a/docs/manual/mod/mod_mime.html.ja.utf8 +++ b/docs/manual/mod/mod_mime.html.ja.utf8 @@ -123,135 +123,6 @@
  • SetOutputFilter
    • top
    -
    -

    複数の拡張子のあるファイル

    -

    ファイルは複数の拡張子を持つことができ、拡張子の順番は通常は関係ありません。例えば、ファイル welcome.html.fr - がコンテントタイプは text/html - に、言語はフランス語にマップされる場合、welcome.fr.html - もまったく同じ情報にマップされます。 - 同じメタ情報にマップされる拡張子が複数あるときには、言語と - コンテントエンコーディングを除いて、 - 右側にあるものが使用されます。たとえば、.gif が MIME タイプ image/gif にマップされ、.html - が MIME タイプ text/html - にマップされる場合は、ファイル welcome.gif.html は - MIME タイプ text/html に関連付けられます。

    - -

    リソースに複数の言語やエンコーディングを関連付けること - ができるため、 - 言語とコンテントエンコーディングは前のものに追加されていきます。 - たとえば、ファイル welcome.html.en.de は - Content-Language: en, de と Content-Type: - text/html として送信されます。

    - -

    複数の拡張子のあるファイルが MIME - タイプとハンドラの両方に関連付けられているときは注意する必要があります。 - その場合、普通はリクエストがハンドラに関連付けられた - モジュールによって扱われることになります。たとえば、拡張子 - .imap が (mod_imagemap の) imap-file - にマップされていて、.html が MIME タイプ text/html - にマップされているときは、ファイル world.imap.html は - imap-file ハンドラと text/html MIME - タイプに関連付けられます。ファイルが処理されるときは imap-file - ハンドラが使用されますので、そのファイルは mod_imagemap - のイメージマップファイルとして扱われることになります。

    - -

    ファイル名のドット区切りでの最後の部分を使って、 - 特定の部分のメタデータにマッピングしたい場合は、 - Add* ディレクティブは使わないでください。 - たとえば foo.html.cgi を CGI スクリプトとして処理したいけれども、 - bar.cgi.html は CGI スクリプトとしては処理したくない場合、 - AddHandler cgi-script .cgi とする代わりに - 次のようにしてください

    - -

    Configure handler based on final extension only

    - <FilesMatch \.cgi$> - - SetHandler cgi-script - - </FilesMatch> -

    - -
    top
    -
    -

    コンテントエンコーディング

    -

    特定の MIME タイプ - のファイルはインターネットでの転送を簡単にするために、 - さらに符号化することができます。これは通常は gzip の - ような圧縮のことを指しますが、pgp のような暗号化や、 - バイナリファイルを ASCII (テキスト) 形式で送るために考案された - UUencoding のことを指すこともあります。

    - -

    HTTP/1.1 RFC - 14.11 節では次のように記述されています。

    - -
    -

    Content-Encoding エンティティヘッダフィールドはメディアタイプの - 修飾子として使われます。それが存在していれば、値はエンティティボディに - どの追加の符号化が適用されたかを示し、Content-Type ヘッダフィールドに - 書かれているメディアタイプを得るためにどの復号機構を適用すべきか、も - 示していることになります。Content-Encoding は主に、元のメディアタイプの - 同一性を失うことなくドキュメントを圧縮することを可能にするために - 使用されます。

    -
    - -

    複数のファイル拡張子 (複数の拡張子については 上の節 を参照) 使うことで、 - ファイルのタイプやエンコーディングを指定することが - できます。

    - -

    たとえば、Microsoft Word のドキュメントがあり、サイズを小さくするために - pkzip されているとします。.doc 拡張子が Microsoft Word の - ファイルタイプと関連付けられていて、.zip 拡張子が - pkzip ファイルエンコーディングと関連付けられていると、ファイル - Resume.doc.zip は pkzip された Word ドキュメントである - ということがわかります。

    - -

    クライアントのブラウザにエンコーディング方法を知らせるために、 - Apache はリソースと共に Content-Encoding ヘッダを - 送ります。

    - -

    Content-encoding: pkzip

    -
    top
    -
    -

    文字セットと言語

    -

    ファイルタイプとファイルエンコーディングの他に重要な情報は - ドキュメントの書かれている言語と、どの文字セットでファイルが表示 - されるべきか、というものです。たとえば、ドキュメントはベトナムの - アルファベットやキリル文字で書かれていて、そのように表示される - 必要があるかもしれません。この情報もまた、HTTP ヘッダで - 送信されます。

    - -

    文字セット、言語、エンコーディング、mime タイプはすべて - コンテントネゴシエーション (mod_negotiation 参照) - の最中に、複数の文字セット、言語、エンコーディング、MIME タイプからなる - 代替物があるときにどのドキュメントをクライアントに送るのかを - 決定するときに使われます。AddCharset, - AddEncoding, AddLanguage, - AddType の各ディレクティブで作成された - 拡張子の関連付け (と MimeMagicFile でリストされている - 拡張子) がこの選択に参加します。AddHandler, - AddInputFilter, - AddOutputFilter の - 各ディレクティブでのみ関連付けられている拡張子は - MultiviewsMatch ディレクティブを - 使うことでマッチの - 処理に含めることも外すこともできます。

    - -

    Charset

    -

    さらに情報を伝えるために、Apache は文書の言語を - Content-Language ヘッダで送ることもあります。 - また、情報を正しく表示するために使用すべき文字セットを示すために - Conten-Type ヘッダに情報を追加することもあります。

    - -

    - Content-Language: en, fr
    - Content-Type: text/plain; charset=ISO-8859-1 -

    - -

    言語の指定は二文字の短縮形で行なわれます。charset が - 使用すべき文字セットの名前です。

    - -
    -
    top

    AddCharset ディレクティブ

    Description:Associe les extensions de noms de fichiers spécifiées au @@ -1075,6 +933,148 @@ d'extensions de noms de fichiers
    @@ -976,6 +847,135 @@ + +
    top
    +
    +

    複数の拡張子のあるファイル

    +

    ファイルは複数の拡張子を持つことができ、拡張子の順番は通常は関係ありません。例えば、ファイル welcome.html.fr + がコンテントタイプは text/html + に、言語はフランス語にマップされる場合、welcome.fr.html + もまったく同じ情報にマップされます。 + 同じメタ情報にマップされる拡張子が複数あるときには、言語と + コンテントエンコーディングを除いて、 + 右側にあるものが使用されます。たとえば、.gif が MIME タイプ image/gif にマップされ、.html + が MIME タイプ text/html + にマップされる場合は、ファイル welcome.gif.html は + MIME タイプ text/html に関連付けられます。

    + +

    リソースに複数の言語やエンコーディングを関連付けること + ができるため、 + 言語とコンテントエンコーディングは前のものに追加されていきます。 + たとえば、ファイル welcome.html.en.de は + Content-Language: en, de と Content-Type: + text/html として送信されます。

    + +

    複数の拡張子のあるファイルが MIME + タイプとハンドラの両方に関連付けられているときは注意する必要があります。 + その場合、普通はリクエストがハンドラに関連付けられた + モジュールによって扱われることになります。たとえば、拡張子 + .imap が (mod_imagemap の) imap-file + にマップされていて、.html が MIME タイプ text/html + にマップされているときは、ファイル world.imap.html は + imap-file ハンドラと text/html MIME + タイプに関連付けられます。ファイルが処理されるときは imap-file + ハンドラが使用されますので、そのファイルは mod_imagemap + のイメージマップファイルとして扱われることになります。

    + +

    ファイル名のドット区切りでの最後の部分を使って、 + 特定の部分のメタデータにマッピングしたい場合は、 + Add* ディレクティブは使わないでください。 + たとえば foo.html.cgi を CGI スクリプトとして処理したいけれども、 + bar.cgi.html は CGI スクリプトとしては処理したくない場合、 + AddHandler cgi-script .cgi とする代わりに + 次のようにしてください

    + +

    Configure handler based on final extension only

    + <FilesMatch \.cgi$> + + SetHandler cgi-script + + </FilesMatch> +

    + +
    top
    +
    +

    コンテントエンコーディング

    +

    特定の MIME タイプ + のファイルはインターネットでの転送を簡単にするために、 + さらに符号化することができます。これは通常は gzip の + ような圧縮のことを指しますが、pgp のような暗号化や、 + バイナリファイルを ASCII (テキスト) 形式で送るために考案された + UUencoding のことを指すこともあります。

    + +

    HTTP/1.1 RFC + 14.11 節では次のように記述されています。

    + +
    +

    Content-Encoding エンティティヘッダフィールドはメディアタイプの + 修飾子として使われます。それが存在していれば、値はエンティティボディに + どの追加の符号化が適用されたかを示し、Content-Type ヘッダフィールドに + 書かれているメディアタイプを得るためにどの復号機構を適用すべきか、も + 示していることになります。Content-Encoding は主に、元のメディアタイプの + 同一性を失うことなくドキュメントを圧縮することを可能にするために + 使用されます。

    +
    + +

    複数のファイル拡張子 (複数の拡張子については 上の節 を参照) 使うことで、 + ファイルのタイプやエンコーディングを指定することが + できます。

    + +

    たとえば、Microsoft Word のドキュメントがあり、サイズを小さくするために + pkzip されているとします。.doc 拡張子が Microsoft Word の + ファイルタイプと関連付けられていて、.zip 拡張子が + pkzip ファイルエンコーディングと関連付けられていると、ファイル + Resume.doc.zip は pkzip された Word ドキュメントである + ということがわかります。

    + +

    クライアントのブラウザにエンコーディング方法を知らせるために、 + Apache はリソースと共に Content-Encoding ヘッダを + 送ります。

    + +

    Content-encoding: pkzip

    +
    top
    +
    +

    文字セットと言語

    +

    ファイルタイプとファイルエンコーディングの他に重要な情報は + ドキュメントの書かれている言語と、どの文字セットでファイルが表示 + されるべきか、というものです。たとえば、ドキュメントはベトナムの + アルファベットやキリル文字で書かれていて、そのように表示される + 必要があるかもしれません。この情報もまた、HTTP ヘッダで + 送信されます。

    + +

    文字セット、言語、エンコーディング、mime タイプはすべて + コンテントネゴシエーション (mod_negotiation 参照) + の最中に、複数の文字セット、言語、エンコーディング、MIME タイプからなる + 代替物があるときにどのドキュメントをクライアントに送るのかを + 決定するときに使われます。AddCharset, + AddEncoding, AddLanguage, + AddType の各ディレクティブで作成された + 拡張子の関連付け (と MimeMagicFile でリストされている + 拡張子) がこの選択に参加します。AddHandler, + AddInputFilter, + AddOutputFilter の + 各ディレクティブでのみ関連付けられている拡張子は + MultiviewsMatch ディレクティブを + 使うことでマッチの + 処理に含めることも外すこともできます。

    + +

    Charset

    +

    さらに情報を伝えるために、Apache は文書の言語を + Content-Language ヘッダで送ることもあります。 + また、情報を正しく表示するために使用すべき文字セットを示すために + Conten-Type ヘッダに情報を追加することもあります。

    + +

    + Content-Language: en, fr
    + Content-Type: text/plain; charset=ISO-8859-1 +

    + +

    言語の指定は二文字の短縮形で行なわれます。charset が + 使用すべき文字セットの名前です。

    +
    diff --git a/docs/manual/mod/mod_mime_magic.html.en b/docs/manual/mod/mod_mime_magic.html.en index 89b612d21b5..75d28c6251a 100644 --- a/docs/manual/mod/mod_mime_magic.html.en +++ b/docs/manual/mod/mod_mime_magic.html.en @@ -57,6 +57,28 @@
  • Notes
    • top
    +

    MimeMagicFile Directive

    +
    説明:ファイル名の拡張子を指定された文字セットにマップする
    + + + + + +
    Description:Enable MIME-type determination based on file contents +using the specified magic file
    Syntax:MimeMagicFile file-path
    Context:server config, virtual host
    Status:Extension
    Module:mod_mime_magic
    +

    The MimeMagicFile directive can be used to + enable this module, the default file is distributed at + conf/magic. Non-rooted paths are relative to the + ServerRoot. Virtual hosts will use + the same file as the main server unless a more specific setting is + used, in which case the more specific setting overrides the main + server's file.

    + +

    Example

    MimeMagicFile conf/magic
    +
    + +
    +
    top

    Format of the Magic File

    @@ -246,28 +268,6 @@ used here.
    - -
    top
    -

    MimeMagicFile Directive

    - - - - - - -
    Description:Enable MIME-type determination based on file contents -using the specified magic file
    Syntax:MimeMagicFile file-path
    Context:server config, virtual host
    Status:Extension
    Module:mod_mime_magic
    -

    The MimeMagicFile directive can be used to - enable this module, the default file is distributed at - conf/magic. Non-rooted paths are relative to the - ServerRoot. Virtual hosts will use - the same file as the main server unless a more specific setting is - used, in which case the more specific setting overrides the main - server's file.

    - -

    Example

    MimeMagicFile conf/magic
    -
    -
    diff --git a/docs/manual/mod/mod_mime_magic.html.fr b/docs/manual/mod/mod_mime_magic.html.fr index 065dc3b313d..f76c015e2d4 100644 --- a/docs/manual/mod/mod_mime_magic.html.fr +++ b/docs/manual/mod/mod_mime_magic.html.fr @@ -58,6 +58,29 @@ octets de son contenu
  • Notes
    • top
    +

    Directive MimeMagicFile

    + + + + + + +
    Description:Active la détermination du type MIME en se basant sur le +contenu du fichier et en utilisant le fichier magique +spécifié
    Syntaxe:MimeMagicFile chemin-fichier
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_mime_magic
    +

    La directive MimeMagicFile permet + d'activer ce module, le fichier par défaut fourni étant + conf/magic. Les chemins sans slash '/' de début sont + relatifs au répertoire défini par la directive ServerRoot. Les serveurs virtuels + utilisent le même fichier que le serveur principal sauf si un + fichier spécifique a été défini pour ce serveur virtuel, auquel cas + c'est ce dernier fichier qui sera utilisé.

    + +

    Exemple

    MimeMagicFile conf/magic
    +
    + +
    +
    top

    Format du fichier magique

    @@ -253,29 +276,6 @@ octets de son contenu used here.
    - -
    top
    -

    Directive MimeMagicFile

    - - - - - - -
    Description:Active la détermination du type MIME en se basant sur le -contenu du fichier et en utilisant le fichier magique -spécifié
    Syntaxe:MimeMagicFile chemin-fichier
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_mime_magic
    -

    La directive MimeMagicFile permet - d'activer ce module, le fichier par défaut fourni étant - conf/magic. Les chemins sans slash '/' de début sont - relatifs au répertoire défini par la directive ServerRoot. Les serveurs virtuels - utilisent le même fichier que le serveur principal sauf si un - fichier spécifique a été défini pour ce serveur virtuel, auquel cas - c'est ce dernier fichier qui sera utilisé.

    - -

    Exemple

    MimeMagicFile conf/magic
    -
    -
    diff --git a/docs/manual/mod/mod_negotiation.html.en b/docs/manual/mod/mod_negotiation.html.en index 6ca0fcc54a4..7be5c8e17fd 100644 --- a/docs/manual/mod/mod_negotiation.html.en +++ b/docs/manual/mod/mod_negotiation.html.en @@ -69,6 +69,118 @@ Negotiation
  • Environment Variables
    • top
    +

    CacheNegotiatedDocs Directive

    + + + + + + + +
    Description:Allows content-negotiated documents to be +cached by proxy servers
    Syntax:CacheNegotiatedDocs On|Off
    Default:CacheNegotiatedDocs Off
    Context:server config, virtual host
    Status:Base
    Module:mod_negotiation
    +

    If set, this directive allows content-negotiated documents + to be cached by proxy servers. This could mean that clients + behind those proxys could retrieve versions of the documents + that are not the best match for their abilities, but it will + make caching more efficient.

    + +

    This directive only applies to requests which come from + HTTP/1.0 browsers. HTTP/1.1 provides much better control over + the caching of negotiated documents, and this directive has no + effect in responses to HTTP/1.1 requests.

    + + +
    +
    top
    +

    ForceLanguagePriority Directive

    + + + + + + + + +
    Description:Action to take if a single acceptable document is not +found
    Syntax:ForceLanguagePriority None|Prefer|Fallback [Prefer|Fallback]
    Default:ForceLanguagePriority Prefer
    Context:server config, virtual host, directory, .htaccess
    Override:FileInfo
    Status:Base
    Module:mod_negotiation
    +

    The ForceLanguagePriority directive uses + the given LanguagePriority to satisfy + negotiation where the server could otherwise not return a single + matching document.

    + +

    ForceLanguagePriority Prefer uses + LanguagePriority to serve a one valid result, rather + than returning an HTTP result 300 (MULTIPLE CHOICES) when there + are several equally valid choices. If the directives below were + given, and the user's Accept-Language header assigned + en and de each as quality .500 + (equally acceptable) then the first matching variant, en, + will be served.

    + + 
    LanguagePriority en fr de
+ForceLanguagePriority Prefer
    + + +

    ForceLanguagePriority Fallback uses + LanguagePriority to + serve a valid result, rather than returning an HTTP result 406 + (NOT ACCEPTABLE). If the directives below were given, and the user's + Accept-Language only permitted an es + language response, but such a variant isn't found, then the first + variant from the LanguagePriority list below will be served.

    + + 
    LanguagePriority en fr de
+ForceLanguagePriority Fallback
    + + +

    Both options, Prefer and Fallback, may be + specified, so either the first matching variant from LanguagePriority will be served if + more than one variant is acceptable, or first available document will + be served if none of the variants matched the client's acceptable list + of languages.

    + +

    See also

    + +
    +
    top
    +

    LanguagePriority Directive

    + + + + + + + +
    Description:The precendence of language variants for cases where +the client does not express a preference
    Syntax:LanguagePriority MIME-lang [MIME-lang] +...
    Context:server config, virtual host, directory, .htaccess
    Override:FileInfo
    Status:Base
    Module:mod_negotiation
    +

    The LanguagePriority sets the precedence + of language variants for the case where the client does not + express a preference, when handling a Multiviews request. The list + of MIME-lang are in order of decreasing preference.

    + + 
    LanguagePriority en fr de
    + + +

    For a request for foo.html, where + foo.html.fr and foo.html.de both + existed, but the browser did not express a language preference, + then foo.html.fr would be returned.

    + +

    Note that this directive only has an effect if a 'best' + language cannot be determined by any other means or the ForceLanguagePriority directive + is not None. In general, the client determines the + language preference, not the server.

    + +

    See also

    + +
    +
    top

    Type maps

    A type map has a format similar to RFC822 mail headers. It @@ -226,118 +338,6 @@ Negotiation that do not have content negotiation meta-information assigned to them when choosing files.

    -
    top
    -

    CacheNegotiatedDocs Directive

    - - - - - - - -
    Description:Allows content-negotiated documents to be -cached by proxy servers
    Syntax:CacheNegotiatedDocs On|Off
    Default:CacheNegotiatedDocs Off
    Context:server config, virtual host
    Status:Base
    Module:mod_negotiation
    -

    If set, this directive allows content-negotiated documents - to be cached by proxy servers. This could mean that clients - behind those proxys could retrieve versions of the documents - that are not the best match for their abilities, but it will - make caching more efficient.

    - -

    This directive only applies to requests which come from - HTTP/1.0 browsers. HTTP/1.1 provides much better control over - the caching of negotiated documents, and this directive has no - effect in responses to HTTP/1.1 requests.

    - - -
    -
    top
    -

    ForceLanguagePriority Directive

    - - - - - - - - -
    Description:Action to take if a single acceptable document is not -found
    Syntax:ForceLanguagePriority None|Prefer|Fallback [Prefer|Fallback]
    Default:ForceLanguagePriority Prefer
    Context:server config, virtual host, directory, .htaccess
    Override:FileInfo
    Status:Base
    Module:mod_negotiation
    -

    The ForceLanguagePriority directive uses - the given LanguagePriority to satisfy - negotiation where the server could otherwise not return a single - matching document.

    - -

    ForceLanguagePriority Prefer uses - LanguagePriority to serve a one valid result, rather - than returning an HTTP result 300 (MULTIPLE CHOICES) when there - are several equally valid choices. If the directives below were - given, and the user's Accept-Language header assigned - en and de each as quality .500 - (equally acceptable) then the first matching variant, en, - will be served.

    - - 
    LanguagePriority en fr de
-ForceLanguagePriority Prefer
    - - -

    ForceLanguagePriority Fallback uses - LanguagePriority to - serve a valid result, rather than returning an HTTP result 406 - (NOT ACCEPTABLE). If the directives below were given, and the user's - Accept-Language only permitted an es - language response, but such a variant isn't found, then the first - variant from the LanguagePriority list below will be served.

    - - 
    LanguagePriority en fr de
-ForceLanguagePriority Fallback
    - - -

    Both options, Prefer and Fallback, may be - specified, so either the first matching variant from LanguagePriority will be served if - more than one variant is acceptable, or first available document will - be served if none of the variants matched the client's acceptable list - of languages.

    - -

    See also

    - -
    -
    top
    -

    LanguagePriority Directive

    - - - - - - - -
    Description:The precendence of language variants for cases where -the client does not express a preference
    Syntax:LanguagePriority MIME-lang [MIME-lang] -...
    Context:server config, virtual host, directory, .htaccess
    Override:FileInfo
    Status:Base
    Module:mod_negotiation
    -

    The LanguagePriority sets the precedence - of language variants for the case where the client does not - express a preference, when handling a Multiviews request. The list - of MIME-lang are in order of decreasing preference.

    - - 
    LanguagePriority en fr de
    - - -

    For a request for foo.html, where - foo.html.fr and foo.html.de both - existed, but the browser did not express a language preference, - then foo.html.fr would be returned.

    - -

    Note that this directive only has an effect if a 'best' - language cannot be determined by any other means or the ForceLanguagePriority directive - is not None. In general, the client determines the - language preference, not the server.

    - -

    See also

    - -

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_negotiation.html.fr b/docs/manual/mod/mod_negotiation.html.fr index 448adfb247d..d17973fb960 100644 --- a/docs/manual/mod/mod_negotiation.html.fr +++ b/docs/manual/mod/mod_negotiation.html.fr @@ -69,6 +69,128 @@ contenu

  • Variables d'environnement
    • top
    +

    Directive CacheNegotiatedDocs

    + + + + + + + +
    Description:Permet la mise en cache au niveau des serveurs mandataires +des documents dont le contenu a été négocié
    Syntaxe:CacheNegotiatedDocs On|Off
    Défaut:CacheNegotiatedDocs Off
    Contexte:configuration du serveur, serveur virtuel
    Statut:Base
    Module:mod_negotiation
    +

    Si elle est définie à "on", cette directive permet la mise en + cache au niveau des serveurs mandataires des documents dont le + contenu a été négocié. Le processus de mise en cache sera alors plus + efficace, mais des clients se trouvant derrière le mandataire + seront alors susceptibles de se voir servir des versions de + documents qui ne correspondent pas forcément à leurs attentes.

    + +

    Cette directive ne s'applique qu'aux requêtes en provenance de + navigateurs HTTP/1.0. HTTP/1.1 fournit un bien meilleur contrôle de + la mise en cache des documents au contenu négocié, et cette + directive n'a aucun effet sur les réponses aux requêtes + HTTP/1.1.

    + + +
    +
    top
    +

    Directive ForceLanguagePriority

    + + + + + + + + +
    Description:Action à entreprendre si un document acceptable unique +n'est pas trouvé
    Syntaxe:ForceLanguagePriority None|Prefer|Fallback [Prefer|Fallback]
    Défaut:ForceLanguagePriority Prefer
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:FileInfo
    Statut:Base
    Module:mod_negotiation
    +

    La directive ForceLanguagePriority utilise + le langage défini par la directive LanguagePriority pour terminer + la négociation lorsque le serveur n'est pas en mesure de trouver une + solution satisfaisante unique.

    + +

    ForceLanguagePriority Prefer utilise la directive + LanguagePriority pour servir le résultat d'un choix + unique, au lieu de renvoyer un résultat HTTP 300 (MULTIPLE CHOICES), + lorsque que plusieurs choix équivalents sont disponibles. Par + exemple, avec les deux directives ci-dessous, si l'en-tête + Accept-Language de l'utilisateur assigne à + en et de une qualité de .500 + (les deux langages sont également acceptables), alors c'est la + première variante acceptable de langue en qui sera + servie.

    + + 
    LanguagePriority en fr de
+ForceLanguagePriority Prefer
    + + +

    ForceLanguagePriority Fallback utilise la directive + LanguagePriority + pour servir un résultat valide, au lieu de renvoyer un résultat HTTP + 406 (NOT ACCEPTABLE). Avec les deux directives ci-dessous, si + l'en-tête Accept-Language de l'utilisateur ne mentionne + que les réponses de langage es, et si aucune variante + dans cette langue n'est trouvée, c'est la première variante de la + liste définie par la directive LanguagePriority qui sera servie.

    + + 
    LanguagePriority en fr de
+ForceLanguagePriority Fallback
    + + +

    Les deux options, Prefer et Fallback, + peuvent être spécifiées, de façon à ce que la variante servie soit + la première variante qui convient définie par la directive + LanguagePriority si + plusieurs variantes sont également acceptables, ou le premier + document disponible si aucune variante ne convient à la liste de + langages acceptables fournie par le client.

    + +

    Voir aussi

    + +
    +
    top
    +

    Directive LanguagePriority

    + + + + + + + +
    Description:L'ordre de priorité des variantes de langages pour les +cas où le client n'a pas formulé de préférences
    Syntaxe:LanguagePriority langage-MIME [langage-MIME] +...
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:FileInfo
    Statut:Base
    Module:mod_negotiation
    +

    La directive LanguagePriority permet de + définir, au cours du traitement d'une requête Multivues, l'ordre de + priorité des variantes de langages pour les cas + où le client n'a pas formulé de préférences. La liste énumère les + langages-MIME dans un ordre de préférences + décroissantes.

    + + 
    LanguagePriority en fr de
    + + +

    Dans le cas d'une requête pour foo.html, si + foo.html.fr et foo.html.de existent, et si + le client n'a pas formulé de préférences, c'est le fichier + foo.html.fr qui sera renvoyé.

    + +

    Notez que cette directive n'a d'effet que si le 'meilleur' + langage n'a pas pu être déterminé d'une autre manière ou si la + valeur de la directive ForceLanguagePriority est + différente de None. En général, c'est le client qui + détermine le langage préféré, non le serveur.

    + +

    Voir aussi

    + +
    +
    top

    Tables de correspondances de types

    Une table de correspondances de types possède un format similaire @@ -232,128 +354,6 @@ contenu prendre en compte les fichiers qui ne comportent pas de métadonnées de négociation de contenu lors du choix du fichier à servir.

    -
    top
    -

    Directive CacheNegotiatedDocs

    - - - - - - - -
    Description:Permet la mise en cache au niveau des serveurs mandataires -des documents dont le contenu a été négocié
    Syntaxe:CacheNegotiatedDocs On|Off
    Défaut:CacheNegotiatedDocs Off
    Contexte:configuration du serveur, serveur virtuel
    Statut:Base
    Module:mod_negotiation
    -

    Si elle est définie à "on", cette directive permet la mise en - cache au niveau des serveurs mandataires des documents dont le - contenu a été négocié. Le processus de mise en cache sera alors plus - efficace, mais des clients se trouvant derrière le mandataire - seront alors susceptibles de se voir servir des versions de - documents qui ne correspondent pas forcément à leurs attentes.

    - -

    Cette directive ne s'applique qu'aux requêtes en provenance de - navigateurs HTTP/1.0. HTTP/1.1 fournit un bien meilleur contrôle de - la mise en cache des documents au contenu négocié, et cette - directive n'a aucun effet sur les réponses aux requêtes - HTTP/1.1.

    - - -
    -
    top
    -

    Directive ForceLanguagePriority

    - - - - - - - - -
    Description:Action à entreprendre si un document acceptable unique -n'est pas trouvé
    Syntaxe:ForceLanguagePriority None|Prefer|Fallback [Prefer|Fallback]
    Défaut:ForceLanguagePriority Prefer
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:FileInfo
    Statut:Base
    Module:mod_negotiation
    -

    La directive ForceLanguagePriority utilise - le langage défini par la directive LanguagePriority pour terminer - la négociation lorsque le serveur n'est pas en mesure de trouver une - solution satisfaisante unique.

    - -

    ForceLanguagePriority Prefer utilise la directive - LanguagePriority pour servir le résultat d'un choix - unique, au lieu de renvoyer un résultat HTTP 300 (MULTIPLE CHOICES), - lorsque que plusieurs choix équivalents sont disponibles. Par - exemple, avec les deux directives ci-dessous, si l'en-tête - Accept-Language de l'utilisateur assigne à - en et de une qualité de .500 - (les deux langages sont également acceptables), alors c'est la - première variante acceptable de langue en qui sera - servie.

    - - 
    LanguagePriority en fr de
-ForceLanguagePriority Prefer
    - - -

    ForceLanguagePriority Fallback utilise la directive - LanguagePriority - pour servir un résultat valide, au lieu de renvoyer un résultat HTTP - 406 (NOT ACCEPTABLE). Avec les deux directives ci-dessous, si - l'en-tête Accept-Language de l'utilisateur ne mentionne - que les réponses de langage es, et si aucune variante - dans cette langue n'est trouvée, c'est la première variante de la - liste définie par la directive LanguagePriority qui sera servie.

    - - 
    LanguagePriority en fr de
-ForceLanguagePriority Fallback
    - - -

    Les deux options, Prefer et Fallback, - peuvent être spécifiées, de façon à ce que la variante servie soit - la première variante qui convient définie par la directive - LanguagePriority si - plusieurs variantes sont également acceptables, ou le premier - document disponible si aucune variante ne convient à la liste de - langages acceptables fournie par le client.

    - -

    Voir aussi

    - -
    -
    top
    -

    Directive LanguagePriority

    - - - - - - - -
    Description:L'ordre de priorité des variantes de langages pour les -cas où le client n'a pas formulé de préférences
    Syntaxe:LanguagePriority langage-MIME [langage-MIME] -...
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:FileInfo
    Statut:Base
    Module:mod_negotiation
    -

    La directive LanguagePriority permet de - définir, au cours du traitement d'une requête Multivues, l'ordre de - priorité des variantes de langages pour les cas - où le client n'a pas formulé de préférences. La liste énumère les - langages-MIME dans un ordre de préférences - décroissantes.

    - - 
    LanguagePriority en fr de
    - - -

    Dans le cas d'une requête pour foo.html, si - foo.html.fr et foo.html.de existent, et si - le client n'a pas formulé de préférences, c'est le fichier - foo.html.fr qui sera renvoyé.

    - -

    Notez que cette directive n'a d'effet que si le 'meilleur' - langage n'a pas pu être déterminé d'une autre manière ou si la - valeur de la directive ForceLanguagePriority est - différente de None. En général, c'est le client qui - détermine le langage préféré, non le serveur.

    - -

    Voir aussi

    - -

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_negotiation.html.ja.utf8 b/docs/manual/mod/mod_negotiation.html.ja.utf8 index abea7eb3f87..98349e6dcc3 100644 --- a/docs/manual/mod/mod_negotiation.html.ja.utf8 +++ b/docs/manual/mod/mod_negotiation.html.ja.utf8 @@ -71,114 +71,6 @@

  • 環境変数
    • top
    -
    -

    タイプマップ

    -

    タイプマップは RFC 822 のメールヘッダに類似した書式です。 - ドキュメントの記述が空行で分離されて書かれていて、ハッシュ文字 - ('#') で始まる行はコメントとして扱われます。 - ドキュメントの説明は複数のヘッダレコードから構成されます。 - レコードは、続きの行が空白で始まっていると複数の行にまたがります。 - 最初の空白が消去されて、前の行とつなげて 1 行として扱われます。 - ヘッダレコードはキーワード名の後に値が続くという形式で、 - キーワード名は常にコロンで終わります。空白はヘッダ名と値の間、 - 値のトークンの間に入れることができます。 - 使用可能なヘッダは以下のとおりです:

    - -
    -
    Content-Encoding:
    -
    ファイルのエンコーディング。Apache は AddEncoding ディレクティブ - で定義されたエンコーディングだけを認識します。通常 compress - されたファイルのための x-compress と gzip - されたファイルのための x-gzip を含みます。 - エンコーディングの比較をするときは、接頭辞 x- - は無視されます。
    - -
    Content-Language:
    -
    インターネット標準の言語タグ - (RFC 1766) - で定義されている言語の種類。例えば、en - は英語を表します。 - 複数の言語が格納される場合はコンマで区切られます。
    - -
    Content-Length:
    -
    ファイルの長さ (バイト数)。 - このヘッダがない場合、ファイルの実際の長さが使用されます。
    - -
    Content-Type:
    -
    ドキュメントの MIME - メディアタイプ、オプショナルなパラメータ付き。パラメータの構文は - name=value - で、メディアタイプや他のパラメータとはセミコロンで分離されます。 - 共通のパラメータは以下のとおり: - -
    -
    level
    -
    メディアタイプのバージョンを示す整数。 - text/html では 2 がデフォルトで、その他の場合は - 0 がデフォルトです。
    - -
    qs
    -
    クライアントの能力に関係なく、variant - を他と比較したときの相対的な「品質」で、0.0 から 1.0 - の範囲の浮動点小数。 - 例えば、写真を表現しようとしているときは普通は JPEG - ファイルの方が ASCII ファイルよりも高い品質になります。 - しかし、リソースが ASCII アートで表現されているときは、ASCII - ファイルの方が JPEG - ファイルよりも高い品質になります。このように、qs - はリソース毎に特有の値を取ります。 -
    -
    - -

    例

    - Content-Type: image/jpeg; qs=0.8 -

    -
    - -
    URI:
    -
    (指定のメディアタイプ、コンテントエンコーディングの) variant の - ファイルの uri. これは、マップファイルからの相対 URL として - 解釈されます。同じサーバに存在しなければならず、クライアントが - 直接リクエストしたときにアクセスを許可されるものでなければなりません。
    - -
    Body:
    -
    Apache 2.0 で新設されたこの Body ヘッダを使って、 - リソースの実際の内容をタイプマップファイルに書くことができます。 - このヘッダは本文の内容の区切りとなる文字列で始まる必要があります。 - タイプマップファイルの続く行は、区切り文字列が見つかるまで、 - リソースの本文になります。 - -

    Example:

    - Body:----xyz----
    - <html>
    - <body>
    - <p>Content of the page.</p>
    - </body>
    - </html>
    - ----xyz---- -

    -
    -
    -
    top
    -
    -

    MultiViews

    -

    MultiViews 探索は、Multiviews Options ディレクティブにより有効になります。 - サーバが /some/dir/foo - へのリクエストを受け取り、/some/dir/foo が存在 - しない場合、サーバはディレクトリを読んで、 - foo.* にあてはまる全てのファイルを探し、 - 事実上それらのファイルをマップするタイプマップを作ります。 - そのとき、メディアタイプとコンテントエンコーディングは、 - そのファイル名を直接指定したときと同じものが割り当てられます。 - それからクライアントの要求に一番合うものを選び、 - そのドキュメントを返します。

    - -

    ファイルを選択する際に、関連するコンテントネゴシエーションの - メタ情報を持たないファイルについて、判定を行うかどうかを - MultiViewsMatch - ディレクティブで設定します。

    -
    -
    top

    CacheNegotiatedDocs ディレクティブ

    説明:コンテントネゴシエーションされたドキュメントをプロキシサーバが @@ -298,6 +190,114 @@
  • AddLanguage
    • +
    top
    +
    +

    タイプマップ

    +

    タイプマップは RFC 822 のメールヘッダに類似した書式です。 + ドキュメントの記述が空行で分離されて書かれていて、ハッシュ文字 + ('#') で始まる行はコメントとして扱われます。 + ドキュメントの説明は複数のヘッダレコードから構成されます。 + レコードは、続きの行が空白で始まっていると複数の行にまたがります。 + 最初の空白が消去されて、前の行とつなげて 1 行として扱われます。 + ヘッダレコードはキーワード名の後に値が続くという形式で、 + キーワード名は常にコロンで終わります。空白はヘッダ名と値の間、 + 値のトークンの間に入れることができます。 + 使用可能なヘッダは以下のとおりです:

    + +
    +
    Content-Encoding:
    +
    ファイルのエンコーディング。Apache は AddEncoding ディレクティブ + で定義されたエンコーディングだけを認識します。通常 compress + されたファイルのための x-compress と gzip + されたファイルのための x-gzip を含みます。 + エンコーディングの比較をするときは、接頭辞 x- + は無視されます。
    + +
    Content-Language:
    +
    インターネット標準の言語タグ + (RFC 1766) + で定義されている言語の種類。例えば、en + は英語を表します。 + 複数の言語が格納される場合はコンマで区切られます。
    + +
    Content-Length:
    +
    ファイルの長さ (バイト数)。 + このヘッダがない場合、ファイルの実際の長さが使用されます。
    + +
    Content-Type:
    +
    ドキュメントの MIME + メディアタイプ、オプショナルなパラメータ付き。パラメータの構文は + name=value + で、メディアタイプや他のパラメータとはセミコロンで分離されます。 + 共通のパラメータは以下のとおり: + +
    +
    level
    +
    メディアタイプのバージョンを示す整数。 + text/html では 2 がデフォルトで、その他の場合は + 0 がデフォルトです。
    + +
    qs
    +
    クライアントの能力に関係なく、variant + を他と比較したときの相対的な「品質」で、0.0 から 1.0 + の範囲の浮動点小数。 + 例えば、写真を表現しようとしているときは普通は JPEG + ファイルの方が ASCII ファイルよりも高い品質になります。 + しかし、リソースが ASCII アートで表現されているときは、ASCII + ファイルの方が JPEG + ファイルよりも高い品質になります。このように、qs + はリソース毎に特有の値を取ります。 +
    +
    + +

    例

    + Content-Type: image/jpeg; qs=0.8 +

    +
    + +
    URI:
    +
    (指定のメディアタイプ、コンテントエンコーディングの) variant の + ファイルの uri. これは、マップファイルからの相対 URL として + 解釈されます。同じサーバに存在しなければならず、クライアントが + 直接リクエストしたときにアクセスを許可されるものでなければなりません。
    + +
    Body:
    +
    Apache 2.0 で新設されたこの Body ヘッダを使って、 + リソースの実際の内容をタイプマップファイルに書くことができます。 + このヘッダは本文の内容の区切りとなる文字列で始まる必要があります。 + タイプマップファイルの続く行は、区切り文字列が見つかるまで、 + リソースの本文になります。 + +

    Example:

    + Body:----xyz----
    + <html>
    + <body>
    + <p>Content of the page.</p>
    + </body>
    + </html>
    + ----xyz---- +

    +
    +
    +
    top
    +
    +

    MultiViews

    +

    MultiViews 探索は、Multiviews Options ディレクティブにより有効になります。 + サーバが /some/dir/foo + へのリクエストを受け取り、/some/dir/foo が存在 + しない場合、サーバはディレクトリを読んで、 + foo.* にあてはまる全てのファイルを探し、 + 事実上それらのファイルをマップするタイプマップを作ります。 + そのとき、メディアタイプとコンテントエンコーディングは、 + そのファイル名を直接指定したときと同じものが割り当てられます。 + それからクライアントの要求に一番合うものを選び、 + そのドキュメントを返します。

    + +

    ファイルを選択する際に、関連するコンテントネゴシエーションの + メタ情報を持たないファイルについて、判定を行うかどうかを + MultiViewsMatch + ディレクティブで設定します。

    +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_nw_ssl.html.en b/docs/manual/mod/mod_nw_ssl.html.en index b93bb6c103b..f7067c995ee 100644 --- a/docs/manual/mod/mod_nw_ssl.html.en +++ b/docs/manual/mod/mod_nw_ssl.html.en @@ -45,7 +45,6 @@

  • SecureListen
    • -
    top

    NWSSLTrustedCerts Directive

    @@ -92,6 +91,7 @@ parameter also enables mutual authentication.

    +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_nw_ssl.html.fr b/docs/manual/mod/mod_nw_ssl.html.fr index 4c12fef2d69..ee14dd10c4d 100644 --- a/docs/manual/mod/mod_nw_ssl.html.fr +++ b/docs/manual/mod/mod_nw_ssl.html.fr @@ -45,7 +45,6 @@

  • SecureListen
    • -
    top

    Directive NWSSLTrustedCerts

    @@ -96,6 +95,7 @@ sp d'activer l'authentification mutuelle.

    +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_privileges.html.en b/docs/manual/mod/mod_privileges.html.en index 54758a89340..e4fcc747e2c 100644 --- a/docs/manual/mod/mod_privileges.html.en +++ b/docs/manual/mod/mod_privileges.html.en @@ -77,65 +77,6 @@ separation is an issue.

  • Security Considerations
    • top
    -
    -

    Security Considerations

    - -

    mod_privileges introduces new security concerns -in situations where untrusted code may be run -within the webserver process. This applies to -untrusted modules, and scripts running under modules such as -mod_php or mod_perl. Scripts running externally (e.g. as CGI -or in an appserver behind mod_proxy or mod_jk) are NOT affected.

    - -

    The basic security concerns with mod_privileges are:

    -
    • Running as a system user introduces the same security issues - as mod_suexec, and near-equivalents such as cgiwrap and suphp.
      • -
    • A privileges-aware malicious user extension (module or script) - could escalate its privileges to anything available to the - httpd process in any virtual host. This introduces new risks - if (and only if) mod_privileges is compiled with the - BIG_SECURITY_HOLE option.
      • -
    • A privileges-aware malicious user extension (module or script) - could escalate privileges to set its user ID to another system - user (and/or group).
      • -
    - -

    The PrivilegesMode directive allows you to -select either FAST or SECURE mode. You can -mix modes, using FAST mode for trusted users and -fully-audited code paths, while imposing SECURE mode where an -untrusted user has scope to introduce code.

    -

    Before describing the modes, we should also introduce the target -use cases: Benign vs Hostile. In a benign situation, you want to -separate users for their convenience, and protect them and the server -against the risks posed by honest mistakes, but you trust your users -are not deliberately subverting system security. In a hostile -situation - e.g. commercial hosting - you may have users deliberately -attacking the system or each other.

    -
    -
    FAST mode
    -
    In FAST mode, requests are run in-process with the -selected uid/gid and privileges, so the overhead is negligible. -This is suitable for benign situations, but is not secure against an -attacker escalating privileges with an in-process module or script.
    -
    SECURE mode
    -
    A request in SECURE mode forks a subprocess, which -then drops privileges. This is a very similar case to running CGI -with suexec, but for the entire request cycle, and with the benefit -of fine-grained control of privileges.
    -
    -

    You can select different PrivilegesModes for -each virtual host, and even in a directory context within a virtual -host. FAST mode is appropriate where the user(s) are -trusted and/or have no privilege to load in-process code. -SECURE mode is appropriate to cases where untrusted code -might be run in-process. However, even in SECURE mode, -there is no protection against a malicious user who is able to -introduce privileges-aware code running before the start of the -request-processing cycle.

    - -
    -
    top

    DTracePrivileges Directive

    @@ -391,6 +332,65 @@ non-threaded MPMs (preforkUser
  • SuexecUserGroup
    • + +
    top
    +
    +

    Security Considerations

    + +

    mod_privileges introduces new security concerns +in situations where untrusted code may be run +within the webserver process. This applies to +untrusted modules, and scripts running under modules such as +mod_php or mod_perl. Scripts running externally (e.g. as CGI +or in an appserver behind mod_proxy or mod_jk) are NOT affected.

    + +

    The basic security concerns with mod_privileges are:

    +
    • Running as a system user introduces the same security issues + as mod_suexec, and near-equivalents such as cgiwrap and suphp.
      • +
    • A privileges-aware malicious user extension (module or script) + could escalate its privileges to anything available to the + httpd process in any virtual host. This introduces new risks + if (and only if) mod_privileges is compiled with the + BIG_SECURITY_HOLE option.
      • +
    • A privileges-aware malicious user extension (module or script) + could escalate privileges to set its user ID to another system + user (and/or group).
      • +
    + +

    The PrivilegesMode directive allows you to +select either FAST or SECURE mode. You can +mix modes, using FAST mode for trusted users and +fully-audited code paths, while imposing SECURE mode where an +untrusted user has scope to introduce code.

    +

    Before describing the modes, we should also introduce the target +use cases: Benign vs Hostile. In a benign situation, you want to +separate users for their convenience, and protect them and the server +against the risks posed by honest mistakes, but you trust your users +are not deliberately subverting system security. In a hostile +situation - e.g. commercial hosting - you may have users deliberately +attacking the system or each other.

    +
    +
    FAST mode
    +
    In FAST mode, requests are run in-process with the +selected uid/gid and privileges, so the overhead is negligible. +This is suitable for benign situations, but is not secure against an +attacker escalating privileges with an in-process module or script.
    +
    SECURE mode
    +
    A request in SECURE mode forks a subprocess, which +then drops privileges. This is a very similar case to running CGI +with suexec, but for the entire request cycle, and with the benefit +of fine-grained control of privileges.
    +
    +

    You can select different PrivilegesModes for +each virtual host, and even in a directory context within a virtual +host. FAST mode is appropriate where the user(s) are +trusted and/or have no privilege to load in-process code. +SECURE mode is appropriate to cases where untrusted code +might be run in-process. However, even in SECURE mode, +there is no protection against a malicious user who is able to +introduce privileges-aware code running before the start of the +request-processing cycle.

    +
    diff --git a/docs/manual/mod/mod_privileges.html.fr b/docs/manual/mod/mod_privileges.html.fr index 1207d81b7f8..cc775932531 100644 --- a/docs/manual/mod/mod_privileges.html.fr +++ b/docs/manual/mod/mod_privileges.html.fr @@ -82,79 +82,6 @@ s
  • Considérations à propos de sécurité
    • top
    -
    -

    Considérations à propos de sécurité

    - -

    mod_privileges introduit de nouveaux problèmes de -sécurité dans les situations où du code non sûr peut -s'exécuter à l'intérieur du processus du serveur web. -Ceci s'applique aux modules non sûrs, et aux scripts s'exécutant sous -des modules comme mod_php ou mod_perl. Les scripts s'exécutant en -externe (comme par exemple les scripts CGI ou ceux s'exécutant sur un -serveur d'applications derrière mod_proxy ou mod_jk) ne sont pas -concernés.

    - -

    Les principaux problèmes de sécurité que l'on rencontre avec -mod_privileges sont :

    - - -
    • L'exécution sous un utilisateur système pose les mêmes problèmes -de sécurité que mod_suexec, et pratiquement les mêmes que cgiwrap et -suphp.
      • -
    • Une extension utilisateur (module ou script) malveillante, écrite en connaissant les mécanismes -utilisés par mod_privileges, -pourrait élever ses privilèges à tout niveau -accessible au processus httpd dans tout serveur virtuel. Ceci introduit -de nouveaux risques si (et seulement si) mod_privileges est compilé avec -l'option BIG_SECURITY_HOLE.
      • -
    • Une extension utilisateur (module ou script) malveillante, écrite en connaissant les mécanismes -utilisés par mod_privileges, -pourrait élever ses privilèges pour s'attribuer -l'identifiant utilisateur d'un autre utilisateur (et/ou groupe) -système.
      • -
    - -

    La directive PrivilegesMode vous permet de -sélectionner soit le mode FAST, soit le mode -SECURE. Vous pouvez panacher les modes en utilisant par -exemple le mode FAST pour les utilisateurs de confiance et -les chemins contenant du code entièrement audité, tout en imposant le -mode SECURE où un utilisateur non sûr a la possibilité -d'introduire du code.

    -

    Avant de décrire les modes, il nous faut présenter les cas -d'utilisation de la cible : "Benign" ou "Hostile". Dans une situation -"Benign", vous voulez séparer les utilisateurs pour leur confort, et les -protéger, ainsi que le serveur, contre les risques induits par les -erreurs involontaires. Dans une situation "Hostile" - par exemple -l'hébergement d'un site commercial - il se peut que des utilisateurs -attaquent délibérément le serveur ou s'attaquent entre eux.

    -
    -
    Mode FAST
    -
    En mode FAST, les requêtes sont traitées "in-process" -avec les uid/gid et privilèges sélectionnés, si bien que la -surcharge est négligeable. Ceci convient aux situations "Benign", mais -n'est pas sécurisé contre un attaquant augmentant ses privilèges avec un -module ou script "in-process".
    -
    Mode SECURE
    -
    Une requête en mode SECURE génère un sous-processus qui -supprime les privilèges. Ce comportement est très similaire à -l'exécution d'un programme CGI avec suexec, mais il reste valable tout -au long du cycle de traitement de la requête, avec en plus l'avantage -d'un contrôle précis des privilèges.
    -
    -

    Vous pouvez sélectionner différents -PrivilegesModes pour chaque serveur virtuel, et -même dans un contexte de répertoire à l'intérieur d'un serveur virtuel. -Le mode FAST convient lorsque les utilisateurs sont sûrs -et/ou n'ont pas le privilège de charger du code "in-process". Le mode -SECURE convient dans les cas où du code non sûr peut -s'exécuter "in-process". Cependant, même en mode SECURE, il -n'y a pas de protection contre un utilisateur malveillant qui a la -possibilité d'introduire du code supportant les privilèges avant le -début du cycle de traitement de la requête.

    - -
    -
    top

    Directive DTracePrivileges

    Description:Determines whether the privileges required by dtrace are enabled.
    -
    Description:Détermine si les privilèges requis par dtrace sont @@ -444,6 +371,79 @@ personnalis
  • User
  • SuexecUserGroup
    • + +
    top
    +
    +

    Considérations à propos de sécurité

    + +

    mod_privileges introduit de nouveaux problèmes de +sécurité dans les situations où du code non sûr peut +s'exécuter à l'intérieur du processus du serveur web. +Ceci s'applique aux modules non sûrs, et aux scripts s'exécutant sous +des modules comme mod_php ou mod_perl. Les scripts s'exécutant en +externe (comme par exemple les scripts CGI ou ceux s'exécutant sur un +serveur d'applications derrière mod_proxy ou mod_jk) ne sont pas +concernés.

    + +

    Les principaux problèmes de sécurité que l'on rencontre avec +mod_privileges sont :

    + + +
    • L'exécution sous un utilisateur système pose les mêmes problèmes +de sécurité que mod_suexec, et pratiquement les mêmes que cgiwrap et +suphp.
      • +
    • Une extension utilisateur (module ou script) malveillante, écrite en connaissant les mécanismes +utilisés par mod_privileges, +pourrait élever ses privilèges à tout niveau +accessible au processus httpd dans tout serveur virtuel. Ceci introduit +de nouveaux risques si (et seulement si) mod_privileges est compilé avec +l'option BIG_SECURITY_HOLE.
      • +
    • Une extension utilisateur (module ou script) malveillante, écrite en connaissant les mécanismes +utilisés par mod_privileges, +pourrait élever ses privilèges pour s'attribuer +l'identifiant utilisateur d'un autre utilisateur (et/ou groupe) +système.
      • +
    + +

    La directive PrivilegesMode vous permet de +sélectionner soit le mode FAST, soit le mode +SECURE. Vous pouvez panacher les modes en utilisant par +exemple le mode FAST pour les utilisateurs de confiance et +les chemins contenant du code entièrement audité, tout en imposant le +mode SECURE où un utilisateur non sûr a la possibilité +d'introduire du code.

    +

    Avant de décrire les modes, il nous faut présenter les cas +d'utilisation de la cible : "Benign" ou "Hostile". Dans une situation +"Benign", vous voulez séparer les utilisateurs pour leur confort, et les +protéger, ainsi que le serveur, contre les risques induits par les +erreurs involontaires. Dans une situation "Hostile" - par exemple +l'hébergement d'un site commercial - il se peut que des utilisateurs +attaquent délibérément le serveur ou s'attaquent entre eux.

    +
    +
    Mode FAST
    +
    En mode FAST, les requêtes sont traitées "in-process" +avec les uid/gid et privilèges sélectionnés, si bien que la +surcharge est négligeable. Ceci convient aux situations "Benign", mais +n'est pas sécurisé contre un attaquant augmentant ses privilèges avec un +module ou script "in-process".
    +
    Mode SECURE
    +
    Une requête en mode SECURE génère un sous-processus qui +supprime les privilèges. Ce comportement est très similaire à +l'exécution d'un programme CGI avec suexec, mais il reste valable tout +au long du cycle de traitement de la requête, avec en plus l'avantage +d'un contrôle précis des privilèges.
    +
    +

    Vous pouvez sélectionner différents +PrivilegesModes pour chaque serveur virtuel, et +même dans un contexte de répertoire à l'intérieur d'un serveur virtuel. +Le mode FAST convient lorsque les utilisateurs sont sûrs +et/ou n'ont pas le privilège de charger du code "in-process". Le mode +SECURE convient dans les cas où du code non sûr peut +s'exécuter "in-process". Cependant, même en mode SECURE, il +n'y a pas de protection contre un utilisateur malveillant qui a la +possibilité d'introduire du code supportant les privilèges avant le +début du cycle de traitement de la requête.

    +
    diff --git a/docs/manual/mod/mod_proxy.html.en b/docs/manual/mod/mod_proxy.html.en index 758bb382f3d..0b1b8f8c7c1 100644 --- a/docs/manual/mod/mod_proxy.html.en +++ b/docs/manual/mod/mod_proxy.html.en @@ -145,893 +145,558 @@
  • mod_ssl
    • top
    -
    -

    Forward Proxies and Reverse - Proxies/Gateways

    -

    Apache HTTP Server can be configured in both a forward and - reverse proxy (also known as gateway) mode.

    - -

    An ordinary forward proxy is an intermediate - server that sits between the client and the origin - server. In order to get content from the origin server, - the client sends a request to the proxy naming the origin server - as the target and the proxy then requests the content from the - origin server and returns it to the client. The client must be - specially configured to use the forward proxy to access other - sites.

    - -

    A typical usage of a forward proxy is to provide Internet - access to internal clients that are otherwise restricted by a - firewall. The forward proxy can also use caching (as provided - by mod_cache) to reduce network usage.

    - -

    The forward proxy is activated using the ProxyRequests directive. Because - forward proxies allow clients to access arbitrary sites through - your server and to hide their true origin, it is essential that - you secure your server so that only - authorized clients can access the proxy before activating a - forward proxy.

    - -

    A reverse proxy (or gateway), by - contrast, appears to the client just like an ordinary web - server. No special configuration on the client is necessary. - The client makes ordinary requests for content in the name-space - of the reverse proxy. The reverse proxy then decides where to - send those requests, and returns the content as if it was itself - the origin.

    - -

    A typical usage of a reverse proxy is to provide Internet - users access to a server that is behind a firewall. Reverse - proxies can also be used to balance load among several back-end - servers, or to provide caching for a slower back-end server. - In addition, reverse proxies can be used simply to bring - several servers into the same URL space.

    - -

    A reverse proxy is activated using the ProxyPass directive or the - [P] flag to the RewriteRule directive. It is - not necessary to turn ProxyRequests on in order to - configure a reverse proxy.

    -
    top
    -
    -

    Basic Examples

    - -

    The examples below are only a very basic idea to help you - get started. Please read the documentation on the individual - directives.

    - -

    In addition, if you wish to have caching enabled, consult - the documentation from mod_cache.

    +

    BalancerGrowth Directive

    + + + + + + + + +
    Description:Number of additional Balancers that can be added Post-configuration
    Syntax:BalancerGrowth #
    Default:BalancerGrowth 5
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    Compatibility:BalancerGrowth is only available in Apache HTTP Server 2.3.13 + and later.
    +

    This directive allows for growth potential in the number of + Balancers available for a virtualhost in addition to the + number pre-configured. It only takes effect if there is at + least 1 pre-configured Balancer.

    -

    Reverse Proxy

    ProxyPass "/foo" "http://foo.example.com/bar"
-ProxyPassReverse "/foo" "http://foo.example.com/bar"
    - -

    Forward Proxy

    ProxyRequests On
-ProxyVia On
-
-<Proxy "*">
-  Require host internal.example.com
-</Proxy>
    +
    top
    +

    BalancerInherit Directive

    + + + + + + + + +
    Description:Inherit ProxyPassed Balancers/Workers from the main server
    Syntax:BalancerInherit On|Off
    Default:BalancerInherit On
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    Compatibility:BalancerInherit is only available in Apache HTTP Server 2.4.5 and later.
    +

    This directive will cause the current server/vhost to "inherit" ProxyPass + Balancers and Workers defined in the main server. This can cause issues and + inconsistent behavior if using the Balancer Manager and so should be disabled + if using that feature.

    +

    The setting in the global server defines the default for all vhosts.

    +
    -
    top
    -
    -

    Access via Handler

    - -

    You can also force a request to be handled as a reverse-proxy - request, by creating a suitable Handler pass-through. The example - configuration below will pass all requests for PHP scripts to the - specified FastCGI server using reverse proxy: -

    +
    top
    +

    BalancerMember Directive

    + + + + + + + +
    Description:Add a member to a load balancing group
    Syntax:BalancerMember [balancerurl] url [key=value [key=value ...]]
    Context:directory
    Status:Extension
    Module:mod_proxy
    Compatibility:BalancerMember is only available in Apache HTTP Server 2.2 + and later.
    +

    This directive adds a member to a load balancing group. It could be used + within a <Proxy balancer://...> container + directive, and can take any of the key value pair parameters available to + ProxyPass directives.

    +

    One additional parameter is available only to BalancerMember directives: + loadfactor. This is the member load factor - a number between 1 + (default) and 100, which defines the weighted load to be applied to the + member in question.

    +

    The balancerurl is only needed when not in + <Proxy balancer://...> + container directive. It corresponds to the url of a balancer defined in + ProxyPass directive.

    +

    The path component of the balancer URL in any + <Proxy balancer://...> container directive + is ignored.

    +

    Trailing slashes should typically be removed from the URL of a + BalancerMember.

    + +
    +
    top
    +

    BalancerPersist Directive

    + + + + + + + + +
    Description:Attempt to persist changes made by the Balancer Manager across restarts.
    Syntax:BalancerPersist On|Off
    Default:BalancerPersist Off
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    Compatibility:BalancerPersist is only available in Apache HTTP Server 2.4.4 and later.
    +

    This directive will cause the shared memory storage associated + with the balancers and balancer members to be persisted across + restarts. This allows these local changes to not be lost during the + normal restart/graceful state transitions.

    + +
    +
    top
    +

    NoProxy Directive

    + + + + + + +
    Description:Hosts, domains, or networks that will be connected to +directly
    Syntax:NoProxy host [host] ...
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    +

    This directive is only useful for Apache httpd proxy servers within + intranets. The NoProxy directive specifies a + list of subnets, IP addresses, hosts and/or domains, separated by + spaces. A request to a host which matches one or more of these is + always served directly, without forwarding to the configured + ProxyRemote proxy server(s).

    -

    Reverse Proxy PHP scripts

    <FilesMatch "\.php$">
-    # Unix sockets require 2.4.7 or later
-    SetHandler  "proxy:unix:/path/to/app.sock|fcgi://localhost/"
-</FilesMatch>
    +

    Example

    ProxyRemote  "*"  "http://firewall.example.com:81"
+NoProxy         ".example.com" "192.168.112.0/21"
    -

    This feature is available in Apache HTTP Server 2.4.10 and later.

    +

    The host arguments to the NoProxy + directive are one of the following type list:

    -
    top
    -
    -

    Workers

    -

    The proxy manages the configuration of origin servers and their - communication parameters in objects called workers. - There are two built-in workers, the default forward proxy worker and the - default reverse proxy worker. Additional workers can be configured - explicitly.

    +
    + +
    Domain
    +
    +

    A Domain is a partially qualified DNS domain name, preceded + by a period. It represents a list of hosts which logically belong to the + same DNS domain or zone (i.e., the suffixes of the hostnames are + all ending in Domain).

    -

    The two default workers have a fixed configuration - and will be used if no other worker matches the request. - They do not use HTTP Keep-Alive or connection pooling. - The TCP connections to the origin server will instead be - opened and closed for each request.

    +

    Examples

    + .com .example.org. +

    -

    Explicitly configured workers are identified by their URL. - They are usually created and configured using - ProxyPass or - ProxyPassMatch when used - for a reverse proxy:

    +

    To distinguish Domains from Hostnames (both syntactically and semantically; a DNS domain can + have a DNS A record, too!), Domains are always written with a + leading period.

    - 
    ProxyPass "/example" "http://backend.example.com" connectiontimeout=5 timeout=30
    +

    Note

    +

    Domain name comparisons are done without regard to the case, and + Domains are always assumed to be anchored in the root of the + DNS tree, therefore two domains .ExAmple.com and + .example.com. (note the trailing period) are considered + equal. Since a domain comparison does not involve a DNS lookup, it is much + more efficient than subnet comparison.

    +
    + +
    SubNet
    +
    +

    A SubNet is a partially qualified internet address in + numeric (dotted quad) form, optionally followed by a slash and the netmask, + specified as the number of significant bits in the SubNet. It is + used to represent a subnet of hosts which can be reached over a common + network interface. In the absence of the explicit net mask it is assumed + that omitted (or zero valued) trailing digits specify the mask. (In this + case, the netmask can only be multiples of 8 bits wide.) Examples:

    -

    This will create a worker associated with the origin server URL - http://backend.example.com and using the given timeout - values. When used in a forward proxy, workers are usually defined - via the ProxySet directive:

    +
    +
    192.168 or 192.168.0.0
    +
    the subnet 192.168.0.0 with an implied netmask of 16 valid bits + (sometimes used in the netmask form 255.255.0.0)
    +
    192.168.112.0/21
    +
    the subnet 192.168.112.0/21 with a netmask of 21 + valid bits (also used in the form 255.255.248.0)
    +
    - 
    ProxySet "http://backend.example.com" connectiontimeout=5 timeout=30
    +

    As a degenerate case, a SubNet with 32 valid bits is the + equivalent to an IPAddr, while a SubNet with zero + valid bits (e.g., 0.0.0.0/0) is the same as the constant + _Default_, matching any IP address.

    + +
    IPAddr
    +
    +

    A IPAddr represents a fully qualified internet address in + numeric (dotted quad) form. Usually, this address represents a host, but + there need not necessarily be a DNS domain name connected with the + address.

    +

    Example

    + 192.168.123.7 +

    -

    or alternatively using Proxy - and ProxySet:

    +

    Note

    +

    An IPAddr does not need to be resolved by the DNS system, so + it can result in more effective apache performance.

    +
    - 
    <Proxy "http://backend.example.com">
-  ProxySet connectiontimeout=5 timeout=30
-</Proxy>
    + +
    Hostname
    +
    +

    A Hostname is a fully qualified DNS domain name which can + be resolved to one or more IPAddrs via the + DNS domain name service. It represents a logical host (in contrast to + Domains, see above) and must be resolvable + to at least one IPAddr (or often to a list + of hosts with different IPAddrs).

    +

    Examples

    + prep.ai.example.edu
    + www.example.org +

    -

    Using explicitly configured workers in the forward mode is - not very common, because forward proxies usually communicate with many - different origin servers. Creating explicit workers for some of the - origin servers can still be useful, if they are used very often. - Explicitly configured workers have no concept of forward or reverse - proxying by themselves. They encapsulate a common concept of - communication with origin servers. A worker created by - ProxyPass for use in a - reverse proxy will be also used for forward proxy requests whenever - the URL to the origin server matches the worker URL and vice versa.

    +

    Note

    +

    In many situations, it is more effective to specify an IPAddr in place of a Hostname since a + DNS lookup can be avoided. Name resolution in Apache httpd can take a remarkable + deal of time when the connection to the name server uses a slow PPP + link.

    +

    Hostname comparisons are done without regard to the case, + and Hostnames are always assumed to be anchored in the root + of the DNS tree, therefore two hosts WWW.ExAmple.com + and www.example.com. (note the trailing period) are + considered equal.

    +
    +
    -

    The URL identifying a direct worker is the URL of its - origin server including any path components given:

    +

    See also

    + +
    +
    top
    +

    <Proxy> Directive

    + + + + + + +
    Description:Container for directives applied to proxied resources
    Syntax:<Proxy wildcard-url> ...</Proxy>
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    +

    Directives placed in <Proxy> + sections apply only to matching proxied content. Shell-style wildcards are + allowed.

    - 
    ProxyPass "/examples" "http://backend.example.com/examples"
-ProxyPass "/docs" "http://backend.example.com/docs"
    +

    For example, the following will allow only hosts in + yournetwork.example.com to access content via your proxy + server:

    + 
    <Proxy "*">
+  Require host yournetwork.example.com
+</Proxy>
    -

    This example defines two different workers, each using a separate - connection pool and configuration.

    -

    Worker Sharing

    -

    Worker sharing happens if the worker URLs overlap, which occurs when - the URL of some worker is a leading substring of the URL of another - worker defined later in the configuration file. In the following example

    +

    The following example will process all files in the foo + directory of example.com through the INCLUDES + filter when they are sent through the proxy server:

    - 
    ProxyPass "/apps" "http://backend.example.com/" timeout=60
-ProxyPass "/examples" "http://backend.example.com/examples" timeout=10
    + 
    <Proxy "http://example.com/foo/*">
+  SetOutputFilter INCLUDES
+</Proxy>
    -

    the second worker isn't actually created. Instead the first - worker is used. The benefit is, that there is only one connection pool, - so connections are more often reused. Note that all configuration attributes - given explicitly for the later worker will be ignored. This will be logged - as a warning. In the above example the resulting timeout value - for the URL /examples will be 60 instead - of 10!

    +

    Differences from the Location configuration section

    +

    A backend URL matches the configuration section if it begins with the + the wildcard-url string, even if the last path segment in the + directive only matches a prefix of the backend URL. For example, + <Proxy "http://example.com/foo"> matches all of + http://example.com/foo, http://example.com/foo/bar, and + http://example.com/foobar. The matching of the final URL differs + from the behavior of the <Location> section, which for purposes of this note + treats the final path component as if it ended in a slash.

    +

    For more control over the matching, see <ProxyMatch>.

    +
    -

    If you want to avoid worker sharing, sort your worker definitions - by URL length, starting with the longest worker URLs. If you want to maximize - worker sharing use the reverse sort order. See also the related warning about - ordering ProxyPass directives.

    -
    +

    See also

    + +
    +
    top
    +

    ProxyAddHeaders Directive

    + + + + + + + + +
    Description:Add proxy information in X-Forwarded-* headers
    Syntax:ProxyAddHeaders Off|On
    Default:ProxyAddHeaders On
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_proxy
    Compatibility:Available in version 2.3.10 and later
    +

    This directive determines whether or not proxy related information should be passed to the + backend server through X-Forwarded-For, X-Forwarded-Host and X-Forwarded-Server HTTP headers.

    +

    Effectiveness

    +

    This option is of use only for HTTP proxying, as handled by mod_proxy_http.

    +
    -

    Explicitly configured workers come in two flavors: - direct workers and (load) balancer workers. - They support many important configuration attributes which are - described below in the ProxyPass - directive. The same attributes can also be set using - ProxySet.

    +
    +
    top
    +

    ProxyBadHeader Directive

    + + + + + + + +
    Description:Determines how to handle bad header lines in a +response
    Syntax:ProxyBadHeader IsError|Ignore|StartBody
    Default:ProxyBadHeader IsError
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    +

    The ProxyBadHeader directive determines the + behaviour of mod_proxy if it receives syntactically invalid + response header lines (i.e. containing no colon) from the origin + server. The following arguments are possible:

    -

    The set of options available for a direct worker - depends on the protocol, which is specified in the origin server URL. - Available protocols include ajp, fcgi, - ftp, http and scgi.

    +
    +
    IsError
    +
    Abort the request and end up with a 502 (Bad Gateway) response. This is + the default behaviour.
    -

    Balancer workers are virtual workers that use direct workers known - as their members to actually handle the requests. Each balancer can - have multiple members. When it handles a request, it chooses a member - based on the configured load balancing algorithm.

    +
    Ignore
    +
    Treat bad header lines as if they weren't sent.
    -

    A balancer worker is created if its worker URL uses - balancer as the protocol scheme. - The balancer URL uniquely identifies the balancer worker. - Members are added to a balancer using - BalancerMember.

    +
    StartBody
    +
    When receiving the first bad header line, finish reading the headers and + treat the remainder as body. This helps to work around buggy backend servers + which forget to insert an empty line between the headers and the body.
    +
    -
    top
    -
    -

    Controlling access to your proxy

    -

    You can control who can access your proxy via the <Proxy> control block as in - the following example:

    +
    +
    top
    +

    ProxyBlock Directive

    + + + + + + +
    Description:Words, hosts, or domains that are banned from being +proxied
    Syntax:ProxyBlock *|word|host|domain +[word|host|domain] ...
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    +

    The ProxyBlock directive specifies a list of + words, hosts and/or domains, separated by spaces. HTTP, HTTPS, and + FTP document requests to sites whose names contain matched words, + hosts or domains are blocked by the proxy server. The proxy + module will also attempt to determine IP addresses of list items which + may be hostnames during startup, and cache them for match test as + well. That may slow down the startup time of the server.

    - 
    <Proxy "*">
-  Require ip 192.168.0
-</Proxy>
    +

    Example

    ProxyBlock "news.example.com" "auctions.example.com" "friends.example.com"
    +
    +

    Note that example would also be sufficient to match any + of these sites.

    -

    For more information on access control directives, see - mod_authz_host.

    +

    Hosts would also be matched if referenced by IP address.

    -

    Strictly limiting access is essential if you are using a - forward proxy (using the ProxyRequests directive). - Otherwise, your server can be used by any client to access - arbitrary hosts while hiding his or her true identity. This is - dangerous both for your network and for the Internet at large. - When using a reverse proxy (using the ProxyPass directive with - ProxyRequests Off), access control is less - critical because clients can only contact the hosts that you - have specifically configured.

    +

    Note also that

    -

    See Also the Proxy-Chain-Auth environment variable.

    + 
    ProxyBlock "*"
    -
    top
    -
    -

    Slow Startup

    -

    If you're using the ProxyBlock directive, hostnames' IP addresses are looked up - and cached during startup for later match test. This may take a few - seconds (or more) depending on the speed with which the hostname lookups - occur.

    -
    top
    -
    -

    Intranet Proxy

    -

    An Apache httpd proxy server situated in an intranet needs to forward - external requests through the company's firewall (for this, configure - the ProxyRemote directive - to forward the respective scheme to the firewall proxy). - However, when it has to - access resources within the intranet, it can bypass the firewall when - accessing hosts. The NoProxy - directive is useful for specifying which hosts belong to the intranet and - should be accessed directly.

    -

    Users within an intranet tend to omit the local domain name from their - WWW requests, thus requesting "http://somehost/" instead of - http://somehost.example.com/. Some commercial proxy servers - let them get away with this and simply serve the request, implying a - configured local domain. When the ProxyDomain directive is used and the server is configured for proxy service, Apache httpd can return - a redirect response and send the client to the correct, fully qualified, - server address. This is the preferred method since the user's bookmark - files will then contain fully qualified hosts.

    -
    top
    -
    -

    Protocol Adjustments

    -

    For circumstances where mod_proxy is sending - requests to an origin server that doesn't properly implement - keepalives or HTTP/1.1, there are two environment variables that can force the - request to use HTTP/1.0 with no keepalive. These are set via the - SetEnv directive.

    - -

    These are the force-proxy-request-1.0 and - proxy-nokeepalive notes.

    - - 
    <Location "/buggyappserver/">
-  ProxyPass "http://buggyappserver:7001/foo/"
-  SetEnv force-proxy-request-1.0 1
-  SetEnv proxy-nokeepalive 1
-</Location>
    - - -
    top
    -
    -

    Request Bodies

    - -

    Some request methods such as POST include a request body. - The HTTP protocol requires that requests which include a body - either use chunked transfer encoding or send a - Content-Length request header. When passing these - requests on to the origin server, mod_proxy_http - will always attempt to send the Content-Length. But - if the body is large and the original request used chunked - encoding, then chunked encoding may also be used in the upstream - request. You can control this selection using environment variables. Setting - proxy-sendcl ensures maximum compatibility with - upstream servers by always sending the - Content-Length, while setting - proxy-sendchunked minimizes resource usage by using - chunked encoding.

    - -

    Under some circumstances, the server must spool request bodies - to disk to satisfy the requested handling of request bodies. For - example, this spooling will occur if the original body was sent with - chunked encoding (and is large), but the administrator has - asked for backend requests to be sent with Content-Length or as HTTP/1.0. - This spooling can also occur if the request body already has a - Content-Length header, but the server is configured to filter incoming - request bodies.

    - -

    LimitRequestBody only applies to - request bodies that the server will spool to disk

    - -
    top
    -
    -

    Reverse Proxy Request Headers

    - -

    When acting in a reverse-proxy mode (using the ProxyPass directive, for example), - mod_proxy_http adds several request headers in - order to pass information to the origin server. These headers - are:

    - -
    -
    X-Forwarded-For
    -
    The IP address of the client.
    -
    X-Forwarded-Host
    -
    The original host requested by the client in the Host - HTTP request header.
    -
    X-Forwarded-Server
    -
    The hostname of the proxy server.
    -
    - -

    Be careful when using these headers on the origin server, since - they will contain more than one (comma-separated) value if the - original request already contained one of these headers. For - example, you can use %{X-Forwarded-For}i in the log - format string of the origin server to log the original clients IP - address, but you may get more than one address if the request - passes through several proxies.

    - -

    See also the ProxyPreserveHost and ProxyVia directives, which control - other request headers.

    - -

    Note: If you need to specify custom request headers to be - added to the forwarded request, use the - RequestHeader - directive.

    +

    blocks connections to all sites.

    -
    +
    top
    -

    BalancerGrowth Directive

    +

    ProxyDomain Directive

    - - - + + -
    Description:Number of additional Balancers that can be added Post-configuration
    Syntax:BalancerGrowth #
    Default:BalancerGrowth 5
    Description:Default domain name for proxied requests
    Syntax:ProxyDomain Domain
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    Compatibility:BalancerGrowth is only available in Apache HTTP Server 2.3.13 - and later.
    -

    This directive allows for growth potential in the number of - Balancers available for a virtualhost in addition to the - number pre-configured. It only takes effect if there is at - least 1 pre-configured Balancer.

    +

    This directive is only useful for Apache httpd proxy servers within + intranets. The ProxyDomain directive specifies + the default domain which the apache proxy server will belong to. If a + request to a host without a domain name is encountered, a redirection + response to the same host with the configured Domain appended + will be generated.

    + +

    Example

          ProxyRemote  "*"  "http://firewall.example.com:81"
    
+      NoProxy         ".example.com" "192.168.112.0/21"
    
+      ProxyDomain     ".example.com"
    +
    top
    -

    BalancerInherit Directive

    +

    ProxyErrorOverride Directive

    - - - - + + + + -
    Description:Inherit ProxyPassed Balancers/Workers from the main server
    Syntax:BalancerInherit On|Off
    Default:BalancerInherit On
    Context:server config, virtual host
    Description:Override error pages for proxied content
    Syntax:ProxyErrorOverride On|Off
    Default:ProxyErrorOverride Off
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_proxy
    Compatibility:BalancerInherit is only available in Apache HTTP Server 2.4.5 and later.
    -

    This directive will cause the current server/vhost to "inherit" ProxyPass - Balancers and Workers defined in the main server. This can cause issues and - inconsistent behavior if using the Balancer Manager and so should be disabled - if using that feature.

    -

    The setting in the global server defines the default for all vhosts.

    - +

    This directive is useful for reverse-proxy setups, where you want to + have a common look and feel on the error pages seen by the end user. + This also allows for included files (via + mod_include's SSI) to get + the error code and act accordingly (default behavior would display + the error page of the proxied server, turning this on shows the SSI + Error message).

    + +

    This directive does not affect the processing of informational (1xx), + normal success (2xx), or redirect (3xx) responses.

    +
    top
    -

    BalancerMember Directive

    +

    ProxyIOBufferSize Directive

    - - - + + + + -
    Description:Add a member to a load balancing group
    Syntax:BalancerMember [balancerurl] url [key=value [key=value ...]]
    Context:directory
    Description:Determine size of internal data throughput buffer
    Syntax:ProxyIOBufferSize bytes
    Default:ProxyIOBufferSize 8192
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    Compatibility:BalancerMember is only available in Apache HTTP Server 2.2 - and later.
    -

    This directive adds a member to a load balancing group. It could be used - within a <Proxy balancer://...> container - directive, and can take any of the key value pair parameters available to - ProxyPass directives.

    -

    One additional parameter is available only to BalancerMember directives: - loadfactor. This is the member load factor - a number between 1 - (default) and 100, which defines the weighted load to be applied to the - member in question.

    -

    The balancerurl is only needed when not in - <Proxy balancer://...> - container directive. It corresponds to the url of a balancer defined in - ProxyPass directive.

    -

    The path component of the balancer URL in any - <Proxy balancer://...> container directive - is ignored.

    -

    Trailing slashes should typically be removed from the URL of a - BalancerMember.

    - +

    The ProxyIOBufferSize directive adjusts the size + of the internal buffer, which is used as a scratchpad for the data between + input and output. The size must be at least 512.

    + +

    In almost every case there's no reason to change that value.

    + +

    If used with AJP this directive sets the maximum AJP packet size in + bytes. Values larger than 65536 are set to 65536. If you change it from + the default, you must also change the packetSize attribute of + your AJP connector on the Tomcat side! The attribute + packetSize is only available in Tomcat 5.5.20+ + and 6.0.2+

    + +

    Normally it is not necessary to change the maximum packet size. + Problems with the default value have been reported when sending + certificates or certificate chains.

    + +
    top
    -

    BalancerPersist Directive

    +

    <ProxyMatch> Directive

    - - - + + -
    Description:Attempt to persist changes made by the Balancer Manager across restarts.
    Syntax:BalancerPersist On|Off
    Default:BalancerPersist Off
    Description:Container for directives applied to regular-expression-matched +proxied resources
    Syntax:<ProxyMatch regex> ...</ProxyMatch>
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    Compatibility:BalancerPersist is only available in Apache HTTP Server 2.4.4 and later.
    -

    This directive will cause the shared memory storage associated - with the balancers and balancer members to be persisted across - restarts. This allows these local changes to not be lost during the - normal restart/graceful state transitions.

    - +

    The <ProxyMatch> directive is + identical to the <Proxy> directive, except it matches URLs + using regular expressions.

    + +

    From 2.4.8 onwards, named groups and backreferences are captured and + written to the environment with the corresponding name prefixed with + "MATCH_" and in upper case. This allows elements of URLs to be referenced + from within expressions and modules like + mod_rewrite. In order to prevent confusion, numbered + (unnamed) backreferences are ignored. Use named groups instead.

    + +
    <ProxyMatch "^http://(?<sitename>[^/]+)">
+    Require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
+</ProxyMatch>
    + + +

    See also

    +
    top
    -

    NoProxy Directive

    +

    ProxyMaxForwards Directive

    - - + + + +
    Description:Hosts, domains, or networks that will be connected to -directly
    Syntax:NoProxy host [host] ...
    Description:Maximium number of proxies that a request can be forwarded +through
    Syntax:ProxyMaxForwards number
    Default:ProxyMaxForwards -1
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    Compatibility:Default behaviour changed in 2.2.7
    -

    This directive is only useful for Apache httpd proxy servers within - intranets. The NoProxy directive specifies a - list of subnets, IP addresses, hosts and/or domains, separated by - spaces. A request to a host which matches one or more of these is - always served directly, without forwarding to the configured - ProxyRemote proxy server(s).

    +

    The ProxyMaxForwards directive specifies the + maximum number of proxies through which a request may pass, if there's no + Max-Forwards header supplied with the request. This may + be set to prevent infinite proxy loops, or a DoS attack.

    -

    Example

    ProxyRemote  "*"  "http://firewall.example.com:81"
-NoProxy         ".example.com" "192.168.112.0/21"
    +

    Example

    ProxyMaxForwards 15
    -

    The host arguments to the NoProxy - directive are one of the following type list:

    - -
    - -
    Domain
    -
    -

    A Domain is a partially qualified DNS domain name, preceded - by a period. It represents a list of hosts which logically belong to the - same DNS domain or zone (i.e., the suffixes of the hostnames are - all ending in Domain).

    +

    Note that setting ProxyMaxForwards is a + violation of the HTTP/1.1 protocol (RFC2616), which forbids a Proxy + setting Max-Forwards if the Client didn't set it. + Earlier Apache httpd versions would always set it. A negative + ProxyMaxForwards value, including the + default -1, gives you protocol-compliant behaviour, but may + leave you open to loops.

    -

    Examples

    - .com .example.org. -

    - -

    To distinguish Domains from Hostnames (both syntactically and semantically; a DNS domain can - have a DNS A record, too!), Domains are always written with a - leading period.

    - -

    Note

    -

    Domain name comparisons are done without regard to the case, and - Domains are always assumed to be anchored in the root of the - DNS tree, therefore two domains .ExAmple.com and - .example.com. (note the trailing period) are considered - equal. Since a domain comparison does not involve a DNS lookup, it is much - more efficient than subnet comparison.

    -
    - - -
    SubNet
    -
    -

    A SubNet is a partially qualified internet address in - numeric (dotted quad) form, optionally followed by a slash and the netmask, - specified as the number of significant bits in the SubNet. It is - used to represent a subnet of hosts which can be reached over a common - network interface. In the absence of the explicit net mask it is assumed - that omitted (or zero valued) trailing digits specify the mask. (In this - case, the netmask can only be multiples of 8 bits wide.) Examples:

    - -
    -
    192.168 or 192.168.0.0
    -
    the subnet 192.168.0.0 with an implied netmask of 16 valid bits - (sometimes used in the netmask form 255.255.0.0)
    -
    192.168.112.0/21
    -
    the subnet 192.168.112.0/21 with a netmask of 21 - valid bits (also used in the form 255.255.248.0)
    -
    - -

    As a degenerate case, a SubNet with 32 valid bits is the - equivalent to an IPAddr, while a SubNet with zero - valid bits (e.g., 0.0.0.0/0) is the same as the constant - _Default_, matching any IP address.

    - - -
    IPAddr
    -
    -

    A IPAddr represents a fully qualified internet address in - numeric (dotted quad) form. Usually, this address represents a host, but - there need not necessarily be a DNS domain name connected with the - address.

    -

    Example

    - 192.168.123.7 -

    - -

    Note

    -

    An IPAddr does not need to be resolved by the DNS system, so - it can result in more effective apache performance.

    -
    - - -
    Hostname
    -
    -

    A Hostname is a fully qualified DNS domain name which can - be resolved to one or more IPAddrs via the - DNS domain name service. It represents a logical host (in contrast to - Domains, see above) and must be resolvable - to at least one IPAddr (or often to a list - of hosts with different IPAddrs).

    - -

    Examples

    - prep.ai.example.edu
    - www.example.org -

    - -

    Note

    -

    In many situations, it is more effective to specify an IPAddr in place of a Hostname since a - DNS lookup can be avoided. Name resolution in Apache httpd can take a remarkable - deal of time when the connection to the name server uses a slow PPP - link.

    -

    Hostname comparisons are done without regard to the case, - and Hostnames are always assumed to be anchored in the root - of the DNS tree, therefore two hosts WWW.ExAmple.com - and www.example.com. (note the trailing period) are - considered equal.

    -
    -
    - -

    See also

    -
    top
    -

    <Proxy> Directive

    +

    ProxyPass Directive

    - - - + + + +
    Description:Container for directives applied to proxied resources
    Syntax:<Proxy wildcard-url> ...</Proxy>
    Context:server config, virtual host
    Description:Maps remote servers into the local server URL-space
    Syntax:ProxyPass [path] !|url [key=value + [key=value ...]] [nocanon] [interpolate] [noquery]
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_proxy
    Compatibility:Unix Domain Socket (UDS) support added in 2.4.7
    -

    Directives placed in <Proxy> - sections apply only to matching proxied content. Shell-style wildcards are - allowed.

    - -

    For example, the following will allow only hosts in - yournetwork.example.com to access content via your proxy - server:

    - - 
    <Proxy "*">
-  Require host yournetwork.example.com
-</Proxy>
    - +

    This directive allows remote servers to be mapped into the + space of the local server; the local server does not act as a + proxy in the conventional sense, but appears to be a mirror of the + remote server. The local server is often called a reverse + proxy or gateway. The path is the name of + a local virtual path; url is a partial URL for the + remote server and cannot include a query string.

    -

    The following example will process all files in the foo - directory of example.com through the INCLUDES - filter when they are sent through the proxy server:

    +
    Note: This directive cannot be used within a + <Directory> context.
    - 
    <Proxy "http://example.com/foo/*">
-  SetOutputFilter INCLUDES
-</Proxy>
    +
    The ProxyRequests directive should + usually be set off when using + ProxyPass.
    +

    In 2.4.7 and later, support for using a Unix Domain Socket is available by using a target + which prepends unix:/path/lis.sock|. For example, to proxy + HTTP and target the UDS at /home/www/socket you would use + unix:/home/www.socket|http://localhost/whatever/.

    -

    Differences from the Location configuration section

    -

    A backend URL matches the configuration section if it begins with the - the wildcard-url string, even if the last path segment in the - directive only matches a prefix of the backend URL. For example, - <Proxy "http://example.com/foo"> matches all of - http://example.com/foo, http://example.com/foo/bar, and - http://example.com/foobar. The matching of the final URL differs - from the behavior of the <Location> section, which for purposes of this note - treats the final path component as if it ended in a slash.

    -

    For more control over the matching, see <ProxyMatch>.

    -
    +
    Note: The path associated with the unix: + URL is DefaultRuntimeDir aware.
    +

    Suppose the local server has address http://example.com/; + then

    -

    See also

    - -
    -
    top
    -

    ProxyAddHeaders Directive

    - - - - - - - - -
    Description:Add proxy information in X-Forwarded-* headers
    Syntax:ProxyAddHeaders Off|On
    Default:ProxyAddHeaders On
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_proxy
    Compatibility:Available in version 2.3.10 and later
    -

    This directive determines whether or not proxy related information should be passed to the - backend server through X-Forwarded-For, X-Forwarded-Host and X-Forwarded-Server HTTP headers.

    -

    Effectiveness

    -

    This option is of use only for HTTP proxying, as handled by mod_proxy_http.

    -
    + 
    <Location "/mirror/foo/">
+    ProxyPass "http://backend.example.com/"
+</Location>
    -
    -
    top
    -

    ProxyBadHeader Directive

    - - - - - - - -
    Description:Determines how to handle bad header lines in a -response
    Syntax:ProxyBadHeader IsError|Ignore|StartBody
    Default:ProxyBadHeader IsError
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    -

    The ProxyBadHeader directive determines the - behaviour of mod_proxy if it receives syntactically invalid - response header lines (i.e. containing no colon) from the origin - server. The following arguments are possible:

    -
    -
    IsError
    -
    Abort the request and end up with a 502 (Bad Gateway) response. This is - the default behaviour.
    +

    will cause a local request for + http://example.com/mirror/foo/bar to be internally converted + into a proxy request to http://backend.example.com/bar.

    -
    Ignore
    -
    Treat bad header lines as if they weren't sent.
    +

    The following alternative syntax is possible, however it can carry a + performance penalty when present in very large numbers. The advantage of + the below syntax is that it allows for dynamic control via the + Balancer Manager interface:

    -
    StartBody
    -
    When receiving the first bad header line, finish reading the headers and - treat the remainder as body. This helps to work around buggy backend servers - which forget to insert an empty line between the headers and the body.
    -
    + 
    ProxyPass "/mirror/foo/" "http://backend.example.com/"
    -
    -
    top
    -

    ProxyBlock Directive

    - - - - - - -
    Description:Words, hosts, or domains that are banned from being -proxied
    Syntax:ProxyBlock *|word|host|domain -[word|host|domain] ...
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    -

    The ProxyBlock directive specifies a list of - words, hosts and/or domains, separated by spaces. HTTP, HTTPS, and - FTP document requests to sites whose names contain matched words, - hosts or domains are blocked by the proxy server. The proxy - module will also attempt to determine IP addresses of list items which - may be hostnames during startup, and cache them for match test as - well. That may slow down the startup time of the server.

    -

    Example

    ProxyBlock "news.example.com" "auctions.example.com" "friends.example.com"
    -
    +
    +

    If the first argument ends with a trailing /, the second + argument should also end with a trailing / and vice + versa. Otherwise the resulting requests to the backend may miss some + needed slashes and do not deliver the expected results. +

    +
    -

    Note that example would also be sufficient to match any - of these sites.

    +

    The ! directive is useful in situations where you don't want + to reverse-proxy a subdirectory, e.g.

    -

    Hosts would also be matched if referenced by IP address.

    + 
    <Location "/mirror/foo/">
+    ProxyPass "http://backend.example.com/"
+</Location>
+<Location "/mirror/foo/i">
+    ProxyPass "!"
+</Location>
    -

    Note also that

    - 
    ProxyBlock "*"
    + 
    ProxyPass "/mirror/foo/i" "!"
+ProxyPass "/mirror/foo" "http://backend.example.com"
    -

    blocks connections to all sites.

    - -
    -
    top
    -

    ProxyDomain Directive

    - - - - - - -
    Description:Default domain name for proxied requests
    Syntax:ProxyDomain Domain
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    -

    This directive is only useful for Apache httpd proxy servers within - intranets. The ProxyDomain directive specifies - the default domain which the apache proxy server will belong to. If a - request to a host without a domain name is encountered, a redirection - response to the same host with the configured Domain appended - will be generated.

    - -

    Example

          ProxyRemote  "*"  "http://firewall.example.com:81"
    
-      NoProxy         ".example.com" "192.168.112.0/21"
    
-      ProxyDomain     ".example.com"
    -
    - -
    -
    top
    -

    ProxyErrorOverride Directive

    - - - - - - - -
    Description:Override error pages for proxied content
    Syntax:ProxyErrorOverride On|Off
    Default:ProxyErrorOverride Off
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_proxy
    -

    This directive is useful for reverse-proxy setups, where you want to - have a common look and feel on the error pages seen by the end user. - This also allows for included files (via - mod_include's SSI) to get - the error code and act accordingly (default behavior would display - the error page of the proxied server, turning this on shows the SSI - Error message).

    - -

    This directive does not affect the processing of informational (1xx), - normal success (2xx), or redirect (3xx) responses.

    - -
    -
    top
    -

    ProxyIOBufferSize Directive

    - - - - - - - -
    Description:Determine size of internal data throughput buffer
    Syntax:ProxyIOBufferSize bytes
    Default:ProxyIOBufferSize 8192
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    -

    The ProxyIOBufferSize directive adjusts the size - of the internal buffer, which is used as a scratchpad for the data between - input and output. The size must be at least 512.

    - -

    In almost every case there's no reason to change that value.

    - -

    If used with AJP this directive sets the maximum AJP packet size in - bytes. Values larger than 65536 are set to 65536. If you change it from - the default, you must also change the packetSize attribute of - your AJP connector on the Tomcat side! The attribute - packetSize is only available in Tomcat 5.5.20+ - and 6.0.2+

    - -

    Normally it is not necessary to change the maximum packet size. - Problems with the default value have been reported when sending - certificates or certificate chains.

    - - -
    -
    top
    -

    <ProxyMatch> Directive

    - - - - - - -
    Description:Container for directives applied to regular-expression-matched -proxied resources
    Syntax:<ProxyMatch regex> ...</ProxyMatch>
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    -

    The <ProxyMatch> directive is - identical to the <Proxy> directive, except it matches URLs - using regular expressions.

    - -

    From 2.4.8 onwards, named groups and backreferences are captured and - written to the environment with the corresponding name prefixed with - "MATCH_" and in upper case. This allows elements of URLs to be referenced - from within expressions and modules like - mod_rewrite. In order to prevent confusion, numbered - (unnamed) backreferences are ignored. Use named groups instead.

    - -
    <ProxyMatch "^http://(?<sitename>[^/]+)">
-    Require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
-</ProxyMatch>
    - - -

    See also

    - -
    -
    top
    -

    ProxyMaxForwards Directive

    - - - - - - - - -
    Description:Maximium number of proxies that a request can be forwarded -through
    Syntax:ProxyMaxForwards number
    Default:ProxyMaxForwards -1
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    Compatibility:Default behaviour changed in 2.2.7
    -

    The ProxyMaxForwards directive specifies the - maximum number of proxies through which a request may pass, if there's no - Max-Forwards header supplied with the request. This may - be set to prevent infinite proxy loops, or a DoS attack.

    - -

    Example

    ProxyMaxForwards 15
    -
    - -

    Note that setting ProxyMaxForwards is a - violation of the HTTP/1.1 protocol (RFC2616), which forbids a Proxy - setting Max-Forwards if the Client didn't set it. - Earlier Apache httpd versions would always set it. A negative - ProxyMaxForwards value, including the - default -1, gives you protocol-compliant behaviour, but may - leave you open to loops.

    - -
    -
    top
    -

    ProxyPass Directive

    - - - - - - - -
    Description:Maps remote servers into the local server URL-space
    Syntax:ProxyPass [path] !|url [key=value - [key=value ...]] [nocanon] [interpolate] [noquery]
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_proxy
    Compatibility:Unix Domain Socket (UDS) support added in 2.4.7
    -

    This directive allows remote servers to be mapped into the - space of the local server; the local server does not act as a - proxy in the conventional sense, but appears to be a mirror of the - remote server. The local server is often called a reverse - proxy or gateway. The path is the name of - a local virtual path; url is a partial URL for the - remote server and cannot include a query string.

    - -
    Note: This directive cannot be used within a - <Directory> context.
    - -
    The ProxyRequests directive should - usually be set off when using - ProxyPass.
    - -

    In 2.4.7 and later, support for using a Unix Domain Socket is available by using a target - which prepends unix:/path/lis.sock|. For example, to proxy - HTTP and target the UDS at /home/www/socket you would use - unix:/home/www.socket|http://localhost/whatever/.

    - -
    Note: The path associated with the unix: - URL is DefaultRuntimeDir aware.
    - -

    Suppose the local server has address http://example.com/; - then

    - - 
    <Location "/mirror/foo/">
-    ProxyPass "http://backend.example.com/"
-</Location>
    - - -

    will cause a local request for - http://example.com/mirror/foo/bar to be internally converted - into a proxy request to http://backend.example.com/bar.

    - -

    The following alternative syntax is possible, however it can carry a - performance penalty when present in very large numbers. The advantage of - the below syntax is that it allows for dynamic control via the - Balancer Manager interface:

    - - 
    ProxyPass "/mirror/foo/" "http://backend.example.com/"
    - - -
    -

    If the first argument ends with a trailing /, the second - argument should also end with a trailing / and vice - versa. Otherwise the resulting requests to the backend may miss some - needed slashes and do not deliver the expected results. -

    -
    - -

    The ! directive is useful in situations where you don't want - to reverse-proxy a subdirectory, e.g.

    - - 
    <Location "/mirror/foo/">
-    ProxyPass "http://backend.example.com/"
-</Location>
-<Location "/mirror/foo/i">
-    ProxyPass "!"
-</Location>
    - - - 
    ProxyPass "/mirror/foo/i" "!"
-ProxyPass "/mirror/foo" "http://backend.example.com"
    - - -

    will proxy all requests to /mirror/foo to - backend.example.com except requests made to - /mirror/foo/i.

    +

    will proxy all requests to /mirror/foo to + backend.example.com except requests made to + /mirror/foo/i.

    Ordering ProxyPass Directives

    The configured ProxyPass @@ -1417,518 +1082,853 @@ ProxyPass "/" "balancer://mycluster/" stickysession=JSESSIONID|jsessionid nofail scheme can be accomplished with mod_rewrite as in the following example.

    - 
    RewriteEngine On
+    
    RewriteEngine On
+
+RewriteCond "%{HTTPS}" =off
+RewriteRule "." "-" [E=protocol:http]
+RewriteCond "%{HTTPS}" =on
+RewriteRule "." "-" [E=protocol:https]
+
+RewriteRule "^/mirror/foo/(.*)" "%{ENV:protocol}://backend.example.com/$1" [P]
+ProxyPassReverse  "/mirror/foo/" "http://backend.example.com/"
+ProxyPassReverse  "/mirror/foo/" "https://backend.example.com/"
    
+
+
+
    +
    top
    +

    ProxyPassInherit Directive

    + + + + + + + + +
    Description:Inherit ProxyPass directives defined from the main server
    Syntax:ProxyPassInherit On|Off
    Default:ProxyPassInherit On
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    Compatibility:ProxyPassInherit is only available in Apache HTTP Server 2.4.5 and later. + and later.
    +

    This directive will cause the current server/vhost to "inherit" + ProxyPass + directives defined in the main server. This can cause issues and + inconsistent behavior if using the Balancer Manager for dynamic changes + and so should be disabled if using that feature.

    +

    The setting in the global server defines the default for all vhosts.

    +

    Disabling ProxyPassInherit also disables BalancerInherit.

    + +
    +
    top
    +

    ProxyPassInterpolateEnv Directive

    + + + + + + + + +
    Description:Enable Environment Variable interpolation in Reverse Proxy configurations
    Syntax:ProxyPassInterpolateEnv On|Off
    Default:ProxyPassInterpolateEnv Off
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_proxy
    Compatibility:Available in httpd 2.2.9 and later
    +

    This directive, together with the interpolate argument to + ProxyPass, ProxyPassReverse, + ProxyPassReverseCookieDomain and + ProxyPassReverseCookiePath + enables reverse proxies to be dynamically + configured using environment variables, which may be set by + another module such as mod_rewrite. + It affects the ProxyPass, + ProxyPassReverse, + ProxyPassReverseCookieDomain, and + ProxyPassReverseCookiePath directives, + and causes them to substitute the value of an environment + variable varname for the string ${varname} + in configuration directives (if the interpolate option is set).

    +

    Keep this turned off (for server performance) unless you need it!

    + +
    +
    top
    +

    ProxyPassMatch Directive

    + + + + + + +
    Description:Maps remote servers into the local server URL-space using regular expressions
    Syntax:ProxyPassMatch [regex] !|url [key=value + [key=value ...]]
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_proxy
    +

    This directive is equivalent to ProxyPass, + but makes use of regular expressions, instead of simple prefix matching. The + supplied regular expression is matched against the url, and if it + matches, the server will substitute any parenthesized matches into the given + string and use it as a new url.

    + +
    Note: This directive cannot be used within a + <Directory> context.
    + +

    Suppose the local server has address http://example.com/; + then

    + + 
    ProxyPassMatch "^/(.*\.gif)$" "http://backend.example.com/$1"
    + + +

    will cause a local request for + http://example.com/foo/bar.gif to be internally converted + into a proxy request to http://backend.example.com/foo/bar.gif.

    +

    Note

    +

    The URL argument must be parsable as a URL before regexp + substitutions (as well as after). This limits the matches you can use. + For instance, if we had used

    + 
    ProxyPassMatch "^(/.*\.gif)$" "http://backend.example.com:8000$1"
    + +

    in our previous example, it would fail with a syntax error + at server startup. This is a bug (PR 46665 in the ASF bugzilla), + and the workaround is to reformulate the match:

    + 
    ProxyPassMatch "^/(.*\.gif)$" "http://backend.example.com:8000/$1"
    + +
    +

    The ! directive is useful in situations where you don't want + to reverse-proxy a subdirectory.

    + +

    When used inside a <LocationMatch> section, the first argument is omitted and the + regexp is obtained from the <LocationMatch>.

    + +

    If you require a more flexible reverse-proxy configuration, see the + RewriteRule directive with the + [P] flag.

    + +
    +

    Default Substitution

    +

    When the URL parameter doesn't use any backreferences into the regular + expression, the original URL will be appended to the URL parameter. +

    +
    + +
    +

    Security Warning

    +

    Take care when constructing the target URL of the rule, considering + the security impact from allowing the client influence over the set of + URLs to which your server will act as a proxy. Ensure that the scheme + and hostname part of the URL is either fixed, or does not allow the + client undue influence.

    +
    + +
    +
    top
    +

    ProxyPassReverse Directive

    + + + + + + +
    Description:Adjusts the URL in HTTP response headers sent from a reverse +proxied server
    Syntax:ProxyPassReverse [path] url +[interpolate]
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_proxy
    +

    This directive lets Apache httpd adjust the URL in the Location, + Content-Location and URI headers on HTTP + redirect responses. This is essential when Apache httpd is used as a + reverse proxy (or gateway) to avoid by-passing the reverse proxy + because of HTTP redirects on the backend servers which stay behind + the reverse proxy.

    + +

    Only the HTTP response headers specifically mentioned above + will be rewritten. Apache httpd will not rewrite other response + headers, nor will it by default rewrite URL references inside HTML pages. + This means that if the proxied content contains absolute URL + references, they will by-pass the proxy. To rewrite HTML content to + match the proxy, you must load and enable mod_proxy_html. +

    + +

    path is the name of a local virtual path. url is a + partial URL for the remote server - the same way they are used for the + ProxyPass directive.

    + +

    For example, suppose the local server has address + http://example.com/; then

    + + 
    ProxyPass         "/mirror/foo/" "http://backend.example.com/"
+ProxyPassReverse  "/mirror/foo/" "http://backend.example.com/"
+ProxyPassReverseCookieDomain  "backend.example.com"  "public.example.com"
+ProxyPassReverseCookiePath  "/"  "/mirror/foo/"
    + + +

    will not only cause a local request for the + http://example.com/mirror/foo/bar to be internally converted + into a proxy request to http://backend.example.com/bar + (the functionality ProxyPass provides here). It also takes care + of redirects the server backend.example.com sends: when + http://backend.example.com/bar is redirected by him to + http://backend.example.com/quux Apache httpd adjusts this to + http://example.com/mirror/foo/quux before forwarding the HTTP + redirect response to the client. Note that the hostname used for + constructing the URL is chosen in respect to the setting of the UseCanonicalName directive.

    + +

    Note that this ProxyPassReverse directive can + also be used in conjunction with the proxy pass-through feature + (RewriteRule ... [P]) from mod_rewrite + because it doesn't depend on a corresponding ProxyPass directive.

    + +

    The optional interpolate keyword, used together with + ProxyPassInterpolateEnv, enables interpolation + of environment variables specified using the format ${VARNAME}. + Note that interpolation is not supported within the scheme portion of a + URL.

    + +

    When used inside a <Location> section, the first argument is omitted and the local + directory is obtained from the <Location>. The same occurs inside a <LocationMatch> section, but will probably not work as + intended, as ProxyPassReverse will interpret the regexp literally as a + path; if needed in this situation, specify the ProxyPassReverse outside + the section, or in a separate <Location> section.

    + +

    This directive is not supported in <Directory> or <Files> sections.

    + +
    +
    top
    +

    ProxyPassReverseCookieDomain Directive

    + + + + + + +
    Description:Adjusts the Domain string in Set-Cookie headers from a reverse- +proxied server
    Syntax:ProxyPassReverseCookieDomain internal-domain +public-domain [interpolate]
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_proxy
    +

    Usage is basically similar to +ProxyPassReverse, but instead of +rewriting headers that are a URL, this rewrites the domain +string in Set-Cookie headers.

    + +
    +
    top
    +

    ProxyPassReverseCookiePath Directive

    + + + + + + +
    Description:Adjusts the Path string in Set-Cookie headers from a reverse- +proxied server
    Syntax:ProxyPassReverseCookiePath internal-path +public-path [interpolate]
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_proxy
    +

    +Useful in conjunction with +ProxyPassReverse +in situations where backend URL paths are mapped to public paths on the +reverse proxy. This directive rewrites the path string in +Set-Cookie headers. If the beginning of the cookie path matches +internal-path, the cookie path will be replaced with +public-path. +

    +In the example given with +ProxyPassReverse, the directive: +

    + 
    ProxyPassReverseCookiePath  "/"  "/mirror/foo/"
    + +

    +will rewrite a cookie with backend path / (or +/example or, in fact, anything) to /mirror/foo/. +

    + +
    +
    top
    +

    ProxyPreserveHost Directive

    + + + + + + + + +
    Description:Use incoming Host HTTP request header for proxy +request
    Syntax:ProxyPreserveHost On|Off
    Default:ProxyPreserveHost Off
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_proxy
    Compatibility:Usable in directory +context in 2.3.3 and later.
    +

    When enabled, this option will pass the Host: line from the incoming + request to the proxied host, instead of the hostname specified in the + ProxyPass line.

    + +

    This option should normally be turned Off. It is mostly + useful in special configurations like proxied mass name-based virtual + hosting, where the original Host header needs to be evaluated by the + backend server.

    + +
    +
    top
    +

    ProxyReceiveBufferSize Directive

    + + + + + + + +
    Description:Network buffer size for proxied HTTP and FTP +connections
    Syntax:ProxyReceiveBufferSize bytes
    Default:ProxyReceiveBufferSize 0
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    +

    The ProxyReceiveBufferSize directive specifies an + explicit (TCP/IP) network buffer size for proxied HTTP and FTP connections, + for increased throughput. It has to be greater than 512 or set + to 0 to indicate that the system's default buffer size should + be used.

    + +

    Example

    ProxyReceiveBufferSize 2048
    +
    + +
    +
    top
    +

    ProxyRemote Directive

    + + + + + + +
    Description:Remote proxy used to handle certain requests
    Syntax:ProxyRemote match remote-server
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    +

    This defines remote proxies to this proxy. match is either the + name of a URL-scheme that the remote server supports, or a partial URL + for which the remote server should be used, or * to indicate + the server should be contacted for all requests. remote-server is + a partial URL for the remote server. Syntax:

    + +

    + remote-server = + scheme://hostname[:port] +

    + +

    scheme is effectively the protocol that should be used to + communicate with the remote server; only http and https + are supported by this module. When using https, the requests + are forwarded through the remote proxy using the HTTP CONNECT method.

    + +

    Example

    ProxyRemote "http://goodguys.example.com/" "http://mirrorguys.example.com:8000"
+ProxyRemote "*" "http://cleverproxy.localdomain"
+ProxyRemote "ftp" "http://ftpproxy.mydomain:8080"
    +
    + +

    In the last example, the proxy will forward FTP requests, encapsulated + as yet another HTTP proxy request, to another proxy which can handle + them.

    + +

    This option also supports reverse proxy configuration - a backend + webserver can be embedded within a virtualhost URL space even if that + server is hidden by another forward proxy.

    + +
    +
    top
    +

    ProxyRemoteMatch Directive

    + + + + + + +
    Description:Remote proxy used to handle requests matched by regular +expressions
    Syntax:ProxyRemoteMatch regex remote-server
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    +

    The ProxyRemoteMatch is identical to the + ProxyRemote directive, except the + first argument is a regular expression + match against the requested URL.

    + +
    +
    top
    +

    ProxyRequests Directive

    + + + + + + + +
    Description:Enables forward (standard) proxy requests
    Syntax:ProxyRequests On|Off
    Default:ProxyRequests Off
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    +

    This allows or prevents Apache httpd from functioning as a forward proxy + server. (Setting ProxyRequests to Off does not disable use of + the ProxyPass directive.)

    + +

    In a typical reverse proxy or gateway configuration, this + option should be set to + Off.

    + +

    In order to get the functionality of proxying HTTP or FTP sites, you + need also mod_proxy_http or mod_proxy_ftp + (or both) present in the server.

    + +

    In order to get the functionality of (forward) proxying HTTPS sites, you + need mod_proxy_connect enabled in the server.

    + +

    Warning

    +

    Do not enable proxying with ProxyRequests until you have secured your server. Open proxy servers are dangerous + both to your network and to the Internet at large.

    +
    + +

    See also

    + +
    +
    top
    +

    ProxySet Directive

    + + + + + + + +
    Description:Set various Proxy balancer or member parameters
    Syntax:ProxySet url key=value [key=value ...]
    Context:directory
    Status:Extension
    Module:mod_proxy
    Compatibility:ProxySet is only available in Apache HTTP Server 2.2 + and later.
    +

    This directive is used as an alternate method of setting any of the + parameters available to Proxy balancers and workers normally done via the + ProxyPass directive. If used + within a <Proxy balancer url|worker url> + container directive, the url argument is not required. As a side + effect the respective balancer or worker gets created. This can be useful + when doing reverse proxying via a + RewriteRule instead of a + ProxyPass directive.

    + + 
    <Proxy "balancer://hotcluster">
+    BalancerMember "http://www2.example.com:8080" loadfactor=1
+    BalancerMember "http://www3.example.com:8080" loadfactor=2
+    ProxySet lbmethod=bytraffic
+</Proxy>
    +
    + + 
    <Proxy "http://backend">
+    ProxySet keepalive=On
+</Proxy>
    + + + 
    ProxySet "balancer://foo" lbmethod=bytraffic timeout=15
    + + + 
    ProxySet "ajp://backend:7001" timeout=15
    + -RewriteCond "%{HTTPS}" =off -RewriteRule "." "-" [E=protocol:http] -RewriteCond "%{HTTPS}" =on -RewriteRule "." "-" [E=protocol:https] +

    Warning

    +

    Keep in mind that the same parameter key can have a different meaning + depending whether it is applied to a balancer or a worker as shown by the two + examples above regarding timeout.

    +
    -RewriteRule "^/mirror/foo/(.*)" "%{ENV:protocol}://backend.example.com/$1" [P] -ProxyPassReverse "/mirror/foo/" "http://backend.example.com/" -ProxyPassReverse "/mirror/foo/" "https://backend.example.com/" +
    +
    top
    +

    ProxySourceAddress Directive

    + + + + + + + +
    Description:Set local IP address for outgoing proxy connections
    Syntax:ProxySourceAddress address
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    Compatibility:Available in version 2.3.9 and later
    +

    This directive allows to set a specific local address to bind to when connecting + to a backend server.

    top
    -

    ProxyPassInherit Directive

    +

    ProxyStatus Directive

    - - - + + + - +
    Description:Inherit ProxyPass directives defined from the main server
    Syntax:ProxyPassInherit On|Off
    Default:ProxyPassInherit On
    Description:Show Proxy LoadBalancer status in mod_status
    Syntax:ProxyStatus Off|On|Full
    Default:ProxyStatus Off
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    Compatibility:ProxyPassInherit is only available in Apache HTTP Server 2.4.5 and later. - and later.
    Compatibility:Available in version 2.2 and later
    -

    This directive will cause the current server/vhost to "inherit" - ProxyPass - directives defined in the main server. This can cause issues and - inconsistent behavior if using the Balancer Manager for dynamic changes - and so should be disabled if using that feature.

    -

    The setting in the global server defines the default for all vhosts.

    -

    Disabling ProxyPassInherit also disables BalancerInherit.

    - +

    This directive determines whether or not proxy + loadbalancer status data is displayed via the mod_status + server-status page.

    +

    Note

    +

    Full is synonymous with On

    +
    + +
    top
    -

    ProxyPassInterpolateEnv Directive

    +

    ProxyTimeout Directive

    - - - - + + + + -
    Description:Enable Environment Variable interpolation in Reverse Proxy configurations
    Syntax:ProxyPassInterpolateEnv On|Off
    Default:ProxyPassInterpolateEnv Off
    Context:server config, virtual host, directory
    Description:Network timeout for proxied requests
    Syntax:ProxyTimeout seconds
    Default:Value of Timeout
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    Compatibility:Available in httpd 2.2.9 and later
    -

    This directive, together with the interpolate argument to - ProxyPass, ProxyPassReverse, - ProxyPassReverseCookieDomain and - ProxyPassReverseCookiePath - enables reverse proxies to be dynamically - configured using environment variables, which may be set by - another module such as mod_rewrite. - It affects the ProxyPass, - ProxyPassReverse, - ProxyPassReverseCookieDomain, and - ProxyPassReverseCookiePath directives, - and causes them to substitute the value of an environment - variable varname for the string ${varname} - in configuration directives (if the interpolate option is set).

    -

    Keep this turned off (for server performance) unless you need it!

    +

    This directive allows a user to specifiy a timeout on proxy requests. + This is useful when you have a slow/buggy appserver which hangs, and you + would rather just return a timeout and fail gracefully instead of waiting + however long it takes the server to return.

    top
    -

    ProxyPassMatch Directive

    +

    ProxyVia Directive

    - - - + + + +
    Description:Maps remote servers into the local server URL-space using regular expressions
    Syntax:ProxyPassMatch [regex] !|url [key=value - [key=value ...]]
    Context:server config, virtual host, directory
    Description:Information provided in the Via HTTP response +header for proxied requests
    Syntax:ProxyVia On|Off|Full|Block
    Default:ProxyVia Off
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    -

    This directive is equivalent to ProxyPass, - but makes use of regular expressions, instead of simple prefix matching. The - supplied regular expression is matched against the url, and if it - matches, the server will substitute any parenthesized matches into the given - string and use it as a new url.

    +

    This directive controls the use of the Via: HTTP + header by the proxy. Its intended use is to control the flow of + proxy requests along a chain of proxy servers. See RFC 2616 (HTTP/1.1), section + 14.45 for an explanation of Via: header lines.

    -
    Note: This directive cannot be used within a - <Directory> context.
    - -

    Suppose the local server has address http://example.com/; - then

    +
      +
    • If set to Off, which is the default, no special processing + is performed. If a request or reply contains a Via: header, + it is passed through unchanged.
      • - 
      ProxyPassMatch "^/(.*\.gif)$" "http://backend.example.com/$1"
      +
    • If set to On, each request and reply will get a + Via: header line added for the current host.
      • +
    • If set to Full, each generated Via: header + line will additionally have the Apache httpd server version shown as a + Via: comment field.
      • -

      will cause a local request for - http://example.com/foo/bar.gif to be internally converted - into a proxy request to http://backend.example.com/foo/bar.gif.

      -

      Note

      -

      The URL argument must be parsable as a URL before regexp - substitutions (as well as after). This limits the matches you can use. - For instance, if we had used

      - 
      ProxyPassMatch "^(/.*\.gif)$" "http://backend.example.com:8000$1"
      +
    • If set to Block, every proxy request will have all its + Via: header lines removed. No new Via: header will + be generated.
      • +
    -

    in our previous example, it would fail with a syntax error - at server startup. This is a bug (PR 46665 in the ASF bugzilla), - and the workaround is to reformulate the match:

    - 
    ProxyPassMatch "^/(.*\.gif)$" "http://backend.example.com:8000/$1"
    +
    +
    top
    +
    +

    Forward Proxies and Reverse + Proxies/Gateways

    +

    Apache HTTP Server can be configured in both a forward and + reverse proxy (also known as gateway) mode.

    -
    -

    The ! directive is useful in situations where you don't want - to reverse-proxy a subdirectory.

    +

    An ordinary forward proxy is an intermediate + server that sits between the client and the origin + server. In order to get content from the origin server, + the client sends a request to the proxy naming the origin server + as the target and the proxy then requests the content from the + origin server and returns it to the client. The client must be + specially configured to use the forward proxy to access other + sites.

    -

    When used inside a <LocationMatch> section, the first argument is omitted and the - regexp is obtained from the <LocationMatch>.

    +

    A typical usage of a forward proxy is to provide Internet + access to internal clients that are otherwise restricted by a + firewall. The forward proxy can also use caching (as provided + by mod_cache) to reduce network usage.

    -

    If you require a more flexible reverse-proxy configuration, see the - RewriteRule directive with the - [P] flag.

    +

    The forward proxy is activated using the ProxyRequests directive. Because + forward proxies allow clients to access arbitrary sites through + your server and to hide their true origin, it is essential that + you secure your server so that only + authorized clients can access the proxy before activating a + forward proxy.

    -
    -

    Default Substitution

    -

    When the URL parameter doesn't use any backreferences into the regular - expression, the original URL will be appended to the URL parameter. -

    -
    +

    A reverse proxy (or gateway), by + contrast, appears to the client just like an ordinary web + server. No special configuration on the client is necessary. + The client makes ordinary requests for content in the name-space + of the reverse proxy. The reverse proxy then decides where to + send those requests, and returns the content as if it was itself + the origin.

    -
    -

    Security Warning

    -

    Take care when constructing the target URL of the rule, considering - the security impact from allowing the client influence over the set of - URLs to which your server will act as a proxy. Ensure that the scheme - and hostname part of the URL is either fixed, or does not allow the - client undue influence.

    -
    +

    A typical usage of a reverse proxy is to provide Internet + users access to a server that is behind a firewall. Reverse + proxies can also be used to balance load among several back-end + servers, or to provide caching for a slower back-end server. + In addition, reverse proxies can be used simply to bring + several servers into the same URL space.

    + +

    A reverse proxy is activated using the ProxyPass directive or the + [P] flag to the RewriteRule directive. It is + not necessary to turn ProxyRequests on in order to + configure a reverse proxy.

    +
    top
    +
    +

    Basic Examples

    + +

    The examples below are only a very basic idea to help you + get started. Please read the documentation on the individual + directives.

    + +

    In addition, if you wish to have caching enabled, consult + the documentation from mod_cache.

    +

    Reverse Proxy

    ProxyPass "/foo" "http://foo.example.com/bar"
+ProxyPassReverse "/foo" "http://foo.example.com/bar"
    -
    top
    -

    ProxyPassReverse Directive

    - - - - - - -
    Description:Adjusts the URL in HTTP response headers sent from a reverse -proxied server
    Syntax:ProxyPassReverse [path] url -[interpolate]
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_proxy
    -

    This directive lets Apache httpd adjust the URL in the Location, - Content-Location and URI headers on HTTP - redirect responses. This is essential when Apache httpd is used as a - reverse proxy (or gateway) to avoid by-passing the reverse proxy - because of HTTP redirects on the backend servers which stay behind - the reverse proxy.

    -

    Only the HTTP response headers specifically mentioned above - will be rewritten. Apache httpd will not rewrite other response - headers, nor will it by default rewrite URL references inside HTML pages. - This means that if the proxied content contains absolute URL - references, they will by-pass the proxy. To rewrite HTML content to - match the proxy, you must load and enable mod_proxy_html. -

    +

    Forward Proxy

    ProxyRequests On
+ProxyVia On
 
-    
    path is the name of a local virtual path. url is a
-    partial URL for the remote server - the same way they are used for the
-    ProxyPass directive.
    
+<Proxy "*">
+  Require host internal.example.com
+</Proxy>
    +
    +
    top
    +
    +

    Access via Handler

    -

    For example, suppose the local server has address - http://example.com/; then

    +

    You can also force a request to be handled as a reverse-proxy + request, by creating a suitable Handler pass-through. The example + configuration below will pass all requests for PHP scripts to the + specified FastCGI server using reverse proxy: +

    + +

    Reverse Proxy PHP scripts

    <FilesMatch "\.php$">
+    # Unix sockets require 2.4.7 or later
+    SetHandler  "proxy:unix:/path/to/app.sock|fcgi://localhost/"
+</FilesMatch>
    +
    - 
    ProxyPass         "/mirror/foo/" "http://backend.example.com/"
-ProxyPassReverse  "/mirror/foo/" "http://backend.example.com/"
-ProxyPassReverseCookieDomain  "backend.example.com"  "public.example.com"
-ProxyPassReverseCookiePath  "/"  "/mirror/foo/"
    +

    This feature is available in Apache HTTP Server 2.4.10 and later.

    +
    top
    +
    +

    Workers

    +

    The proxy manages the configuration of origin servers and their + communication parameters in objects called workers. + There are two built-in workers, the default forward proxy worker and the + default reverse proxy worker. Additional workers can be configured + explicitly.

    -

    will not only cause a local request for the - http://example.com/mirror/foo/bar to be internally converted - into a proxy request to http://backend.example.com/bar - (the functionality ProxyPass provides here). It also takes care - of redirects the server backend.example.com sends: when - http://backend.example.com/bar is redirected by him to - http://backend.example.com/quux Apache httpd adjusts this to - http://example.com/mirror/foo/quux before forwarding the HTTP - redirect response to the client. Note that the hostname used for - constructing the URL is chosen in respect to the setting of the UseCanonicalName directive.

    +

    The two default workers have a fixed configuration + and will be used if no other worker matches the request. + They do not use HTTP Keep-Alive or connection pooling. + The TCP connections to the origin server will instead be + opened and closed for each request.

    -

    Note that this ProxyPassReverse directive can - also be used in conjunction with the proxy pass-through feature - (RewriteRule ... [P]) from mod_rewrite - because it doesn't depend on a corresponding ProxyPass directive.

    +

    Explicitly configured workers are identified by their URL. + They are usually created and configured using + ProxyPass or + ProxyPassMatch when used + for a reverse proxy:

    -

    The optional interpolate keyword, used together with - ProxyPassInterpolateEnv, enables interpolation - of environment variables specified using the format ${VARNAME}. - Note that interpolation is not supported within the scheme portion of a - URL.

    + 
    ProxyPass "/example" "http://backend.example.com" connectiontimeout=5 timeout=30
    -

    When used inside a <Location> section, the first argument is omitted and the local - directory is obtained from the <Location>. The same occurs inside a <LocationMatch> section, but will probably not work as - intended, as ProxyPassReverse will interpret the regexp literally as a - path; if needed in this situation, specify the ProxyPassReverse outside - the section, or in a separate <Location> section.

    -

    This directive is not supported in <Directory> or <Files> sections.

    +

    This will create a worker associated with the origin server URL + http://backend.example.com and using the given timeout + values. When used in a forward proxy, workers are usually defined + via the ProxySet directive:

    -
    -
    top
    -

    ProxyPassReverseCookieDomain Directive

    - - - - - - -
    Description:Adjusts the Domain string in Set-Cookie headers from a reverse- -proxied server
    Syntax:ProxyPassReverseCookieDomain internal-domain -public-domain [interpolate]
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_proxy
    -

    Usage is basically similar to -ProxyPassReverse, but instead of -rewriting headers that are a URL, this rewrites the domain -string in Set-Cookie headers.

    + 
    ProxySet "http://backend.example.com" connectiontimeout=5 timeout=30
    -
    -
    top
    -

    ProxyPassReverseCookiePath Directive

    - - - - - - -
    Description:Adjusts the Path string in Set-Cookie headers from a reverse- -proxied server
    Syntax:ProxyPassReverseCookiePath internal-path -public-path [interpolate]
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_proxy
    -

    -Useful in conjunction with -ProxyPassReverse -in situations where backend URL paths are mapped to public paths on the -reverse proxy. This directive rewrites the path string in -Set-Cookie headers. If the beginning of the cookie path matches -internal-path, the cookie path will be replaced with -public-path. -

    -In the example given with -ProxyPassReverse, the directive: -

    - 
    ProxyPassReverseCookiePath  "/"  "/mirror/foo/"
    -

    -will rewrite a cookie with backend path / (or -/example or, in fact, anything) to /mirror/foo/. -

    +

    or alternatively using Proxy + and ProxySet:

    -
    -
    top
    -

    ProxyPreserveHost Directive

    - - - - - - - - -
    Description:Use incoming Host HTTP request header for proxy -request
    Syntax:ProxyPreserveHost On|Off
    Default:ProxyPreserveHost Off
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_proxy
    Compatibility:Usable in directory -context in 2.3.3 and later.
    -

    When enabled, this option will pass the Host: line from the incoming - request to the proxied host, instead of the hostname specified in the - ProxyPass line.

    + 
    <Proxy "http://backend.example.com">
+  ProxySet connectiontimeout=5 timeout=30
+</Proxy>
    -

    This option should normally be turned Off. It is mostly - useful in special configurations like proxied mass name-based virtual - hosting, where the original Host header needs to be evaluated by the - backend server.

    -
    -
    top
    -

    ProxyReceiveBufferSize Directive

    - - - - - - - -
    Description:Network buffer size for proxied HTTP and FTP -connections
    Syntax:ProxyReceiveBufferSize bytes
    Default:ProxyReceiveBufferSize 0
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    -

    The ProxyReceiveBufferSize directive specifies an - explicit (TCP/IP) network buffer size for proxied HTTP and FTP connections, - for increased throughput. It has to be greater than 512 or set - to 0 to indicate that the system's default buffer size should - be used.

    +

    Using explicitly configured workers in the forward mode is + not very common, because forward proxies usually communicate with many + different origin servers. Creating explicit workers for some of the + origin servers can still be useful, if they are used very often. + Explicitly configured workers have no concept of forward or reverse + proxying by themselves. They encapsulate a common concept of + communication with origin servers. A worker created by + ProxyPass for use in a + reverse proxy will be also used for forward proxy requests whenever + the URL to the origin server matches the worker URL and vice versa.

    -

    Example

    ProxyReceiveBufferSize 2048
    -
    +

    The URL identifying a direct worker is the URL of its + origin server including any path components given:

    -
    -
    top
    -

    ProxyRemote Directive

    - - - - - - -
    Description:Remote proxy used to handle certain requests
    Syntax:ProxyRemote match remote-server
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    -

    This defines remote proxies to this proxy. match is either the - name of a URL-scheme that the remote server supports, or a partial URL - for which the remote server should be used, or * to indicate - the server should be contacted for all requests. remote-server is - a partial URL for the remote server. Syntax:

    + 
    ProxyPass "/examples" "http://backend.example.com/examples"
+ProxyPass "/docs" "http://backend.example.com/docs"
    -

    - remote-server = - scheme://hostname[:port] -

    -

    scheme is effectively the protocol that should be used to - communicate with the remote server; only http and https - are supported by this module. When using https, the requests - are forwarded through the remote proxy using the HTTP CONNECT method.

    +

    This example defines two different workers, each using a separate + connection pool and configuration.

    -

    Example

    ProxyRemote "http://goodguys.example.com/" "http://mirrorguys.example.com:8000"
-ProxyRemote "*" "http://cleverproxy.localdomain"
-ProxyRemote "ftp" "http://ftpproxy.mydomain:8080"
    -
    +

    Worker Sharing

    +

    Worker sharing happens if the worker URLs overlap, which occurs when + the URL of some worker is a leading substring of the URL of another + worker defined later in the configuration file. In the following example

    -

    In the last example, the proxy will forward FTP requests, encapsulated - as yet another HTTP proxy request, to another proxy which can handle - them.

    + 
    ProxyPass "/apps" "http://backend.example.com/" timeout=60
+ProxyPass "/examples" "http://backend.example.com/examples" timeout=10
    -

    This option also supports reverse proxy configuration - a backend - webserver can be embedded within a virtualhost URL space even if that - server is hidden by another forward proxy.

    -
    -
    top
    -

    ProxyRemoteMatch Directive

    - - - - - - -
    Description:Remote proxy used to handle requests matched by regular -expressions
    Syntax:ProxyRemoteMatch regex remote-server
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    -

    The ProxyRemoteMatch is identical to the - ProxyRemote directive, except the - first argument is a regular expression - match against the requested URL.

    +

    the second worker isn't actually created. Instead the first + worker is used. The benefit is, that there is only one connection pool, + so connections are more often reused. Note that all configuration attributes + given explicitly for the later worker will be ignored. This will be logged + as a warning. In the above example the resulting timeout value + for the URL /examples will be 60 instead + of 10!

    -
    -
    top
    -

    ProxyRequests Directive

    - - - - - - - -
    Description:Enables forward (standard) proxy requests
    Syntax:ProxyRequests On|Off
    Default:ProxyRequests Off
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    -

    This allows or prevents Apache httpd from functioning as a forward proxy - server. (Setting ProxyRequests to Off does not disable use of - the ProxyPass directive.)

    +

    If you want to avoid worker sharing, sort your worker definitions + by URL length, starting with the longest worker URLs. If you want to maximize + worker sharing use the reverse sort order. See also the related warning about + ordering ProxyPass directives.

    -

    In a typical reverse proxy or gateway configuration, this - option should be set to - Off.

    +
    -

    In order to get the functionality of proxying HTTP or FTP sites, you - need also mod_proxy_http or mod_proxy_ftp - (or both) present in the server.

    +

    Explicitly configured workers come in two flavors: + direct workers and (load) balancer workers. + They support many important configuration attributes which are + described below in the ProxyPass + directive. The same attributes can also be set using + ProxySet.

    -

    In order to get the functionality of (forward) proxying HTTPS sites, you - need mod_proxy_connect enabled in the server.

    +

    The set of options available for a direct worker + depends on the protocol, which is specified in the origin server URL. + Available protocols include ajp, fcgi, + ftp, http and scgi.

    -

    Warning

    -

    Do not enable proxying with ProxyRequests until you have secured your server. Open proxy servers are dangerous - both to your network and to the Internet at large.

    -
    +

    Balancer workers are virtual workers that use direct workers known + as their members to actually handle the requests. Each balancer can + have multiple members. When it handles a request, it chooses a member + based on the configured load balancing algorithm.

    -

    See also

    - -
    -
    top
    -

    ProxySet Directive

    - - - - - - - -
    Description:Set various Proxy balancer or member parameters
    Syntax:ProxySet url key=value [key=value ...]
    Context:directory
    Status:Extension
    Module:mod_proxy
    Compatibility:ProxySet is only available in Apache HTTP Server 2.2 - and later.
    -

    This directive is used as an alternate method of setting any of the - parameters available to Proxy balancers and workers normally done via the - ProxyPass directive. If used - within a <Proxy balancer url|worker url> - container directive, the url argument is not required. As a side - effect the respective balancer or worker gets created. This can be useful - when doing reverse proxying via a - RewriteRule instead of a - ProxyPass directive.

    +

    A balancer worker is created if its worker URL uses + balancer as the protocol scheme. + The balancer URL uniquely identifies the balancer worker. + Members are added to a balancer using + BalancerMember.

    - 
    <Proxy "balancer://hotcluster">
-    BalancerMember "http://www2.example.com:8080" loadfactor=1
-    BalancerMember "http://www3.example.com:8080" loadfactor=2
-    ProxySet lbmethod=bytraffic
-</Proxy>
    -
    +
    top
    +
    +

    Controlling access to your proxy

    +

    You can control who can access your proxy via the <Proxy> control block as in + the following example:

    - 
    <Proxy "http://backend">
-    ProxySet keepalive=On
+      
    <Proxy "*">
+  Require ip 192.168.0
 </Proxy>
    
 
 
-    
    ProxySet "balancer://foo" lbmethod=bytraffic timeout=15
    
+      
    For more information on access control directives, see
+      mod_authz_host.
    
 
+      
    Strictly limiting access is essential if you are using a
+      forward proxy (using the ProxyRequests directive).
+      Otherwise, your server can be used by any client to access
+      arbitrary hosts while hiding his or her true identity.  This is
+      dangerous both for your network and for the Internet at large.
+      When using a reverse proxy (using the ProxyPass directive with
+      ProxyRequests Off), access control is less
+      critical because clients can only contact the hosts that you
+      have specifically configured.
    
 
-    
    ProxySet "ajp://backend:7001" timeout=15
    
+      
    See Also the Proxy-Chain-Auth environment variable.
    
 
+
    top
    +
    +

    Slow Startup

    +

    If you're using the ProxyBlock directive, hostnames' IP addresses are looked up + and cached during startup for later match test. This may take a few + seconds (or more) depending on the speed with which the hostname lookups + occur.

    +
    top
    +
    +

    Intranet Proxy

    +

    An Apache httpd proxy server situated in an intranet needs to forward + external requests through the company's firewall (for this, configure + the ProxyRemote directive + to forward the respective scheme to the firewall proxy). + However, when it has to + access resources within the intranet, it can bypass the firewall when + accessing hosts. The NoProxy + directive is useful for specifying which hosts belong to the intranet and + should be accessed directly.

    -

    Warning

    -

    Keep in mind that the same parameter key can have a different meaning - depending whether it is applied to a balancer or a worker as shown by the two - examples above regarding timeout.

    -
    +

    Users within an intranet tend to omit the local domain name from their + WWW requests, thus requesting "http://somehost/" instead of + http://somehost.example.com/. Some commercial proxy servers + let them get away with this and simply serve the request, implying a + configured local domain. When the ProxyDomain directive is used and the server is configured for proxy service, Apache httpd can return + a redirect response and send the client to the correct, fully qualified, + server address. This is the preferred method since the user's bookmark + files will then contain fully qualified hosts.

    +
    top
    +
    +

    Protocol Adjustments

    +

    For circumstances where mod_proxy is sending + requests to an origin server that doesn't properly implement + keepalives or HTTP/1.1, there are two environment variables that can force the + request to use HTTP/1.0 with no keepalive. These are set via the + SetEnv directive.

    +

    These are the force-proxy-request-1.0 and + proxy-nokeepalive notes.

    -
    -
    top
    -

    ProxySourceAddress Directive

    - - - - - - - -
    Description:Set local IP address for outgoing proxy connections
    Syntax:ProxySourceAddress address
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    Compatibility:Available in version 2.3.9 and later
    -

    This directive allows to set a specific local address to bind to when connecting - to a backend server.

    + 
    <Location "/buggyappserver/">
+  ProxyPass "http://buggyappserver:7001/foo/"
+  SetEnv force-proxy-request-1.0 1
+  SetEnv proxy-nokeepalive 1
+</Location>
    -
    -
    top
    -

    ProxyStatus Directive

    - - - - - - - - -
    Description:Show Proxy LoadBalancer status in mod_status
    Syntax:ProxyStatus Off|On|Full
    Default:ProxyStatus Off
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    Compatibility:Available in version 2.2 and later
    -

    This directive determines whether or not proxy - loadbalancer status data is displayed via the mod_status - server-status page.

    -

    Note

    -

    Full is synonymous with On

    -
    +
    top
    +
    +

    Request Bodies

    -
    -
    top
    -

    ProxyTimeout Directive

    - - - - - - - -
    Description:Network timeout for proxied requests
    Syntax:ProxyTimeout seconds
    Default:Value of Timeout
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    -

    This directive allows a user to specifiy a timeout on proxy requests. - This is useful when you have a slow/buggy appserver which hangs, and you - would rather just return a timeout and fail gracefully instead of waiting - however long it takes the server to return.

    +

    Some request methods such as POST include a request body. + The HTTP protocol requires that requests which include a body + either use chunked transfer encoding or send a + Content-Length request header. When passing these + requests on to the origin server, mod_proxy_http + will always attempt to send the Content-Length. But + if the body is large and the original request used chunked + encoding, then chunked encoding may also be used in the upstream + request. You can control this selection using environment variables. Setting + proxy-sendcl ensures maximum compatibility with + upstream servers by always sending the + Content-Length, while setting + proxy-sendchunked minimizes resource usage by using + chunked encoding.

    -
    -
    top
    -

    ProxyVia Directive

    - - - - - - - -
    Description:Information provided in the Via HTTP response -header for proxied requests
    Syntax:ProxyVia On|Off|Full|Block
    Default:ProxyVia Off
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    -

    This directive controls the use of the Via: HTTP - header by the proxy. Its intended use is to control the flow of - proxy requests along a chain of proxy servers. See RFC 2616 (HTTP/1.1), section - 14.45 for an explanation of Via: header lines.

    +

    Under some circumstances, the server must spool request bodies + to disk to satisfy the requested handling of request bodies. For + example, this spooling will occur if the original body was sent with + chunked encoding (and is large), but the administrator has + asked for backend requests to be sent with Content-Length or as HTTP/1.0. + This spooling can also occur if the request body already has a + Content-Length header, but the server is configured to filter incoming + request bodies.

    -
      -
    • If set to Off, which is the default, no special processing - is performed. If a request or reply contains a Via: header, - it is passed through unchanged.
      • +

      LimitRequestBody only applies to + request bodies that the server will spool to disk

      -
    • If set to On, each request and reply will get a - Via: header line added for the current host.
      • +
    top
    +
    +

    Reverse Proxy Request Headers

    -
  • If set to Full, each generated Via: header - line will additionally have the Apache httpd server version shown as a - Via: comment field.
    • +

    When acting in a reverse-proxy mode (using the ProxyPass directive, for example), + mod_proxy_http adds several request headers in + order to pass information to the origin server. These headers + are:

    -
  • If set to Block, every proxy request will have all its - Via: header lines removed. No new Via: header will - be generated.
    • - +
    +
    X-Forwarded-For
    +
    The IP address of the client.
    +
    X-Forwarded-Host
    +
    The original host requested by the client in the Host + HTTP request header.
    +
    X-Forwarded-Server
    +
    The hostname of the proxy server.
    +
    -
    +

    Be careful when using these headers on the origin server, since + they will contain more than one (comma-separated) value if the + original request already contained one of these headers. For + example, you can use %{X-Forwarded-For}i in the log + format string of the origin server to log the original clients IP + address, but you may get more than one address if the request + passes through several proxies.

    + +

    See also the ProxyPreserveHost and ProxyVia directives, which control + other request headers.

    + +

    Note: If you need to specify custom request headers to be + added to the forwarded request, use the + RequestHeader + directive.

    + +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_proxy.html.fr b/docs/manual/mod/mod_proxy.html.fr index f3da25edd47..ef187da79c7 100644 --- a/docs/manual/mod/mod_proxy.html.fr +++ b/docs/manual/mod/mod_proxy.html.fr @@ -157,1055 +157,676 @@

  • mod_ssl
    • top
    -
    -

    Mandataires directs et - mandataires/passerelles inverses

    -

    Le serveur HTTP Apache peut être configuré dans les deux modes mandataire - direct et mandataire inverse (aussi nommé - mode passerelle).

    +

    Directive BalancerGrowth

    + + + + + + + + +
    Description:Nombre de membres supplémentaires pouvant être ajoutés +après la configuration initiale
    Syntaxe:BalancerGrowth #
    Défaut:BalancerGrowth 5
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    Compatibilité:BalancerGrowth est disponible depuis la version 2.3.13 du +serveur HTTP Apache
    +

    Cette directive permet de définir le nombre de membres pouvant + être ajoutés au groupe de répartition de charge préconfiguré d'un + serveur virtuel. Elle n'est active que si le groupe a été + préconfiguré avec un membre au minimum.

    -

    Un mandataire direct standard est un serveur - intermédiaire qui s'intercale entre le client et le serveur - demandé. Pour obtenir un contenu hébergé par - le serveur demandé, le client envoie une requête au - mandataire en nommant le serveur demandé comme - cible, puis le mandataire extrait le contenu depuis le - serveur demandé et le renvoie enfin au client. Le client doit être - configuré de manière appropriée pour pouvoir utiliser le mandataire - direct afin d'accéder à d'autres sites.

    +
    +
    top
    +

    Directive BalancerInherit

    + + + + + + + + +
    Description:Héritage des membres du groupes de répartition de + charge du mandataire définis au niveau du serveur principal
    Syntaxe:BalancerInherit On|Off
    Défaut:BalancerInherit On
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    Compatibilité:Disponible à partir de la version 2.4.5 du serveur + HTTP Apache.
    +

    Cette directive permet d'attribuer au serveur virtuel courant + l'héritage des membres de groupes de répartition de charge + définis au niveau du serveur + principal. Elle ne doit pas être activée si vous + utilisez la fonctionnalité de modifications dynamiques du + gestionnaire de répartition de charge (Balancer Manager) pour + éviter des problèmes et des comportements inattendus.

    +

    Les définitions au niveau du serveur principal constituent + les définitions par défaut au niveau des serveurs virtuels.

    + + +
    +
    top
    +

    Directive BalancerMember

    + + + + + + + +
    Description:Ajoute un membre à un groupe de répartition de +charge
    Syntaxe:BalancerMember [balancerurl] url [clé=valeur [clé=valeur ...]]
    Contexte:répertoire
    Statut:Extension
    Module:mod_proxy
    Compatibilité:Disponible depuis la version 2.2 du serveur HTTP Apache.
    +

    Cette directive permet d'ajouter un membre à un groupe de + répartition de charge. Elle peut se trouver dans un conteneur + <Proxy balancer://...>, et accepte + tous les paramètres de paires clé/valeur que supporte la directive + ProxyPass.

    +

    La directive BalancerMember accepte un paramètre + supplémentaire : loadfactor. Il s'agit du facteur de + charge du membre - un nombre entre 1 (valeur par défaut) et 100, qui + définit la charge à appliquer au membre en question.

    +

    L'argument balancerurl n'est requis que s'il ne se trouve pas + dèjà dans la directive de conteneur <Proxy + balancer://...>. Il correspond à l'URL d'un + répartiteur de charge défini par une directive ProxyPass.

    +

    La partie chemin de l'URL du répartiteur dans toute directive de + conteneur <Proxy balancer://...> est + ignorée.

    +

    En particulier, le slash de fin de l'URL d'un + BalancerMember doit être supprimé.

    -

    L'accès à Internet depuis des clients situés derrière un - pare-feu est une utilisation typique du mandataire direct. Le - mandataire direct peut aussi utiliser la mise en cache (fournie - par mod_cache) pour réduire la charge du - réseau.

    +
    +
    top
    +

    Directive BalancerPersist

    + + + + + + + + +
    Description:Tente de conserver les changements effectués par le + gestionnaire de répartition de charge après un redémarrage du + serveur.
    Syntaxe:BalancerPersist On|Off
    Défaut:BalancerPersist Off
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    Compatibilité:BalancerPersist n'est disponible qu'à partir de la + version 2.4.4 du serveur HTTP Apache.
    +

    Cette directive permet de conserver le contenu de l'espace + mémoire partagé associé aux répartiteurs de charge et à leurs + membres après un redémarrage du serveur. Ces modifications + locales ne sont ainsi pas perdues lors des transitions d'état + dues à un redémarrage.

    + +
    +
    top
    +

    Directive NoProxy

    + + + + + + +
    Description:Serveurs, domaines ou réseaux auquels on se connectera +directement
    Syntaxe:NoProxy domaine [domaine] ...
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    +

    Cette directive n'a d'utilité que pour les serveurs mandataires + Apache httpd au sein d'Intranets. La directive + NoProxy permet de spécifier une liste de + sous-réseaux, d'adresses IP, de serveurs et/ou de domaines séparés + par des espaces. Une requête pour un serveur qui correspond à un ou + plusieurs critères sera toujours servie par ce serveur directement, + sans être redirigée vers le(s) serveur(s) mandataire(s) défini(s) par + la directive ProxyRemote.

    -

    La fonctionnalité de mandataire direct est activée via la - directive ProxyRequests. - Comme les mandataires directs permettent aux clients d'accéder à - des sites quelconques via votre serveur et de dissimuler leur - véritable origine, il est indispensable de sécuriser votre serveur de façon à ce que seuls - les clients autorisés puissent accéder à votre serveur avant - d'activer la fonctionnalité de mandataire direct.

    +

    Exemple

    ProxyRemote  *  http://firewall.example.com:81
+NoProxy         .example.com 192.168.112.0/21
    +
    -

    Un mandataire inverse (ou passerelle), - quant à lui, apparaît au client comme un serveur web standard. - Aucune configuration particulière du client n'est nécessaire. Le - client adresse ses demandes de contenus ordinaires dans l'espace - de nommage du mandataire inverse. Ce dernier décide alors où - envoyer ces requêtes, et renvoie le contenu au client comme s'il - l'hébergeait lui-même.

    +

    Le type des arguments serveur de la directive + NoProxy appartiennent à la liste suivante + :

    -

    L'accès d'utilisateurs depuis Internet vers un serveur situé - derrière un pare-feu est une utilisation typique du mandataire - inverse. On peut aussi utiliser les mandataires inverses pour - mettre en oeuvre une répartition de charge entre plusieurs - serveurs en arrière-plan, ou fournir un cache pour un serveur - d'arrière-plan plus lent. Les mandataires inverses peuvent aussi - tout simplement servir à rassembler plusieurs serveurs dans le - même espace de nommage d'URLs.

    +
    + +
    Domaine
    +
    +

    Un domaine est ici un nom de domaine DNS partiellement + qualifié précédé d'un point. Il représente une liste de serveurs qui + appartiennent logiquement au même domaine ou à la même zonz DNS + (en d'autres termes, les nom des serveurs se terminent tous par + domaine).

    -

    La fonctionnalité de mandataire inverse est activée via la - directive ProxyPass ou - le drapeau [P] de la directive RewriteRule. Il n'est - pas nécessaire de définir ProxyRequests pour configurer - un mandataire inverse.

    -
    top
    -
    -

    Exemples simples

    +

    Exemple

    + .com .example.org. +

    -

    Les exemples ci-dessous illustrent de manière très basique la - mise en oeuvre de la fonctionnalité de mandataire et ne sont là que - pour vous aider à démarrer. Reportez-vous à la documentation de - chaque directive.

    +

    Pour faire la distinction entre domaines et nom d'hôtes (des points de vue à la fois + syntaxique et + sémantique, un domaine DNS pouvant aussi avoir un enregistrement DNS + de type A !), les domaines sont toujours spécifiés en les + préfixant par un point.

    -

    Si en outre, vous désirez activer la mise en cache, consultez la - documentation de mod_cache.

    +

    Note

    +

    Les comparaisons de noms de domaines s'effectuent sans tenir + compte de la casse, et les parties droites des Domaines + sont toujours censées correspondre à la racine de l'arborescence + DNS, si bien que les domaines .ExEmple.com et + .example.com. (notez le point à la fin du nom) sont + considérés comme identiques. Comme une comparaison de domaines ne + nécessite pas de recherche DNS, elle est beaucoup plus efficace + qu'une comparaison de sous-réseaux.

    +
    -

    Mandataire inverse

    ProxyPass /foo http://foo.example.com/bar
-ProxyPassReverse /foo http://foo.example.com/bar
    -
    + +
    Sous-réseau
    +
    +

    Un Sous-réseau est une adresse internet partiellement + qualifiée sous forme numérique (quatre nombres séparés par des + points), optionnellement suivie d'un slash et du masque de + sous-réseau spécifiant le nombre de bits significatifs dans le + Sous-réseau. Il représente un sous-réseau de serveurs qui + peuvent être atteints depuis la même interface réseau. En l'absence + de masque de sous-réseau explicite, il est sous-entendu que les + digits manquants (ou caractères 0) de fin spécifient le masque de + sous-réseau (Dans ce cas, le masque de sous-réseau ne peut être + qu'un multiple de 8). Voici quelques exemples :

    -

    Mandataire direct

    ProxyRequests On
-ProxyVia On
+    
    
+    
    192.168 ou 192.168.0.0
    
+    
    le sous-réseau 192.168.0.0 avec un masque de sous-réseau
+    implicite de 16 bits significatifs (parfois exprimé sous la forme
+    255.255.0.0)
    
+    
    192.168.112.0/21
    
+    
    le sous-réseau 192.168.112.0/21 avec un masque de
+    sous-réseau implicite de 21 bits significatifs (parfois exprimé
+    sous la forme255.255.248.0)
    
+    
    
 
-<Proxy *>
-  Require host internal.example.com
-</Proxy>
    -
    -
    top
    -
    -

    Accès via un gestionnaire

    +

    Comme cas extrêmes, un Sous-réseau avec un masque de + sous-réseau de 32 bits significatifs est équivalent à une adresse IP, alors qu'un Sous-réseau avec un masque de + sous-réseau de 0 bit significatif (c'est à dire 0.0.0.0/0) est + identique à la constante _Default_, et peut correspondre + à toute adresse IP.

    -

    Vous pouvez aussi forcer le traitement d'une requête en tant que - requête de mandataire inverse en créant un gestionnaire de transfert - approprié. Dans l'exemple suivant, toutes les requêtes pour - des scripts PHP seront transmises au serveur FastCGI - spécifié via un mandat inverse : -

    + +
    Adresse IP
    +
    +

    Une Adresse IP est une adresse internet pleinement + qualifiée sous forme numérique (quatre nombres séparés par des + points). En général, cette adresse représente un serveur, mais elle + ne doit pas nécessairement correspondre à un nom de domaine DNS.

    +

    Exemple

    + 192.168.123.7 +

    -

    Scripts PHP et mandataire inverse

    <FilesMatch \.php$>
-    # Les sockets Unix nécessitent une version 2.4.7 ou supérieure du
-    # serveur HTTP Apache
-    SetHandler  "proxy:unix:/path/to/app.sock|fcgi://localhost/"
-</FilesMatch>
    -
    - -

    Cette fonctionnalité est disponible à partir de la version - 2.4.10 du serveur HTTP Apache.

    +

    Note

    +

    Une Adresse IP ne nécessite pas de résolution DNS, + et peut ainsi s'avérer plus efficace quant aux performances + d'Apache.

    +
    -
    top
    -
    -

    Workers

    -

    Le mandataire gère la configuration et les paramètres de - communication des serveurs originaux au sein d'objets nommés - workers. Deux types de worker sont fournis : le worker - par défaut du mandataire direct et le worker par défaut du - mandataire inverse. Il est aussi possible de définir explicitement - des workers supplémentaires.

    + +
    Nom de serveur
    +
    +

    Un Nom de serveur est un nom de domaine DNS pleinement + qualifié qui peut être résolu en une ou plusieurs adresses IP par le + service de noms de domaines DNS. Il représente un hôte logique (par + opposition aux Domaines, voir + ci-dessus), et doit pouvoir être résolu en une ou plusieurs adresses IP (ou souvent en une liste + d'hôtes avec différentes adresses + IP).

    -

    Les deux workers par défaut possèdent une configuration figée - et seront utilisés si aucun autre worker ne correspond à la - requête. Ils n'utilisent ni les jeux de connexions (connection - pooling), ni les - connexions HTTP persistantes (Keep-Alive). En effet, les - connexions TCP vers le serveur original sont fermées et ouvertes - pour chaque requête.

    +

    Exemples

    + prep.ai.example.edu
    + www.example.org +

    -

    Les workers définis explicitement sont identifiés par leur URL. - Ils sont en général définis via les directives ProxyPass ou ProxyPassMatch lorsqu'on les - utilise dans le cadre d'un mandataire inverse :

    +

    Note

    +

    Dans de nombreuses situations, il est plus efficace de + spécifier une adresse IP qu'un + Nom de serveur car cela évite d'avoir à effectuer une + recherche DNS. La résolution de nom dans Apache httpd peut prendre un + temps très long lorsque la connexion avec le serveur de noms + utilise une liaison PPP lente.

    +

    Les comparaisons de Nom de serveur s'effectuent sans tenir + compte de la casse, et les parties droites des Noms de serveur + sont toujours censées correspondre à la racine de l'arborescence + DNS, si bien que les domaines WWW.ExEmple.com et + www.example.com. (notez le point à la fin du nom) sont + considérés comme identiques.

    +
    + - 
    ProxyPass /example http://backend.example.com connectiontimeout=5 timeout=30
    +

    Voir aussi

    +
    - +
    top
    +

    Directive <Proxy>

    + + + + + + +
    Description:Conteneur de directives s'appliquant à des ressources +mandatées
    Syntaxe:<Proxy url-avec-jokers> ...</Proxy>
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    +

    Les directives situées dans une section <Proxy> ne s'appliquent qu'au contenu + mandaté concerné. Les jokers de style shell sont autorisés.

    -

    Cette directive va créer un worker associé à l'URL du serveur - original http://backend.example.com, et utilisant les - valeurs de timeout données. Lorsqu'ils sont utilisés dans le cadre - d'un mandataire direct, les workers sont en général définis via la - directive ProxySet,

    +

    Par exemple, les lignes suivantes n'autoriseront à accéder à un + contenu via votre serveur mandataire que les hôtes appartenant à + votre-reseau.example.com :

    - 
    ProxySet http://backend.example.com connectiontimeout=5 timeout=30
    -
    - + 
    <Proxy *>
+  Require host votre-reseau.example.com
+</Proxy>
    -

    ou encore via les directives Proxy et ProxySet :

    - 
    <Proxy http://backend.example.com>
-  ProxySet connectiontimeout=5 timeout=30
+    
    Dans l'exemple suivant, tous les fichiers du répertoire
+    foo de example.com seront traités par le
+    filtre INCLUDES lorsqu'ils seront envoyés par
+    l'intermédiaire du serveur mandataire :
    
+
+    
    <Proxy http://example.com/foo/*>
+  SetOutputFilter INCLUDES
 </Proxy>
    
 
 
-      
    L'utilisation de workers définis explicitement dans le mode
-      mandataire direct n'est pas très courante, car les mandataires
-      directs communiquent en général avec de nombreux serveurs
-      originaux. La création explicite de workers pour certains serveurs
-      originaux peut cependant s'avérer utile si ces serveurs sont
-      très souvent sollicités. A leur niveau, les workers explicitement
-      définis ne possèdent aucune notion de mandataire direct ou
-      inverse. Ils encapsulent un concept de communication commun avec
-      les serveurs originaux. Un worker créé via la directive ProxyPass pour être utilisé dans le
-      cadre d'un mandataire inverse sera aussi utilisé dans le cadre
-      d'un mandataire directe chaque fois que l'URL vers le serveur
-      original correspondra à l'URL du worker, et vice versa.
    
+    
    Différences avec la section de configuration Location
    
+      
    Une URL d'arrière-plan sera concernée par le conteneur Proxy si
+      elle commence par la url-avec-jokers, même si le
+      dernier segment de chemin de la directive ne correspond qu'à un
+      préfixe de segment dee chemin de l'URL d'arrière-plan. Par exemple, <Proxy
+      http://example.com/foo> correspondra entre autres aux URLs
+      http://example.com/foo, http://example.com/foo/bar, et
+      http://example.com/foobar. La correspondance de l'URL finale
+      diffère du comportement de la section <Location> qui, pour le cas de cette note,
+      traitera le segment de chemin final comme s'il se terminait par un
+      slash.
    
+      
    Pour un contrôle plus fin de la correspondance des URL, voir la
+      directive <ProxyMatch>.
    
+    
    
 
-      
    L'URL qui identifie un worker correspond à l'URL de son serveur
-      original, y compris un éventuel chemin donné :
    
 
-      
    ProxyPass /examples http://backend.example.com/examples
-ProxyPass /docs http://backend.example.com/docs
    
+
    Voir aussi
    
+
+
    +
    top
    +

    Directive ProxyAddHeaders

    + + + + + + + + +
    Description:Ajoute des informations à propos du mandataire aux +en-têtes X-Forwarded-*
    Syntaxe:ProxyAddHeaders Off|On
    Défaut:ProxyAddHeaders On
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_proxy
    Compatibilité:Disponible depuis la version 2.3.10
    +

    Cette directive permet de passer au serveur d'arrière-plan des + informations à propos du mandataire via les en-têtes HTTP + X-Forwarded-For, X-Forwarded-Host et X-Forwarded-Server.

    +

    Utilité

    +

    Cette option n'est utile que dans le cas du mandat HTTP traité + par mod_proxy_http.

    +
    +
    +
    top
    +

    Directive ProxyBadHeader

    + + + + + + + +
    Description:Détermine la manière de traiter les lignes d'en-tête +incorrectes d'une réponse
    Syntaxe:ProxyBadHeader IsError|Ignore|StartBody
    Défaut:ProxyBadHeader IsError
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    +

    La directive ProxyBadHeader permet de + déterminer le comportement de mod_proxy lorsqu'il + reçoit des lignes d'en-tête de réponse dont la syntaxe n'est pas valide (c'est + à dire ne contenant pas de caractère ':') en provenance du serveur + original. Les arguments disponibles sont :

    -

    Dans cet exemple, deux workers différents sont définis, chacun - d'eux utilisant des configurations et jeux de connexions - séparés.

    +
    +
    IsError
    +
    Annule la requête et renvoie une réponse de code 502 (mauvaise + passerelle). C'est le comportement par défaut.
    -

    Partage de workers

    -

    Le partage de workers intervient lorsque les URLs des workers - s'entrecoupent, ce qui arrive lorsque l'URL d'un worker - correspond au début de l'URL d'un autre worker défini plus loin - dans le fichier de configuration. Dans l'exemple suivant,

    +
    Ignore
    +
    Traite les lignes d'en-tête incorrectes comme si elles n'avaient + pas été envoyées.
    - 
    ProxyPass /apps http://backend.example.com/ timeout=60
-ProxyPass /examples http://backend.example.com/examples timeout=10
    +
    StartBody
    +
    A la réception de la première ligne d'en-tête incorrecte, les + autres en-têtes sont lus et ce qui reste est traité en tant que + corps. Ceci facilite la prise en compte des serveurs d'arrière-plan + bogués qui oublient d'insérer une ligne vide entre les + en-têtes et le corps.
    +
    +
    +
    top
    +

    Directive ProxyBlock

    + + + + + + +
    Description:Termes, serveurs ou domaines bloqués par le +mandataire
    Syntaxe:ProxyBlock *|terme|serveur|domaine +[terme|serveur|domaine] ...
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    +

    La directive ProxyBlock permet de + spécifier une liste de termes, serveurs et/ou domaines, séparés par + des espaces. Les requêtes de documents HTTP, HTTPS, FTP vers des + sites dont les noms contiennent des termes, noms de serveur ou + domaine correspondants seront bloqués par le serveur + mandataire. La module proxy va aussi tenter de déterminer les + adresses IP des éléments de la liste qui peuvent correspondre à des + noms d'hôtes au cours du démarrage, et les mettra en cache à des + fins de comparaisons ultérieures. Ceci peut ralentir le démarrage du + serveur.

    -

    le second worker n'est pas vraiment créé. C'est le premier - worker qui est en fait utilisé. L'avantage de ceci réside dans - le fait qu'il n'existe qu'un seul jeu de connexions, ces - dernières étant donc réutilisées plus souvent. Notez que tous - les attributs de configuration définis explicitement pour le - deuxième worker seront ignorés, ce qui sera journalisé en tant - qu'avertissement. Ainsi, dans l'exemple ci-dessus, la valeur de - timeout retenue pour l'URL /exemples sera - 60, et non 10 !

    +

    Exemple

    ProxyBlock news.example.com auctions.example.com friends.example.com
    +
    -

    Si vous voulez empêcher le partage de workers, classez vos - définitions de workers selon la longueur des URLs, de la plus - longue à la plus courte. Si au contraire vous voulez favoriser - ce partage, utilisez l'ordre de classement inverse. Voir aussi - l'avertissement à propos de l'ordre de classement des directives - ProxyPass.

    +

    Notez qu'example suffirait aussi pour atteindre + ces sites.

    -
    +

    Hosts conviendrait aussi s'il était référencé par adresse IP.

    -

    Les workers définis explicitement sont de deux sortes : - workers directs et workers de répartition (de - charge). Ils supportent de nombreux attributs de - configuration importants décrits dans la directive ProxyPass. Ces mêmes attributs - peuvent aussi être définis via la directive ProxySet.

    +

    Notez aussi que

    -

    Le jeu d'options disponibles pour un worker direct dépend du - protocole spécifié dans l'URL du serveur original. Les protocoles - disponibles comprennent ajp, fcgi, - ftp, http et scgi.

    + 
    ProxyBlock *
    -

    Les workers de répartition sont des workers virtuels qui - utilisent les workers directs, connus comme faisant partie de leurs - membres, pour le traitement effectif des requêtes. Chaque - répartiteur peut comporter plusieurs membres. Lorsqu'il traite une - requête, il choisit un de ses membres en fonction de l'algorithme - de répartition de charge défini.

    - -

    Un worker de répartition est créé si son URL de worker comporte - balancer comme indicateur de protocole. L'URL du - répartiteur permet d'identifier de manière unique le worker de - répartition. La directive BalancerMember permet d'ajouter des - membres au répartiteur.

    - -
    top
    -
    -

    Contrôler l'accès à votre - mandataire

    -

    Vous pouvez restreindre l'accès à votre mandataire via le bloc - de contrôle <Proxy> comme dans - l'exemple suivant :

    - - 
    <Proxy *>
-  Require ip 192.168.0
-</Proxy>
    - - -

    Pour plus de détails sur les directives de contrôle d'accès, - voir la documentation du module - mod_authz_host.

    - -

    Restreindre l'accès de manière stricte est essentiel si vous - mettez en oeuvre un mandataire direct (en définissant la directive - ProxyRequests à "on"). - Dans le cas contraire, votre serveur pourrait être utilisé par - n'importe quel client pour accéder à des serveurs quelconques, - tout en masquant sa véritable identité. Ceci représente un danger - non seulement pour votre réseau, mais aussi pour l'Internet au - sens large. Dans le cas de la mise en oeuvre d'un mandataire - inverse (en utilisant la directive ProxyPass avec ProxyRequests Off), le contrôle - d'accès est moins critique car les clients ne peuvent contacter - que les serveurs que vous avez spécifiés.

    - -

    Voir aussi la variable d'environnement Proxy-Chain-Auth.

    - -
    top
    -
    -

    Ralentissement au démarrage

    -

    Si vous utilisez la directive ProxyBlock, les noms d'hôtes sont résolus en adresses - IP puis ces dernières mises en cache au cours du démarrage - à des fins de tests de comparaisons ultérieurs. Ce processus peut - durer plusieurs secondes (ou d'avantage) en fonction de la vitesse - à laquelle s'effectue la résolution des noms d'hôtes.

    -
    top
    -
    -

    Mandataire en Intranet

    -

    Un serveur mandataire Apache httpd situé à l'intérieur d'un Intranet - doit faire suivre les requêtes destinées à un serveur externe à - travers le pare-feu de l'entreprise (pour ce faire, définissez la - directive ProxyRemote de - façon à ce qu'elle fasse suivre le protocole concerné - vers le mandataire du pare-feu). Cependant, lorsqu'il doit accéder - à des ressources situées dans l'Intranet, il peut se passer du - pare-feu pour accéder aux serveurs. A cet effet, la directive - NoProxy permet de - spécifier quels hôtes appartiennent à l'Intranet et peuvent donc - être accédés directement.

    - -

    Les utilisateurs d'un Intranet ont tendance à oublier le nom du - domaine local dans leurs requêtes WWW, et demandent par exemple - "http://un-serveur/" au lieu de - http://un-serveur.example.com/. Certains serveurs - mandataires commerciaux acceptent ce genre de requête et les - traitent simplement en utilisant un nom de domaine local - implicite. Lorsque la directive ProxyDomain est utilisée et si le - serveur est configuré comme - mandataire, Apache httpd peut renvoyer une réponse de redirection et - ainsi fournir au client l'adresse de serveur correcte, - entièrement qualifiée. C'est la méthode à privilégier car le - fichier des marque-pages de l'utilisateur contiendra alors des - noms de serveurs entièrement qualifiés.

    -
    top
    -
    -

    Ajustements relatifs au - protocole

    -

    Pour les cas où mod_proxy envoie des requêtes - vers un serveur qui n'implémente pas correctement les connexions - persistantes ou le protocole HTTP/1.1, il existe deux variables - d'environnement qui permettent de forcer les requêtes à utiliser - le protocole HTTP/1.0 avec connexions non persistantes. Elles - peuvent être définies via la directive SetEnv.

    - -

    Il s'agit des variables force-proxy-request-1.0 et - proxy-nokeepalive.

    - - 
    <Location /buggyappserver/>
-  ProxyPass http://buggyappserver:7001/foo/
-  SetEnv force-proxy-request-1.0 1
-  SetEnv proxy-nokeepalive 1
-</Location>
    - - -
    top
    -
    -

    Corps de requêtes

    - -

    Certaines méthodes de requêtes comme POST comportent un corps de - requête. Le protocole HTTP stipule que les requêtes qui comportent - un corps doivent soit utiliser un codage de transmission - fractionnée (chunked transfer encoding), soit envoyer un en-tête de requête - Content-Length. Lorsqu'il fait suivre ce genre de - requête vers le serveur demandé, mod_proxy_http - s'efforce toujours d'envoyer l'en-tête Content-Length. - Par contre, si la taille du corps est importante, et si la requête - originale utilise un codage à fractionnement, ce dernier peut aussi - être utilisé dans la requête montante. Ce comportement peut être - contrôlé à l'aide de variables - d'environnement. Ainsi, si elle est définie, la variable - proxy-sendcl assure une compatibilité maximale avec les - serveurs demandés en imposant l'envoi de l'en-tête - Content-Length, alors que - proxy-sendchunked diminue la consommation de ressources - en imposant l'utilisation d'un codage à fractionnement.

    - -

    Dans certaines circonstances, le serveur doit mettre en file - d'attente sur disque les corps de requêtes afin de satisfaire le - traitement demandé des corps de requêtes. Par exemple, cette mise en - file d'attente se produira si le corps original a été envoyé selon un - codage morcelé (et possède une taille importante), alors que - l'administrateur a demandé que les requêtes du serveur - d'arrière-plan soient envoyées avec l'en-tête Content-Length ou en - HTTP/1.0. Cette mise en file d'attente se produira aussi si le corps - de la requête contient déjà un en-tête Content-Length, alors que le - serveur est configuré pour filtrer les corps des requêtes entrantes.

    - -

    La directive LimitRequestBody ne s'applique qu'aux - corps de requêtes que le serveur met en file d'attente sur disque.

    - -
    top
    -
    -

    En-têtes de requête du mandataire - inverse

    - -

    Lorsqu'il est configuré en mode mandataire inverse (en utilisant - par exemple la directive ProxyPass), - mod_proxy_http ajoute plusieurs en-têtes de requête - afin de transmettre des informations au serveur demandé. Ces - en-têtes sont les suivants :

    - -
    -
    X-Forwarded-For
    -
    L'adresse IP du client.
    -
    X-Forwarded-Host
    -
    L'hôte d'origine demandé par le client dans l'en-tête de - requête HTTP Host.
    -
    X-Forwarded-Server
    -
    Le nom d'hôte du serveur mandataire.
    -
    - -

    Ces en-têtes doivent être utilisés avec précautions sur le - serveur demandé, car ils contiendront plus d'une valeur (séparées - par des virgules) si la requête originale contenait déjà un de ces - en-têtes. Par exemple, vous pouvez utiliser - %{X-Forwarded-For}i dans la chaîne de format du journal - du serveur demandé pour enregistrer les adresses IP des clients - originaux, mais il est possible que vous obteniez plusieurs adresses - si la requête passe à travers plusieurs mandataires.

    - -

    Voir aussi les directives ProxyPreserveHost et ProxyVia directives, qui permettent - de contrôler d'autres en-têtes de requête.

    -

    Note : Si vous devez ajouter des en-têtes particuliers à la - requête mandatée, utilisez la directive RequestHeader.

    +

    bloque les connexions vers tous les sites.

    -
    +
    top
    -

    Directive BalancerGrowth

    +

    Directive ProxyDomain

    - - - + + -
    Description:Nombre de membres supplémentaires pouvant être ajoutés -après la configuration initiale
    Syntaxe:BalancerGrowth #
    Défaut:BalancerGrowth 5
    Description:Nom de domaine par défaut pour les requêtes +mandatées
    Syntaxe:ProxyDomain Domaine
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    Compatibilité:BalancerGrowth est disponible depuis la version 2.3.13 du -serveur HTTP Apache
    -

    Cette directive permet de définir le nombre de membres pouvant - être ajoutés au groupe de répartition de charge préconfiguré d'un - serveur virtuel. Elle n'est active que si le groupe a été - préconfiguré avec un membre au minimum.

    +

    Cette directive n'a d'utilité que pour les serveurs mandataires + Apache httpd au sein d'un Intranet. La directive + ProxyDomain permet de spécifier le domaine + par défaut auquel le serveur mandataire apache appartient. Si le + serveur reçoit une requête pour un hôte sans nom de domaine, il va + générer une réponse de redirection vers le même hôte suffixé par le + Domaine spécifié.

    + +

    Exemple

          ProxyRemote  *  http://firewall.example.com:81
    
+      NoProxy         .example.com 192.168.112.0/21
    
+      ProxyDomain     .example.com
    +
    top
    -

    Directive BalancerInherit

    +

    Directive ProxyErrorOverride

    - - - - + + + + -
    Description:Héritage des membres du groupes de répartition de - charge du mandataire définis au niveau du serveur principal
    Syntaxe:BalancerInherit On|Off
    Défaut:BalancerInherit On
    Contexte:configuration du serveur, serveur virtuel
    Description:Outrepasser les pages d'erreur pour les contenus +mandatés
    Syntaxe:ProxyErrorOverride On|Off
    Défaut:ProxyErrorOverride Off
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_proxy
    Compatibilité:Disponible à partir de la version 2.4.5 du serveur - HTTP Apache.
    -

    Cette directive permet d'attribuer au serveur virtuel courant - l'héritage des membres de groupes de répartition de charge - définis au niveau du serveur - principal. Elle ne doit pas être activée si vous - utilisez la fonctionnalité de modifications dynamiques du - gestionnaire de répartition de charge (Balancer Manager) pour - éviter des problèmes et des comportements inattendus.

    -

    Les définitions au niveau du serveur principal constituent - les définitions par défaut au niveau des serveurs virtuels.

    - - +

    Cette directive est utile pour les configurations de mandataires + inverses, lorsque vous souhaitez que les pages d'erreur envoyées + aux utilisateurs finaux présentent un aspect homogène. Elle permet + aussi l'inclusion de fichiers (via les SSI de + mod_include) pour obtenir le code d'erreur et agir + en conséquence (le comportement par défaut afficherait la page + d'erreur du serveur mandaté, alors que c'est le message d'erreur SSI + qui sera affiché si cette directive est à "on").

    + +

    Cette directive n'affecte pas le traitement des réponses + informatives (1xx), de type succès normal (2xx), ou de redirection + (3xx).

    +
    top
    -

    Directive BalancerMember

    +

    Directive ProxyIOBufferSize

    - - - + + + + -
    Description:Ajoute un membre à un groupe de répartition de -charge
    Syntaxe:BalancerMember [balancerurl] url [clé=valeur [clé=valeur ...]]
    Contexte:répertoire
    Description:Détermine la taille du tampon interne de transfert de +données
    Syntaxe:ProxyIOBufferSize octets
    Défaut:ProxyIOBufferSize 8192
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    Compatibilité:Disponible depuis la version 2.2 du serveur HTTP Apache.
    -

    Cette directive permet d'ajouter un membre à un groupe de - répartition de charge. Elle peut se trouver dans un conteneur - <Proxy balancer://...>, et accepte - tous les paramètres de paires clé/valeur que supporte la directive - ProxyPass.

    -

    La directive BalancerMember accepte un paramètre - supplémentaire : loadfactor. Il s'agit du facteur de - charge du membre - un nombre entre 1 (valeur par défaut) et 100, qui - définit la charge à appliquer au membre en question.

    -

    L'argument balancerurl n'est requis que s'il ne se trouve pas - dèjà dans la directive de conteneur <Proxy - balancer://...>. Il correspond à l'URL d'un - répartiteur de charge défini par une directive ProxyPass.

    -

    La partie chemin de l'URL du répartiteur dans toute directive de - conteneur <Proxy balancer://...> est - ignorée.

    -

    En particulier, le slash de fin de l'URL d'un - BalancerMember doit être supprimé.

    +

    La directive ProxyIOBufferSize permet + d'ajuster la taille du tampon interne utilisé comme bloc-note pour + les transferts de données entre entrée et sortie. La taille minimale + est de 512 octets.

    + +

    Dans la plupart des cas, il n'y a aucune raison de modifier cette + valeur.

    + +

    Si elle est utilisée avec AJP, cette directive permet de définir + la taille maximale du paquet AJP en octets. Si la valeur spécifiée + est supérieure à 65536, elle est corrigée et prend la valeur 65536. + Si vous ne conservez pas + la valeur par défaut, vous devez aussi modifier l'attribut + packetSize de votre connecteur AJP du côté de Tomcat ! + L'attribut packetSize n'est disponible que dans Tomcat + 5.5.20+ et 6.0.2+.

    +

    Il n'est normalement pas nécessaire de modifier la taille + maximale du paquet. Des problèmes ont cependant été rapportés avec + la valeur par défaut lors de l'envoi de certificats ou de chaînes de + certificats.

    +
    top
    -

    Directive BalancerPersist

    +

    Directive <ProxyMatch>

    - - - + + -
    Description:Tente de conserver les changements effectués par le - gestionnaire de répartition de charge après un redémarrage du - serveur.
    Syntaxe:BalancerPersist On|Off
    Défaut:BalancerPersist Off
    Description:Conteneur de directives s'appliquant à des ressources +mandatées correspondant à une expression rationnelle
    Syntaxe:<ProxyMatch regex> ...</ProxyMatch>
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    Compatibilité:BalancerPersist n'est disponible qu'à partir de la - version 2.4.4 du serveur HTTP Apache.
    -

    Cette directive permet de conserver le contenu de l'espace - mémoire partagé associé aux répartiteurs de charge et à leurs - membres après un redémarrage du serveur. Ces modifications - locales ne sont ainsi pas perdues lors des transitions d'état - dues à un redémarrage.

    - +

    La directive <ProxyMatch> est + identique à la directive <Proxy>, à l'exception qu'elle définit + les URLs auxquelles elle s'applique en utilisant une expression rationnelle.

    + +

    A partir de la version 2.4.8, les groupes nommés et les + références arrières sont extraits et enregistrés dans + l'environnement avec leur nom en majuscules et préfixé par "MATCH_". Ceci permet + de référencer des URLs dans des expressions + ou au sein de modules comme mod_rewrite. Pour + éviter toute confusion, les références arrières numérotées (non + nommées) sont ignorées. Vous devez utiliser à la place des groupes + nommés.

    + +
    <ProxyMatch ^http://(?<sitename>[^/]+)>
+    Require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
+</ProxyMatch>
    + + +

    Voir aussi

    +
    top
    -

    Directive NoProxy

    +

    Directive ProxyMaxForwards

    - - + + + +
    Description:Serveurs, domaines ou réseaux auquels on se connectera -directement
    Syntaxe:NoProxy domaine [domaine] ...
    Description:Nombre maximum de mandataires à travers lesquelles une +requête peut être redirigée
    Syntaxe:ProxyMaxForwards nombre
    Défaut:ProxyMaxForwards -1
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    Compatibilité:Comportement par défaut +modifié dans 2.2.7
    -

    Cette directive n'a d'utilité que pour les serveurs mandataires - Apache httpd au sein d'Intranets. La directive - NoProxy permet de spécifier une liste de - sous-réseaux, d'adresses IP, de serveurs et/ou de domaines séparés - par des espaces. Une requête pour un serveur qui correspond à un ou - plusieurs critères sera toujours servie par ce serveur directement, - sans être redirigée vers le(s) serveur(s) mandataire(s) défini(s) par - la directive ProxyRemote.

    +

    La directive ProxyMaxForwards permet de + spécifier le nombre maximum de mandataires à travers lesquels une + requête peut passer dans le cas où la la requête ne contient pas + d'en-tête Max-Forwards. Ceci permet de se prémunir + contre les boucles infinies de mandataires ou contre les attaques de + type déni de service.

    -

    Exemple

    ProxyRemote  *  http://firewall.example.com:81
-NoProxy         .example.com 192.168.112.0/21
    +

    Exemple

    ProxyMaxForwards 15
    -

    Le type des arguments serveur de la directive - NoProxy appartiennent à la liste suivante - :

    +

    Notez que la définition de la directive + ProxyMaxForwards constitue une violation du + protocole HTTP/1.1 (RFC2616), qui interdit à un mandataire de + définir Max-Forwards si le client ne l'a pas fait + lui-même. Les versions précédentes d'Apache httpd la définissaient + systématiquement. Une valeur négative de + ProxyMaxForwards, y compris la valeur par + défaut -1, implique un comportement compatible avec le protocole, + mais vous expose aux bouclages infinis.

    -
    - -
    Domaine
    -
    -

    Un domaine est ici un nom de domaine DNS partiellement - qualifié précédé d'un point. Il représente une liste de serveurs qui - appartiennent logiquement au même domaine ou à la même zonz DNS - (en d'autres termes, les nom des serveurs se terminent tous par - domaine).

    +
    +
    top
    +

    Directive ProxyPass

    + + + + + + + +
    Description:Référencer des serveurs distants depuis +l'espace d'URLs du serveur local
    Syntaxe:ProxyPass [chemin] !|url [clé=valeur + [clé=valeur ...]] [nocanon] [interpolate] [noquery]
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_proxy
    Compatibilité:Les sockets de style Unix (Unix Domain Socket - UDS) +sont supportés à partir de la version 2.4.7 du serveur HTTP Apache
    +

    Cette directive permet de référencer des serveurs distants depuis + l'espace d'URLs du serveur local ; le serveur + local n'agit pas en tant que mandataire au sens conventionnel, mais + plutôt comme miroir du serveur distant. Le serveur local est + souvent nommé mandataire inverse ou + passerelle. L'argument chemin est le nom d'un + chemin virtuel local ; url est une URL partielle pour le + serveur distant et ne doit pas contenir de chaîne d'arguments.

    -

    Exemple

    - .com .example.org. -

    +
    Note : Cette directive ne peut pas être + utilisée dans un contexte de niveau répertoire.
    -

    Pour faire la distinction entre domaines et nom d'hôtes (des points de vue à la fois - syntaxique et - sémantique, un domaine DNS pouvant aussi avoir un enregistrement DNS - de type A !), les domaines sont toujours spécifiés en les - préfixant par un point.

    +
    En général, la directive ProxyRequests doit être définie à + off lorsqu'on utilise la directive + ProxyPass.
    -

    Note

    -

    Les comparaisons de noms de domaines s'effectuent sans tenir - compte de la casse, et les parties droites des Domaines - sont toujours censées correspondre à la racine de l'arborescence - DNS, si bien que les domaines .ExEmple.com et - .example.com. (notez le point à la fin du nom) sont - considérés comme identiques. Comme une comparaison de domaines ne - nécessite pas de recherche DNS, elle est beaucoup plus efficace - qu'une comparaison de sous-réseaux.

    -
    +

    Les sockets de style Unix sont supportés à partir de la version + 2.4.7 du serveur HTTP Apache ; pour utiliser cette fonctionnalité, + il suffit d'utiliser une URL cible préfixée par + unix:/path/lis.sock|. Par exemple, pour mandater HTTP + et cibler l'UDS /home/www/socket, vous devez utiliser + unix:/home/www.socket|http://localhost/whatever/.

    - -
    Sous-réseau
    -
    -

    Un Sous-réseau est une adresse internet partiellement - qualifiée sous forme numérique (quatre nombres séparés par des - points), optionnellement suivie d'un slash et du masque de - sous-réseau spécifiant le nombre de bits significatifs dans le - Sous-réseau. Il représente un sous-réseau de serveurs qui - peuvent être atteints depuis la même interface réseau. En l'absence - de masque de sous-réseau explicite, il est sous-entendu que les - digits manquants (ou caractères 0) de fin spécifient le masque de - sous-réseau (Dans ce cas, le masque de sous-réseau ne peut être - qu'un multiple de 8). Voici quelques exemples :

    +
    Note :Le chemin associé à l'URL + unix: tient compte de la directive + DefaultRuntimeDir.
    -
    -
    192.168 ou 192.168.0.0
    -
    le sous-réseau 192.168.0.0 avec un masque de sous-réseau - implicite de 16 bits significatifs (parfois exprimé sous la forme - 255.255.0.0)
    -
    192.168.112.0/21
    -
    le sous-réseau 192.168.112.0/21 avec un masque de - sous-réseau implicite de 21 bits significatifs (parfois exprimé - sous la forme255.255.248.0)
    -
    +

    Supposons que le serveur local a pour adresse + http://example.com/ ; alors la ligne

    -

    Comme cas extrêmes, un Sous-réseau avec un masque de - sous-réseau de 32 bits significatifs est équivalent à une adresse IP, alors qu'un Sous-réseau avec un masque de - sous-réseau de 0 bit significatif (c'est à dire 0.0.0.0/0) est - identique à la constante _Default_, et peut correspondre - à toute adresse IP.

    + 
    <Location /mirror/foo/>
+    ProxyPass http://backend.example.com/
+</Location>
    - -
    Adresse IP
    -
    -

    Une Adresse IP est une adresse internet pleinement - qualifiée sous forme numérique (quatre nombres séparés par des - points). En général, cette adresse représente un serveur, mais elle - ne doit pas nécessairement correspondre à un nom de domaine DNS.

    -

    Exemple

    - 192.168.123.7 -

    -

    Note

    -

    Une Adresse IP ne nécessite pas de résolution DNS, - et peut ainsi s'avérer plus efficace quant aux performances - d'Apache.

    -
    +

    va convertir en interne toute requête pour + http://example.com/miroir/foo/bar en une requête + mandatée pour http://backend.example.com/bar.

    - -
    Nom de serveur
    -
    -

    Un Nom de serveur est un nom de domaine DNS pleinement - qualifié qui peut être résolu en une ou plusieurs adresses IP par le - service de noms de domaines DNS. Il représente un hôte logique (par - opposition aux Domaines, voir - ci-dessus), et doit pouvoir être résolu en une ou plusieurs adresses IP (ou souvent en une liste - d'hôtes avec différentes adresses - IP).

    +

    La syntaxe alternative suivante est valide, bien qu'elle puisse + induire une dégradation des performances lorsqu'elle est + présente en très grand nombre. Elle possède l'avantage de + permettre un contrôle dynamique via l'interface Balancer Manager :

    -

    Exemples

    - prep.ai.example.edu
    - www.example.org -

    - -

    Note

    -

    Dans de nombreuses situations, il est plus efficace de - spécifier une adresse IP qu'un - Nom de serveur car cela évite d'avoir à effectuer une - recherche DNS. La résolution de nom dans Apache httpd peut prendre un - temps très long lorsque la connexion avec le serveur de noms - utilise une liaison PPP lente.

    -

    Les comparaisons de Nom de serveur s'effectuent sans tenir - compte de la casse, et les parties droites des Noms de serveur - sont toujours censées correspondre à la racine de l'arborescence - DNS, si bien que les domaines WWW.ExEmple.com et - www.example.com. (notez le point à la fin du nom) sont - considérés comme identiques.

    -
    - - -

    Voir aussi

    - -
    -
    top
    -

    Directive <Proxy>

    - - - - - - -
    Description:Conteneur de directives s'appliquant à des ressources -mandatées
    Syntaxe:<Proxy url-avec-jokers> ...</Proxy>
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    -

    Les directives situées dans une section <Proxy> ne s'appliquent qu'au contenu - mandaté concerné. Les jokers de style shell sont autorisés.

    - -

    Par exemple, les lignes suivantes n'autoriseront à accéder à un - contenu via votre serveur mandataire que les hôtes appartenant à - votre-reseau.example.com :

    - - 
    <Proxy *>
-  Require host votre-reseau.example.com
-</Proxy>
    - - -

    Dans l'exemple suivant, tous les fichiers du répertoire - foo de example.com seront traités par le - filtre INCLUDES lorsqu'ils seront envoyés par - l'intermédiaire du serveur mandataire :

    - - 
    <Proxy http://example.com/foo/*>
-  SetOutputFilter INCLUDES
-</Proxy>
    - - -

    Différences avec la section de configuration Location

    -

    Une URL d'arrière-plan sera concernée par le conteneur Proxy si - elle commence par la url-avec-jokers, même si le - dernier segment de chemin de la directive ne correspond qu'à un - préfixe de segment dee chemin de l'URL d'arrière-plan. Par exemple, <Proxy - http://example.com/foo> correspondra entre autres aux URLs - http://example.com/foo, http://example.com/foo/bar, et - http://example.com/foobar. La correspondance de l'URL finale - diffère du comportement de la section <Location> qui, pour le cas de cette note, - traitera le segment de chemin final comme s'il se terminait par un - slash.

    -

    Pour un contrôle plus fin de la correspondance des URL, voir la - directive <ProxyMatch>.

    -
    + 
    ProxyPass /miroir/foo/ http://backend.example.com/
    -

    Voir aussi

    - -
    -
    top
    -

    Directive ProxyAddHeaders

    - - - - - - - - -
    Description:Ajoute des informations à propos du mandataire aux -en-têtes X-Forwarded-*
    Syntaxe:ProxyAddHeaders Off|On
    Défaut:ProxyAddHeaders On
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_proxy
    Compatibilité:Disponible depuis la version 2.3.10
    -

    Cette directive permet de passer au serveur d'arrière-plan des - informations à propos du mandataire via les en-têtes HTTP - X-Forwarded-For, X-Forwarded-Host et X-Forwarded-Server.

    -

    Utilité

    -

    Cette option n'est utile que dans le cas du mandat HTTP traité - par mod_proxy_http.

    +
    +

    Si le premier argument se termine par un slash + /, il doit en être de même pour le second argument + et vice versa. Dans le cas contraire, il risque de manquer des + slashes nécessaires dans la requête résultante vers le serveur + d'arrière-plan et les résulats ne seront pas ceux attendus. +

    -
    -
    top
    -

    Directive ProxyBadHeader

    - - - - - - - -
    Description:Détermine la manière de traiter les lignes d'en-tête -incorrectes d'une réponse
    Syntaxe:ProxyBadHeader IsError|Ignore|StartBody
    Défaut:ProxyBadHeader IsError
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    -

    La directive ProxyBadHeader permet de - déterminer le comportement de mod_proxy lorsqu'il - reçoit des lignes d'en-tête de réponse dont la syntaxe n'est pas valide (c'est - à dire ne contenant pas de caractère ':') en provenance du serveur - original. Les arguments disponibles sont :

    - -
    -
    IsError
    -
    Annule la requête et renvoie une réponse de code 502 (mauvaise - passerelle). C'est le comportement par défaut.
    - -
    Ignore
    -
    Traite les lignes d'en-tête incorrectes comme si elles n'avaient - pas été envoyées.
    +

    Le drapeau ! permet de soustraire un sous-répertoire + du mandat inverse, comme dans l'exemple suivant :

    -
    StartBody
    -
    A la réception de la première ligne d'en-tête incorrecte, les - autres en-têtes sont lus et ce qui reste est traité en tant que - corps. Ceci facilite la prise en compte des serveurs d'arrière-plan - bogués qui oublient d'insérer une ligne vide entre les - en-têtes et le corps.
    -
    + 
    <Location /mirror/foo/>
+    ProxyPass http://backend.example.com/
+</Location>
+<Location /mirror/foo/i>
+    ProxyPass !
+</Location>
    -
    -
    top
    -

    Directive ProxyBlock

    - - - - - - -
    Description:Termes, serveurs ou domaines bloqués par le -mandataire
    Syntaxe:ProxyBlock *|terme|serveur|domaine -[terme|serveur|domaine] ...
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    -

    La directive ProxyBlock permet de - spécifier une liste de termes, serveurs et/ou domaines, séparés par - des espaces. Les requêtes de documents HTTP, HTTPS, FTP vers des - sites dont les noms contiennent des termes, noms de serveur ou - domaine correspondants seront bloqués par le serveur - mandataire. La module proxy va aussi tenter de déterminer les - adresses IP des éléments de la liste qui peuvent correspondre à des - noms d'hôtes au cours du démarrage, et les mettra en cache à des - fins de comparaisons ultérieures. Ceci peut ralentir le démarrage du - serveur.

    -

    Exemple

    ProxyBlock news.example.com auctions.example.com friends.example.com
    -
    + 
    ProxyPass /mirror/foo/i !
+ProxyPass /mirror/foo http://backend.example.com
    -

    Notez qu'example suffirait aussi pour atteindre - ces sites.

    -

    Hosts conviendrait aussi s'il était référencé par adresse IP.

    +

    va mandater toutes les requêtes pour /miroir/foo + vers backend.example.com, sauf les requêtes + pour /miroir/foo/i.

    -

    Notez aussi que

    +

    Ordre de classement des directives ProxyPass

    +

    Les directives ProxyPass et ProxyPassMatch sont évaluées dans + l'ordre de leur apparition dans le fichier de configuration. La + première règle qui correspond s'applique. Vous devez donc en + général classer les règles ProxyPass qui entrent en conflit de + l'URL la plus longue à la plus courte. Dans le cas contraire, les + règles situées après une règle dont l'URL correspond au début de + leur propre URL seront ignorées. Notez que tout ceci est en + relation avec le partage de workers. Par contre, on ne peut placer + qu'une seule directive ProxyPass dans une section + Location, et c'est la section + la plus spécifique qui l'emportera.

    - 
    ProxyBlock *
    +

    Pour les mêmes raisons, les exclusions doivent se situer + avant les directives ProxyPass + générales.

    +
    -

    bloque les connexions vers tous les sites.

    +

    Depuis la version 2.1 du serveur HTTP Apache, mod_proxy supporte + les groupements de connexions vers un serveur d'arrière-plan. Les + connexions créées à la demande peuvent être enregistrées dans un + groupement pour une utilisation ultérieure. La taille du groupe + ainsi que d'autres caractéristiques peuvent être définies via la + directive ProxyPass au moyen de paramètres + clé=valeur dont la description fait l'objet du tableau + ci-dessous.

    -
    -
    top
    -

    Directive ProxyDomain

    - - - - - - -
    Description:Nom de domaine par défaut pour les requêtes -mandatées
    Syntaxe:ProxyDomain Domaine
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    -

    Cette directive n'a d'utilité que pour les serveurs mandataires - Apache httpd au sein d'un Intranet. La directive - ProxyDomain permet de spécifier le domaine - par défaut auquel le serveur mandataire apache appartient. Si le - serveur reçoit une requête pour un hôte sans nom de domaine, il va - générer une réponse de redirection vers le même hôte suffixé par le - Domaine spécifié.

    +

    Par défaut, mod_proxy permet et met en réserve le nombre maximum + de connexions pouvant être utilisées simultanément par le processus + enfant concerné du serveur web. Le paramètre max permet + de réduire cette valeur par défaut. Le paramètre ttl, + quant à lui, permet de définir une durée de vie optionnelle ; les + connexions qui n'ont pas été utilisées pendant au moins + ttl secondes seront fermées. ttl permet + aussi d'empêcher l'utilisation d'une connexion susceptible d'être + fermée suite à une fin de vie de connexion persistante sur le + serveur d'arrière-plan.

    -

    Exemple

          ProxyRemote  *  http://firewall.example.com:81
    
-      NoProxy         .example.com 192.168.112.0/21
    
-      ProxyDomain     .example.com
    -
    +

    Le groupement de connexions est maintenu au niveau de chaque + processus enfant du serveur web, et max, ainsi que les + autres paramètres, ne font + l'objet d'aucune coordination entre les différents processus + enfants, sauf si un seul processus enfant est autorisé par la + configuration ou la conception du module multi-processus (MPM).

    -
    -
    top
    -

    Directive ProxyErrorOverride

    - - - - - - - -
    Description:Outrepasser les pages d'erreur pour les contenus -mandatés
    Syntaxe:ProxyErrorOverride On|Off
    Défaut:ProxyErrorOverride Off
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_proxy
    -

    Cette directive est utile pour les configurations de mandataires - inverses, lorsque vous souhaitez que les pages d'erreur envoyées - aux utilisateurs finaux présentent un aspect homogène. Elle permet - aussi l'inclusion de fichiers (via les SSI de - mod_include) pour obtenir le code d'erreur et agir - en conséquence (le comportement par défaut afficherait la page - d'erreur du serveur mandaté, alors que c'est le message d'erreur SSI - qui sera affiché si cette directive est à "on").

    - -

    Cette directive n'affecte pas le traitement des réponses - informatives (1xx), de type succès normal (2xx), ou de redirection - (3xx).

    - -
    -
    top
    -

    Directive ProxyIOBufferSize

    - - - - - - - -
    Description:Détermine la taille du tampon interne de transfert de -données
    Syntaxe:ProxyIOBufferSize octets
    Défaut:ProxyIOBufferSize 8192
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    -

    La directive ProxyIOBufferSize permet - d'ajuster la taille du tampon interne utilisé comme bloc-note pour - les transferts de données entre entrée et sortie. La taille minimale - est de 512 octets.

    - -

    Dans la plupart des cas, il n'y a aucune raison de modifier cette - valeur.

    - -

    Si elle est utilisée avec AJP, cette directive permet de définir - la taille maximale du paquet AJP en octets. Si la valeur spécifiée - est supérieure à 65536, elle est corrigée et prend la valeur 65536. - Si vous ne conservez pas - la valeur par défaut, vous devez aussi modifier l'attribut - packetSize de votre connecteur AJP du côté de Tomcat ! - L'attribut packetSize n'est disponible que dans Tomcat - 5.5.20+ et 6.0.2+.

    -

    Il n'est normalement pas nécessaire de modifier la taille - maximale du paquet. Des problèmes ont cependant été rapportés avec - la valeur par défaut lors de l'envoi de certificats ou de chaînes de - certificats.

    - - -
    -
    top
    -

    Directive <ProxyMatch>

    - - - - - - -
    Description:Conteneur de directives s'appliquant à des ressources -mandatées correspondant à une expression rationnelle
    Syntaxe:<ProxyMatch regex> ...</ProxyMatch>
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    -

    La directive <ProxyMatch> est - identique à la directive <Proxy>, à l'exception qu'elle définit - les URLs auxquelles elle s'applique en utilisant une expression rationnelle.

    - -

    A partir de la version 2.4.8, les groupes nommés et les - références arrières sont extraits et enregistrés dans - l'environnement avec leur nom en majuscules et préfixé par "MATCH_". Ceci permet - de référencer des URLs dans des expressions - ou au sein de modules comme mod_rewrite. Pour - éviter toute confusion, les références arrières numérotées (non - nommées) sont ignorées. Vous devez utiliser à la place des groupes - nommés.

    - -
    <ProxyMatch ^http://(?<sitename>[^/]+)>
-    Require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
-</ProxyMatch>
    - - -

    Voir aussi

    - -
    -
    top
    -

    Directive ProxyMaxForwards

    - - - - - - - - -
    Description:Nombre maximum de mandataires à travers lesquelles une -requête peut être redirigée
    Syntaxe:ProxyMaxForwards nombre
    Défaut:ProxyMaxForwards -1
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    Compatibilité:Comportement par défaut -modifié dans 2.2.7
    -

    La directive ProxyMaxForwards permet de - spécifier le nombre maximum de mandataires à travers lesquels une - requête peut passer dans le cas où la la requête ne contient pas - d'en-tête Max-Forwards. Ceci permet de se prémunir - contre les boucles infinies de mandataires ou contre les attaques de - type déni de service.

    - -

    Exemple

    ProxyMaxForwards 15
    -
    - -

    Notez que la définition de la directive - ProxyMaxForwards constitue une violation du - protocole HTTP/1.1 (RFC2616), qui interdit à un mandataire de - définir Max-Forwards si le client ne l'a pas fait - lui-même. Les versions précédentes d'Apache httpd la définissaient - systématiquement. Une valeur négative de - ProxyMaxForwards, y compris la valeur par - défaut -1, implique un comportement compatible avec le protocole, - mais vous expose aux bouclages infinis.

    - -
    -
    top
    -

    Directive ProxyPass

    - - - - - - - -
    Description:Référencer des serveurs distants depuis -l'espace d'URLs du serveur local
    Syntaxe:ProxyPass [chemin] !|url [clé=valeur - [clé=valeur ...]] [nocanon] [interpolate] [noquery]
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_proxy
    Compatibilité:Les sockets de style Unix (Unix Domain Socket - UDS) -sont supportés à partir de la version 2.4.7 du serveur HTTP Apache
    -

    Cette directive permet de référencer des serveurs distants depuis - l'espace d'URLs du serveur local ; le serveur - local n'agit pas en tant que mandataire au sens conventionnel, mais - plutôt comme miroir du serveur distant. Le serveur local est - souvent nommé mandataire inverse ou - passerelle. L'argument chemin est le nom d'un - chemin virtuel local ; url est une URL partielle pour le - serveur distant et ne doit pas contenir de chaîne d'arguments.

    - -
    Note : Cette directive ne peut pas être - utilisée dans un contexte de niveau répertoire.
    - -
    En général, la directive ProxyRequests doit être définie à - off lorsqu'on utilise la directive - ProxyPass.
    - -

    Les sockets de style Unix sont supportés à partir de la version - 2.4.7 du serveur HTTP Apache ; pour utiliser cette fonctionnalité, - il suffit d'utiliser une URL cible préfixée par - unix:/path/lis.sock|. Par exemple, pour mandater HTTP - et cibler l'UDS /home/www/socket, vous devez utiliser - unix:/home/www.socket|http://localhost/whatever/.

    - -
    Note :Le chemin associé à l'URL - unix: tient compte de la directive - DefaultRuntimeDir.
    - -

    Supposons que le serveur local a pour adresse - http://example.com/ ; alors la ligne

    - - 
    <Location /mirror/foo/>
-    ProxyPass http://backend.example.com/
-</Location>
    - - -

    va convertir en interne toute requête pour - http://example.com/miroir/foo/bar en une requête - mandatée pour http://backend.example.com/bar.

    - -

    La syntaxe alternative suivante est valide, bien qu'elle puisse - induire une dégradation des performances lorsqu'elle est - présente en très grand nombre. Elle possède l'avantage de - permettre un contrôle dynamique via l'interface Balancer Manager :

    - - 
    ProxyPass /miroir/foo/ http://backend.example.com/
    - - -
    -

    Si le premier argument se termine par un slash - /, il doit en être de même pour le second argument - et vice versa. Dans le cas contraire, il risque de manquer des - slashes nécessaires dans la requête résultante vers le serveur - d'arrière-plan et les résulats ne seront pas ceux attendus. -

    -
    - -

    Le drapeau ! permet de soustraire un sous-répertoire - du mandat inverse, comme dans l'exemple suivant :

    - - 
    <Location /mirror/foo/>
-    ProxyPass http://backend.example.com/
-</Location>
-<Location /mirror/foo/i>
-    ProxyPass !
-</Location>
    - - - 
    ProxyPass /mirror/foo/i !
-ProxyPass /mirror/foo http://backend.example.com
    - - -

    va mandater toutes les requêtes pour /miroir/foo - vers backend.example.com, sauf les requêtes - pour /miroir/foo/i.

    - -

    Ordre de classement des directives ProxyPass

    -

    Les directives ProxyPass et ProxyPassMatch sont évaluées dans - l'ordre de leur apparition dans le fichier de configuration. La - première règle qui correspond s'applique. Vous devez donc en - général classer les règles ProxyPass qui entrent en conflit de - l'URL la plus longue à la plus courte. Dans le cas contraire, les - règles situées après une règle dont l'URL correspond au début de - leur propre URL seront ignorées. Notez que tout ceci est en - relation avec le partage de workers. Par contre, on ne peut placer - qu'une seule directive ProxyPass dans une section - Location, et c'est la section - la plus spécifique qui l'emportera.

    - -

    Pour les mêmes raisons, les exclusions doivent se situer - avant les directives ProxyPass - générales.

    - -
    - -

    Depuis la version 2.1 du serveur HTTP Apache, mod_proxy supporte - les groupements de connexions vers un serveur d'arrière-plan. Les - connexions créées à la demande peuvent être enregistrées dans un - groupement pour une utilisation ultérieure. La taille du groupe - ainsi que d'autres caractéristiques peuvent être définies via la - directive ProxyPass au moyen de paramètres - clé=valeur dont la description fait l'objet du tableau - ci-dessous.

    - -

    Par défaut, mod_proxy permet et met en réserve le nombre maximum - de connexions pouvant être utilisées simultanément par le processus - enfant concerné du serveur web. Le paramètre max permet - de réduire cette valeur par défaut. Le paramètre ttl, - quant à lui, permet de définir une durée de vie optionnelle ; les - connexions qui n'ont pas été utilisées pendant au moins - ttl secondes seront fermées. ttl permet - aussi d'empêcher l'utilisation d'une connexion susceptible d'être - fermée suite à une fin de vie de connexion persistante sur le - serveur d'arrière-plan.

    - -

    Le groupement de connexions est maintenu au niveau de chaque - processus enfant du serveur web, et max, ainsi que les - autres paramètres, ne font - l'objet d'aucune coordination entre les différents processus - enfants, sauf si un seul processus enfant est autorisé par la - configuration ou la conception du module multi-processus (MPM).

    - -

    Exemple

    ProxyPass /example http://backend.example.com max=20 ttl=120 retry=300
    +

    Exemple

    ProxyPass /example http://backend.example.com max=20 ttl=120 retry=300
    Paramètres de BalancerMember
    @@ -1543,651 +1164,1030 @@ ProxyPass /mirror/foo http://backend.example.com Disponible depuis la version 2.4.2 du serveur HTTP Apache.
    -

    Exemple de configuration d'un répartiteur de charge

    - 
    ProxyPass /special-area http://special.example.com smax=5 max=10
-ProxyPass / balancer://mycluster/ stickysession=JSESSIONID|jsessionid nofailover=On
-<Proxy balancer://mycluster>
-    BalancerMember ajp://1.2.3.4:8009
-    BalancerMember ajp://1.2.3.5:8009 loadfactor=20
-    # Less powerful server, don't send as many requests there,
-    BalancerMember ajp://1.2.3.6:8009 loadfactor=5
-</Proxy>
    +
    +

    Exemple de configuration d'un répartiteur de charge

    + 
    ProxyPass /special-area http://special.example.com smax=5 max=10
+ProxyPass / balancer://mycluster/ stickysession=JSESSIONID|jsessionid nofailover=On
+<Proxy balancer://mycluster>
+    BalancerMember ajp://1.2.3.4:8009
+    BalancerMember ajp://1.2.3.5:8009 loadfactor=20
+    # Less powerful server, don't send as many requests there,
+    BalancerMember ajp://1.2.3.6:8009 loadfactor=5
+</Proxy>
    + + +

    Configuration d'un serveur cible de réserve qui ne sera utilisé que si + aucun autre serveur cible n'est disponible

    + 
    ProxyPass / balancer://hotcluster/ 
+<Proxy balancer://hotcluster>
+    BalancerMember ajp://1.2.3.4:8009 loadfactor=1
+    BalancerMember ajp://1.2.3.5:8009 loadfactor=2
+    # The server below is on hot standby
+    BalancerMember ajp://1.2.3.6:8009 status=+H
+    ProxySet lbmethod=bytraffic
+</Proxy>
    + + +

    Normalement, mod_proxy va mettre sous leur forme canonique les + URLs traitées par ProxyPass. Mais ceci peut être incompatible avec + certains serveurs d'arrière-plan, et en particulier avec ceux qui + utilisent PATH_INFO. Le mot-clé optionnel + nocanon modifie ce comportement et permet de transmettre + le chemin d'URL sous sa forme brute au serveur d'arrière-plan. Notez + que ceci peut affecter la sécurité de votre serveur d'arrière-plan, + car la protection limitée contre les attaques à base d'URL que + fournit le mandataire est alors supprimée.

    + +

    Par défaut, mod_proxy inclut la chaîne de paramètres lors de la + génération de la variable d'environnement + SCRIPT_FILENAME. Le mot-clé optionnel noquery + (disponible à partir de la version 2.4.1) permet d'exclure cette + chaîne.

    + +

    Lorsque la directive ProxyPass est utilisée à l'intérieur d'une + section <Location>, le premier argument est omis et le répertoire + local est obtenu à partir de la section <Location>. Il en sera de même dans une + section <LocationMatch> ; cependant, ProxyPass + n'interprète pas les expressions rationnelles, et il sera ici + nécessaire d'utiliser la directive + ProxyPassMatch à la place.

    + +

    Cette directive ne peut pas être placée dans une section + <Directory> ou + <Files>.

    + +

    Si vous avez besoin d'un configuration de mandataire inverse plus + souple, reportez-vous à la documentaion de la directive RewriteRule et son drapeau + [P].

    + +

    Le mot-clé optionnel interpolate, en combinaison avec la directive + ProxyPassInterpolateEnv, permet à ProxyPass + d'interpoler les variables d'environnement à l'aide de la syntaxe + ${VARNAME}. Notez que de nombreuses variables + d'environnement standard dérivées de CGI n'existeront pas lorsque + l'interpolation se produit ; vous devrez alors encore avoir avoir + recours à mod_rewrite pour des règles + complexes. Notez aussi que l'interpolation n'est pas supportée dans + la partie protocole d'une URL. La détermination dynamique du + protocole peut être effectuée à l'aide de + mod_rewrite comme dans l'exemple suivant :

    + + 
    RewriteEngine On
+
+RewriteCond %{HTTPS} =off
+RewriteRule . - [E=protocol:http]
+RewriteCond %{HTTPS} =on
+RewriteRule . - [E=protocol:https]
+
+RewriteRule ^/mirror/foo/(.*) %{ENV:protocol}://backend.example.com/$1 [P]
+ProxyPassReverse  /mirror/foo/ http://backend.example.com/
+ProxyPassReverse  /mirror/foo/ https://backend.example.com/
    + + + +
    +
    top
    +

    Directive ProxyPassInherit

    + + + + + + + + +
    Description:Héritage des directives ProxyPass définies au niveau du +serveur principal
    Syntaxe:ProxyPassInherit On|Off
    Défaut:ProxyPassInherit On
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    Compatibilité:Disponible à partir de la version 2.4.5 du serveur +HTTP Apache.
    +

    Cette directive permet à un serveur virtuel d'hériter des + directives ProxyPass définies + au niveau du serveur principal. Si vous utilisez la fonctionnalité de + modifications dynamiques du Balancer Manager, cette directive peut + causer des problèmes et des comportements inattendus et doit donc + être désactivée.

    +

    Les valeurs définies au niveau du serveur principal + constituent les valeurs par défaut pour tous les serveurs virtuels.

    +

    La désactivation de ProxyPassInherit désactive aussi la + directive BalancerInherit.

    + +
    +
    top
    +

    Directive ProxyPassInterpolateEnv

    + + + + + + + + +
    Description:Active l'interpolation des variables d'environnement dans +les configurations de mandataires inverses
    Syntaxe:ProxyPassInterpolateEnv On|Off
    Défaut:ProxyPassInterpolateEnv Off
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_proxy
    Compatibilité:Disponible depuis la version 2.2.9 d'Apache
    +

    Cette directive, ainsi que l'argument interpolate des + directives ProxyPass, + ProxyPassReverse, + ProxyPassReverseCookieDomain et + ProxyPassReverseCookiePath, permet de + configurer dynamiquement un mandataire inverse à l'aide de + variables d'environnement, ces dernières pouvant être définies par un + autre module comme mod_rewrite. Elle affecte les + directives ProxyPass, + ProxyPassReverse, + ProxyPassReverseCookieDomain, et + ProxyPassReverseCookiePath, en leur indiquant + de remplacer la chaîne ${nom_var} dans les directives + de configuration par la valeur de la variable d'environnement + nom_var (si l'option interpolate est + spécifiée).

    +

    Conservez cette directive à off (pour les performances du + serveur), sauf si vous en avez réellement besoin.

    + +
    +
    top
    +

    Directive ProxyPassMatch

    + + + + + + +
    Description:Fait correspondre des serveurs distants dans l'espace d'URL +du serveur local en utilisant des expressions rationnelles
    Syntaxe:ProxyPassMatch [regex] !|url +[clé=valeur + [clé=valeur ...]]
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_proxy
    +

    Cette directive est identique à la directive ProxyPass, mais fait usage des + expressions rationnelles, au lieu d'une simple comparaison de + préfixes. L'expression rationnelle spécifiée est comparée à + l'url, et si elle correspond, le serveur va substituer + toute correspondance entre parenthèses dans la chaîne donnée et + l'utiliser comme nouvelle url.

    + +
    Note : Cette directive ne peut pas être + utilisée dans un contexte de niveau répertoire.
    + +

    Supposons que le serveur local a pour adresse + http://example.com/ ; alors

    + + 
    ProxyPassMatch ^(/.*\.gif)$ http://backend.example.com/$1
    + + +

    va provoquer la conversion interne de la requête locale + http://example.com/foo/bar.gif en une requête mandatée + pour http://backend.example.com/foo/bar.gif.

    + +

    Note

    +

    L'argument URL doit pouvoir être interprété en tant qu'URL + avant les substitutions d'expressions rationnelles (et + doit aussi l'être après). Ceci limite les correspondances que vous + pouvez utiliser. Par exemple, si l'on avait utilisé

    + 
    ProxyPassMatch ^(/.*\.gif)$ http://backend.example.com:8000$1
    + +

    dans l'exemple précédent, nous aurions provoqué une erreur de + syntaxe au démarrage du serveur. C'est une bogue (PR 46665 dans + ASF bugzilla), et il est possible de la contourner en reformulant + la correspondance :

    + 
    ProxyPassMatch ^/(.*\.gif)$ http://backend.example.com:8000/$1
    + +
    + +

    Le drapeau ! vous permet de ne pas mandater un + sous-répertoire donné.

    + +

    Dans une section <LocationMatch>, le premier argument est + omis et l'expression rationnelle est obtenue à partir de la directive + <LocationMatch>.

    + +

    Si vous avez besoin d'une configuration du mandataire inverse + plus flexible, voyez la directive RewriteRule avec le drapeau + [P].

    + +
    +

    Substitution par défaut

    +

    Lorsque le paramètre URL n'utilise pas de références arrières + dans l'expression rationnelle, l'URL originale sera ajoutée au + paramètre URL. +

    +
    + +
    +

    Avertissement à propos de la sécurité

    +

    Lors de la construction de l'URL cible de la règle, il convient + de prendre en compte l'impact en matière de sécurité qu'aura le + fait de permettre au client d'influencer le jeu d'URLs pour + lesquelles votre serveur agira en tant que mandataire. + Assurez-vous que la partie protocole://nom-serveur de l'URL soit + fixe, ou ne permette pas au client de l'influencer induement.

    +
    + +
    +
    top
    +

    Directive ProxyPassReverse

    + + + + + + +
    Description:Ajuste l'URL dans les en-têtes de la réponse HTTP envoyée +par un serveur mandaté en inverse
    Syntaxe:ProxyPassReverse [chemin] url +[interpolate]
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_proxy
    +

    Cette directive permet de faire en sorte qu'Apache httpd ajuste l'URL + dans les en-têtes Location, + Content-Location et URI des réponses de + redirection HTTP. Ceci est essentiel lorsqu'Apache httpd est utilisé en + tant que mandataire inverse (ou passerelle), afin d'éviter de + court-circuiter le mandataire inverse suite aux redirections HTTP + sur le serveur d'arrière-plan qui restent derrière le mandataire + inverse.

    + +

    Seuls les en-têtes de réponse HTTP spécialement mentionnés + ci-dessus seront réécrits. Apache httpd ne réécrira ni les autres en-têtes + de réponse, ni par défaut les références d'URLs dans les pages HTML. Cela + signifie que dans le cas où un contenu mandaté contient des + références à des URLs absolues, elles court-circuiteront le + mandataire. Pour réécrire un contenu HTML afin qu'il corresponde au + mandataire, vous devez charger et activer le module + mod_proxy_html. +

    + +

    chemin est le nom d'un chemin virtuel local. + url est une URL partielle pour le serveur distant - ils + sont utilisés de la même façon qu'avec la directive ProxyPass.

    + +

    Supposons par exemple que le serveur local a pour adresse + http://example.com/ ; alors

    + + 
    ProxyPass         /mirror/foo/ http://backend.example.com/
+ProxyPassReverse  /mirror/foo/ http://backend.example.com/
+ProxyPassReverseCookieDomain  backend.example.com  public.example.com
+ProxyPassReverseCookiePath  /  /mirror/foo/
    + + +

    ne va pas seulement provoquer la conversion interne d'une requête + locale pour http://example.com/miroir/foo/bar en une + requête mandatée pour http://backend.example.com/bar + (la fonctionnalité fournie par ProxyPass). Il va + aussi s'occuper des redirections que le serveur + backend.example.com envoie : lorsque + http://backend.example.com/bar est redirigé par + celui-ci vers http://backend.example.com/quux, Apache + httpd corrige ceci en http://example.com/miroir/foo/quux + avant de faire suivre la redirection HTTP au client. Notez que le + nom d'hôte utilisé pour construire l'URL est choisi en respectant la + définition de la directive UseCanonicalName.

    + +

    Notez que la directive ProxyPassReverse + peut aussi être utilisée en conjonction avec la fonctionnalité + pass-through (RewriteRule ... [P]) du module + mod_rewrite, car elle ne dépend pas d'une directive + ProxyPass + correspondante.

    + +

    Le mot-clé optionnel interpolate, en + combinaison avec la directive + ProxyPassInterpolateEnv, permet + l'interpolation des variables d'environnement spécifiées en + utilisant le format ${VARNAME} Notez que l'interpolation + n'est pas supportée dans la partie protocole d'une URL. +

    + +

    Lorsque cette directive est utilisée dans une section <Location>, le premier + argument est omis et le répertoire local est obtenu à partir de + l'argument de la directive <Location>. Il en est de même à l'intérieur + d'une section <LocationMatch>, mais le résultat ne sera + probablement pas celui attendu car ProxyPassReverse va interpréter + l'expression rationnelle littéralement comme un chemin ; si besoin + est dans ce cas, définissez la directive ProxyPassReverse en dehors + de la section, ou dans une section <Location> séparée.

    + +

    Cette directive ne peut pas être placée dans une section + <Directory> ou + <Files>.

    + +
    +
    top
    +

    Directive ProxyPassReverseCookieDomain

    + + + + + + +
    Description:Ajuste la chaîne correspondant au domaine dans les en-têtes +Set-Cookie en provenance d'un serveur mandaté
    Syntaxe:ProxyPassReverseCookieDomain domaine-interne +domaine-public [interpolate]
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_proxy
    +

    L'utilisation de cette directive est similaire à celle de la +directive ProxyPassReverse, +mais au lieu de réécrire des en-têtes qui contiennent des URLs, elle +réécrit la chaîne correspondant au domaine dans les en-têtes +Set-Cookie.

    + +
    +
    top
    +

    Directive ProxyPassReverseCookiePath

    + + + + + + +
    Description:Ajuste la chaîne correspondant au chemin dans les en-têtes +Set-Cookie en provenance d'un serveur mandaté
    Syntaxe:ProxyPassReverseCookiePath chemin-interne +chemin-public [interpolate]
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_proxy
    +

    +Cette directive s'avère utile en conjonction avec la directive +ProxyPassReverse dans les +situations où les chemins d'URL d'arrière-plan correspondent à des +chemins publics sur le mandataire inverse. Cette directive permet de +réécrire la chaîne path dans les en-têtes +Set-Cookie. Si le début du chemin du cookie correspond à +chemin-interne, le chemin du cookie sera remplacé par +chemin-public. +

    +Dans l'exemple fourni avec la directive ProxyPassReverse, la directive : +

    + 
    ProxyPassReverseCookiePath  /  /mirror/foo/
    + +

    +va réécrire un cookie possédant un chemin d'arrière-plan / +(ou /example ou en fait tout chemin) +en /mirror/foo/.. +

    + +
    +
    top
    +

    Directive ProxyPreserveHost

    + + + + + + + + +
    Description:Utilise l'en-tête de requête entrante Host pour la requête +du mandataire
    Syntaxe:ProxyPreserveHost On|Off
    Défaut:ProxyPreserveHost Off
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_proxy
    Compatibilité:Utilisable +dans un contexte de répertoire depuis la version 2.3.3.
    +

    Lorsqu'elle est activée, cette directive va transmettre l'en-tête + Host: de la requête entrante vers le serveur mandaté, au lieu du nom + d'hôte spécifié par la directive ProxyPass.

    + +

    Cette directive est habituellement définie à Off. + Elle est principalement utile dans les configurations particulières + comme l'hébergement virtuel mandaté en masse à base de nom, où + l'en-tête Host d'origine doit être évalué par le serveur + d'arrière-plan.

    + +
    +
    top
    +

    Directive ProxyReceiveBufferSize

    + + + + + + + +
    Description:Taille du tampon réseau pour les connexions mandatées HTTP +et FTP
    Syntaxe:ProxyReceiveBufferSize octets
    Défaut:ProxyReceiveBufferSize 0
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    +

    La directive ProxyReceiveBufferSize permet + de spécifier une taille de tampon réseau explicite (TCP/IP) pour les + connexions mandatées HTTP et FTP, afin d'améliorer le débit de + données. Elle doit être supérieure à 512 ou définie à + 0 pour indiquer que la taille de tampon par défaut du + système doit être utilisée.

    + +

    Exemple

    ProxyReceiveBufferSize 2048
    +
    + +
    +
    top
    +

    Directive ProxyRemote

    + + + + + + +
    Description:Mandataire distant à utiliser pour traiter certaines +requêtes
    Syntaxe:ProxyRemote comparaison serveur-distant
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    +

    Cette directive permet de définir des mandataires distants pour + ce mandataire. comparaison est soit le nom d'un protocole + que supporte le serveur distant, soit une URL partielle pour + laquelle le serveur distant devra être utilisé, soit * + pour indiquer que le serveur distant doit être utilisé pour toutes + les requêtes. serveur-distant est une URL partielle + correspondant au serveur distant. Syntaxe :

    + +

    + serveur-distant = + protocole://nom-serveur[:port] +

    + +

    protocole est effectivement le protocole à utiliser + pour communiquer avec le serveur distant ; ce module ne supporte que + http et https. Lorsqu'on utilise + https, les requêtes sont redirigées par le mandataire + distant en utilisant la méthode HTTP CONNECT.

    + +

    Exemple

    ProxyRemote http://goodguys.example.com/ http://mirrorguys.example.com:8000
+ProxyRemote * http://cleverproxy.localdomain
+ProxyRemote ftp http://ftpproxy.mydomain:8080
    +
    + +

    Dans la dernière ligne de l'exemple, le mandataire va faire + suivre les requêtes FTP, encapsulées dans une autre requête mandatée + HTTP, vers un autre mandataire capable de les traiter.

    + +

    Cette directive supporte aussi les configurations de mandataire + inverse - un serveur web d'arrière-plan peut être intégré dans + l'espace d'URL d'un serveur virtuel, même si ce serveur est caché + par un autre mandataire direct.

    + +
    +
    top
    +

    Directive ProxyRemoteMatch

    + + + + + + +
    Description:Le mandataire distant à utiliser pour traiter les requêtes +correspondant à une expression rationnelle
    Syntaxe:ProxyRemoteMatch regex serveur-distant
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    +

    La directive ProxyRemoteMatch est + identique à la directive ProxyRemote, à l'exception du + premier argument qui est une expression + rationnelle à mettre en correspondance avec l'URL de la + requête.

    + +
    +
    top
    +

    Directive ProxyRequests

    + + + + + + + +
    Description:Active la fonctionnalité (standard) de mandataire +direct
    Syntaxe:ProxyRequests On|Off
    Défaut:ProxyRequests Off
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    +

    Cette directive permet d'activer/désactiver la fonctionnalité de + serveur mandataire direct d'Apache httpd. Définir ProxyRequests à + Off n'interdit pas l'utilisation de la directive + ProxyPass.

    +

    Pour une configuration typique de mandataire inverse ou + passerelle, cette directive doit être définie à + Off.

    -

    Configuration d'un serveur cible de réserve qui ne sera utilisé que si - aucun autre serveur cible n'est disponible

    - 
    ProxyPass / balancer://hotcluster/ 
-<Proxy balancer://hotcluster>
-    BalancerMember ajp://1.2.3.4:8009 loadfactor=1
-    BalancerMember ajp://1.2.3.5:8009 loadfactor=2
-    # The server below is on hot standby
-    BalancerMember ajp://1.2.3.6:8009 status=+H
-    ProxySet lbmethod=bytraffic
-</Proxy>
    +

    Afin d'activer la fonctionnalité de mandataire pour des sites + HTTP et/ou FTP, les modules mod_proxy_http et/ou + mod_proxy_ftp doivent également être chargés dans le + serveur.

    +

    Pour activer la fonctionnalité de mandataire sur les sites chiffrés en HTTPS, le module + mod_proxy_connect doit également être chargé dans le serveur.

    -

    Normalement, mod_proxy va mettre sous leur forme canonique les - URLs traitées par ProxyPass. Mais ceci peut être incompatible avec - certains serveurs d'arrière-plan, et en particulier avec ceux qui - utilisent PATH_INFO. Le mot-clé optionnel - nocanon modifie ce comportement et permet de transmettre - le chemin d'URL sous sa forme brute au serveur d'arrière-plan. Notez - que ceci peut affecter la sécurité de votre serveur d'arrière-plan, - car la protection limitée contre les attaques à base d'URL que - fournit le mandataire est alors supprimée.

    +

    Avertissement

    +

    N'activez pas la fonctionnalité de mandataire avec la directive + ProxyRequests avant + d'avoir sécurisé votre serveur. Les serveurs + mandataires ouverts sont dangereux non seulement pour votre + réseau, mais aussi pour l'Internet au sens large.

    +
    -

    Par défaut, mod_proxy inclut la chaîne de paramètres lors de la - génération de la variable d'environnement - SCRIPT_FILENAME. Le mot-clé optionnel noquery - (disponible à partir de la version 2.4.1) permet d'exclure cette - chaîne.

    +

    Voir aussi

    + +
    +
    top
    +

    Directive ProxySet

    + + + + + + + +
    Description:Définit différents paramètres relatifs à la répartition de +charge des mandataires et aux membres des groupes de répartition de +charge
    Syntaxe:ProxySet url clé=valeur [clé=valeur ...]
    Contexte:répertoire
    Statut:Extension
    Module:mod_proxy
    Compatibilité:ProxySet n'est disponible que depuis la version 2.2 +du serveur HTTP Apache.
    +

    Cette directive propose une méthode alternative pour définir tout + paramètre relatif aux répartiteurs de charge et serveurs cibles de + mandataires normalement définis via la directive ProxyPass. Si elle se trouve dans un + conteneur <Proxy url de répartiteur|url de + serveur cible>, l'argument url n'est pas + nécessaire. Comme effet de bord, le répartiteur ou serveur cible respectif + est créé. Ceci peut s'avérer utile pour la mise en oeuvre d'un + mandataire inverse via une directive RewriteRule au lieu de ProxyPass.

    -

    Lorsque la directive ProxyPass est utilisée à l'intérieur d'une - section <Location>, le premier argument est omis et le répertoire - local est obtenu à partir de la section <Location>. Il en sera de même dans une - section <LocationMatch> ; cependant, ProxyPass - n'interprète pas les expressions rationnelles, et il sera ici - nécessaire d'utiliser la directive - ProxyPassMatch à la place.

    + 
    <Proxy balancer://hotcluster>
+    BalancerMember http://www2.example.com:8080 loadfactor=1
+    BalancerMember http://www3.example.com:8080 loadfactor=2
+    ProxySet lbmethod=bytraffic
+</Proxy>
    +
    -

    Cette directive ne peut pas être placée dans une section - <Directory> ou - <Files>.

    + 
    <Proxy http://backend>
+    ProxySet keepalive=On
+</Proxy>
    -

    Si vous avez besoin d'un configuration de mandataire inverse plus - souple, reportez-vous à la documentaion de la directive RewriteRule et son drapeau - [P].

    -

    Le mot-clé optionnel interpolate, en combinaison avec la directive - ProxyPassInterpolateEnv, permet à ProxyPass - d'interpoler les variables d'environnement à l'aide de la syntaxe - ${VARNAME}. Notez que de nombreuses variables - d'environnement standard dérivées de CGI n'existeront pas lorsque - l'interpolation se produit ; vous devrez alors encore avoir avoir - recours à mod_rewrite pour des règles - complexes. Notez aussi que l'interpolation n'est pas supportée dans - la partie protocole d'une URL. La détermination dynamique du - protocole peut être effectuée à l'aide de - mod_rewrite comme dans l'exemple suivant :

    + 
    ProxySet balancer://foo lbmethod=bytraffic timeout=15
    - 
    RewriteEngine On
 
-RewriteCond %{HTTPS} =off
-RewriteRule . - [E=protocol:http]
-RewriteCond %{HTTPS} =on
-RewriteRule . - [E=protocol:https]
+    
    ProxySet ajp://backend:7001 timeout=15
    
 
-RewriteRule ^/mirror/foo/(.*) %{ENV:protocol}://backend.example.com/$1 [P]
-ProxyPassReverse  /mirror/foo/ http://backend.example.com/
-ProxyPassReverse  /mirror/foo/ https://backend.example.com/
    +

    Avertissement

    +

    Gardez à l'esprit qu'une même clé de paramètre peut avoir + différentes significations selon qu'elle s'applique à un + répartiteur ou à un serveur cible, et ceci est illustré par les deux + exemples précédents où il est question d'un timeout.

    +
    top
    -

    Directive ProxyPassInherit

    +

    Directive ProxySourceAddress

    - - - + + - +
    Description:Héritage des directives ProxyPass définies au niveau du -serveur principal
    Syntaxe:ProxyPassInherit On|Off
    Défaut:ProxyPassInherit On
    Description:Définit l'adresse IP locale pour les connexions mandatées +sortantes
    Syntaxe:ProxySourceAddress adresse
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    Compatibilité:Disponible à partir de la version 2.4.5 du serveur -HTTP Apache.
    Compatibilité:Disponible depuis la version 2.3.9
    -

    Cette directive permet à un serveur virtuel d'hériter des - directives ProxyPass définies - au niveau du serveur principal. Si vous utilisez la fonctionnalité de - modifications dynamiques du Balancer Manager, cette directive peut - causer des problèmes et des comportements inattendus et doit donc - être désactivée.

    -

    Les valeurs définies au niveau du serveur principal - constituent les valeurs par défaut pour tous les serveurs virtuels.

    -

    La désactivation de ProxyPassInherit désactive aussi la - directive BalancerInherit.

    - +

    Cette directive permet de définir une adresse IP locale + spécifique à laquelle faire référence lors d'une connexion à un + serveur d'arrière-plan.

    + +
    top
    -

    Directive ProxyPassInterpolateEnv

    +

    Directive ProxyStatus

    - - - - + + + + - +
    Description:Active l'interpolation des variables d'environnement dans -les configurations de mandataires inverses
    Syntaxe:ProxyPassInterpolateEnv On|Off
    Défaut:ProxyPassInterpolateEnv Off
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Description:Affiche l'état du répartiteur de charge du mandataire dans +mod_status
    Syntaxe:ProxyStatus Off|On|Full
    Défaut:ProxyStatus Off
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    Compatibilité:Disponible depuis la version 2.2.9 d'Apache
    Compatibilité:Disponible depuis la version 2.2 d'Apache
    -

    Cette directive, ainsi que l'argument interpolate des - directives ProxyPass, - ProxyPassReverse, - ProxyPassReverseCookieDomain et - ProxyPassReverseCookiePath, permet de - configurer dynamiquement un mandataire inverse à l'aide de - variables d'environnement, ces dernières pouvant être définies par un - autre module comme mod_rewrite. Elle affecte les - directives ProxyPass, - ProxyPassReverse, - ProxyPassReverseCookieDomain, et - ProxyPassReverseCookiePath, en leur indiquant - de remplacer la chaîne ${nom_var} dans les directives - de configuration par la valeur de la variable d'environnement - nom_var (si l'option interpolate est - spécifiée).

    -

    Conservez cette directive à off (pour les performances du - serveur), sauf si vous en avez réellement besoin.

    +

    Cette directive permet de spécifier si les données d'état du + répartiteur de charge du mandataire doivent être affichées via la + page d'état du serveur du module mod_status.

    +

    Note

    +

    L'argument Full produit le même effet que + l'argument On.

    +
    +
    top
    -

    Directive ProxyPassMatch

    +

    Directive ProxyTimeout

    - - - + + + +
    Description:Fait correspondre des serveurs distants dans l'espace d'URL -du serveur local en utilisant des expressions rationnelles
    Syntaxe:ProxyPassMatch [regex] !|url -[clé=valeur - [clé=valeur ...]]
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Description:Délai d'attente réseau pour les requêtes +mandatées
    Syntaxe:ProxyTimeout secondes
    Défaut:Valeur de la directive Timeout
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    -

    Cette directive est identique à la directive ProxyPass, mais fait usage des - expressions rationnelles, au lieu d'une simple comparaison de - préfixes. L'expression rationnelle spécifiée est comparée à - l'url, et si elle correspond, le serveur va substituer - toute correspondance entre parenthèses dans la chaîne donnée et - l'utiliser comme nouvelle url.

    +

    Cette directive permet à l'utilisateur de spécifier un délai pour + les requêtes mandatées. Ceci s'avère utile dans le cas d'un serveur + d'applications lent et bogué qui a tendance à se bloquer, et si vous + préférez simplement renvoyer une erreur timeout et abandonner la + connexion en douceur plutôt que d'attendre jusqu'à ce que le serveur + veuille bien répondre.

    + +
    +
    top
    +

    Directive ProxyVia

    + + + + + + + +
    Description:Information fournie dans l'en-tête de réponse HTTP +Via pour les requêtes mandatées
    Syntaxe:ProxyVia On|Off|Full|Block
    Défaut:ProxyVia Off
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    +

    Cette directive permet de contrôler l'utilisation de l'en-tête + HTTP Via: par le mandataire. Le but recherché est de + contrôler le flux des requêtes mandatées tout au long d'une chaîne + de serveurs mandataires. Voir RFC 2616 (HTTP/1.1), + section 14.45 pour une description des lignes d'en-tête + Via:.

    -
    Note : Cette directive ne peut pas être - utilisée dans un contexte de niveau répertoire.
    +
      +
    • Si elle est définie à Off, valeur par défaut, cette + directive n'effectue aucun traitement particulier. Si une requête ou + une réponse contient un en-tête Via:, il est transmis + sans modification.
      • -

      Supposons que le serveur local a pour adresse - http://example.com/ ; alors

      +
    • Si elle est définie à On, chaque requête ou réponse + se verra ajouter une ligne d'en-tête Via: pour le + serveur courant.
      • - 
      ProxyPassMatch ^(/.*\.gif)$ http://backend.example.com/$1
      +
    • Si elle est définie à Full, chaque ligne d'en-tête + Via: se verra ajouter la version du serveur Apache + httpd sous la forme d'un champ de commentaire Via:.
      • +
    • Si elle est définie à Block, chaque requête + mandatée verra ses lignes d'en-tête Via: supprimées. + Aucun nouvel en-tête Via: ne sera généré.
      • +
    -

    va provoquer la conversion interne de la requête locale - http://example.com/foo/bar.gif en une requête mandatée - pour http://backend.example.com/foo/bar.gif.

    +
    +
    top
    +
    +

    Mandataires directs et + mandataires/passerelles inverses

    +

    Le serveur HTTP Apache peut être configuré dans les deux modes mandataire + direct et mandataire inverse (aussi nommé + mode passerelle).

    -

    Note

    -

    L'argument URL doit pouvoir être interprété en tant qu'URL - avant les substitutions d'expressions rationnelles (et - doit aussi l'être après). Ceci limite les correspondances que vous - pouvez utiliser. Par exemple, si l'on avait utilisé

    - 
    ProxyPassMatch ^(/.*\.gif)$ http://backend.example.com:8000$1
    +

    Un mandataire direct standard est un serveur + intermédiaire qui s'intercale entre le client et le serveur + demandé. Pour obtenir un contenu hébergé par + le serveur demandé, le client envoie une requête au + mandataire en nommant le serveur demandé comme + cible, puis le mandataire extrait le contenu depuis le + serveur demandé et le renvoie enfin au client. Le client doit être + configuré de manière appropriée pour pouvoir utiliser le mandataire + direct afin d'accéder à d'autres sites.

    -

    dans l'exemple précédent, nous aurions provoqué une erreur de - syntaxe au démarrage du serveur. C'est une bogue (PR 46665 dans - ASF bugzilla), et il est possible de la contourner en reformulant - la correspondance :

    - 
    ProxyPassMatch ^/(.*\.gif)$ http://backend.example.com:8000/$1
    +

    L'accès à Internet depuis des clients situés derrière un + pare-feu est une utilisation typique du mandataire direct. Le + mandataire direct peut aussi utiliser la mise en cache (fournie + par mod_cache) pour réduire la charge du + réseau.

    -
    +

    La fonctionnalité de mandataire direct est activée via la + directive ProxyRequests. + Comme les mandataires directs permettent aux clients d'accéder à + des sites quelconques via votre serveur et de dissimuler leur + véritable origine, il est indispensable de sécuriser votre serveur de façon à ce que seuls + les clients autorisés puissent accéder à votre serveur avant + d'activer la fonctionnalité de mandataire direct.

    -

    Le drapeau ! vous permet de ne pas mandater un - sous-répertoire donné.

    +

    Un mandataire inverse (ou passerelle), + quant à lui, apparaît au client comme un serveur web standard. + Aucune configuration particulière du client n'est nécessaire. Le + client adresse ses demandes de contenus ordinaires dans l'espace + de nommage du mandataire inverse. Ce dernier décide alors où + envoyer ces requêtes, et renvoie le contenu au client comme s'il + l'hébergeait lui-même.

    -

    Dans une section <LocationMatch>, le premier argument est - omis et l'expression rationnelle est obtenue à partir de la directive - <LocationMatch>.

    +

    L'accès d'utilisateurs depuis Internet vers un serveur situé + derrière un pare-feu est une utilisation typique du mandataire + inverse. On peut aussi utiliser les mandataires inverses pour + mettre en oeuvre une répartition de charge entre plusieurs + serveurs en arrière-plan, ou fournir un cache pour un serveur + d'arrière-plan plus lent. Les mandataires inverses peuvent aussi + tout simplement servir à rassembler plusieurs serveurs dans le + même espace de nommage d'URLs.

    -

    Si vous avez besoin d'une configuration du mandataire inverse - plus flexible, voyez la directive RewriteRule avec le drapeau - [P].

    +

    La fonctionnalité de mandataire inverse est activée via la + directive ProxyPass ou + le drapeau [P] de la directive RewriteRule. Il n'est + pas nécessaire de définir ProxyRequests pour configurer + un mandataire inverse.

    +
    top
    +
    +

    Exemples simples

    -
    -

    Substitution par défaut

    -

    Lorsque le paramètre URL n'utilise pas de références arrières - dans l'expression rationnelle, l'URL originale sera ajoutée au - paramètre URL. -

    -
    +

    Les exemples ci-dessous illustrent de manière très basique la + mise en oeuvre de la fonctionnalité de mandataire et ne sont là que + pour vous aider à démarrer. Reportez-vous à la documentation de + chaque directive.

    -
    -

    Avertissement à propos de la sécurité

    -

    Lors de la construction de l'URL cible de la règle, il convient - de prendre en compte l'impact en matière de sécurité qu'aura le - fait de permettre au client d'influencer le jeu d'URLs pour - lesquelles votre serveur agira en tant que mandataire. - Assurez-vous que la partie protocole://nom-serveur de l'URL soit - fixe, ou ne permette pas au client de l'influencer induement.

    -
    +

    Si en outre, vous désirez activer la mise en cache, consultez la + documentation de mod_cache.

    +

    Mandataire inverse

    ProxyPass /foo http://foo.example.com/bar
+ProxyPassReverse /foo http://foo.example.com/bar
    -
    top
    -

    Directive ProxyPassReverse

    - - - - - - -
    Description:Ajuste l'URL dans les en-têtes de la réponse HTTP envoyée -par un serveur mandaté en inverse
    Syntaxe:ProxyPassReverse [chemin] url -[interpolate]
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_proxy
    -

    Cette directive permet de faire en sorte qu'Apache httpd ajuste l'URL - dans les en-têtes Location, - Content-Location et URI des réponses de - redirection HTTP. Ceci est essentiel lorsqu'Apache httpd est utilisé en - tant que mandataire inverse (ou passerelle), afin d'éviter de - court-circuiter le mandataire inverse suite aux redirections HTTP - sur le serveur d'arrière-plan qui restent derrière le mandataire - inverse.

    - -

    Seuls les en-têtes de réponse HTTP spécialement mentionnés - ci-dessus seront réécrits. Apache httpd ne réécrira ni les autres en-têtes - de réponse, ni par défaut les références d'URLs dans les pages HTML. Cela - signifie que dans le cas où un contenu mandaté contient des - références à des URLs absolues, elles court-circuiteront le - mandataire. Pour réécrire un contenu HTML afin qu'il corresponde au - mandataire, vous devez charger et activer le module - mod_proxy_html. -

    - -

    chemin est le nom d'un chemin virtuel local. - url est une URL partielle pour le serveur distant - ils - sont utilisés de la même façon qu'avec la directive ProxyPass.

    -

    Supposons par exemple que le serveur local a pour adresse - http://example.com/ ; alors

    - - 
    ProxyPass         /mirror/foo/ http://backend.example.com/
-ProxyPassReverse  /mirror/foo/ http://backend.example.com/
-ProxyPassReverseCookieDomain  backend.example.com  public.example.com
-ProxyPassReverseCookiePath  /  /mirror/foo/
    - - -

    ne va pas seulement provoquer la conversion interne d'une requête - locale pour http://example.com/miroir/foo/bar en une - requête mandatée pour http://backend.example.com/bar - (la fonctionnalité fournie par ProxyPass). Il va - aussi s'occuper des redirections que le serveur - backend.example.com envoie : lorsque - http://backend.example.com/bar est redirigé par - celui-ci vers http://backend.example.com/quux, Apache - httpd corrige ceci en http://example.com/miroir/foo/quux - avant de faire suivre la redirection HTTP au client. Notez que le - nom d'hôte utilisé pour construire l'URL est choisi en respectant la - définition de la directive UseCanonicalName.

    +

    Mandataire direct

    ProxyRequests On
+ProxyVia On
 
-    
    Notez que la directive ProxyPassReverse
-    peut aussi être utilisée en conjonction avec la fonctionnalité
-    pass-through (RewriteRule ...  [P]) du module
-    mod_rewrite, car elle ne dépend pas d'une directive
-    ProxyPass
-    correspondante.
    
+<Proxy *>
+  Require host internal.example.com
+</Proxy>
    +
    +
    top
    +
    +

    Accès via un gestionnaire

    -

    Le mot-clé optionnel interpolate, en - combinaison avec la directive - ProxyPassInterpolateEnv, permet - l'interpolation des variables d'environnement spécifiées en - utilisant le format ${VARNAME} Notez que l'interpolation - n'est pas supportée dans la partie protocole d'une URL. +

    Vous pouvez aussi forcer le traitement d'une requête en tant que + requête de mandataire inverse en créant un gestionnaire de transfert + approprié. Dans l'exemple suivant, toutes les requêtes pour + des scripts PHP seront transmises au serveur FastCGI + spécifié via un mandat inverse :

    -

    Lorsque cette directive est utilisée dans une section <Location>, le premier - argument est omis et le répertoire local est obtenu à partir de - l'argument de la directive <Location>. Il en est de même à l'intérieur - d'une section <LocationMatch>, mais le résultat ne sera - probablement pas celui attendu car ProxyPassReverse va interpréter - l'expression rationnelle littéralement comme un chemin ; si besoin - est dans ce cas, définissez la directive ProxyPassReverse en dehors - de la section, ou dans une section <Location> séparée.

    +

    Scripts PHP et mandataire inverse

    <FilesMatch \.php$>
+    # Les sockets Unix nécessitent une version 2.4.7 ou supérieure du
+    # serveur HTTP Apache
+    SetHandler  "proxy:unix:/path/to/app.sock|fcgi://localhost/"
+</FilesMatch>
    +
    -

    Cette directive ne peut pas être placée dans une section - <Directory> ou - <Files>.

    +

    Cette fonctionnalité est disponible à partir de la version + 2.4.10 du serveur HTTP Apache.

    -
    -
    top
    -

    Directive ProxyPassReverseCookieDomain

    - - - - - - -
    Description:Ajuste la chaîne correspondant au domaine dans les en-têtes -Set-Cookie en provenance d'un serveur mandaté
    Syntaxe:ProxyPassReverseCookieDomain domaine-interne -domaine-public [interpolate]
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_proxy
    -

    L'utilisation de cette directive est similaire à celle de la -directive ProxyPassReverse, -mais au lieu de réécrire des en-têtes qui contiennent des URLs, elle -réécrit la chaîne correspondant au domaine dans les en-têtes -Set-Cookie.

    +
    top
    +
    +

    Workers

    +

    Le mandataire gère la configuration et les paramètres de + communication des serveurs originaux au sein d'objets nommés + workers. Deux types de worker sont fournis : le worker + par défaut du mandataire direct et le worker par défaut du + mandataire inverse. Il est aussi possible de définir explicitement + des workers supplémentaires.

    + +

    Les deux workers par défaut possèdent une configuration figée + et seront utilisés si aucun autre worker ne correspond à la + requête. Ils n'utilisent ni les jeux de connexions (connection + pooling), ni les + connexions HTTP persistantes (Keep-Alive). En effet, les + connexions TCP vers le serveur original sont fermées et ouvertes + pour chaque requête.

    + +

    Les workers définis explicitement sont identifiés par leur URL. + Ils sont en général définis via les directives ProxyPass ou ProxyPassMatch lorsqu'on les + utilise dans le cadre d'un mandataire inverse :

    + 
    ProxyPass /example http://backend.example.com connectiontimeout=5 timeout=30
    -
    top
    -

    Directive ProxyPassReverseCookiePath

    - - - - - - -
    Description:Ajuste la chaîne correspondant au chemin dans les en-têtes -Set-Cookie en provenance d'un serveur mandaté
    Syntaxe:ProxyPassReverseCookiePath chemin-interne -chemin-public [interpolate]
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_proxy
    -

    -Cette directive s'avère utile en conjonction avec la directive -ProxyPassReverse dans les -situations où les chemins d'URL d'arrière-plan correspondent à des -chemins publics sur le mandataire inverse. Cette directive permet de -réécrire la chaîne path dans les en-têtes -Set-Cookie. Si le début du chemin du cookie correspond à -chemin-interne, le chemin du cookie sera remplacé par -chemin-public. -

    -Dans l'exemple fourni avec la directive ProxyPassReverse, la directive : -

    - 
    ProxyPassReverseCookiePath  /  /mirror/foo/
    + -

    -va réécrire un cookie possédant un chemin d'arrière-plan / -(ou /example ou en fait tout chemin) -en /mirror/foo/.. -

    +

    Cette directive va créer un worker associé à l'URL du serveur + original http://backend.example.com, et utilisant les + valeurs de timeout données. Lorsqu'ils sont utilisés dans le cadre + d'un mandataire direct, les workers sont en général définis via la + directive ProxySet,

    + 
    ProxySet http://backend.example.com connectiontimeout=5 timeout=30
    -
    top
    -

    Directive ProxyPreserveHost

    - - - - - - - - -
    Description:Utilise l'en-tête de requête entrante Host pour la requête -du mandataire
    Syntaxe:ProxyPreserveHost On|Off
    Défaut:ProxyPreserveHost Off
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_proxy
    Compatibilité:Utilisable -dans un contexte de répertoire depuis la version 2.3.3.
    -

    Lorsqu'elle est activée, cette directive va transmettre l'en-tête - Host: de la requête entrante vers le serveur mandaté, au lieu du nom - d'hôte spécifié par la directive ProxyPass.

    + -

    Cette directive est habituellement définie à Off. - Elle est principalement utile dans les configurations particulières - comme l'hébergement virtuel mandaté en masse à base de nom, où - l'en-tête Host d'origine doit être évalué par le serveur - d'arrière-plan.

    +

    ou encore via les directives Proxy et ProxySet :

    -
    -
    top
    -

    Directive ProxyReceiveBufferSize

    - - - - - - - -
    Description:Taille du tampon réseau pour les connexions mandatées HTTP -et FTP
    Syntaxe:ProxyReceiveBufferSize octets
    Défaut:ProxyReceiveBufferSize 0
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    -

    La directive ProxyReceiveBufferSize permet - de spécifier une taille de tampon réseau explicite (TCP/IP) pour les - connexions mandatées HTTP et FTP, afin d'améliorer le débit de - données. Elle doit être supérieure à 512 ou définie à - 0 pour indiquer que la taille de tampon par défaut du - système doit être utilisée.

    + 
    <Proxy http://backend.example.com>
+  ProxySet connectiontimeout=5 timeout=30
+</Proxy>
    -

    Exemple

    ProxyReceiveBufferSize 2048
    -
    -
    -
    top
    -

    Directive ProxyRemote

    - - - - - - -
    Description:Mandataire distant à utiliser pour traiter certaines -requêtes
    Syntaxe:ProxyRemote comparaison serveur-distant
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    -

    Cette directive permet de définir des mandataires distants pour - ce mandataire. comparaison est soit le nom d'un protocole - que supporte le serveur distant, soit une URL partielle pour - laquelle le serveur distant devra être utilisé, soit * - pour indiquer que le serveur distant doit être utilisé pour toutes - les requêtes. serveur-distant est une URL partielle - correspondant au serveur distant. Syntaxe :

    +

    L'utilisation de workers définis explicitement dans le mode + mandataire direct n'est pas très courante, car les mandataires + directs communiquent en général avec de nombreux serveurs + originaux. La création explicite de workers pour certains serveurs + originaux peut cependant s'avérer utile si ces serveurs sont + très souvent sollicités. A leur niveau, les workers explicitement + définis ne possèdent aucune notion de mandataire direct ou + inverse. Ils encapsulent un concept de communication commun avec + les serveurs originaux. Un worker créé via la directive ProxyPass pour être utilisé dans le + cadre d'un mandataire inverse sera aussi utilisé dans le cadre + d'un mandataire directe chaque fois que l'URL vers le serveur + original correspondra à l'URL du worker, et vice versa.

    -

    - serveur-distant = - protocole://nom-serveur[:port] -

    +

    L'URL qui identifie un worker correspond à l'URL de son serveur + original, y compris un éventuel chemin donné :

    -

    protocole est effectivement le protocole à utiliser - pour communiquer avec le serveur distant ; ce module ne supporte que - http et https. Lorsqu'on utilise - https, les requêtes sont redirigées par le mandataire - distant en utilisant la méthode HTTP CONNECT.

    + 
    ProxyPass /examples http://backend.example.com/examples
+ProxyPass /docs http://backend.example.com/docs
    -

    Exemple

    ProxyRemote http://goodguys.example.com/ http://mirrorguys.example.com:8000
-ProxyRemote * http://cleverproxy.localdomain
-ProxyRemote ftp http://ftpproxy.mydomain:8080
    -
    -

    Dans la dernière ligne de l'exemple, le mandataire va faire - suivre les requêtes FTP, encapsulées dans une autre requête mandatée - HTTP, vers un autre mandataire capable de les traiter.

    +

    Dans cet exemple, deux workers différents sont définis, chacun + d'eux utilisant des configurations et jeux de connexions + séparés.

    -

    Cette directive supporte aussi les configurations de mandataire - inverse - un serveur web d'arrière-plan peut être intégré dans - l'espace d'URL d'un serveur virtuel, même si ce serveur est caché - par un autre mandataire direct.

    +

    Partage de workers

    +

    Le partage de workers intervient lorsque les URLs des workers + s'entrecoupent, ce qui arrive lorsque l'URL d'un worker + correspond au début de l'URL d'un autre worker défini plus loin + dans le fichier de configuration. Dans l'exemple suivant,

    -
    -
    top
    -

    Directive ProxyRemoteMatch

    - - - - - - -
    Description:Le mandataire distant à utiliser pour traiter les requêtes -correspondant à une expression rationnelle
    Syntaxe:ProxyRemoteMatch regex serveur-distant
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    -

    La directive ProxyRemoteMatch est - identique à la directive ProxyRemote, à l'exception du - premier argument qui est une expression - rationnelle à mettre en correspondance avec l'URL de la - requête.

    + 
    ProxyPass /apps http://backend.example.com/ timeout=60
+ProxyPass /examples http://backend.example.com/examples timeout=10
    -
    -
    top
    -

    Directive ProxyRequests

    - - - - - - - -
    Description:Active la fonctionnalité (standard) de mandataire -direct
    Syntaxe:ProxyRequests On|Off
    Défaut:ProxyRequests Off
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    -

    Cette directive permet d'activer/désactiver la fonctionnalité de - serveur mandataire direct d'Apache httpd. Définir ProxyRequests à - Off n'interdit pas l'utilisation de la directive - ProxyPass.

    -

    Pour une configuration typique de mandataire inverse ou - passerelle, cette directive doit être définie à - Off.

    +

    le second worker n'est pas vraiment créé. C'est le premier + worker qui est en fait utilisé. L'avantage de ceci réside dans + le fait qu'il n'existe qu'un seul jeu de connexions, ces + dernières étant donc réutilisées plus souvent. Notez que tous + les attributs de configuration définis explicitement pour le + deuxième worker seront ignorés, ce qui sera journalisé en tant + qu'avertissement. Ainsi, dans l'exemple ci-dessus, la valeur de + timeout retenue pour l'URL /exemples sera + 60, et non 10 !

    -

    Afin d'activer la fonctionnalité de mandataire pour des sites - HTTP et/ou FTP, les modules mod_proxy_http et/ou - mod_proxy_ftp doivent également être chargés dans le - serveur.

    +

    Si vous voulez empêcher le partage de workers, classez vos + définitions de workers selon la longueur des URLs, de la plus + longue à la plus courte. Si au contraire vous voulez favoriser + ce partage, utilisez l'ordre de classement inverse. Voir aussi + l'avertissement à propos de l'ordre de classement des directives + ProxyPass.

    -

    Pour activer la fonctionnalité de mandataire sur les sites chiffrés en HTTPS, le module - mod_proxy_connect doit également être chargé dans le serveur.

    +
    -

    Avertissement

    -

    N'activez pas la fonctionnalité de mandataire avec la directive - ProxyRequests avant - d'avoir sécurisé votre serveur. Les serveurs - mandataires ouverts sont dangereux non seulement pour votre - réseau, mais aussi pour l'Internet au sens large.

    -
    +

    Les workers définis explicitement sont de deux sortes : + workers directs et workers de répartition (de + charge). Ils supportent de nombreux attributs de + configuration importants décrits dans la directive ProxyPass. Ces mêmes attributs + peuvent aussi être définis via la directive ProxySet.

    -

    Voir aussi

    - -
    -
    top
    -

    Directive ProxySet

    - - - - - - - -
    Description:Définit différents paramètres relatifs à la répartition de -charge des mandataires et aux membres des groupes de répartition de -charge
    Syntaxe:ProxySet url clé=valeur [clé=valeur ...]
    Contexte:répertoire
    Statut:Extension
    Module:mod_proxy
    Compatibilité:ProxySet n'est disponible que depuis la version 2.2 -du serveur HTTP Apache.
    -

    Cette directive propose une méthode alternative pour définir tout - paramètre relatif aux répartiteurs de charge et serveurs cibles de - mandataires normalement définis via la directive ProxyPass. Si elle se trouve dans un - conteneur <Proxy url de répartiteur|url de - serveur cible>, l'argument url n'est pas - nécessaire. Comme effet de bord, le répartiteur ou serveur cible respectif - est créé. Ceci peut s'avérer utile pour la mise en oeuvre d'un - mandataire inverse via une directive RewriteRule au lieu de ProxyPass.

    +

    Le jeu d'options disponibles pour un worker direct dépend du + protocole spécifié dans l'URL du serveur original. Les protocoles + disponibles comprennent ajp, fcgi, + ftp, http et scgi.

    + +

    Les workers de répartition sont des workers virtuels qui + utilisent les workers directs, connus comme faisant partie de leurs + membres, pour le traitement effectif des requêtes. Chaque + répartiteur peut comporter plusieurs membres. Lorsqu'il traite une + requête, il choisit un de ses membres en fonction de l'algorithme + de répartition de charge défini.

    - 
    <Proxy balancer://hotcluster>
-    BalancerMember http://www2.example.com:8080 loadfactor=1
-    BalancerMember http://www3.example.com:8080 loadfactor=2
-    ProxySet lbmethod=bytraffic
-</Proxy>
    -
    +

    Un worker de répartition est créé si son URL de worker comporte + balancer comme indicateur de protocole. L'URL du + répartiteur permet d'identifier de manière unique le worker de + répartition. La directive BalancerMember permet d'ajouter des + membres au répartiteur.

    - 
    <Proxy http://backend>
-    ProxySet keepalive=On
+
    top
    +
    +

    Contrôler l'accès à votre + mandataire

    +

    Vous pouvez restreindre l'accès à votre mandataire via le bloc + de contrôle <Proxy> comme dans + l'exemple suivant :

    + + 
    <Proxy *>
+  Require ip 192.168.0
 </Proxy>
    - 
    ProxySet balancer://foo lbmethod=bytraffic timeout=15
    +

    Pour plus de détails sur les directives de contrôle d'accès, + voir la documentation du module + mod_authz_host.

    +

    Restreindre l'accès de manière stricte est essentiel si vous + mettez en oeuvre un mandataire direct (en définissant la directive + ProxyRequests à "on"). + Dans le cas contraire, votre serveur pourrait être utilisé par + n'importe quel client pour accéder à des serveurs quelconques, + tout en masquant sa véritable identité. Ceci représente un danger + non seulement pour votre réseau, mais aussi pour l'Internet au + sens large. Dans le cas de la mise en oeuvre d'un mandataire + inverse (en utilisant la directive ProxyPass avec ProxyRequests Off), le contrôle + d'accès est moins critique car les clients ne peuvent contacter + que les serveurs que vous avez spécifiés.

    - 
    ProxySet ajp://backend:7001 timeout=15
    +

    Voir aussi la variable d'environnement Proxy-Chain-Auth.

    +
    top
    +
    +

    Ralentissement au démarrage

    +

    Si vous utilisez la directive ProxyBlock, les noms d'hôtes sont résolus en adresses + IP puis ces dernières mises en cache au cours du démarrage + à des fins de tests de comparaisons ultérieurs. Ce processus peut + durer plusieurs secondes (ou d'avantage) en fonction de la vitesse + à laquelle s'effectue la résolution des noms d'hôtes.

    +
    top
    +
    +

    Mandataire en Intranet

    +

    Un serveur mandataire Apache httpd situé à l'intérieur d'un Intranet + doit faire suivre les requêtes destinées à un serveur externe à + travers le pare-feu de l'entreprise (pour ce faire, définissez la + directive ProxyRemote de + façon à ce qu'elle fasse suivre le protocole concerné + vers le mandataire du pare-feu). Cependant, lorsqu'il doit accéder + à des ressources situées dans l'Intranet, il peut se passer du + pare-feu pour accéder aux serveurs. A cet effet, la directive + NoProxy permet de + spécifier quels hôtes appartiennent à l'Intranet et peuvent donc + être accédés directement.

    -

    Avertissement

    -

    Gardez à l'esprit qu'une même clé de paramètre peut avoir - différentes significations selon qu'elle s'applique à un - répartiteur ou à un serveur cible, et ceci est illustré par les deux - exemples précédents où il est question d'un timeout.

    -
    +

    Les utilisateurs d'un Intranet ont tendance à oublier le nom du + domaine local dans leurs requêtes WWW, et demandent par exemple + "http://un-serveur/" au lieu de + http://un-serveur.example.com/. Certains serveurs + mandataires commerciaux acceptent ce genre de requête et les + traitent simplement en utilisant un nom de domaine local + implicite. Lorsque la directive ProxyDomain est utilisée et si le + serveur est configuré comme + mandataire, Apache httpd peut renvoyer une réponse de redirection et + ainsi fournir au client l'adresse de serveur correcte, + entièrement qualifiée. C'est la méthode à privilégier car le + fichier des marque-pages de l'utilisateur contiendra alors des + noms de serveurs entièrement qualifiés.

    +
    top
    +
    +

    Ajustements relatifs au + protocole

    +

    Pour les cas où mod_proxy envoie des requêtes + vers un serveur qui n'implémente pas correctement les connexions + persistantes ou le protocole HTTP/1.1, il existe deux variables + d'environnement qui permettent de forcer les requêtes à utiliser + le protocole HTTP/1.0 avec connexions non persistantes. Elles + peuvent être définies via la directive SetEnv.

    +

    Il s'agit des variables force-proxy-request-1.0 et + proxy-nokeepalive.

    -
    -
    top
    -

    Directive ProxySourceAddress

    - - - - - - - -
    Description:Définit l'adresse IP locale pour les connexions mandatées -sortantes
    Syntaxe:ProxySourceAddress adresse
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    Compatibilité:Disponible depuis la version 2.3.9
    -

    Cette directive permet de définir une adresse IP locale - spécifique à laquelle faire référence lors d'une connexion à un - serveur d'arrière-plan.

    + 
    <Location /buggyappserver/>
+  ProxyPass http://buggyappserver:7001/foo/
+  SetEnv force-proxy-request-1.0 1
+  SetEnv proxy-nokeepalive 1
+</Location>
    -
    -
    top
    -

    Directive ProxyStatus

    - - - - - - - - -
    Description:Affiche l'état du répartiteur de charge du mandataire dans -mod_status
    Syntaxe:ProxyStatus Off|On|Full
    Défaut:ProxyStatus Off
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    Compatibilité:Disponible depuis la version 2.2 d'Apache
    -

    Cette directive permet de spécifier si les données d'état du - répartiteur de charge du mandataire doivent être affichées via la - page d'état du serveur du module mod_status.

    -

    Note

    -

    L'argument Full produit le même effet que - l'argument On.

    -
    +
    top
    +
    +

    Corps de requêtes

    +

    Certaines méthodes de requêtes comme POST comportent un corps de + requête. Le protocole HTTP stipule que les requêtes qui comportent + un corps doivent soit utiliser un codage de transmission + fractionnée (chunked transfer encoding), soit envoyer un en-tête de requête + Content-Length. Lorsqu'il fait suivre ce genre de + requête vers le serveur demandé, mod_proxy_http + s'efforce toujours d'envoyer l'en-tête Content-Length. + Par contre, si la taille du corps est importante, et si la requête + originale utilise un codage à fractionnement, ce dernier peut aussi + être utilisé dans la requête montante. Ce comportement peut être + contrôlé à l'aide de variables + d'environnement. Ainsi, si elle est définie, la variable + proxy-sendcl assure une compatibilité maximale avec les + serveurs demandés en imposant l'envoi de l'en-tête + Content-Length, alors que + proxy-sendchunked diminue la consommation de ressources + en imposant l'utilisation d'un codage à fractionnement.

    -
    -
    top
    -

    Directive ProxyTimeout

    - - - - - - - -
    Description:Délai d'attente réseau pour les requêtes -mandatées
    Syntaxe:ProxyTimeout secondes
    Défaut:Valeur de la directive Timeout
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    -

    Cette directive permet à l'utilisateur de spécifier un délai pour - les requêtes mandatées. Ceci s'avère utile dans le cas d'un serveur - d'applications lent et bogué qui a tendance à se bloquer, et si vous - préférez simplement renvoyer une erreur timeout et abandonner la - connexion en douceur plutôt que d'attendre jusqu'à ce que le serveur - veuille bien répondre.

    +

    Dans certaines circonstances, le serveur doit mettre en file + d'attente sur disque les corps de requêtes afin de satisfaire le + traitement demandé des corps de requêtes. Par exemple, cette mise en + file d'attente se produira si le corps original a été envoyé selon un + codage morcelé (et possède une taille importante), alors que + l'administrateur a demandé que les requêtes du serveur + d'arrière-plan soient envoyées avec l'en-tête Content-Length ou en + HTTP/1.0. Cette mise en file d'attente se produira aussi si le corps + de la requête contient déjà un en-tête Content-Length, alors que le + serveur est configuré pour filtrer les corps des requêtes entrantes.

    -
    -
    top
    -

    Directive ProxyVia

    - - - - - - - -
    Description:Information fournie dans l'en-tête de réponse HTTP -Via pour les requêtes mandatées
    Syntaxe:ProxyVia On|Off|Full|Block
    Défaut:ProxyVia Off
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_proxy
    -

    Cette directive permet de contrôler l'utilisation de l'en-tête - HTTP Via: par le mandataire. Le but recherché est de - contrôler le flux des requêtes mandatées tout au long d'une chaîne - de serveurs mandataires. Voir RFC 2616 (HTTP/1.1), - section 14.45 pour une description des lignes d'en-tête - Via:.

    +

    La directive LimitRequestBody ne s'applique qu'aux + corps de requêtes que le serveur met en file d'attente sur disque.

    -
      -
    • Si elle est définie à Off, valeur par défaut, cette - directive n'effectue aucun traitement particulier. Si une requête ou - une réponse contient un en-tête Via:, il est transmis - sans modification.
      • +
    top
    +
    +

    En-têtes de requête du mandataire + inverse

    -
  • Si elle est définie à On, chaque requête ou réponse - se verra ajouter une ligne d'en-tête Via: pour le - serveur courant.
    • +

    Lorsqu'il est configuré en mode mandataire inverse (en utilisant + par exemple la directive ProxyPass), + mod_proxy_http ajoute plusieurs en-têtes de requête + afin de transmettre des informations au serveur demandé. Ces + en-têtes sont les suivants :

    -
  • Si elle est définie à Full, chaque ligne d'en-tête - Via: se verra ajouter la version du serveur Apache - httpd sous la forme d'un champ de commentaire Via:.
    • +
    +
    X-Forwarded-For
    +
    L'adresse IP du client.
    +
    X-Forwarded-Host
    +
    L'hôte d'origine demandé par le client dans l'en-tête de + requête HTTP Host.
    +
    X-Forwarded-Server
    +
    Le nom d'hôte du serveur mandataire.
    +
    -
  • Si elle est définie à Block, chaque requête - mandatée verra ses lignes d'en-tête Via: supprimées. - Aucun nouvel en-tête Via: ne sera généré.
    • - +

    Ces en-têtes doivent être utilisés avec précautions sur le + serveur demandé, car ils contiendront plus d'une valeur (séparées + par des virgules) si la requête originale contenait déjà un de ces + en-têtes. Par exemple, vous pouvez utiliser + %{X-Forwarded-For}i dans la chaîne de format du journal + du serveur demandé pour enregistrer les adresses IP des clients + originaux, mais il est possible que vous obteniez plusieurs adresses + si la requête passe à travers plusieurs mandataires.

    -
    +

    Voir aussi les directives ProxyPreserveHost et ProxyVia directives, qui permettent + de contrôler d'autres en-têtes de requête.

    + +

    Note : Si vous devez ajouter des en-têtes particuliers à la + requête mandatée, utilisez la directive RequestHeader.

    + +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_proxy.html.ja.utf8 b/docs/manual/mod/mod_proxy.html.ja.utf8 index 7a1563c5437..b2cbacad31b 100644 --- a/docs/manual/mod/mod_proxy.html.ja.utf8 +++ b/docs/manual/mod/mod_proxy.html.ja.utf8 @@ -121,195 +121,6 @@

  • mod_ssl
    • top
    -
    -

    フォワードプロキシとリバースプロキシ

    -

    Apache はフォワードプロキシとしても、 - リバースプロキシとしても設定することができます。

    - -

    通常のフォワードプロキシはクライアントと - オリジンサーバ (訳注: コンテンツ生成元のサーバ) - の間に位置する中間サーバです。 - オリジンサーバからコンテンツを取得する過程では、クライアントは - 行き先としてオリジンサーバを指定しつつプロキシにリクエストを送り、 - プロキシはオリジンサーバからコンテンツ取得のリクエストを送り、 - コンテンツが取得できればそれをクライアントに返します。 - クライアントが他のサイトにフォワードプロクシ経由でアクセスするには、 - 特別にそれ用の設定をしなければなりません。

    - -

    フォワードプロキシの一般的な使用方法は、ファイアウォールによって - 制限されている内部のクライアントにインターネットへのアクセスを - 提供するものです。フォワードプロキシはネットワークの使用量を - 減らすために (mod_cache で提供されている) - キャッシュ機能を用いることもできます。

    - -

    フォワードプロキシは ProxyRequests ディレクティブで - 有効になります。フォワードプロキシでは、クライアントは本当の身元を - 隠して任意のサイトにアクセスできるようになるため、フォワードプロキシを - 有効にする前に、承認されたクライアントのみがプロキシにアクセスできるように - サーバを安全にすることが重要です。

    - -

    一方リバースプロキシは、クライアントには普通の - ウェブサーバのように見えます。クライアント側に特別な設定は必要ありません。 - クライアントはリバースプロキシの名前空間に対して通常のコンテンツへの - リクエストを行ないます。プロキシはリクエストをどこに送れば良いかを判定し、 - あたかも自分自身がオリジンサーバであったかのようにクライアントに - コンテンツを返します。

    - -

    リバースプロキシのよくある利用方法は、インターネットユーザに - ファイアウォールの中にあるサーバにアクセスを与えるというものです。 - リバースプロキシは複数のバックエンドサーバへ負荷分散をするために - 使ったり、遅いバックエンドエンドサーバのためにキャッシュ機能を提供したり - するために使えます。また、リバースプロキシは複数のサーバを - 同じ URL 空間にまとめるために使うこともできます。

    - -

    リバースプロキシは ProxyPass ディレクティブや - RewriteRule ディレクティブの - [P] フラグを使うことで有効になります。リバースプロキシの - 設定のために ProxyRequests を設定する必要は - ありません。

    -
    top
    -
    -

    基本の例

    - -

    以下の例は手始めの簡単な例です。個々のディレクティブの意味は - それぞれの説明をお読みください。

    - -

    またキャッシュ機能を有効にしたい場合は、mod_cache - の説明を読んでください。

    - -

    フォワードプロキシ

    - ProxyRequests On
    - ProxyVia On
    -
    - <Proxy *>
    - - Order deny,allow
    - Deny from all
    - Allow from internal.example.com
    -     - </Proxy> -

    - -

    リバースプロキシ

    - ProxyRequests Off
    -
    - <Proxy *>
    - - Order deny,allow
    - Allow from all
    -     - </Proxy>
    -
    - ProxyPass /foo http://foo.example.com/bar
    - ProxyPassReverse /foo http://foo.example.com/bar -

    -
    top
    -
    -

    プロキシへのアクセス制御

    -

    プロキシのアクセスは以下のように <Proxy> コンテナの中に - ディレクティブを書くことで制御できます:

    - -

    - <Proxy *>
    - - Order Deny,Allow
    - Deny from all
    - Allow from 192.168.0
    -     - </Proxy> -

    - -

    アクセス制御のためのディレクティブのより詳しい情報は - mod_authz_host をお読みください。

    - -

    (ProxyRequests ディレクティブを - 使って) フォワードプロキシを設定している場合は、厳しくアクセス - 制限を行なうことが非常に大切です。そうしないと、任意のクライアントが - 身元を明かすことなく任意のホストにアクセスするためにサーバを使うことが - できてしまいます。これはあなた自身のネットワークにとっても、インターネット - 全体にとっても危険なことです。(ProxyRequests Off にして - ProxyPass ディレクティブを使って) - リバースプロキシを使っている場合には、クライアントはあなたが明示的に - 設定したホストにしかアクセスできないため、フォワードプロキシのとき - ほどアクセス制御に力を注がなくても大丈夫です。

    - -
    top
    -
    -

    遅い起動

    -

    ProxyBlock ディレクティブを使っている場合、 - 後のテストのために起動時にホストの - IP アドレスが調べられてキャッシュされます。ホスト名のルックアップの - 速さによっては、数秒 (かそれ以上) かかるかもしれません。

    -
    top
    -
    -

    イントラネットプロキシ

    -

    イントラネットにある Apache プロキシサーバは外部へのリクエストを - 会社のファイアウォールを通して送らなければなりません。(このためには - 個々の scheme についてそれぞれ、ファイアウォールの - プロキシにフォワードされるように - ProxyRemote ディレクティブを - 設定してください)。しかしイントラネット内のリソースにアクセスするときは、 - ファイアウォールを通さないでもアクセスできます。 - どのホストがイントラネットに属し、直接アクセスすべきかを指定するには、 - NoProxy ディレクティブが - 役に立ちます。

    - -

    イントラネット内のユーザは WWW のリクエストでローカルドメインを - 省略することがよくあります。http://somehost.example.com/ - というリクエストの代わりに "http://somehost/" をリクエストしたりします。 - このようなリクエストを受け付け、サーバに設定されているローカルドメインが - 暗黙のうちに使われていると解釈して、単純にリクエストを処理するものも - 商用プロキシサーバの中にはあります。 - サーバが プロキシのサービス用に設定されていて - ProxyDomain ディレクティブが - 使用された場合には、Apache はクライアントにリダイレクト応答を送って、 - 正しい、完全な ((訳注: fully qualified)) - サーバのアドレスに送ることができます。このように - リダイレクトすると、ユーザのブックマークが正しい完全なホスト名を含む - ことにもなるため、より好ましい方法と言えるでしょう。

    -
    top
    -
    -

    プロトコルの調整

    -

    Keepalive や HTTP/1.1 を適切に実装していないアプリケーションサーバに対して - mod_proxy がリクエストを送信する場合、 - HTTP/1.0 を使って keepalive を無しにしてリクエストを送るようにする - 環境変数が二つあります。これらは SetEnv ディレクティブで設定します。

    - -

    force-proxy-request-1.0 と proxy-nokeepalive - がその環境変数です。

    - -

    - <Location /buggyappserver/>
    - - ProxyPass http://buggyappserver:7001/foo/
    - SetEnv force-proxy-request-1.0 1
    - SetEnv proxy-nokeepalive 1
    -     - </Location> -

    - -
    top
    -
    -

    リクエストボディ

    - -

    POST メソッドなどのリクエストには、リクエストボディがあります。 - HTTP プロトコル仕様によると、ボディのあるリクエストは chunked - 転送を使うか、Content-Length - ヘッダを送信しなければなりません。 - このようなリクエストをオリジンサーバに送信する場合、 - mod_proxy_http は常に Content-Length - を送ろうと試みます。しかし。ボディが大きく、オリジナルのリクエストで - chunked 転送が使われている場合、上流へのリクエストに - chunked 転送も使われます。 - この挙動は 環境変数で制御できます。 - proxy-sendcl を設定すると、可能な限り常に - Content-Length を付与して、 - 上流サーバに送信するようになります。 - 逆に proxy-sendchunked を設定すると、リソース消費を抑え、 - chnked エンコードを使って送信するようになります。

    - -
    -
    top

    BalancerGrowth ディレクティブ

    @@ -1240,6 +1051,195 @@ URL を調整する +
    top
    +
    +

    フォワードプロキシとリバースプロキシ

    +

    Apache はフォワードプロキシとしても、 + リバースプロキシとしても設定することができます。

    + +

    通常のフォワードプロキシはクライアントと + オリジンサーバ (訳注: コンテンツ生成元のサーバ) + の間に位置する中間サーバです。 + オリジンサーバからコンテンツを取得する過程では、クライアントは + 行き先としてオリジンサーバを指定しつつプロキシにリクエストを送り、 + プロキシはオリジンサーバからコンテンツ取得のリクエストを送り、 + コンテンツが取得できればそれをクライアントに返します。 + クライアントが他のサイトにフォワードプロクシ経由でアクセスするには、 + 特別にそれ用の設定をしなければなりません。

    + +

    フォワードプロキシの一般的な使用方法は、ファイアウォールによって + 制限されている内部のクライアントにインターネットへのアクセスを + 提供するものです。フォワードプロキシはネットワークの使用量を + 減らすために (mod_cache で提供されている) + キャッシュ機能を用いることもできます。

    + +

    フォワードプロキシは ProxyRequests ディレクティブで + 有効になります。フォワードプロキシでは、クライアントは本当の身元を + 隠して任意のサイトにアクセスできるようになるため、フォワードプロキシを + 有効にする前に、承認されたクライアントのみがプロキシにアクセスできるように + サーバを安全にすることが重要です。

    + +

    一方リバースプロキシは、クライアントには普通の + ウェブサーバのように見えます。クライアント側に特別な設定は必要ありません。 + クライアントはリバースプロキシの名前空間に対して通常のコンテンツへの + リクエストを行ないます。プロキシはリクエストをどこに送れば良いかを判定し、 + あたかも自分自身がオリジンサーバであったかのようにクライアントに + コンテンツを返します。

    + +

    リバースプロキシのよくある利用方法は、インターネットユーザに + ファイアウォールの中にあるサーバにアクセスを与えるというものです。 + リバースプロキシは複数のバックエンドサーバへ負荷分散をするために + 使ったり、遅いバックエンドエンドサーバのためにキャッシュ機能を提供したり + するために使えます。また、リバースプロキシは複数のサーバを + 同じ URL 空間にまとめるために使うこともできます。

    + +

    リバースプロキシは ProxyPass ディレクティブや + RewriteRule ディレクティブの + [P] フラグを使うことで有効になります。リバースプロキシの + 設定のために ProxyRequests を設定する必要は + ありません。

    +
    top
    +
    +

    基本の例

    + +

    以下の例は手始めの簡単な例です。個々のディレクティブの意味は + それぞれの説明をお読みください。

    + +

    またキャッシュ機能を有効にしたい場合は、mod_cache + の説明を読んでください。

    + +

    フォワードプロキシ

    + ProxyRequests On
    + ProxyVia On
    +
    + <Proxy *>
    + + Order deny,allow
    + Deny from all
    + Allow from internal.example.com
    +     + </Proxy> +

    + +

    リバースプロキシ

    + ProxyRequests Off
    +
    + <Proxy *>
    + + Order deny,allow
    + Allow from all
    +     + </Proxy>
    +
    + ProxyPass /foo http://foo.example.com/bar
    + ProxyPassReverse /foo http://foo.example.com/bar +

    +
    top
    +
    +

    プロキシへのアクセス制御

    +

    プロキシのアクセスは以下のように <Proxy> コンテナの中に + ディレクティブを書くことで制御できます:

    + +

    + <Proxy *>
    + + Order Deny,Allow
    + Deny from all
    + Allow from 192.168.0
    +     + </Proxy> +

    + +

    アクセス制御のためのディレクティブのより詳しい情報は + mod_authz_host をお読みください。

    + +

    (ProxyRequests ディレクティブを + 使って) フォワードプロキシを設定している場合は、厳しくアクセス + 制限を行なうことが非常に大切です。そうしないと、任意のクライアントが + 身元を明かすことなく任意のホストにアクセスするためにサーバを使うことが + できてしまいます。これはあなた自身のネットワークにとっても、インターネット + 全体にとっても危険なことです。(ProxyRequests Off にして + ProxyPass ディレクティブを使って) + リバースプロキシを使っている場合には、クライアントはあなたが明示的に + 設定したホストにしかアクセスできないため、フォワードプロキシのとき + ほどアクセス制御に力を注がなくても大丈夫です。

    + +
    top
    +
    +

    遅い起動

    +

    ProxyBlock ディレクティブを使っている場合、 + 後のテストのために起動時にホストの + IP アドレスが調べられてキャッシュされます。ホスト名のルックアップの + 速さによっては、数秒 (かそれ以上) かかるかもしれません。

    +
    top
    +
    +

    イントラネットプロキシ

    +

    イントラネットにある Apache プロキシサーバは外部へのリクエストを + 会社のファイアウォールを通して送らなければなりません。(このためには + 個々の scheme についてそれぞれ、ファイアウォールの + プロキシにフォワードされるように + ProxyRemote ディレクティブを + 設定してください)。しかしイントラネット内のリソースにアクセスするときは、 + ファイアウォールを通さないでもアクセスできます。 + どのホストがイントラネットに属し、直接アクセスすべきかを指定するには、 + NoProxy ディレクティブが + 役に立ちます。

    + +

    イントラネット内のユーザは WWW のリクエストでローカルドメインを + 省略することがよくあります。http://somehost.example.com/ + というリクエストの代わりに "http://somehost/" をリクエストしたりします。 + このようなリクエストを受け付け、サーバに設定されているローカルドメインが + 暗黙のうちに使われていると解釈して、単純にリクエストを処理するものも + 商用プロキシサーバの中にはあります。 + サーバが プロキシのサービス用に設定されていて + ProxyDomain ディレクティブが + 使用された場合には、Apache はクライアントにリダイレクト応答を送って、 + 正しい、完全な ((訳注: fully qualified)) + サーバのアドレスに送ることができます。このように + リダイレクトすると、ユーザのブックマークが正しい完全なホスト名を含む + ことにもなるため、より好ましい方法と言えるでしょう。

    +
    top
    +
    +

    プロトコルの調整

    +

    Keepalive や HTTP/1.1 を適切に実装していないアプリケーションサーバに対して + mod_proxy がリクエストを送信する場合、 + HTTP/1.0 を使って keepalive を無しにしてリクエストを送るようにする + 環境変数が二つあります。これらは SetEnv ディレクティブで設定します。

    + +

    force-proxy-request-1.0 と proxy-nokeepalive + がその環境変数です。

    + +

    + <Location /buggyappserver/>
    + + ProxyPass http://buggyappserver:7001/foo/
    + SetEnv force-proxy-request-1.0 1
    + SetEnv proxy-nokeepalive 1
    +     + </Location> +

    + +
    top
    +
    +

    リクエストボディ

    + +

    POST メソッドなどのリクエストには、リクエストボディがあります。 + HTTP プロトコル仕様によると、ボディのあるリクエストは chunked + 転送を使うか、Content-Length + ヘッダを送信しなければなりません。 + このようなリクエストをオリジンサーバに送信する場合、 + mod_proxy_http は常に Content-Length + を送ろうと試みます。しかし。ボディが大きく、オリジナルのリクエストで + chunked 転送が使われている場合、上流へのリクエストに + chunked 転送も使われます。 + この挙動は 環境変数で制御できます。 + proxy-sendcl を設定すると、可能な限り常に + Content-Length を付与して、 + 上流サーバに送信するようになります。 + 逆に proxy-sendchunked を設定すると、リソース消費を抑え、 + chnked エンコードを使って送信するようになります。

    + +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_proxy_connect.html.en b/docs/manual/mod/mod_proxy_connect.html.en index c78488e4c89..7174cc7fa5a 100644 --- a/docs/manual/mod/mod_proxy_connect.html.en +++ b/docs/manual/mod/mod_proxy_connect.html.en @@ -66,19 +66,6 @@

  • mod_proxy
    • top
    -
    -

    Request notes

    -

    mod_proxy_connect creates the following request notes for - logging using the %{VARNAME}n format in - LogFormat or - ErrorLogFormat: -

    -
    -
    proxy-source-port
    -
    The local port used for the connection to the backend server.
    -
    -
    -
    top

    AllowCONNECT Directive

    説明:Number of additional Balancers that can be added Post-configuration
    allow connections to the listed ports only.

    +
    top
    +
    +

    Request notes

    +

    mod_proxy_connect creates the following request notes for + logging using the %{VARNAME}n format in + LogFormat or + ErrorLogFormat: +

    +
    +
    proxy-source-port
    +
    The local port used for the connection to the backend server.
    +
    +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_proxy_connect.html.fr b/docs/manual/mod/mod_proxy_connect.html.fr index 6f1ef520549..974b628de36 100644 --- a/docs/manual/mod/mod_proxy_connect.html.fr +++ b/docs/manual/mod/mod_proxy_connect.html.fr @@ -69,19 +69,6 @@ des requ

  • mod_proxy
    • top
    -
    -

    Informations sur les requêtes

    -

    mod_proxy_connect enregistre les informations - suivantes pour journalisation via le format %{NOMVAR}n - dans les directives LogFormat ou ErrorLogFormat : -

    -
    -
    proxy-source-port
    -
    Le port local utilisé pour la connexion vers le serveur - d'arrière-plan.
    -
    -
    -
    top

    Directive AllowCONNECT

    Description:Ports that are allowed to CONNECT through the @@ -103,6 +90,19 @@ Port ranges available since Apache 2.3.7.
    vers les ports spécifiés.

    +
    top
    +
    +

    Informations sur les requêtes

    +

    mod_proxy_connect enregistre les informations + suivantes pour journalisation via le format %{NOMVAR}n + dans les directives LogFormat ou ErrorLogFormat : +

    +
    +
    proxy-source-port
    +
    Le port local utilisé pour la connexion vers le serveur + d'arrière-plan.
    +
    +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_proxy_connect.html.ja.utf8 b/docs/manual/mod/mod_proxy_connect.html.ja.utf8 index afdb340c044..8b8d00c872c 100644 --- a/docs/manual/mod/mod_proxy_connect.html.ja.utf8 +++ b/docs/manual/mod/mod_proxy_connect.html.ja.utf8 @@ -63,7 +63,6 @@

  • AllowCONNECT
  • mod_proxy
    • -
    top

    AllowCONNECT ディレクティブ

    Description:Ports autorisés à se CONNECTer à travers le @@ -109,6 +96,19 @@ d'Apache 2.3.5. Plages de ports disponibles depuis Apache 2.3.7.
    @@ -80,6 +79,7 @@ Port ranges available since Apache 2.3.7.

    このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

    +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_proxy_express.html.en b/docs/manual/mod/mod_proxy_express.html.en index 6eb52c1f75c..3d7975e69d0 100644 --- a/docs/manual/mod/mod_proxy_express.html.en +++ b/docs/manual/mod/mod_proxy_express.html.en @@ -87,7 +87,6 @@

    -
    top

    ProxyExpressDBMFile Directive

    @@ -171,6 +170,7 @@ controls whether the module will be active.

    +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_proxy_express.html.fr b/docs/manual/mod/mod_proxy_express.html.fr index de0ec838194..ee6fc7d9790 100644 --- a/docs/manual/mod/mod_proxy_express.html.fr +++ b/docs/manual/mod/mod_proxy_express.html.fr @@ -93,7 +93,6 @@ dynamique inverse de masse

    -
    top

    Directive ProxyExpressDBMFile

    @@ -177,6 +176,7 @@ dynamique inverse de masse d'activer/désactiver le module.

    +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_proxy_ftp.html.en b/docs/manual/mod/mod_proxy_ftp.html.en index 07711274a72..ca0d91576f2 100644 --- a/docs/manual/mod/mod_proxy_ftp.html.en +++ b/docs/manual/mod/mod_proxy_ftp.html.en @@ -72,6 +72,63 @@

  • mod_proxy
    • top
    +

    ProxyFtpDirCharset Directive

    +
    + + + + + + + +
    Description:Define the character set for proxied FTP listings
    Syntax:ProxyFtpDirCharset character set
    Default:ProxyFtpDirCharset ISO-8859-1
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_proxy_ftp
    Compatibility:Available in Apache 2.2.7 and later. Moved from mod_proxy in Apache 2.3.5.
    +

    The ProxyFtpDirCharset directive defines the + character set to be set for FTP directory listings in HTML generated by + mod_proxy_ftp.

    + +
    +
    top
    +

    ProxyFtpEscapeWildcards Directive

    + + + + + + + + +
    Description:Whether wildcards in requested filenames are escaped when sent to the FTP server
    Syntax:ProxyFtpEscapeWildcards [on|off]
    Default:on
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_proxy_ftp
    Compatibility:Available in Apache 2.3.3 and later
    +

    The ProxyFtpEscapeWildcards directive + controls whether wildcard characters ("*?[{~") in requested + filenames are escaped with backslash before sending them to the + FTP server. That is the default behavior, but many FTP servers + don't know about the escaping and try to serve the literal filenames + they were sent, including the backslashes in the names.

    +

    Set to "off" to allow downloading files with wildcards + in their names from FTP servers that don't understand wildcard + escaping.

    + +
    +
    top
    +

    ProxyFtpListOnWildcard Directive

    + + + + + + + + +
    Description:Whether wildcards in requested filenames trigger a file listing
    Syntax:ProxyFtpListOnWildcard [on|off]
    Default:on
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_proxy_ftp
    Compatibility:Available in Apache 2.3.3 and later
    +

    The ProxyFtpListOnWildcard directive + controls whether wildcard characters ("*?[{~") in requested + filenames cause mod_proxy_ftp to return a listing + of files instead of downloading a file. By default (value on), + they do. Set to "off" to allow downloading files even if they + have wildcard characters in their names.

    + +
    +
    top

    Why doesn't file type xxx download via FTP?

    @@ -175,63 +232,6 @@ See the ProxyFtpListOnWildcard directive.

    -
    top
    -

    ProxyFtpDirCharset Directive

    - - - - - - - - -
    Description:Define the character set for proxied FTP listings
    Syntax:ProxyFtpDirCharset character set
    Default:ProxyFtpDirCharset ISO-8859-1
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_proxy_ftp
    Compatibility:Available in Apache 2.2.7 and later. Moved from mod_proxy in Apache 2.3.5.
    -

    The ProxyFtpDirCharset directive defines the - character set to be set for FTP directory listings in HTML generated by - mod_proxy_ftp.

    - -
    -
    top
    -

    ProxyFtpEscapeWildcards Directive

    - - - - - - - - -
    Description:Whether wildcards in requested filenames are escaped when sent to the FTP server
    Syntax:ProxyFtpEscapeWildcards [on|off]
    Default:on
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_proxy_ftp
    Compatibility:Available in Apache 2.3.3 and later
    -

    The ProxyFtpEscapeWildcards directive - controls whether wildcard characters ("*?[{~") in requested - filenames are escaped with backslash before sending them to the - FTP server. That is the default behavior, but many FTP servers - don't know about the escaping and try to serve the literal filenames - they were sent, including the backslashes in the names.

    -

    Set to "off" to allow downloading files with wildcards - in their names from FTP servers that don't understand wildcard - escaping.

    - -
    -
    top
    -

    ProxyFtpListOnWildcard Directive

    - - - - - - - - -
    Description:Whether wildcards in requested filenames trigger a file listing
    Syntax:ProxyFtpListOnWildcard [on|off]
    Default:on
    Context:server config, virtual host, directory
    Status:Extension
    Module:mod_proxy_ftp
    Compatibility:Available in Apache 2.3.3 and later
    -

    The ProxyFtpListOnWildcard directive - controls whether wildcard characters ("*?[{~") in requested - filenames cause mod_proxy_ftp to return a listing - of files instead of downloading a file. By default (value on), - they do. Set to "off" to allow downloading files even if they - have wildcard characters in their names.

    - -

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_proxy_ftp.html.fr b/docs/manual/mod/mod_proxy_ftp.html.fr index 78d94507733..de04868e2b5 100644 --- a/docs/manual/mod/mod_proxy_ftp.html.fr +++ b/docs/manual/mod/mod_proxy_ftp.html.fr @@ -76,6 +76,71 @@

  • mod_proxy
    • top
    +

    Directive ProxyFtpDirCharset

    + + + + + + + + +
    Description:Définit le jeu de caractères des listings FTP +mandatés
    Syntaxe:ProxyFtpDirCharset jeu-caractères
    Défaut:ProxyFtpDirCharset ISO-8859-1
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_proxy_ftp
    Compatibilité:Disponible depuis la version 2.2.7 d'Apache. Déplacé +depuis mod_proxy à partir de la version 2.3.5 d'Apache
    +

    La directive ProxyFtpDirCharset permet de + définir le jeu de caractères à utiliser pour les listings FTP en + HTML générés par mod_proxy_ftp.

    + +
    +
    top
    +

    Directive ProxyFtpEscapeWildcards

    + + + + + + + + +
    Description:Les caractères génériques dans les noms de fichiers +doivent-ils être échappés lorsqu'ils sont envoyés au serveur FTP ?
    Syntaxe:ProxyFtpEscapeWildcards [on|off]
    Défaut:on
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_proxy_ftp
    Compatibilité:Disponible depuis la version 2.3.3 du serveur HTTP Apache
    +

    La directive ProxyFtpEscapeWildcards permet + de déterminer si les caractères génériques ("*?[{~") que contiennent + les noms de fichiers demandés doivent être échappés pas un slash + inversé avant d'être envoyés au serveur FTP. Il s'agit du comportement + par défaut ; cependant, de nombreux serveurs FTP n'ont aucune + connaissance de la notion d'échappement, et tentent de servir le + fichier demandé sous sa forme littérale, en incluant les slashes + inversés dans son nom.

    +

    Définissez cette directive à "off" pour permettre le + téléchargement de fichiers dont les noms contiennent des caractères + génériques depuis des serveurs FTP qui ne connaissent pas + l'échappement des caractères génériques.

    + +
    +
    top
    +

    Directive ProxyFtpListOnWildcard

    + + + + + + + + +
    Description:Les caractères génériques dans les noms de fichiers +demandés doivent-ils déclencher l'affichage d'un listing ?
    Syntaxe:ProxyFtpListOnWildcard [on|off]
    Défaut:on
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_proxy_ftp
    Compatibilité:Disponible depuis la version 2.3.3 du serveur HTTP Apache
    +

    La directive ProxyFtpListOnWildcard permet + de déterminer si les caractères génériques ("*?[{~") que contiennent + les noms de fichiers demandés provoquent l'affichage d'un listing de + fichiers par mod_proxy_ftp au lieu de télécharger un + fichier. Il s'agit de leur comportement par défaut (valeur on). + Définissez cette directive à "off" pour permettre le téléchargement de + fichiers même si leur nom contient des caractères génériques.

    + +
    +
    top

    Pourquoi les fichiers du type xxx ne sont-ils pas téléchargeables par FTP ?

    @@ -199,71 +264,6 @@ ProxyFtpListOnWildcard.

    -
    top
    -

    Directive ProxyFtpDirCharset

    - - - - - - - - -
    Description:Définit le jeu de caractères des listings FTP -mandatés
    Syntaxe:ProxyFtpDirCharset jeu-caractères
    Défaut:ProxyFtpDirCharset ISO-8859-1
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_proxy_ftp
    Compatibilité:Disponible depuis la version 2.2.7 d'Apache. Déplacé -depuis mod_proxy à partir de la version 2.3.5 d'Apache
    -

    La directive ProxyFtpDirCharset permet de - définir le jeu de caractères à utiliser pour les listings FTP en - HTML générés par mod_proxy_ftp.

    - -
    -
    top
    -

    Directive ProxyFtpEscapeWildcards

    - - - - - - - - -
    Description:Les caractères génériques dans les noms de fichiers -doivent-ils être échappés lorsqu'ils sont envoyés au serveur FTP ?
    Syntaxe:ProxyFtpEscapeWildcards [on|off]
    Défaut:on
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_proxy_ftp
    Compatibilité:Disponible depuis la version 2.3.3 du serveur HTTP Apache
    -

    La directive ProxyFtpEscapeWildcards permet - de déterminer si les caractères génériques ("*?[{~") que contiennent - les noms de fichiers demandés doivent être échappés pas un slash - inversé avant d'être envoyés au serveur FTP. Il s'agit du comportement - par défaut ; cependant, de nombreux serveurs FTP n'ont aucune - connaissance de la notion d'échappement, et tentent de servir le - fichier demandé sous sa forme littérale, en incluant les slashes - inversés dans son nom.

    -

    Définissez cette directive à "off" pour permettre le - téléchargement de fichiers dont les noms contiennent des caractères - génériques depuis des serveurs FTP qui ne connaissent pas - l'échappement des caractères génériques.

    - -
    -
    top
    -

    Directive ProxyFtpListOnWildcard

    - - - - - - - - -
    Description:Les caractères génériques dans les noms de fichiers -demandés doivent-ils déclencher l'affichage d'un listing ?
    Syntaxe:ProxyFtpListOnWildcard [on|off]
    Défaut:on
    Contexte:configuration du serveur, serveur virtuel, répertoire
    Statut:Extension
    Module:mod_proxy_ftp
    Compatibilité:Disponible depuis la version 2.3.3 du serveur HTTP Apache
    -

    La directive ProxyFtpListOnWildcard permet - de déterminer si les caractères génériques ("*?[{~") que contiennent - les noms de fichiers demandés provoquent l'affichage d'un listing de - fichiers par mod_proxy_ftp au lieu de télécharger un - fichier. Il s'agit de leur comportement par défaut (valeur on). - Définissez cette directive à "off" pour permettre le téléchargement de - fichiers même si leur nom contient des caractères génériques.

    - -

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_proxy_html.html.en b/docs/manual/mod/mod_proxy_html.html.en index 3259c46a195..975e1142708 100644 --- a/docs/manual/mod/mod_proxy_html.html.en +++ b/docs/manual/mod/mod_proxy_html.html.en @@ -71,7 +71,6 @@ extensive documentation

  • ProxyHTMLURLMap
    • -
    top

    ProxyHTMLBufSize Directive

    @@ -426,6 +425,7 @@ If TRUE, or if no condition is defined, the map is applied.

    in mod_proxy_html 3.x for HTTPD 2.0 and 2.2 is also supported.

    +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_proxy_html.html.fr b/docs/manual/mod/mod_proxy_html.html.fr index 3118f0212b6..43dea5d7701 100644 --- a/docs/manual/mod/mod_proxy_html.html.fr +++ b/docs/manual/mod/mod_proxy_html.html.fr @@ -77,7 +77,6 @@ d

  • ProxyHTMLURLMap
    • -
    top

    Directive ProxyHTMLBufSize

    @@ -495,6 +494,7 @@ conditions dans mod_proxy_html 3.x pour HTTPD 2.0 et 2.2 est aussi supportée.

    +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_proxy_scgi.html.en b/docs/manual/mod/mod_proxy_scgi.html.en index fde6e4970cf..a35c1a0d6bb 100644 --- a/docs/manual/mod/mod_proxy_scgi.html.en +++ b/docs/manual/mod/mod_proxy_scgi.html.en @@ -63,48 +63,6 @@

  • mod_proxy_balancer
    • top
    -
    -

    Examples

    -

    Remember, in order to make the following examples work, you have to - enable mod_proxy and mod_proxy_scgi.

    - -

    Simple gateway

    ProxyPass /scgi-bin/ scgi://localhost:4000/
    -
    - -

    The balanced gateway needs mod_proxy_balancer and - at least one load balancer algorithm module, such as - mod_lbmethod_byrequests, in addition to the proxy - modules listed above. mod_lbmethod_byrequests is the - default, and will be used for this example configuration.

    - -

    Balanced gateway

    ProxyPass "/scgi-bin/" "balancer://somecluster/"
-<Proxy "balancer://somecluster">
-    BalancerMember "scgi://localhost:4000"
-    BalancerMember "scgi://localhost:4001"
-</Proxy>
    -
    -
    top
    -
    -

    Environment Variables

    -

    In addition to the configuration directives that control the - behaviour of mod_proxy, an environment - variable may also control the SCGI protocol - provider:

    -
    -
    proxy-scgi-pathinfo
    -
    By default mod_proxy_scgi will neither create - nor export the PATH_INFO environment variable. This allows - the backend SCGI server to correctly determine SCRIPT_NAME - and Script-URI and be compliant with RFC 3875 section 3.3. - If instead you need mod_proxy_scgi to generate - a "best guess" for PATH_INFO, set this env-var. The - variable must be set before SetEnv - is effective. SetEnvIf can be - used instead: SetEnvIf Request_URI . proxy-scgi-pathinfo -
    -
    -
    -
    top

    ProxySCGIInternalRedirect Directive

  • Exemples
    • top
    +

    Directive ReflectorHeader

    +
    Description:Enable or disable internal redirect responses from the @@ -171,6 +129,48 @@ ProxySCGISendfile On ProxySCGISendfile X-Send-Static + +
    top
    +
    +

    Examples

    +

    Remember, in order to make the following examples work, you have to + enable mod_proxy and mod_proxy_scgi.

    + +

    Simple gateway

    ProxyPass /scgi-bin/ scgi://localhost:4000/
    +
    + +

    The balanced gateway needs mod_proxy_balancer and + at least one load balancer algorithm module, such as + mod_lbmethod_byrequests, in addition to the proxy + modules listed above. mod_lbmethod_byrequests is the + default, and will be used for this example configuration.

    + +

    Balanced gateway

    ProxyPass "/scgi-bin/" "balancer://somecluster/"
+<Proxy "balancer://somecluster">
+    BalancerMember "scgi://localhost:4000"
+    BalancerMember "scgi://localhost:4001"
+</Proxy>
    +
    +
    top
    +
    +

    Environment Variables

    +

    In addition to the configuration directives that control the + behaviour of mod_proxy, an environment + variable may also control the SCGI protocol + provider:

    +
    +
    proxy-scgi-pathinfo
    +
    By default mod_proxy_scgi will neither create + nor export the PATH_INFO environment variable. This allows + the backend SCGI server to correctly determine SCRIPT_NAME + and Script-URI and be compliant with RFC 3875 section 3.3. + If instead you need mod_proxy_scgi to generate + a "best guess" for PATH_INFO, set this env-var. The + variable must be set before SetEnv + is effective. SetEnvIf can be + used instead: SetEnvIf Request_URI . proxy-scgi-pathinfo +
    +
    diff --git a/docs/manual/mod/mod_proxy_scgi.html.fr b/docs/manual/mod/mod_proxy_scgi.html.fr index 442a0688a54..68c49c550c6 100644 --- a/docs/manual/mod/mod_proxy_scgi.html.fr +++ b/docs/manual/mod/mod_proxy_scgi.html.fr @@ -67,52 +67,6 @@
  • mod_proxy_balancer
    • top
    -
    -

    Exemples

    -

    Rappelez-vous, pour que les exemples suivants puissent - fonctionner, vous devez activer mod_proxy et - mod_proxy_scgi.

    - -

    Passerelle simple

    ProxyPass /scgi-bin/ scgi://localhost:4000/
    -
    - -

    La passerelle à répartition de charge nécessite le chargement du - module mod_proxy_balancer et d'au moins un module - fournissant un algorithme de répartition de charge, comme - mod_lbmethod_byrequests en plus des modules - déjà cités. mod_lbmethod_byrequests est le module - par défaut et sera utilisé dans cet exemple de configuration.

    - -

    Passerelle à répartition de charge

    ProxyPass /scgi-bin/ balancer://somecluster/
-<Proxy balancer://somecluster>
-    BalancerMember scgi://localhost:4000
-    BalancerMember scgi://localhost:4001
-</Proxy>
    -
    -
    top
    -
    -

    Variables d'environnement

    -

    En plus des directives de configuration qui permettent de - contrôler le comportement de mod_proxy, une - variable d'environnement peut aussi - contrôler le fournisseur de protocole SCGI :

    -
    -
    proxy-scgi-pathinfo
    -
    Par défaut, mod_proxy_scgi ne créera ni - exportera jamais la variable d'environnement - PATH_INFO. Ceci permet au serveur SCGI d'arrière-plan - de déterminer correctement SCRIPT_NAME et - Script-URI, et de rester en conformité avec la section - 3.3 de la RFC 3875. Si au contraire vous souhaitez que - mod_proxy_scgi génère une estimation la plus - précise possible de PATH_INFO, définissez cette - variable d'environnement. La variable doit être définie avant - que la directive SetEnv ne soit effective. Il est possible - d'utiliser à la place la directive SetEnvIf : SetEnvIf Request_URI . proxy-scgi-pathinfo -
    -
    -
    -
    top

    Directive ProxySCGIInternalRedirect

    ProxySCGISendfile X-Send-Static + +
    top
    +
    +

    Exemples

    +

    Rappelez-vous, pour que les exemples suivants puissent + fonctionner, vous devez activer mod_proxy et + mod_proxy_scgi.

    + +

    Passerelle simple

    ProxyPass /scgi-bin/ scgi://localhost:4000/
    +
    + +

    La passerelle à répartition de charge nécessite le chargement du + module mod_proxy_balancer et d'au moins un module + fournissant un algorithme de répartition de charge, comme + mod_lbmethod_byrequests en plus des modules + déjà cités. mod_lbmethod_byrequests est le module + par défaut et sera utilisé dans cet exemple de configuration.

    + +

    Passerelle à répartition de charge

    ProxyPass /scgi-bin/ balancer://somecluster/
+<Proxy balancer://somecluster>
+    BalancerMember scgi://localhost:4000
+    BalancerMember scgi://localhost:4001
+</Proxy>
    +
    +
    top
    +
    +

    Variables d'environnement

    +

    En plus des directives de configuration qui permettent de + contrôler le comportement de mod_proxy, une + variable d'environnement peut aussi + contrôler le fournisseur de protocole SCGI :

    +
    +
    proxy-scgi-pathinfo
    +
    Par défaut, mod_proxy_scgi ne créera ni + exportera jamais la variable d'environnement + PATH_INFO. Ceci permet au serveur SCGI d'arrière-plan + de déterminer correctement SCRIPT_NAME et + Script-URI, et de rester en conformité avec la section + 3.3 de la RFC 3875. Si au contraire vous souhaitez que + mod_proxy_scgi génère une estimation la plus + précise possible de PATH_INFO, définissez cette + variable d'environnement. La variable doit être définie avant + que la directive SetEnv ne soit effective. Il est possible + d'utiliser à la place la directive SetEnvIf : SetEnvIf Request_URI . proxy-scgi-pathinfo +
    +
    diff --git a/docs/manual/mod/mod_reflector.html.en b/docs/manual/mod/mod_reflector.html.en index 4f988b07e7b..7c09a405aaf 100644 --- a/docs/manual/mod/mod_reflector.html.en +++ b/docs/manual/mod/mod_reflector.html.en @@ -49,6 +49,22 @@
  • Examples
    • top
    +

    ReflectorHeader Directive

    +
    Description:Active ou désactive les réponses de redirection interne en @@ -188,6 +142,52 @@ provenance du serveur cible.
    + + + + + + +
    Description:Reflect an input header to the output headers
    Syntax:ReflectorHeader inputheader [outputheader]
    Context:server config, virtual host, directory, .htaccess
    Override:Options
    Status:Base
    Module:mod_reflector
    +

    This directive controls the reflection of request headers to the response. + The first argument is the name of the request header to copy. If the optional + second argument is specified, it will be used as the name of the response + header, otherwise the original request header name will be used.

    + +
    +
    top

    Examples

    @@ -74,22 +90,6 @@
    -
    top
    -

    ReflectorHeader Directive

    - - - - - - - -
    Description:Reflect an input header to the output headers
    Syntax:ReflectorHeader inputheader [outputheader]
    Context:server config, virtual host, directory, .htaccess
    Override:Options
    Status:Base
    Module:mod_reflector
    -

    This directive controls the reflection of request headers to the response. - The first argument is the name of the request header to copy. If the optional - second argument is specified, it will be used as the name of the response - header, otherwise the original request header name will be used.

    - -

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_reflector.html.fr b/docs/manual/mod/mod_reflector.html.fr index 4728039239e..6f6dd9036ed 100644 --- a/docs/manual/mod/mod_reflector.html.fr +++ b/docs/manual/mod/mod_reflector.html.fr @@ -52,6 +52,24 @@ filtres en sortie.

    + + + + + + +
    Description:Réfléchit un en-tête d'entrée dans les en-têtes de sortie
    Syntaxe:ReflectorHeader en-tête-entrée [en-tête-sortie]
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:Options
    Statut:Base
    Module:mod_reflector
    +

    Cette directive permet de contrôler la répercution des en-têtes + de la requête dans la réponse. Le premier argument correspond au nom + de l'en-tête à copier. Si le second argument (optionnel) est + spécifié, il définit le nom sous lequel l'en-tête sera répercuté + dans la réponse ; dans le cas contraire, c'est le nom de l'en-tête + original qui sera utilisé.

    + +
    +
    top

    Exemples

    @@ -78,24 +96,6 @@ filtres en sortie.
    -
    top
    -

    Directive ReflectorHeader

    - - - - - - - -
    Description:Réfléchit un en-tête d'entrée dans les en-têtes de sortie
    Syntaxe:ReflectorHeader en-tête-entrée [en-tête-sortie]
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:Options
    Statut:Base
    Module:mod_reflector
    -

    Cette directive permet de contrôler la répercution des en-têtes - de la requête dans la réponse. Le premier argument correspond au nom - de l'en-tête à copier. Si le second argument (optionnel) est - spécifié, il définit le nom sous lequel l'en-tête sera répercuté - dans la réponse ; dans le cas contraire, c'est le nom de l'en-tête - original qui sera utilisé.

    - -

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_remoteip.html.en b/docs/manual/mod/mod_remoteip.html.en index bca106a4e25..7bba4f54ed2 100644 --- a/docs/manual/mod/mod_remoteip.html.en +++ b/docs/manual/mod/mod_remoteip.html.en @@ -77,48 +77,6 @@ via the request headers.

  • mod_log_config
    • top
    -
    -

    Remote IP Processing

    - -

    Apache by default identifies the useragent with the connection's - client_ip value, and the connection remote_host and remote_logname are - derived from this value. These fields play a role in authentication, - authorization and logging and other purposes by other loadable - modules.

    - -

    mod_remoteip overrides the client IP of the connection with the - advertised useragent IP as provided by a proxy or load balancer, for - the duration of the request. A load balancer might establish a long - lived keepalive connection with the server, and each request will - have the correct useragent IP, even though the underlying client IP - address of the load balancer remains unchanged.

    - -

    When multiple, comma delimited useragent IP addresses are listed in the - header value, they are processed in Right-to-Left order. Processing - halts when a given useragent IP address is not trusted to present the - preceding IP address. The header field is updated to this remaining - list of unconfirmed IP addresses, or if all IP addresses were trusted, - this header is removed from the request altogether.

    - -

    In overriding the client IP, the module stores the list of intermediate - hosts in a remoteip-proxy-ip-list note, which mod_log_config - can record using the %{remoteip-proxy-ip-list}n format token. - If the administrator needs to store this as an additional header, this - same value can also be recording as a header using the directive - RemoteIPProxiesHeader.

    - -

    IPv4-over-IPv6 Mapped Addresses

    - As with httpd in general, any IPv4-over-IPv6 mapped addresses are recorded - in their IPv4 representation.
    - -

    Internal (Private) Addresses

    - All internal addresses 10/8, 172.16/12, 192.168/16, 169.254/16 and 127/8 - blocks (and IPv6 addresses outside of the public 2000::/3 block) are only - evaluated by mod_remoteip when RemoteIPInternalProxy - internal (intranet) proxies are registered.
    - -
    -
    top

    RemoteIPHeader Directive

    @@ -264,6 +222,48 @@ RemoteIPTrustedProxyList conf/trusted-proxies.lst proxy.isp.example.com #some well known ISP

    + +
    top
    +
    +

    Remote IP Processing

    + +

    Apache by default identifies the useragent with the connection's + client_ip value, and the connection remote_host and remote_logname are + derived from this value. These fields play a role in authentication, + authorization and logging and other purposes by other loadable + modules.

    + +

    mod_remoteip overrides the client IP of the connection with the + advertised useragent IP as provided by a proxy or load balancer, for + the duration of the request. A load balancer might establish a long + lived keepalive connection with the server, and each request will + have the correct useragent IP, even though the underlying client IP + address of the load balancer remains unchanged.

    + +

    When multiple, comma delimited useragent IP addresses are listed in the + header value, they are processed in Right-to-Left order. Processing + halts when a given useragent IP address is not trusted to present the + preceding IP address. The header field is updated to this remaining + list of unconfirmed IP addresses, or if all IP addresses were trusted, + this header is removed from the request altogether.

    + +

    In overriding the client IP, the module stores the list of intermediate + hosts in a remoteip-proxy-ip-list note, which mod_log_config + can record using the %{remoteip-proxy-ip-list}n format token. + If the administrator needs to store this as an additional header, this + same value can also be recording as a header using the directive + RemoteIPProxiesHeader.

    + +

    IPv4-over-IPv6 Mapped Addresses

    + As with httpd in general, any IPv4-over-IPv6 mapped addresses are recorded + in their IPv4 representation.
    + +

    Internal (Private) Addresses

    + All internal addresses 10/8, 172.16/12, 192.168/16, 169.254/16 and 127/8 + blocks (and IPv6 addresses outside of the public 2000::/3 block) are only + evaluated by mod_remoteip when RemoteIPInternalProxy + internal (intranet) proxies are registered.
    +
    diff --git a/docs/manual/mod/mod_remoteip.html.fr b/docs/manual/mod/mod_remoteip.html.fr index 621bb233125..ed8dc636d87 100644 --- a/docs/manual/mod/mod_remoteip.html.fr +++ b/docs/manual/mod/mod_remoteip.html.fr @@ -83,53 +83,6 @@ r
  • mod_ident
    • top
    -
    -

    Traitement des adresses distantes

    - -

    Apache identifie le client par la valeur remote_ip de la - connexion, et de cette valeur découlent les valeurs remote_host et - remote_logname de la connexion. Ces champs jouent un rôle - dans l'authentification, l'autorisation et la connexion, ainsi que - dans d'autres traitements effectués par d'autres modules - chargeables.

    - -

    mod_remoteip remplace la véritable remote_ip par la remote_ip - indiquée par exemple par un mandataire chaque fois que le serveur - effectue une évaluation du client, et réinitialise les valeurs de - remote_host et remote_logname afin de déclencher une nouvelle - requête dns ou ident sur l'adresse IP distante.

    - -

    Lorsque la valeur de l'en-tête comporte plusieurs adresses IP - distantes séparées par des virgules, celles-ci sont traitées de la - droite vers la gauche. Le traitement s'arrête lorsque l'adresse IP - distante courante n'est pas digne de confiance pour présenter - l'adresse IP précédente. Le champ d'en-tête est alors mis à jour de - façon à ne contenir que cette liste d'adresses non confirmées, ou - bien, si toutes les adresses IP sont dignes de confiance, cet - en-tête est tout bonnement supprimé de la requête.

    - -

    Lors du remplacement de l'adresse IP distante, le module stocke - la liste des hôtes intermédiaires dans un mémo - remoteip-proxy-ip-list, que l'on peut faire enregistrer par - mod_log_config en utilisant le symbole de format - %{remoteip-proxy-ip-list}n. Si l'administrateur doit - stocker ceci dans un en-tête additionnel, la même valeur peut aussi - être enregistrée sous la forme d'un en-tête en utilisant la - directive RemoteIPProxiesHeader.

    - -

    Adresses IPv4 converties au format IPv6

    - Avec httpd, d'une manière générale, toute adresse IPv4 convertie au - format IPv6 est enregistrée sous sa forme IPv4.
    - -

    Adresses internes (privées)

    - Tous les blocs d'adresses internes 10/8, 172.16/12, 192.168/16, - 169.254/16 and 127/8 (ainsi que les adresses IPv6 en dehors du bloc - public 2000::/3 block) ne sont évaluées par mod_remoteip que lorsque - des mandataires internes (intranet) - RemoteIPInternalProxy sont enregistrés.
    - -
    -
    top

    Directive RemoteIPHeader

    Description:Declare the header field which should be parsed for useragent IP addresses
    sonra LoadModule yönergesi ile sunucunuza yükleyebilirsiniz.

    - -
    top
    -

    LoadFile Yönergesi

    -
    Description:Définit le champ d'en-tête qui contiendra les adresses IP @@ -305,6 +258,53 @@ RemoteIPTrustedProxyList conf/trusted-proxies.lst proxy.isp.example.com #un FAI bien connu

    + +
    top
    +
    +

    Traitement des adresses distantes

    + +

    Apache identifie le client par la valeur remote_ip de la + connexion, et de cette valeur découlent les valeurs remote_host et + remote_logname de la connexion. Ces champs jouent un rôle + dans l'authentification, l'autorisation et la connexion, ainsi que + dans d'autres traitements effectués par d'autres modules + chargeables.

    + +

    mod_remoteip remplace la véritable remote_ip par la remote_ip + indiquée par exemple par un mandataire chaque fois que le serveur + effectue une évaluation du client, et réinitialise les valeurs de + remote_host et remote_logname afin de déclencher une nouvelle + requête dns ou ident sur l'adresse IP distante.

    + +

    Lorsque la valeur de l'en-tête comporte plusieurs adresses IP + distantes séparées par des virgules, celles-ci sont traitées de la + droite vers la gauche. Le traitement s'arrête lorsque l'adresse IP + distante courante n'est pas digne de confiance pour présenter + l'adresse IP précédente. Le champ d'en-tête est alors mis à jour de + façon à ne contenir que cette liste d'adresses non confirmées, ou + bien, si toutes les adresses IP sont dignes de confiance, cet + en-tête est tout bonnement supprimé de la requête.

    + +

    Lors du remplacement de l'adresse IP distante, le module stocke + la liste des hôtes intermédiaires dans un mémo + remoteip-proxy-ip-list, que l'on peut faire enregistrer par + mod_log_config en utilisant le symbole de format + %{remoteip-proxy-ip-list}n. Si l'administrateur doit + stocker ceci dans un en-tête additionnel, la même valeur peut aussi + être enregistrée sous la forme d'un en-tête en utilisant la + directive RemoteIPProxiesHeader.

    + +

    Adresses IPv4 converties au format IPv6

    + Avec httpd, d'une manière générale, toute adresse IPv4 convertie au + format IPv6 est enregistrée sous sa forme IPv4.
    + +

    Adresses internes (privées)

    + Tous les blocs d'adresses internes 10/8, 172.16/12, 192.168/16, + 169.254/16 and 127/8 (ainsi que les adresses IPv6 en dehors du bloc + public 2000::/3 block) ne sont évaluées par mod_remoteip que lorsque + des mandataires internes (intranet) + RemoteIPInternalProxy sont enregistrés.
    +
    diff --git a/docs/manual/mod/mod_reqtimeout.html.en b/docs/manual/mod/mod_reqtimeout.html.en index 1efc5ab7df3..8aafa445c44 100644 --- a/docs/manual/mod/mod_reqtimeout.html.en +++ b/docs/manual/mod/mod_reqtimeout.html.en @@ -43,51 +43,6 @@
  • Examples
    • top
    -
    -

    Examples

    - -
      -
    1. - Allow 10 seconds to receive the request including the headers and - 30 seconds for receiving the request body: - - 
      RequestReadTimeout header=10 body=30
      - -
      2. - -
    2. - Allow at least 10 seconds to receive the request body. - If the client sends data, increase the timeout by 1 second for every - 1000 bytes received, with no upper limit for the timeout (except for - the limit given indirectly by - LimitRequestBody): - - 
      RequestReadTimeout body=10,MinRate=1000
      - -
      3. - -
    3. - Allow at least 10 seconds to receive the request including the headers. - If the client sends data, increase the timeout by 1 second for every - 500 bytes received. But do not allow more than 30 seconds for the - request including the headers: - - 
      RequestReadTimeout header=10-30,MinRate=500
      - -
      4. - -
    4. - Usually, a server should have both header and body timeouts configured. - If a common configuration is used for http and https virtual hosts, the - timeouts should not be set too low: - - 
      RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500
      - -
      5. - -
    -
    -
    top

    RequestReadTimeout Directive

    + +
    top
    +
    +

    Examples

    + +
      +
    1. + Allow 10 seconds to receive the request including the headers and + 30 seconds for receiving the request body: + + 
      RequestReadTimeout header=10 body=30
      + +
      2. + +
    2. + Allow at least 10 seconds to receive the request body. + If the client sends data, increase the timeout by 1 second for every + 1000 bytes received, with no upper limit for the timeout (except for + the limit given indirectly by + LimitRequestBody): + + 
      RequestReadTimeout body=10,MinRate=1000
      + +
      3. + +
    3. + Allow at least 10 seconds to receive the request including the headers. + If the client sends data, increase the timeout by 1 second for every + 500 bytes received. But do not allow more than 30 seconds for the + request including the headers: + + 
      RequestReadTimeout header=10-30,MinRate=500
      + +
      4. + +
    4. + Usually, a server should have both header and body timeouts configured. + If a common configuration is used for http and https virtual hosts, the + timeouts should not be set too low: + + 
      RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500
      + +
      5. + +
    diff --git a/docs/manual/mod/mod_reqtimeout.html.fr b/docs/manual/mod/mod_reqtimeout.html.fr index 6e9c1d16944..3c37a0ac55e 100644 --- a/docs/manual/mod/mod_reqtimeout.html.fr +++ b/docs/manual/mod/mod_reqtimeout.html.fr @@ -44,52 +44,6 @@ donn
  • Exemples
    • top
    -
    -

    Exemples

    - -
      -
    1. - Accorde 10 secondes pour la réception des en-têtes de la requête - et 30 secondes pour la réception du corps : - - 
      RequestTimeout headerinit=10 body=30
      - -
      2. - -
    2. - Accorde au moins 10 secondes pour la réception du corps de - la requête. Si le client envoie des données, augmente ce délai - d'une seconde pour chaque paquet de 1000 octets reçus, sans - limite supérieure (sauf si une limite a été - spécifiée via la directive LimitRequestBody) : - - 
      RequestReadTimeout body=10,MinRate=1000
      - -
      3. - -
    3. - Accorde au moins 10 secondes pour la réception de de la - requête, en-têtes inclus. Si le client envoie des données, augmente ce délai - d'une seconde pour chaque paquet de 500 octets reçus, mais - n'alloue que 30 secondes pour la requête, en-têtes inclus : - - 
      RequestReadTimeout header=10-30,MinRate=500
      - -
      4. - -
    4. - En général, un serveur doit avoir ses délais d'en-tête et de - corps configurés. Si les serveurs virtuels http et https - utilisent une configuration commune, les délais ne doivent pas - être définis trop bas : - - 
      RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500
      - -
      5. - -
    -
    -
    top

    Directive RequestReadTimeout

    Description:Set timeout values for receiving request headers and body from client. @@ -169,6 +124,51 @@ version 2.3.14 and earlier.
  • Yüklenebilir Modüllerin Windows için Oluşturulması
    • top
    +

    LoadFile Yönergesi

    +
    Description:Définit des délais maximums pour la réception des en-têtes @@ -179,6 +133,52 @@ Apache ; d + +
    top
    +
    +

    Exemples

    + +
      +
    1. + Accorde 10 secondes pour la réception des en-têtes de la requête + et 30 secondes pour la réception du corps : + + 
      RequestTimeout headerinit=10 body=30
      + +
      2. + +
    2. + Accorde au moins 10 secondes pour la réception du corps de + la requête. Si le client envoie des données, augmente ce délai + d'une seconde pour chaque paquet de 1000 octets reçus, sans + limite supérieure (sauf si une limite a été + spécifiée via la directive LimitRequestBody) : + + 
      RequestReadTimeout body=10,MinRate=1000
      + +
      3. + +
    3. + Accorde au moins 10 secondes pour la réception de de la + requête, en-têtes inclus. Si le client envoie des données, augmente ce délai + d'une seconde pour chaque paquet de 500 octets reçus, mais + n'alloue que 30 secondes pour la requête, en-têtes inclus : + + 
      RequestReadTimeout header=10-30,MinRate=500
      + +
      4. + +
    4. + En général, un serveur doit avoir ses délais d'en-tête et de + corps configurés. Si les serveurs virtuels http et https + utilisent une configuration commune, les délais ne doivent pas + être définis trop bas : + + 
      RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500
      + +
      5. + +
    diff --git a/docs/manual/mod/mod_request.html.en b/docs/manual/mod/mod_request.html.en index 0456c8e7ea7..f416fd51c3c 100644 --- a/docs/manual/mod/mod_request.html.en +++ b/docs/manual/mod/mod_request.html.en @@ -39,7 +39,6 @@
  • KeptBodySize
    • -
    top

    KeptBodySize Directive

    @@ -96,6 +95,7 @@ mod_include.
  • mod_auth_form documentation
    • +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_request.html.fr b/docs/manual/mod/mod_request.html.fr index 4dd7669d749..cf67fb4c068 100644 --- a/docs/manual/mod/mod_request.html.fr +++ b/docs/manual/mod/mod_request.html.fr @@ -40,7 +40,6 @@ les corps de requ

  • KeptBodySize
    • -
    top

    Directive KeptBodySize

    @@ -102,6 +101,7 @@ comme mod_include.
  • la documentation de mod_auth_form
    • +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_request.html.tr.utf8 b/docs/manual/mod/mod_request.html.tr.utf8 index 1dd0f67dc64..88ec27bb800 100644 --- a/docs/manual/mod/mod_request.html.tr.utf8 +++ b/docs/manual/mod/mod_request.html.tr.utf8 @@ -39,7 +39,6 @@

  • KeptBodySize
    • -
    top

    KeptBodySize Yönergesi

    @@ -96,6 +95,7 @@ istek gövdesi iptal edilmek yerine belirtilen azami boyutta tutulur.
  • mod_auth_form belgesi
    • +

    Mevcut Diller:  en  | diff --git a/docs/manual/mod/mod_rewrite.html.en b/docs/manual/mod/mod_rewrite.html.en index e076dee3db6..83fc59430b3 100644 --- a/docs/manual/mod/mod_rewrite.html.en +++ b/docs/manual/mod/mod_rewrite.html.en @@ -68,42 +68,6 @@ URLs on the fly

  • Logging
    • top
    -
    -

    Logging

    - -

    mod_rewrite offers detailed logging of its actions - at the trace1 to trace8 log levels. The - log level can be set specifically for mod_rewrite - using the LogLevel directive: Up to - level debug, no actions are logged, while trace8 - means that practically all actions are logged.

    - -
    - Using a high trace log level for mod_rewrite - will slow down your Apache HTTP Server dramatically! Use a log - level higher than trace2 only for debugging! -
    - -

    Example

    LogLevel alert rewrite:trace3
    -
    - -

    RewriteLog

    -

    Those familiar with earlier versions of - mod_rewrite will no doubt be looking for the - RewriteLog and RewriteLogLevel - directives. This functionality has been completely replaced by the - new per-module logging configuration mentioned above. -

    - -

    To get just the mod_rewrite-specific log - messages, pipe the log file through grep:

    -

    - tail -f error_log|fgrep '[rewrite:' -

    -
    - -
    -
    top

    RewriteBase Directive

    @@ -1457,6 +1421,42 @@ redirection
    Description:Sets the base URL for per-directory rewrites
    +
    +
    top
    +
    +

    Logging

    + +

    mod_rewrite offers detailed logging of its actions + at the trace1 to trace8 log levels. The + log level can be set specifically for mod_rewrite + using the LogLevel directive: Up to + level debug, no actions are logged, while trace8 + means that practically all actions are logged.

    + +
    + Using a high trace log level for mod_rewrite + will slow down your Apache HTTP Server dramatically! Use a log + level higher than trace2 only for debugging! +
    + +

    Example

    LogLevel alert rewrite:trace3
    +
    + +

    RewriteLog

    +

    Those familiar with earlier versions of + mod_rewrite will no doubt be looking for the + RewriteLog and RewriteLogLevel + directives. This functionality has been completely replaced by the + new per-module logging configuration mentioned above. +

    + +

    To get just the mod_rewrite-specific log + messages, pipe the log file through grep:

    +

    + tail -f error_log|fgrep '[rewrite:' +

    +
    +
    diff --git a/docs/manual/mod/mod_rewrite.html.fr b/docs/manual/mod/mod_rewrite.html.fr index 8416eeb3384..0ccb68a5d3e 100644 --- a/docs/manual/mod/mod_rewrite.html.fr +++ b/docs/manual/mod/mod_rewrite.html.fr @@ -77,46 +77,6 @@ r
  • Journalisation
    • top
    -
    -

    Journalisation

    - -

    mod_rewrite offre une journalisation détaillée - de ses actions aux niveaux de journalisation trace1 à - trace8. Le niveau de journalisation peut être défini de - manière spécifique à mod_rewrite via la directive - LogLevel : jusqu'au niveau - debug aucune action n'est journalisée, alors qu'elles - le sont pratiquement toutes au niveau trace8.

    - -
    - L'utilisation d'un niveau de journalisation élevé pour - mod_rewrite va ralentir votre serveur HTTP Apache - de manière dramatique ! N'utilisez un niveau de journalisation - supérieur à trace2 qu'à des fins de débogage ! -
    - -

    Exemple

    LogLevel alert rewrite:trace3
    -
    - -

    RewriteLog

    -

    Ceux qui sont familiers avec les versions précédentes de - mod_rewrite vont probablement rechercher en vain les - directives RewriteLog et - RewriteLogLevel. Elles ont été en effet remplacées - par une configuration de la journalisation par module, comme - mentionné plus haut. -

    - -

    Pour extraire les traces spécifiques à - mod_rewrite, affichez le fichier journal en - redirigeant la sortie vers grep :

    -

    - tail -f error_log|fgrep '[rewrite:' -

    -
    - -
    -
    top

    Directive RewriteBase

    Description:Définit l'URL de base pour les réécritures au niveau @@ -1569,6 +1529,46 @@ externe
    +
    +
    top
    +
    +

    Journalisation

    + +

    mod_rewrite offre une journalisation détaillée + de ses actions aux niveaux de journalisation trace1 à + trace8. Le niveau de journalisation peut être défini de + manière spécifique à mod_rewrite via la directive + LogLevel : jusqu'au niveau + debug aucune action n'est journalisée, alors qu'elles + le sont pratiquement toutes au niveau trace8.

    + +
    + L'utilisation d'un niveau de journalisation élevé pour + mod_rewrite va ralentir votre serveur HTTP Apache + de manière dramatique ! N'utilisez un niveau de journalisation + supérieur à trace2 qu'à des fins de débogage ! +
    + +

    Exemple

    LogLevel alert rewrite:trace3
    +
    + +

    RewriteLog

    +

    Ceux qui sont familiers avec les versions précédentes de + mod_rewrite vont probablement rechercher en vain les + directives RewriteLog et + RewriteLogLevel. Elles ont été en effet remplacées + par une configuration de la journalisation par module, comme + mentionné plus haut. +

    + +

    Pour extraire les traces spécifiques à + mod_rewrite, affichez le fichier journal en + redirigeant la sortie vers grep :

    +

    + tail -f error_log|fgrep '[rewrite:' +

    +
    +
    diff --git a/docs/manual/mod/mod_sed.html.en b/docs/manual/mod/mod_sed.html.en index 2f1380bc0e4..9bc6b313ae7 100644 --- a/docs/manual/mod/mod_sed.html.en +++ b/docs/manual/mod/mod_sed.html.en @@ -73,6 +73,34 @@ the author's blog.

  • Sed Commands
    • top
    +

    InputSed Directive

    + + + + + + +
    Description:Sed command to filter request data (typically POST data)
    Syntax:InputSed sed-command
    Context:directory, .htaccess
    Status:Experimental
    Module:mod_sed
    +

    The InputSed directive specifies the sed command + to execute on the request data e.g., POST data. +

    + +
    +
    top
    +

    OutputSed Directive

    + + + + + + +
    Description:Sed command for filtering response content
    Syntax:OutputSed sed-command
    Context:directory, .htaccess
    Status:Experimental
    Module:mod_sed
    +

    The OutputSed directive specifies the sed + command to execute on the response. +

    + +
    +
    top

    Sample Configuration

    Adding an output filter 

    # In the following example, the sed filter will change the string
@@ -117,34 +145,6 @@ page.
         
    Swap the contents of the hold buffer and the current line.
    -
    top
    -

    InputSed Directive

    - - - - - - -
    Description:Sed command to filter request data (typically POST data)
    Syntax:InputSed sed-command
    Context:directory, .htaccess
    Status:Experimental
    Module:mod_sed
    -

    The InputSed directive specifies the sed command - to execute on the request data e.g., POST data. -

    - -
    -
    top
    -

    OutputSed Directive

    - - - - - - -
    Description:Sed command for filtering response content
    Syntax:OutputSed sed-command
    Context:directory, .htaccess
    Status:Experimental
    Module:mod_sed
    -

    The OutputSed directive specifies the sed - command to execute on the response. -

    - -

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_sed.html.fr b/docs/manual/mod/mod_sed.html.fr index 34494ba9b89..628033a8fb1 100644 --- a/docs/manual/mod/mod_sed.html.fr +++ b/docs/manual/mod/mod_sed.html.fr @@ -83,6 +83,38 @@ recherche/remplacement de cha

  • Commandes sed
    • top
    +

    Directive InputSed

    + + + + + + +
    Description:Commande sed à exécuter pour le filtrage des données d'une +requête (en général des données POST)
    Syntaxe:InputSed commande-sed
    Contexte:répertoire, .htaccess
    Statut:
    Module:mod_sed
    +

    La directive InputSed permet de spécifier + la commande sed à exécuter pour le filtrage des données (en général + des données POST) d'une requête. +

    + +
    +
    top
    +

    Directive OutputSed

    + + + + + + +
    Description:Commande sed pour le filtrage des contenus de type +réponse
    Syntaxe:OutputSed commande-sed
    Contexte:répertoire, .htaccess
    Statut:
    Module:mod_sed
    +

    La directive OutputSed permet de spécifier + la commande sed à exécuter dans le cadre du traitement + d'une réponse. +

    + +
    +
    top

    Exemple de configuration

    Ajout d'un filtre en sortie

    # Dans l'exemple suivant, le filtre sed va remplacer la chaîne
@@ -127,38 +159,6 @@ recherche/remplacement de cha
         
    Echange les contenus du tampon et de la ligne courante.
    -
    top
    -

    Directive InputSed

    - - - - - - -
    Description:Commande sed à exécuter pour le filtrage des données d'une -requête (en général des données POST)
    Syntaxe:InputSed commande-sed
    Contexte:répertoire, .htaccess
    Statut:
    Module:mod_sed
    -

    La directive InputSed permet de spécifier - la commande sed à exécuter pour le filtrage des données (en général - des données POST) d'une requête. -

    - -
    -
    top
    -

    Directive OutputSed

    - - - - - - -
    Description:Commande sed pour le filtrage des contenus de type -réponse
    Syntaxe:OutputSed commande-sed
    Contexte:répertoire, .htaccess
    Statut:
    Module:mod_sed
    -

    La directive OutputSed permet de spécifier - la commande sed à exécuter dans le cadre du traitement - d'une réponse. -

    - -

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_session.html.en b/docs/manual/mod/mod_session.html.en index 09efce48784..9c8214657ac 100644 --- a/docs/manual/mod/mod_session.html.en +++ b/docs/manual/mod/mod_session.html.en @@ -88,6 +88,144 @@

  • mod_session_dbd
    • top
    +

    Session Directive

    + + + + + + + + +
    Description:Enables a session for the current directory or location
    Syntax:Session On|Off
    Default:Session Off
    Context:server config, virtual host, directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_session
    +

    The Session directive enables a session for the + directory or location container. Further directives control where the + session will be stored and how privacy is maintained.

    + +
    +
    top
    +

    SessionEnv Directive

    + + + + + + + + +
    Description:Control whether the contents of the session are written to the +HTTP_SESSION environment variable
    Syntax:SessionEnv On|Off
    Default:SessionEnv Off
    Context:server config, virtual host, directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_session
    +

    If set to On, the SessionEnv directive + causes the contents of the session to be written to a CGI environment + variable called HTTP_SESSION.

    + +

    The string is written in the URL query format, for example:

    + +

    + key1=foo&key3=bar +

    + + +
    +
    top
    +

    SessionExclude Directive

    + + + + + + + +
    Description:Define URL prefixes for which a session is ignored
    Syntax:SessionExclude path
    Default:none
    Context:server config, virtual host, directory, .htaccess
    Status:Extension
    Module:mod_session
    +

    The SessionExclude directive allows sessions to + be disabled relative to URL prefixes only. This can be used to make a + website more efficient, by targeting a more precise URL space for which + a session should be maintained. By default, all URLs within the directory + or location are included in the session. The + SessionExclude directive takes + precedence over the + SessionInclude directive.

    + +

    Warning

    +

    This directive has a similar purpose to the path attribute + in HTTP cookies, but should not be confused with this attribute. This + directive does not set the path attribute, which must be + configured separately.

    + +
    +
    top
    +

    SessionHeader Directive

    + + + + + + + + +
    Description:Import session updates from a given HTTP response header
    Syntax:SessionHeader header
    Default:none
    Context:server config, virtual host, directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_session
    +

    The SessionHeader directive defines the name of an + HTTP response header which, if present, will be parsed and written to the + current session.

    + +

    The header value is expected to be in the URL query format, for example:

    + +

    + key1=foo&key2=&key3=bar +

    + +

    Where a key is set to the empty string, that key will be removed from the + session.

    + + +
    +
    top
    +

    SessionInclude Directive

    + + + + + + + + +
    Description:Define URL prefixes for which a session is valid
    Syntax:SessionInclude path
    Default:all URLs
    Context:server config, virtual host, directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_session
    +

    The SessionInclude directive allows sessions to + be made valid for specific URL prefixes only. This can be used to make a + website more efficient, by targeting a more precise URL space for which + a session should be maintained. By default, all URLs within the directory + or location are included in the session.

    + +

    Warning

    +

    This directive has a similar purpose to the path attribute + in HTTP cookies, but should not be confused with this attribute. This + directive does not set the path attribute, which must be + configured separately.

    + +
    +
    top
    +

    SessionMaxAge Directive

    + + + + + + + + +
    Description:Define a maximum age in seconds for a session
    Syntax:SessionMaxAge maxage
    Default:SessionMaxAge 0
    Context:server config, virtual host, directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_session
    +

    The SessionMaxAge directive defines a time limit + for which a session will remain valid. When a session is saved, this time + limit is reset and an existing session can be continued. If a session + becomes older than this limit without a request to the server to refresh + the session, the session will time out and be removed. Where a session is + used to stored user login details, this has the effect of logging the user + out automatically after the given time.

    + +

    Setting the maxage to zero disables session expiry.

    + +
    +
    top

    What is a session?

    At the core of the session interface is a table of key and value pairs @@ -343,144 +481,6 @@ AuthName realm

    -
    top
    -

    Session Directive

    - - - - - - - - -
    Description:Enables a session for the current directory or location
    Syntax:Session On|Off
    Default:Session Off
    Context:server config, virtual host, directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_session
    -

    The Session directive enables a session for the - directory or location container. Further directives control where the - session will be stored and how privacy is maintained.

    - -
    -
    top
    -

    SessionEnv Directive

    - - - - - - - - -
    Description:Control whether the contents of the session are written to the -HTTP_SESSION environment variable
    Syntax:SessionEnv On|Off
    Default:SessionEnv Off
    Context:server config, virtual host, directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_session
    -

    If set to On, the SessionEnv directive - causes the contents of the session to be written to a CGI environment - variable called HTTP_SESSION.

    - -

    The string is written in the URL query format, for example:

    - -

    - key1=foo&key3=bar -

    - - -
    -
    top
    -

    SessionExclude Directive

    - - - - - - - -
    Description:Define URL prefixes for which a session is ignored
    Syntax:SessionExclude path
    Default:none
    Context:server config, virtual host, directory, .htaccess
    Status:Extension
    Module:mod_session
    -

    The SessionExclude directive allows sessions to - be disabled relative to URL prefixes only. This can be used to make a - website more efficient, by targeting a more precise URL space for which - a session should be maintained. By default, all URLs within the directory - or location are included in the session. The - SessionExclude directive takes - precedence over the - SessionInclude directive.

    - -

    Warning

    -

    This directive has a similar purpose to the path attribute - in HTTP cookies, but should not be confused with this attribute. This - directive does not set the path attribute, which must be - configured separately.

    - -
    -
    top
    -

    SessionHeader Directive

    - - - - - - - - -
    Description:Import session updates from a given HTTP response header
    Syntax:SessionHeader header
    Default:none
    Context:server config, virtual host, directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_session
    -

    The SessionHeader directive defines the name of an - HTTP response header which, if present, will be parsed and written to the - current session.

    - -

    The header value is expected to be in the URL query format, for example:

    - -

    - key1=foo&key2=&key3=bar -

    - -

    Where a key is set to the empty string, that key will be removed from the - session.

    - - -
    -
    top
    -

    SessionInclude Directive

    - - - - - - - - -
    Description:Define URL prefixes for which a session is valid
    Syntax:SessionInclude path
    Default:all URLs
    Context:server config, virtual host, directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_session
    -

    The SessionInclude directive allows sessions to - be made valid for specific URL prefixes only. This can be used to make a - website more efficient, by targeting a more precise URL space for which - a session should be maintained. By default, all URLs within the directory - or location are included in the session.

    - -

    Warning

    -

    This directive has a similar purpose to the path attribute - in HTTP cookies, but should not be confused with this attribute. This - directive does not set the path attribute, which must be - configured separately.

    - -
    -
    top
    -

    SessionMaxAge Directive

    - - - - - - - - -
    Description:Define a maximum age in seconds for a session
    Syntax:SessionMaxAge maxage
    Default:SessionMaxAge 0
    Context:server config, virtual host, directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_session
    -

    The SessionMaxAge directive defines a time limit - for which a session will remain valid. When a session is saved, this time - limit is reset and an existing session can be continued. If a session - becomes older than this limit without a request to the server to refresh - the session, the session will time out and be removed. Where a session is - used to stored user login details, this has the effect of logging the user - out automatically after the given time.

    - -

    Setting the maxage to zero disables session expiry.

    - -

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_session.html.fr b/docs/manual/mod/mod_session.html.fr index 8238103164c..1607a278385 100644 --- a/docs/manual/mod/mod_session.html.fr +++ b/docs/manual/mod/mod_session.html.fr @@ -99,6 +99,158 @@

  • mod_session_dbd
    • top
    +

    Directive Session

    + + + + + + + + +
    Description:Ouvre une session pour le contexte courant
    Syntaxe:Session On|Off
    Défaut:Session Off
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_session
    +

    La directive Session permet d'ouvrir une + session pour le contexte ou conteneur courant. Les directives + suivantes permettent de définir où la session sera stockée et + comment sera assurée la confidentialité.

    + +
    +
    top
    +

    Directive SessionEnv

    + + + + + + + + +
    Description:Définit si le contenu de la session doit être enregistré +dans la variable d'environnement HTTP_SESSION
    Syntaxe:SessionEnv On|Off
    Défaut:SessionEnv Off
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_session
    +

    Lorsque la directive SessionEnv est + définie à On, le contenu de la session est enregistré + dans une variable d'environnement CGI nommée + HTTP_SESSION.

    + +

    La chaîne est écrite sous le même format que celui de la chaîne + d'arguments d'une URL, comme dans l'exemple suivant :

    + +

    + clé1=foo&clé3=bar +

    + + +
    +
    top
    +

    Directive SessionExclude

    + + + + + + + +
    Description:Définit les préfixes d'URLs pour lesquels une session sera +ignorée
    Syntaxe:SessionExclude chemin
    Défaut:none
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    Statut:Extension
    Module:mod_session
    +

    La directive SessionExclude permet de + définir les préfixes d'URLs pour lesquels la session sera + désactivée. Ceci peut améliorer l'efficacité d'un site web, en + ciblant de manière plus précise l'espace d'URL pour lequel une + session devra être maintenue. Par défaut, toutes les URLs du + contexte ou du conteneur courant sont incluses dans la session. La + directive SessionExclude + l'emporte sur la directive SessionInclude.

    + +

    Avertissement

    +

    Cette directive a un comportement similaire à celui de l'attribut + chemin des cookies HTTP, mais ne doit pas être confondue + avec cet attribut. En effet, cette directive ne définit pas + l'attribut chemin, qui doit être configuré + séparément.

    + +
    +
    top
    +

    Directive SessionHeader

    + + + + + + + + +
    Description:Importation des mises à jour de session depuis l'en-tête de +réponse HTTP spécifié
    Syntaxe:SessionHeader en-tête
    Défaut:none
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_session
    +

    La directive SessionHeader permet de + définir le nom d'un en-tête de réponse HTTP qui, s'il est présent, + sera lu et son contenu écrit dans la session courante.

    + +

    Le contenu de l'en-tête doit se présenter sous le même format que + celui de la chaîne d'arguments d'une URL, comme dans l'exemple + suivant :

    + +

    + clé1=foo&clé2=&clé3=bar +

    + +

    Si une clé a pour valeur la chaîne vide, elle sera supprimée de + la session.

    + + +
    +
    top
    +

    Directive SessionInclude

    + + + + + + + + +
    Description:Définit les préfixes d'URL pour lesquels une session est +valide
    Syntaxe:SessionInclude chemin
    Défaut:toutes URLs
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_session
    +

    La directive SessionInclude permet de + définir les préfixes d'URL spécifiques pour lesquels une session + sera valide. Ceci peut améliorer l'efficacité d'un site web, en + ciblant de manière plus précise l'espace d'URL pour lequel une + session devra être maintenue. Par défaut, toutes les URLs du + contexte ou du conteneur courant sont incluses dans la session.

    + +

    Avertissement

    +

    Cette directive a un comportement similaire à celui de l'attribut + chemin des cookies HTTP, mais ne doit pas être confondue + avec cet attribut. En effet, cette directive ne définit pas + l'attribut chemin, qui doit être configuré séparément.

    + +
    +
    top
    +

    Directive SessionMaxAge

    + + + + + + + + +
    Description:Définit une durée de vie maximale pour la session en +secondes
    Syntaxe:SessionMaxAge durée de vie maximale
    Défaut:SessionMaxAge 0
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_session
    +

    La directive SessionMaxAge permet de + définir la durée maximale pendant laquelle une session restera + valide. Lorsqu'une session est sauvegardée, cette durée est + réinitialisée et la session peut continuer d'exister. Si la durée + d'une session dépasse cette limite sans qu'une requête au serveur ne + vienne la rafraîchir, la session va passer hors délai et sera + supprimée. Lorsqu'une session est utilisée pour stocker les + informations de connexion d'un utilisateur, ceci aura pour effet de + le déconnecter automatiquement après le délai spécifié.

    + +

    Donner à cette directive la valeur 0 empêche l'expiration de la + session.

    + +
    +
    top

    Qu'est-ce qu'une session ?

    Au coeur de l'interface de session se trouve une table de @@ -395,158 +547,6 @@ AuthName realm

    -
    top
    -

    Directive Session

    - - - - - - - - -
    Description:Ouvre une session pour le contexte courant
    Syntaxe:Session On|Off
    Défaut:Session Off
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_session
    -

    La directive Session permet d'ouvrir une - session pour le contexte ou conteneur courant. Les directives - suivantes permettent de définir où la session sera stockée et - comment sera assurée la confidentialité.

    - -
    -
    top
    -

    Directive SessionEnv

    - - - - - - - - -
    Description:Définit si le contenu de la session doit être enregistré -dans la variable d'environnement HTTP_SESSION
    Syntaxe:SessionEnv On|Off
    Défaut:SessionEnv Off
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_session
    -

    Lorsque la directive SessionEnv est - définie à On, le contenu de la session est enregistré - dans une variable d'environnement CGI nommée - HTTP_SESSION.

    - -

    La chaîne est écrite sous le même format que celui de la chaîne - d'arguments d'une URL, comme dans l'exemple suivant :

    - -

    - clé1=foo&clé3=bar -

    - - -
    -
    top
    -

    Directive SessionExclude

    - - - - - - - -
    Description:Définit les préfixes d'URLs pour lesquels une session sera -ignorée
    Syntaxe:SessionExclude chemin
    Défaut:none
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    Statut:Extension
    Module:mod_session
    -

    La directive SessionExclude permet de - définir les préfixes d'URLs pour lesquels la session sera - désactivée. Ceci peut améliorer l'efficacité d'un site web, en - ciblant de manière plus précise l'espace d'URL pour lequel une - session devra être maintenue. Par défaut, toutes les URLs du - contexte ou du conteneur courant sont incluses dans la session. La - directive SessionExclude - l'emporte sur la directive SessionInclude.

    - -

    Avertissement

    -

    Cette directive a un comportement similaire à celui de l'attribut - chemin des cookies HTTP, mais ne doit pas être confondue - avec cet attribut. En effet, cette directive ne définit pas - l'attribut chemin, qui doit être configuré - séparément.

    - -
    -
    top
    -

    Directive SessionHeader

    - - - - - - - - -
    Description:Importation des mises à jour de session depuis l'en-tête de -réponse HTTP spécifié
    Syntaxe:SessionHeader en-tête
    Défaut:none
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_session
    -

    La directive SessionHeader permet de - définir le nom d'un en-tête de réponse HTTP qui, s'il est présent, - sera lu et son contenu écrit dans la session courante.

    - -

    Le contenu de l'en-tête doit se présenter sous le même format que - celui de la chaîne d'arguments d'une URL, comme dans l'exemple - suivant :

    - -

    - clé1=foo&clé2=&clé3=bar -

    - -

    Si une clé a pour valeur la chaîne vide, elle sera supprimée de - la session.

    - - -
    -
    top
    -

    Directive SessionInclude

    - - - - - - - - -
    Description:Définit les préfixes d'URL pour lesquels une session est -valide
    Syntaxe:SessionInclude chemin
    Défaut:toutes URLs
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_session
    -

    La directive SessionInclude permet de - définir les préfixes d'URL spécifiques pour lesquels une session - sera valide. Ceci peut améliorer l'efficacité d'un site web, en - ciblant de manière plus précise l'espace d'URL pour lequel une - session devra être maintenue. Par défaut, toutes les URLs du - contexte ou du conteneur courant sont incluses dans la session.

    - -

    Avertissement

    -

    Cette directive a un comportement similaire à celui de l'attribut - chemin des cookies HTTP, mais ne doit pas être confondue - avec cet attribut. En effet, cette directive ne définit pas - l'attribut chemin, qui doit être configuré séparément.

    - -
    -
    top
    -

    Directive SessionMaxAge

    - - - - - - - - -
    Description:Définit une durée de vie maximale pour la session en -secondes
    Syntaxe:SessionMaxAge durée de vie maximale
    Défaut:SessionMaxAge 0
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_session
    -

    La directive SessionMaxAge permet de - définir la durée maximale pendant laquelle une session restera - valide. Lorsqu'une session est sauvegardée, cette durée est - réinitialisée et la session peut continuer d'exister. Si la durée - d'une session dépasse cette limite sans qu'une requête au serveur ne - vienne la rafraîchir, la session va passer hors délai et sera - supprimée. Lorsqu'une session est utilisée pour stocker les - informations de connexion d'un utilisateur, ceci aura pour effet de - le déconnecter automatiquement après le délai spécifié.

    - -

    Donner à cette directive la valeur 0 empêche l'expiration de la - session.

    - -

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_session_cookie.html.en b/docs/manual/mod/mod_session_cookie.html.en index 1b7f91ce0e0..b638bff330f 100644 --- a/docs/manual/mod/mod_session_cookie.html.en +++ b/docs/manual/mod/mod_session_cookie.html.en @@ -74,25 +74,6 @@

  • mod_session_dbd
    • top
    -
    -

    Basic Examples

    - -

    To create a simple session and store it in a cookie called - session, configure the session as follows:

    - -

    Browser based session

    Session On
-SessionCookieName session path=/
    -
    - -

    For more examples on how the session can be configured to be read - from and written to by a CGI application, see the - mod_session examples section.

    - -

    For documentation on how the session can be used to store username - and password details, see the mod_auth_form module.

    - -
    -
    top

    SessionCookieName Directive

    @@ -164,6 +145,25 @@ SessionCookieName2 session path=/private;domain=example.com;httponly;secure;vers +
    top
    +
    +

    Basic Examples

    + +

    To create a simple session and store it in a cookie called + session, configure the session as follows:

    + +

    Browser based session

    Session On
+SessionCookieName session path=/
    +
    + +

    For more examples on how the session can be configured to be read + from and written to by a CGI application, see the + mod_session examples section.

    + +

    For documentation on how the session can be used to store username + and password details, see the mod_auth_form module.

    + +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_session_cookie.html.fr b/docs/manual/mod/mod_session_cookie.html.fr index 7347fd700c0..a8ab01406b5 100644 --- a/docs/manual/mod/mod_session_cookie.html.fr +++ b/docs/manual/mod/mod_session_cookie.html.fr @@ -79,28 +79,6 @@

  • mod_session_dbd
    • top
    -
    -

    Exemples simples

    - -

    Pour créer une session et la stocker dans un cookie nommé - session, configurez-la comme suit :

    - -

    Session stockée au niveau du navigateur

    Session On
-SessionCookieName session path=/
    -
    - -

    Pour plus d'exemples sur la manière dont une session doit être - configurée pour qu'une application CGI puisse l'utiliser, voir la - section exemples de la documentation du module - mod_session.

    - -

    Pour des détails sur la manière dont une session peut être - utilisée pour stocker des informations de type nom - d'utilisateur/mot de passe, voir la documentation du module - mod_auth_form.

    - -
    -
    top

    Directive SessionCookieName

    Description:Name and attributes for the RFC2109 cookie storing the session
    Description:Nom et attributs du cookie RFC2109 dans lequel la session @@ -184,6 +162,28 @@ des en-t +
    top
    +
    +

    Exemples simples

    + +

    Pour créer une session et la stocker dans un cookie nommé + session, configurez-la comme suit :

    + +

    Session stockée au niveau du navigateur

    Session On
+SessionCookieName session path=/
    +
    + +

    Pour plus d'exemples sur la manière dont une session doit être + configurée pour qu'une application CGI puisse l'utiliser, voir la + section exemples de la documentation du module + mod_session.

    + +

    Pour des détails sur la manière dont une session peut être + utilisée pour stocker des informations de type nom + d'utilisateur/mot de passe, voir la documentation du module + mod_auth_form.

    + +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_session_crypto.html.en b/docs/manual/mod/mod_session_crypto.html.en index c6433029c8b..2f46202e3c8 100644 --- a/docs/manual/mod/mod_session_crypto.html.en +++ b/docs/manual/mod/mod_session_crypto.html.en @@ -71,29 +71,6 @@

  • mod_session_dbd
    • top
    -
    -

    Basic Usage

    - -

    To create a simple encrypted session and store it in a cookie called - session, configure the session as follows:

    - -

    Browser based encrypted session

    Session On
-SessionCookieName session path=/
-SessionCryptoPassphrase secret
    -
    - -

    The session will be encrypted with the given key. Different servers can - be configured to share sessions by ensuring the same encryption key is used - on each server.

    - -

    If the encryption key is changed, sessions will be invalidated - automatically.

    - -

    For documentation on how the session can be used to store username - and password details, see the mod_auth_form module.

    - -
    -
    top

    SessionCryptoCipher Directive

    @@ -232,6 +209,29 @@ SessionCryptoPassphrase "exec:/path/to/otherProgram argument1" +
    top
    +
    +

    Basic Usage

    + +

    To create a simple encrypted session and store it in a cookie called + session, configure the session as follows:

    + +

    Browser based encrypted session

    Session On
+SessionCookieName session path=/
+SessionCryptoPassphrase secret
    +
    + +

    The session will be encrypted with the given key. Different servers can + be configured to share sessions by ensuring the same encryption key is used + on each server.

    + +

    If the encryption key is changed, sessions will be invalidated + automatically.

    + +

    For documentation on how the session can be used to store username + and password details, see the mod_auth_form module.

    + +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_session_crypto.html.fr b/docs/manual/mod/mod_session_crypto.html.fr index a434091c149..312c2f17dbf 100644 --- a/docs/manual/mod/mod_session_crypto.html.fr +++ b/docs/manual/mod/mod_session_crypto.html.fr @@ -74,33 +74,6 @@

  • mod_session_dbd
    • top
    -
    -

    Utilisation de base

    - -

    Pour créer une session chiffrée et la stocker dans un cookie - nommé session, configurez la comme suit :

    - -

    Session chiffrée stockée au niveau du - serveur

    Session On
-SessionCookieName session path=/
-SessionCryptoPassphrase secret
    -
    - -

    La session sera chiffrée avec la clé spécifiée. Il est possible - de configurer plusieurs serveurs pour qu'ils puissent partager des - sessions, en s'assurant que la même clé de chiffrement est - utilisée sur chaque serveur.

    - -

    Si la clé de chiffrement est modifiée, les sessions seront - automatiquement invalidées.

    - -

    Pour des détails sur la manière dont une session peut être - utilisée pour stocker des informations de type nom - d'utilisateur/mot de passe, voir la documentation du module - mod_auth_form.

    - -
    -
    top

    Directive SessionCryptoCipher

    Description:The crypto cipher to be used to encrypt the session
    @@ -258,6 +231,33 @@ session +
    top
    +
    +

    Utilisation de base

    + +

    Pour créer une session chiffrée et la stocker dans un cookie + nommé session, configurez la comme suit :

    + +

    Session chiffrée stockée au niveau du + serveur

    Session On
+SessionCookieName session path=/
+SessionCryptoPassphrase secret
    +
    + +

    La session sera chiffrée avec la clé spécifiée. Il est possible + de configurer plusieurs serveurs pour qu'ils puissent partager des + sessions, en s'assurant que la même clé de chiffrement est + utilisée sur chaque serveur.

    + +

    Si la clé de chiffrement est modifiée, les sessions seront + automatiquement invalidées.

    + +

    Pour des détails sur la manière dont une session peut être + utilisée pour stocker des informations de type nom + d'utilisateur/mot de passe, voir la documentation du module + mod_auth_form.

    + +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_session_dbd.html.en b/docs/manual/mod/mod_session_dbd.html.en index 95db6db97e0..423112a0497 100644 --- a/docs/manual/mod/mod_session_dbd.html.en +++ b/docs/manual/mod/mod_session_dbd.html.en @@ -86,86 +86,6 @@

  • mod_dbd
    • top
    -
    -

    DBD Configuration

    - -

    Before the mod_session_dbd module can be configured to maintain a - session, the mod_dbd module must be configured to make the various database queries - available to the server.

    - -

    There are four queries required to keep a session maintained, to select an existing session, - to update an existing session, to insert a new session, and to delete an expired or empty - session. These queries are configured as per the example below.

    - -

    Sample DBD configuration

    DBDriver pgsql
-DBDParams "dbname=apachesession user=apache password=xxxxx host=localhost"
-DBDPrepareSQL "delete from session where key = %s" deletesession
-DBDPrepareSQL "update session set value = %s, expiry = %lld, key = %s where key = %s" updatesession
-DBDPrepareSQL "insert into session (value, expiry, key) values (%s, %lld, %s)" insertsession
-DBDPrepareSQL "select value from session where key = %s and (expiry = 0 or expiry > %lld)" selectsession
-DBDPrepareSQL "delete from session where expiry != 0 and expiry < %lld" cleansession
    -
    - -
    top
    -
    -

    Anonymous Sessions

    - -

    Anonymous sessions are keyed against a unique UUID, and stored on the - browser within an HTTP cookie. This method is similar to that used by most - application servers to store session information.

    - -

    To create a simple anonymous session and store it in a postgres database - table called apachesession, and save the session ID in a cookie - called session, configure the session as follows:

    - -

    SQL based anonymous session

    Session On
-SessionDBDCookieName session path=/
    -
    - -

    For more examples on how the session can be configured to be read - from and written to by a CGI application, see the - mod_session examples section.

    - -

    For documentation on how the session can be used to store username - and password details, see the mod_auth_form module.

    - -
    top
    -
    -

    Per User Sessions

    - -

    Per user sessions are keyed against the username of a successfully - authenticated user. It offers the most privacy, as no external handle - to the session exists outside of the authenticated realm.

    - -

    Per user sessions work within a correctly configured authenticated - environment, be that using basic authentication, digest authentication - or SSL client certificates. Due to the limitations of who came first, - the chicken or the egg, per user sessions cannot be used to store - authentication credentials from a module like - mod_auth_form.

    - -

    To create a simple per user session and store it in a postgres database - table called apachesession, and with the session keyed to the - userid, configure the session as follows:

    - -

    SQL based per user session

    Session On
-SessionDBDPerUser On
    -
    - -
    top
    -
    -

    Database Housekeeping

    -

    Over the course of time, the database can be expected to start accumulating - expired sessions. At this point, the mod_session_dbd module - is not yet able to handle session expiry automatically.

    - -

    Warning

    -

    The administrator will need to set up an external process via cron to clean - out expired sessions.

    -
    - -
    -
    top

    SessionDBDCookieName Directive

    Description:L'algorithme à utiliser pour le chiffrement de la session
    @@ -324,6 +244,86 @@ SessionDBDCookieName2 session path=/private;domain=example.com;httponly;secure;v +
    top
    +
    +

    DBD Configuration

    + +

    Before the mod_session_dbd module can be configured to maintain a + session, the mod_dbd module must be configured to make the various database queries + available to the server.

    + +

    There are four queries required to keep a session maintained, to select an existing session, + to update an existing session, to insert a new session, and to delete an expired or empty + session. These queries are configured as per the example below.

    + +

    Sample DBD configuration

    DBDriver pgsql
+DBDParams "dbname=apachesession user=apache password=xxxxx host=localhost"
+DBDPrepareSQL "delete from session where key = %s" deletesession
+DBDPrepareSQL "update session set value = %s, expiry = %lld, key = %s where key = %s" updatesession
+DBDPrepareSQL "insert into session (value, expiry, key) values (%s, %lld, %s)" insertsession
+DBDPrepareSQL "select value from session where key = %s and (expiry = 0 or expiry > %lld)" selectsession
+DBDPrepareSQL "delete from session where expiry != 0 and expiry < %lld" cleansession
    +
    + +
    top
    +
    +

    Anonymous Sessions

    + +

    Anonymous sessions are keyed against a unique UUID, and stored on the + browser within an HTTP cookie. This method is similar to that used by most + application servers to store session information.

    + +

    To create a simple anonymous session and store it in a postgres database + table called apachesession, and save the session ID in a cookie + called session, configure the session as follows:

    + +

    SQL based anonymous session

    Session On
+SessionDBDCookieName session path=/
    +
    + +

    For more examples on how the session can be configured to be read + from and written to by a CGI application, see the + mod_session examples section.

    + +

    For documentation on how the session can be used to store username + and password details, see the mod_auth_form module.

    + +
    top
    +
    +

    Per User Sessions

    + +

    Per user sessions are keyed against the username of a successfully + authenticated user. It offers the most privacy, as no external handle + to the session exists outside of the authenticated realm.

    + +

    Per user sessions work within a correctly configured authenticated + environment, be that using basic authentication, digest authentication + or SSL client certificates. Due to the limitations of who came first, + the chicken or the egg, per user sessions cannot be used to store + authentication credentials from a module like + mod_auth_form.

    + +

    To create a simple per user session and store it in a postgres database + table called apachesession, and with the session keyed to the + userid, configure the session as follows:

    + +

    SQL based per user session

    Session On
+SessionDBDPerUser On
    +
    + +
    top
    +
    +

    Database Housekeeping

    +

    Over the course of time, the database can be expected to start accumulating + expired sessions. At this point, the mod_session_dbd module + is not yet able to handle session expiry automatically.

    + +

    Warning

    +

    The administrator will need to set up an external process via cron to clean + out expired sessions.

    +
    + +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_session_dbd.html.fr b/docs/manual/mod/mod_session_dbd.html.fr index 2d41ba3e750..5bec52e6ec4 100644 --- a/docs/manual/mod/mod_session_dbd.html.fr +++ b/docs/manual/mod/mod_session_dbd.html.fr @@ -92,101 +92,6 @@

  • mod_dbd
    • top
    -
    -

    Configuration de DBD

    - -

    Pour que le module mod_session_dbd puisse être - configuré et maintenir une session, il faut tout d'abord - configurer le module mod_dbd pour que le serveur - puisse exécuter des requêtes vers la base de données.

    - -

    Quatre types de requêtes sont nécessaires pour maintenir une - session, sélectionner ou mettre à jour une session existante, - insérer une nouvelle session et supprimer une session vide ou - arrivée à expiration. Ces requêtes sont configurées comme dans - l'exemple suivant :

    - -

    Exemple de configuration de DBD

    DBDriver pgsql
-DBDParams "dbname=apachesession user=apache password=xxxxx host=localhost"
-DBDPrepareSQL "delete from session where key = %s" deletesession
-DBDPrepareSQL "update session set value = %s, expiry = %lld, key = %s where key = %s" updatesession
-DBDPrepareSQL "insert into session (value, expiry, key) values (%s, %lld, %s)" insertsession
-DBDPrepareSQL "select value from session where key = %s and (expiry = 0 or expiry > %lld)" selectsession
-DBDPrepareSQL "delete from session where expiry != 0 and expiry < %lld" cleansession
    -
    - -
    top
    -
    -

    Sessions anonymes

    - -

    Les sessions anonymes sont identifiées par un UUID unique, et - stockées dans un cookie au niveau du navigateur. Cette méthode est - similaire à celle utilisée par la plupart des serveurs - d'applications pour stocker les informations de session.

    - -

    Pour créer une session anonyme, la stocker dans une table de - base de donnée postgres nommée apachesession, et - sauvegarder l'identifiant de session dans un cookie nommé - session, configurez la session comme suit :

    - -

    Session anonyme basée sur SQL

    Session On
-SessionDBDCookieName session path=/
    -
    - -

    Pour plus d'exemples sur la manière dont une application CGI - peut accéder aux informations de session, voir la section exemples - de la documentation du module mod_session.

    - -

    Pour des détails sur la manière dont une session peut être - utilisée pour stocker des informations de type nom - d'utilisateur/mot de passe, voir la documentation du module - mod_auth_form.

    - -
    top
    -
    -

    Sessions propres à un - utilisateur

    - -

    Les sessions propres à un utilisateur sont identifiées par le - nom de l'utilisateur authentifié avec succès. Ceci permet - d'assurer une confidentialité optimale, car aucun traitement - externe à la session n'existe en dehors du contexte - authentifié.

    - -

    Les sessions propres à un utilisateur ne fonctionnent que dans - un environnement d'authentification correctement configuré, qu'il - s'agisse d'une authentification de base, à base de condensés - (digest) ou de certificats client SSL. Suite à des limitations - dues à des dépendances mutuelles, les sessions propres à un - utilisateur ne peuvent pas être utilisées pour stocker les données - d'authentification en provenance d'un module comme - mod_auth_form.

    - -

    Pour créer une session propre à un utilisateur, la stocker dans - une table de base de données postgres nommée - apachesession, avec comme clé de session l'identifiant - utilisateur, ajoutez les lignes suivantes :

    - -

    Session propre à un utilisateur basée sur SQL

    Session On
-SessionDBDPerUser On
    -
    - -
    top
    -
    -

    Nettoyage de la base de - données

    -

    Avec le temps, la base de données va commencer à accumuler des - sessions expirées. Pour le moment, le module - mod_session_dbd n'est pas en mesure de gérer - automatiquement l'expiration des sessions.

    - -

    Avertissement

    -

    L'administrateur devra mettre en oeuvre un traitement externe - via cron pour nettoyer les sessions expirées.

    -
    - -
    -
    top

    Directive SessionDBDCookieName

    Description:Name and attributes for the RFC2109 cookie storing the session ID
    Description:Nom et attributs du cookie RFC2109 qui contient @@ -374,6 +279,101 @@ pr +
    top
    +
    +

    Configuration de DBD

    + +

    Pour que le module mod_session_dbd puisse être + configuré et maintenir une session, il faut tout d'abord + configurer le module mod_dbd pour que le serveur + puisse exécuter des requêtes vers la base de données.

    + +

    Quatre types de requêtes sont nécessaires pour maintenir une + session, sélectionner ou mettre à jour une session existante, + insérer une nouvelle session et supprimer une session vide ou + arrivée à expiration. Ces requêtes sont configurées comme dans + l'exemple suivant :

    + +

    Exemple de configuration de DBD

    DBDriver pgsql
+DBDParams "dbname=apachesession user=apache password=xxxxx host=localhost"
+DBDPrepareSQL "delete from session where key = %s" deletesession
+DBDPrepareSQL "update session set value = %s, expiry = %lld, key = %s where key = %s" updatesession
+DBDPrepareSQL "insert into session (value, expiry, key) values (%s, %lld, %s)" insertsession
+DBDPrepareSQL "select value from session where key = %s and (expiry = 0 or expiry > %lld)" selectsession
+DBDPrepareSQL "delete from session where expiry != 0 and expiry < %lld" cleansession
    +
    + +
    top
    +
    +

    Sessions anonymes

    + +

    Les sessions anonymes sont identifiées par un UUID unique, et + stockées dans un cookie au niveau du navigateur. Cette méthode est + similaire à celle utilisée par la plupart des serveurs + d'applications pour stocker les informations de session.

    + +

    Pour créer une session anonyme, la stocker dans une table de + base de donnée postgres nommée apachesession, et + sauvegarder l'identifiant de session dans un cookie nommé + session, configurez la session comme suit :

    + +

    Session anonyme basée sur SQL

    Session On
+SessionDBDCookieName session path=/
    +
    + +

    Pour plus d'exemples sur la manière dont une application CGI + peut accéder aux informations de session, voir la section exemples + de la documentation du module mod_session.

    + +

    Pour des détails sur la manière dont une session peut être + utilisée pour stocker des informations de type nom + d'utilisateur/mot de passe, voir la documentation du module + mod_auth_form.

    + +
    top
    +
    +

    Sessions propres à un + utilisateur

    + +

    Les sessions propres à un utilisateur sont identifiées par le + nom de l'utilisateur authentifié avec succès. Ceci permet + d'assurer une confidentialité optimale, car aucun traitement + externe à la session n'existe en dehors du contexte + authentifié.

    + +

    Les sessions propres à un utilisateur ne fonctionnent que dans + un environnement d'authentification correctement configuré, qu'il + s'agisse d'une authentification de base, à base de condensés + (digest) ou de certificats client SSL. Suite à des limitations + dues à des dépendances mutuelles, les sessions propres à un + utilisateur ne peuvent pas être utilisées pour stocker les données + d'authentification en provenance d'un module comme + mod_auth_form.

    + +

    Pour créer une session propre à un utilisateur, la stocker dans + une table de base de données postgres nommée + apachesession, avec comme clé de session l'identifiant + utilisateur, ajoutez les lignes suivantes :

    + +

    Session propre à un utilisateur basée sur SQL

    Session On
+SessionDBDPerUser On
    +
    + +
    top
    +
    +

    Nettoyage de la base de + données

    +

    Avec le temps, la base de données va commencer à accumuler des + sessions expirées. Pour le moment, le module + mod_session_dbd n'est pas en mesure de gérer + automatiquement l'expiration des sessions.

    + +

    Avertissement

    +

    L'administrateur devra mettre en oeuvre un traitement externe + via cron pour nettoyer les sessions expirées.

    +
    + +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_setenvif.html.en b/docs/manual/mod/mod_setenvif.html.en index db944390a3e..01391ea269f 100644 --- a/docs/manual/mod/mod_setenvif.html.en +++ b/docs/manual/mod/mod_setenvif.html.en @@ -77,7 +77,6 @@ BrowserMatch MSIE !netscape

    -
    top

    BrowserMatch Directive

    @@ -322,6 +321,7 @@ without respect to case combination.

    +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_setenvif.html.fr b/docs/manual/mod/mod_setenvif.html.fr index bbb84ac53f2..ff11ea31642 100644 --- a/docs/manual/mod/mod_setenvif.html.fr +++ b/docs/manual/mod/mod_setenvif.html.fr @@ -79,7 +79,6 @@ BrowserMatch MSIE !netscape

  • Les variables d'environnement et le serveur HTTP Apache
    • -
    top

    Directive BrowserMatch

    @@ -335,6 +334,7 @@ attributs de la requ combinaison des mêmes caractères, sans tenir compte de la casse.

    +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_setenvif.html.ja.utf8 b/docs/manual/mod/mod_setenvif.html.ja.utf8 index 3b4068100f3..3bf84aa831a 100644 --- a/docs/manual/mod/mod_setenvif.html.ja.utf8 +++ b/docs/manual/mod/mod_setenvif.html.ja.utf8 @@ -69,7 +69,6 @@

    -
    top

    BrowserMatch ディレクティブ

    @@ -304,6 +303,7 @@ +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_setenvif.html.ko.euc-kr b/docs/manual/mod/mod_setenvif.html.ko.euc-kr index d5f219a4815..5f430ca0499 100644 --- a/docs/manual/mod/mod_setenvif.html.ko.euc-kr +++ b/docs/manual/mod/mod_setenvif.html.ko.euc-kr @@ -64,7 +64,6 @@

    -
    top

    BrowserMatch Áö½Ã¾î

    @@ -261,6 +260,7 @@ site ȯ°æº¯¼ö¸¦ "apache"·Î ¼³Á¤ÇÑ´Ù.

    +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_setenvif.html.tr.utf8 b/docs/manual/mod/mod_setenvif.html.tr.utf8 index 052ad485fb0..7632b20bb8b 100644 --- a/docs/manual/mod/mod_setenvif.html.tr.utf8 +++ b/docs/manual/mod/mod_setenvif.html.tr.utf8 @@ -75,7 +75,6 @@ BrowserMatch MSIE !netscape

    -
    top

    BrowserMatch Yönergesi

    @@ -309,6 +308,7 @@ bağlı olmaksızın yapılmış tanımlara göre atar. "example" değeri atanmaktadır.

    +

    Mevcut Diller:  en  | diff --git a/docs/manual/mod/mod_so.html.en b/docs/manual/mod/mod_so.html.en index 0f81198bf16..9c2db2cf164 100644 --- a/docs/manual/mod/mod_so.html.en +++ b/docs/manual/mod/mod_so.html.en @@ -67,6 +67,53 @@ Windows

  • Creating Loadable Modules for Windows
    • top
    +

    LoadFile Directive

    + + + + + + +
    Description:Link in the named object file or library
    Syntax:LoadFile filename [filename] ...
    Context:server config, virtual host
    Status:Extension
    Module:mod_so
    + +

    The LoadFile directive links in the named object files or + libraries when the server is started or restarted; this is used + to load additional code which may be required for some module + to work. Filename is either an absolute path or + relative to ServerRoot.

    + +

    For example:

    + + 
    LoadFile libexec/libxmlparse.so
    + + + +
    +
    top
    +

    LoadModule Directive

    + + + + + + +
    Description:Links in the object file or library, and adds to the list +of active modules
    Syntax:LoadModule module filename
    Context:server config, virtual host
    Status:Extension
    Module:mod_so
    +

    The LoadModule directive links in the object file or library + filename and adds the module structure named + module to the list of active modules. Module + is the name of the external variable of type + module in the file, and is listed as the Module Identifier + in the module documentation. Example:

    + + 
    LoadModule status_module modules/mod_status.so
    + + +

    loads the named module from the modules subdirectory of the + ServerRoot.

    + +
    +
    top

    Creating Loadable Modules for Windows

    @@ -140,53 +187,6 @@ Windows
    root, and use the LoadModule directive to load it.

    -
    -
    top
    -

    LoadFile Directive

    - - - - - - -
    Description:Link in the named object file or library
    Syntax:LoadFile filename [filename] ...
    Context:server config, virtual host
    Status:Extension
    Module:mod_so
    - -

    The LoadFile directive links in the named object files or - libraries when the server is started or restarted; this is used - to load additional code which may be required for some module - to work. Filename is either an absolute path or - relative to ServerRoot.

    - -

    For example:

    - - 
    LoadFile libexec/libxmlparse.so
    - - - -
    -
    top
    -

    LoadModule Directive

    - - - - - - -
    Description:Links in the object file or library, and adds to the list -of active modules
    Syntax:LoadModule module filename
    Context:server config, virtual host
    Status:Extension
    Module:mod_so
    -

    The LoadModule directive links in the object file or library - filename and adds the module structure named - module to the list of active modules. Module - is the name of the external variable of type - module in the file, and is listed as the Module Identifier - in the module documentation. Example:

    - - 
    LoadModule status_module modules/mod_status.so
    - - -

    loads the named module from the modules subdirectory of the - ServerRoot.

    -
    diff --git a/docs/manual/mod/mod_so.html.fr b/docs/manual/mod/mod_so.html.fr index 545b6c3cc8d..92e5d282bcc 100644 --- a/docs/manual/mod/mod_so.html.fr +++ b/docs/manual/mod/mod_so.html.fr @@ -71,6 +71,56 @@ inclus)
    Windows
    top
    +

    Directive LoadFile

    + + + + + + +
    Description:Liaison du fichier objet ou de la bibliothèque +spécifié
    Syntaxe:LoadFile nom-fichier [nom-fichier] ...
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_so
    + +

    La directive LoadFile permet de lier le fichier objet ou la + bibliothèque spécifié au serveur lors du démarrage ou du redémarrage + de ce dernier ; ceci permet d'ajouter tout code additionnel + nécessaire au fonctionnement d'un module. + nom-fichier est soit un chemin absolu, soit un chemin + relatif au répertoire défini par la directive ServerRoot.

    + +

    Par exemple:

    + + 
    LoadFile libexec/libxmlparse.so
    + + + +
    +
    top
    +

    Directive LoadModule

    + + + + + + +
    Description:Liaison avec le serveur du fichier objet ou de la +bibliothèque spécifié, et ajout de ce dernier à la liste des modules +actifs
    Syntaxe:LoadModule module nom-fichier
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_so
    +

    La directive LoadModule permet de lier le fichier objet ou la + bibliothèque nom-fichier avec le serveur, et d'ajouter la + structure de module nommée module à la liste des modules + actifs. module est le nom de la variable externe de type + module dans le fichier, et est référencé comme Identificateur de + module dans la documentation des modules. Exemple :

    + + 
    LoadModule status_module modules/mod_status.so
    + + +

    charge le module spécifié depuis le sous-répertoire des modules + situé à la racine du serveur.

    + +
    +
    top

    Création de modules chargeables pour Windows

    @@ -152,56 +202,6 @@ Windows modules à la racine de votre serveur, et d'utiliser la directive LoadModule pour la charger.

    -
    -
    top
    -

    Directive LoadFile

    - - - - - - -
    Description:Liaison du fichier objet ou de la bibliothèque -spécifié
    Syntaxe:LoadFile nom-fichier [nom-fichier] ...
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_so
    - -

    La directive LoadFile permet de lier le fichier objet ou la - bibliothèque spécifié au serveur lors du démarrage ou du redémarrage - de ce dernier ; ceci permet d'ajouter tout code additionnel - nécessaire au fonctionnement d'un module. - nom-fichier est soit un chemin absolu, soit un chemin - relatif au répertoire défini par la directive ServerRoot.

    - -

    Par exemple:

    - - 
    LoadFile libexec/libxmlparse.so
    - - - -
    -
    top
    -

    Directive LoadModule

    - - - - - - -
    Description:Liaison avec le serveur du fichier objet ou de la -bibliothèque spécifié, et ajout de ce dernier à la liste des modules -actifs
    Syntaxe:LoadModule module nom-fichier
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_so
    -

    La directive LoadModule permet de lier le fichier objet ou la - bibliothèque nom-fichier avec le serveur, et d'ajouter la - structure de module nommée module à la liste des modules - actifs. module est le nom de la variable externe de type - module dans le fichier, et est référencé comme Identificateur de - module dans la documentation des modules. Exemple :

    - - 
    LoadModule status_module modules/mod_status.so
    - - -

    charge le module spécifié depuis le sous-répertoire des modules - situé à la racine du serveur.

    -
    diff --git a/docs/manual/mod/mod_so.html.ja.utf8 b/docs/manual/mod/mod_so.html.ja.utf8 index 5f773e52766..406fcbcb0b4 100644 --- a/docs/manual/mod/mod_so.html.ja.utf8 +++ b/docs/manual/mod/mod_so.html.ja.utf8 @@ -68,6 +68,53 @@
  • Windows 用のロード可能なモジュールを作成する
    • top
    +

    LoadFile ディレクティブ

    + + + + + + +
    説明:指定されたオブジェクトファイルやライブラリをリンクする
    構文:LoadFile filename [filename] ...
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Extension
    モジュール:mod_so
    + +

    LoadFile ディレクティブは、サーバが起動されたときや再起動されたときに、 + 指定されたオブジェクトファイルやライブラリをリンクします。 + これはモジュールが動作するために必要になるかもしれない追加の + コードを読み込むために使用されます。Filename は絶対パスか、ServerRoot からの相対パスです。

    + +

    例:

    + + 
    LoadFile libexec/libxmlparse.so
    + + + +
    +
    top
    +

    LoadModule ディレクティブ

    + + + + + + +
    説明:オブジェクトファイルやライブラリをリンクし、使用モジュールの +リストに追加する
    構文:LoadModule module filename
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Extension
    モジュール:mod_so
    + +

    LoadModule ディレクティブは filename + というオブジェクトファイルおよびライブラリをリンクし、module + という名前のモジュールの構造をアクティブなモジュールのリストに追加します。 + Module はファイル中の module + 型の外部変数の名前で、モジュールのドキュメントに + モジュール識別子として書かれているものです。例 :

    + + 
    LoadModule status_module modules/mod_status.so
    + + +

    これは ServerRoot の modules サブディレクトリから指定された名前の + モジュールをロードします。

    + +
    +
    top

    Windows 用のロード可能なモジュールを作成する

    @@ -141,53 +188,6 @@ LoadModule ディレクティブを使って読み込んでください。

    -
    top
    -

    LoadFile ディレクティブ

    - - - - - - -
    説明:指定されたオブジェクトファイルやライブラリをリンクする
    構文:LoadFile filename [filename] ...
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Extension
    モジュール:mod_so
    - -

    LoadFile ディレクティブは、サーバが起動されたときや再起動されたときに、 - 指定されたオブジェクトファイルやライブラリをリンクします。 - これはモジュールが動作するために必要になるかもしれない追加の - コードを読み込むために使用されます。Filename は絶対パスか、ServerRoot からの相対パスです。

    - -

    例:

    - - 
    LoadFile libexec/libxmlparse.so
    - - - -
    -
    top
    -

    LoadModule ディレクティブ

    - - - - - - -
    説明:オブジェクトファイルやライブラリをリンクし、使用モジュールの -リストに追加する
    構文:LoadModule module filename
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Extension
    モジュール:mod_so
    - -

    LoadModule ディレクティブは filename - というオブジェクトファイルおよびライブラリをリンクし、module - という名前のモジュールの構造をアクティブなモジュールのリストに追加します。 - Module はファイル中の module - 型の外部変数の名前で、モジュールのドキュメントに - モジュール識別子として書かれているものです。例 :

    - - 
    LoadModule status_module modules/mod_status.so
    - - -

    これは ServerRoot の modules サブディレクトリから指定された名前の - モジュールをロードします。

    - -

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_so.html.ko.euc-kr b/docs/manual/mod/mod_so.html.ko.euc-kr index ebe668d8a99..f663cb0c94f 100644 --- a/docs/manual/mod/mod_so.html.ko.euc-kr +++ b/docs/manual/mod/mod_so.html.ko.euc-kr @@ -65,6 +65,50 @@

  • À©µµ¿ìÁî¿¡¼­ ÀоîµéÀÏ ¸ðµâ ¸¸µé±â
    • top
    +

    LoadFile Áö½Ã¾î

    + + + + + + +
    ¼³¸í:ÁöÁ¤ÇÑ ¸ñÀûÆÄÀÏÀ̳ª ¶óÀ̺귯¸®¸¦ ÀоîµéÀδÙ
    ¹®¹ý:LoadFile filename [filename] ...
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤
    »óÅÂ:Extension
    ¸ðµâ:mod_so
    + +

    LoadFile Áö½Ã¾î´Â ¼­¹ö°¡ ½ÃÀÛÇϰųª Àç½ÃÀÛÇÒ¶§ ÁöÁ¤ÇÑ + ¸ñÀûÆÄÀÏÀ̳ª ¶óÀ̺귯¸®¸¦ ÀоîµéÀδÙ(link in). ÀÌ Áö½Ã¾î´Â + ¾î¶² ¸ðµâÀÌ µ¿ÀÛÇϱâÀ§ÇØ ÇÊ¿äÇÑ Äڵ带 Ãß°¡·Î ÀоîµéÀ϶§ + »ç¿ëÇÑ´Ù. FilenameÀº Àý´ë°æ·ÎÀ̰ųª ServerRoot¿¡ ´ëÇÑ »ó´ë°æ·ÎÀÌ´Ù.

    + +

    ¿¹¸¦ µé¾î:

    + +

    LoadFile libexec/libxmlparse.so

    + + +
    +
    top
    +

    LoadModule Áö½Ã¾î

    + + + + + + +
    ¼³¸í:¸ñÀûÆÄÀÏÀ̳ª ¶óÀ̺귯¸®¸¦ ÀоîµéÀÌ°í, »ç¿ë°¡´ÉÇÑ +¸ðµâ ¸ñ·Ï¿¡ Ãß°¡ÇÑ´Ù
    ¹®¹ý:LoadModule module filename
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤
    »óÅÂ:Extension
    ¸ðµâ:mod_so
    +

    LoadModule Áö½Ã¾î´Â ¸ñÀûÆÄÀÏ È¤Àº ¶óÀ̺귯¸® filenameÀ» + ÀоîµéÀÌ°í, »ç¿ë°¡´ÉÇÑ ¸ðµâ ¸ñ·Ï¿¡ moduleÀ̶ó´Â + ¸ðµâ ±¸Á¶Ã¼¸¦ Ãß°¡ÇÑ´Ù. ModuleÀº ÆÄÀÏÀÇ + module ÀÚ·áÇü ¿ÜºÎº¯¼ö¸íÀ̸ç, ¸ðµâ ¹®¼­ÀÇ ¸ðµâ¸í¿¡ + ³ª¿Â´Ù. ¿¹¸¦ µé¸é:

    + +

    + LoadModule status_module modules/mod_status.so +

    + +

    ServerRootÀÇ modules ÇÏÀ§µð·ºÅ丮¿¡¼­ ÁöÁ¤ÇÑ ¸ðµâÀ» ÀоîµéÀδÙ.

    + +
    +
    top

    À©µµ¿ìÁî¿¡¼­ ÀоîµéÀÏ ¸ðµâ ¸¸µé±â

    @@ -125,50 +169,6 @@ modules µð·ºÅ丮¿¡ µÎ°í, LoadModule Áö½Ã¾î¸¦ »ç¿ëÇÏ¿© ÀоîµéÀδÙ.

    -
    -
    top
    -

    LoadFile Áö½Ã¾î

    - - - - - - -
    ¼³¸í:ÁöÁ¤ÇÑ ¸ñÀûÆÄÀÏÀ̳ª ¶óÀ̺귯¸®¸¦ ÀоîµéÀδÙ
    ¹®¹ý:LoadFile filename [filename] ...
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤
    »óÅÂ:Extension
    ¸ðµâ:mod_so
    - -

    LoadFile Áö½Ã¾î´Â ¼­¹ö°¡ ½ÃÀÛÇϰųª Àç½ÃÀÛÇÒ¶§ ÁöÁ¤ÇÑ - ¸ñÀûÆÄÀÏÀ̳ª ¶óÀ̺귯¸®¸¦ ÀоîµéÀδÙ(link in). ÀÌ Áö½Ã¾î´Â - ¾î¶² ¸ðµâÀÌ µ¿ÀÛÇϱâÀ§ÇØ ÇÊ¿äÇÑ Äڵ带 Ãß°¡·Î ÀоîµéÀ϶§ - »ç¿ëÇÑ´Ù. FilenameÀº Àý´ë°æ·ÎÀ̰ųª ServerRoot¿¡ ´ëÇÑ »ó´ë°æ·ÎÀÌ´Ù.

    - -

    ¿¹¸¦ µé¾î:

    - -

    LoadFile libexec/libxmlparse.so

    - - -
    -
    top
    -

    LoadModule Áö½Ã¾î

    - - - - - - -
    ¼³¸í:¸ñÀûÆÄÀÏÀ̳ª ¶óÀ̺귯¸®¸¦ ÀоîµéÀÌ°í, »ç¿ë°¡´ÉÇÑ -¸ðµâ ¸ñ·Ï¿¡ Ãß°¡ÇÑ´Ù
    ¹®¹ý:LoadModule module filename
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤
    »óÅÂ:Extension
    ¸ðµâ:mod_so
    -

    LoadModule Áö½Ã¾î´Â ¸ñÀûÆÄÀÏ È¤Àº ¶óÀ̺귯¸® filenameÀ» - ÀоîµéÀÌ°í, »ç¿ë°¡´ÉÇÑ ¸ðµâ ¸ñ·Ï¿¡ moduleÀ̶ó´Â - ¸ðµâ ±¸Á¶Ã¼¸¦ Ãß°¡ÇÑ´Ù. ModuleÀº ÆÄÀÏÀÇ - module ÀÚ·áÇü ¿ÜºÎº¯¼ö¸íÀ̸ç, ¸ðµâ ¹®¼­ÀÇ ¸ðµâ¸í¿¡ - ³ª¿Â´Ù. ¿¹¸¦ µé¸é:

    - -

    - LoadModule status_module modules/mod_status.so -

    - -

    ServerRootÀÇ modules ÇÏÀ§µð·ºÅ丮¿¡¼­ ÁöÁ¤ÇÑ ¸ðµâÀ» ÀоîµéÀδÙ.

    -
    diff --git a/docs/manual/mod/mod_so.html.tr.utf8 b/docs/manual/mod/mod_so.html.tr.utf8 index b62c4fb1ff2..fb228816b2e 100644 --- a/docs/manual/mod/mod_so.html.tr.utf8 +++ b/docs/manual/mod/mod_so.html.tr.utf8 @@ -64,6 +64,57 @@ yeniden başlatılması sırasında yüklenmesini sağlar.
    + + + + + +
    Açıklama:Belirtilen nesne dosyasını veya kütüphaneyi sunucu ile ilintiler. +
    Sözdizimi:LoadFile dosya-ismi [dosya-ismi] ...
    Bağlam:sunucu geneli, sanal konak
    Durum:Eklenti
    Modül:mod_so
    + +

    LoadFile yönergesi ismi belirtilen kütüphaneleri + veya nesne dosyalarını sunucu başlatılırken veya yeniden başlatılırken + sunucu ile ilintiler. Yönerge, bazı modüllerin çalışması sırasında + gereken ek kodların yüklenmesi için kullanılır. + dosya-ismi olarak mutlak bir dosya yolu + belirtilebileceği gibi ServerRoot’a + göreli bir dosya yolu da belirtilebilir.

    + +

    Örnek:

    + + 
    LoadFile libexec/libxmlparse.so
    + + + +
    +
    top
    +

    LoadModule Yönergesi

    + + + + + + +
    Açıklama:Belirtilen nesne dosyasını veya kütüphaneyi sunucu ile ilintiler +ve etkin modül listesine ekler.
    Sözdizimi:LoadModule modül dosya-ismi
    Bağlam:sunucu geneli, sanal konak
    Durum:Eklenti
    Modül:mod_so
    +

    LoadModule yönergesi + dosya-ismi ile belirtilen nesne dosyasını veya + kütüphaneyi sunucu ile ilintiler ve etkin modül listesine belirtilen + modül ismiyle ekler. modül, + modülün kaynak dosyasında module türündeki tek harici + değişkenin ismi olup modül belgelerinde Modül Betimleyici olarak + geçer. Örneğin,

    + + 
    LoadModule status_module modules/mod_status.so
    + + +

    satırı ile ismi belirtilen dosya ServerRoot dizini altındaki + modules alt dizininden yüklenir.

    + +
    +
    top

    Yüklenebilir Modüllerin Windows için Oluşturulması

    @@ -138,57 +189,6 @@ yeniden başlatılması sırasında yüklenmesini sağlar.
    - - - - - -
    Açıklama:Belirtilen nesne dosyasını veya kütüphaneyi sunucu ile ilintiler. -
    Sözdizimi:LoadFile dosya-ismi [dosya-ismi] ...
    Bağlam:sunucu geneli, sanal konak
    Durum:Eklenti
    Modül:mod_so
    - -

    LoadFile yönergesi ismi belirtilen kütüphaneleri - veya nesne dosyalarını sunucu başlatılırken veya yeniden başlatılırken - sunucu ile ilintiler. Yönerge, bazı modüllerin çalışması sırasında - gereken ek kodların yüklenmesi için kullanılır. - dosya-ismi olarak mutlak bir dosya yolu - belirtilebileceği gibi ServerRoot’a - göreli bir dosya yolu da belirtilebilir.

    - -

    Örnek:

    - - 
    LoadFile libexec/libxmlparse.so
    - - - -
    -
    top
    -

    LoadModule Yönergesi

    - - - - - - -
    Açıklama:Belirtilen nesne dosyasını veya kütüphaneyi sunucu ile ilintiler -ve etkin modül listesine ekler.
    Sözdizimi:LoadModule modül dosya-ismi
    Bağlam:sunucu geneli, sanal konak
    Durum:Eklenti
    Modül:mod_so
    -

    LoadModule yönergesi - dosya-ismi ile belirtilen nesne dosyasını veya - kütüphaneyi sunucu ile ilintiler ve etkin modül listesine belirtilen - modül ismiyle ekler. modül, - modülün kaynak dosyasında module türündeki tek harici - değişkenin ismi olup modül belgelerinde Modül Betimleyici olarak - geçer. Örneğin,

    - - 
    LoadModule status_module modules/mod_status.so
    - - -

    satırı ile ismi belirtilen dosya ServerRoot dizini altındaki - modules alt dizininden yüklenir.

    -
    diff --git a/docs/manual/mod/mod_speling.html.en b/docs/manual/mod/mod_speling.html.en index 8c3451b695c..8b3836fc657 100644 --- a/docs/manual/mod/mod_speling.html.en +++ b/docs/manual/mod/mod_speling.html.en @@ -72,7 +72,6 @@ misspellings.
  • CheckSpelling
    • -
    top

    CheckCaseOnly Directive

    @@ -133,6 +132,7 @@ module

    +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_speling.html.fr b/docs/manual/mod/mod_speling.html.fr index ccf43e24577..93230d06e98 100644 --- a/docs/manual/mod/mod_speling.html.fr +++ b/docs/manual/mod/mod_speling.html.fr @@ -73,7 +73,6 @@ fautes de frappe mineures.

  • CheckSpelling
    • -
    top

    Directive CheckCaseOnly

    @@ -136,6 +135,7 @@ majuscules

    +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_speling.html.ja.utf8 b/docs/manual/mod/mod_speling.html.ja.utf8 index 58f335ae82a..3daa38e1318 100644 --- a/docs/manual/mod/mod_speling.html.ja.utf8 +++ b/docs/manual/mod/mod_speling.html.ja.utf8 @@ -76,7 +76,6 @@

  • CheckSpelling
    • -
    top

    CheckCaseOnly ディレクティブ

    @@ -141,6 +140,7 @@ 期待とは違う挙動になるからです。

    +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_speling.html.ko.euc-kr b/docs/manual/mod/mod_speling.html.ko.euc-kr index 3b72cd9741a..0eb35c26d5e 100644 --- a/docs/manual/mod/mod_speling.html.ko.euc-kr +++ b/docs/manual/mod/mod_speling.html.ko.euc-kr @@ -67,7 +67,6 @@

  • CheckSpelling
    • -
    top

    CheckCaseOnly Áö½Ã¾î

    @@ -124,6 +123,7 @@

    +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_ssl.html.en b/docs/manual/mod/mod_ssl.html.en index 58627b4dc0d..36482a7c8f4 100644 --- a/docs/manual/mod/mod_ssl.html.en +++ b/docs/manual/mod/mod_ssl.html.en @@ -122,201 +122,6 @@ to provide the cryptography engine.

  • Authorization providers for use with Require
    • top
    -
    -

    Environment Variables

    - -

    This module can be configured to provide several items of SSL information -as additional environment variables to the SSI and CGI namespace. This -information is not provided by default for performance reasons. (See -SSLOptions StdEnvVars, below.) The generated variables -are listed in the table below. For backward compatibility the information can -be made available under different names, too. Look in the Compatibility chapter for details on the -compatibility variables.

    - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Variable Name:Value Type:Description:
    HTTPS flag HTTPS is being used.
    SSL_PROTOCOL string The SSL protocol version (SSLv3, TLSv1, TLSv1.1, TLSv1.2)
    SSL_SESSION_ID string The hex-encoded SSL session id
    SSL_SESSION_RESUMED string Initial or Resumed SSL Session. Note: multiple requests may be served over the same (Initial or Resumed) SSL session if HTTP KeepAlive is in use
    SSL_SECURE_RENEG string true if secure renegotiation is supported, else false
    SSL_CIPHER string The cipher specification name
    SSL_CIPHER_EXPORT string true if cipher is an export cipher
    SSL_CIPHER_USEKEYSIZE number Number of cipher bits (actually used)
    SSL_CIPHER_ALGKEYSIZE number Number of cipher bits (possible)
    SSL_COMPRESS_METHOD string SSL compression method negotiated
    SSL_VERSION_INTERFACE string The mod_ssl program version
    SSL_VERSION_LIBRARY string The OpenSSL program version
    SSL_CLIENT_M_VERSION string The version of the client certificate
    SSL_CLIENT_M_SERIAL string The serial of the client certificate
    SSL_CLIENT_S_DN string Subject DN in client's certificate
    SSL_CLIENT_S_DN_x509 string Component of client's Subject DN
    SSL_CLIENT_I_DN string Issuer DN of client's certificate
    SSL_CLIENT_I_DN_x509 string Component of client's Issuer DN
    SSL_CLIENT_V_START string Validity of client's certificate (start time)
    SSL_CLIENT_V_END string Validity of client's certificate (end time)
    SSL_CLIENT_V_REMAIN string Number of days until client's certificate expires
    SSL_CLIENT_A_SIG string Algorithm used for the signature of client's certificate
    SSL_CLIENT_A_KEY string Algorithm used for the public key of client's certificate
    SSL_CLIENT_CERT string PEM-encoded client certificate
    SSL_CLIENT_CERT_CHAIN_n string PEM-encoded certificates in client certificate chain
    SSL_CLIENT_CERT_RFC4523_CEA string Serial number and issuer of the certificate. The format matches that of the CertificateExactAssertion in RFC4523
    SSL_CLIENT_VERIFY string NONE, SUCCESS, GENEROUS or FAILED:reason
    SSL_SERVER_M_VERSION string The version of the server certificate
    SSL_SERVER_M_SERIAL string The serial of the server certificate
    SSL_SERVER_S_DN string Subject DN in server's certificate
    SSL_SERVER_S_DN_x509 string Component of server's Subject DN
    SSL_SERVER_I_DN string Issuer DN of server's certificate
    SSL_SERVER_I_DN_x509 string Component of server's Issuer DN
    SSL_SERVER_V_START string Validity of server's certificate (start time)
    SSL_SERVER_V_END string Validity of server's certificate (end time)
    SSL_SERVER_A_SIG string Algorithm used for the signature of server's certificate
    SSL_SERVER_A_KEY string Algorithm used for the public key of server's certificate
    SSL_SERVER_CERT string PEM-encoded server certificate
    SSL_SRP_USER string SRP username
    SSL_SRP_USERINFO string SRP user info
    SSL_TLS_SNI string Contents of the SNI TLS extension (if supplied with ClientHello)
    - -

    x509 specifies a component of an X.509 DN; one of -C,ST,L,O,OU,CN,T,I,G,S,D,UID,Email. In Apache 2.1 and -later, x509 may also include a numeric _n -suffix. If the DN in question contains multiple attributes of the -same name, this suffix is used as a zero-based index to select a -particular attribute. For example, where the server certificate -subject DN included two OU attributes, SSL_SERVER_S_DN_OU_0 -and -SSL_SERVER_S_DN_OU_1 could be used to reference each. A -variable name without a _n suffix is equivalent to that -name with a _0 suffix; the first (or only) attribute. -When the environment table is populated using -the StdEnvVars option of -the SSLOptions directive, the -first (or only) attribute of any DN is added only under a non-suffixed -name; i.e. no _0 suffixed entries are added.

    - -

    The format of the *_DN variables has changed in Apache HTTPD -2.3.11. See the LegacyDNStringFormat option for -SSLOptions for details.

    - -

    SSL_CLIENT_V_REMAIN is only available in version 2.1 -and later.

    - -

    A number of additional environment variables can also be used -in SSLRequire expressions, or in custom log -formats:

    - -
    HTTP_USER_AGENT        PATH_INFO             AUTH_TYPE
-HTTP_REFERER           QUERY_STRING          SERVER_SOFTWARE
-HTTP_COOKIE            REMOTE_HOST           API_VERSION
-HTTP_FORWARDED         REMOTE_IDENT          TIME_YEAR
-HTTP_HOST              IS_SUBREQ             TIME_MON
-HTTP_PROXY_CONNECTION  DOCUMENT_ROOT         TIME_DAY
-HTTP_ACCEPT            SERVER_ADMIN          TIME_HOUR
-THE_REQUEST            SERVER_NAME           TIME_MIN
-REQUEST_FILENAME       SERVER_PORT           TIME_SEC
-REQUEST_METHOD         SERVER_PROTOCOL       TIME_WDAY
-REQUEST_SCHEME         REMOTE_ADDR           TIME
-REQUEST_URI            REMOTE_USER
    - -

    In these contexts, two special formats can also be used:

    - -
    -
    ENV:variablename
    -
    This will expand to the standard environment - variable variablename.
    - -
    HTTP:headername
    -
    This will expand to the value of the request header with name - headername.
    -
    - -
    top
    -
    -

    Custom Log Formats

    - -

    When mod_ssl is built into Apache or at least -loaded (under DSO situation) additional functions exist for the Custom Log Format of -mod_log_config. First there is an -additional ``%{varname}x'' -eXtension format function which can be used to expand any variables -provided by any module, especially those provided by mod_ssl which can -you find in the above table.

    -

    -For backward compatibility there is additionally a special -``%{name}c'' cryptography format function -provided. Information about this function is provided in the Compatibility chapter.

    -

    Example

    CustomLog "logs/ssl_request_log" "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
    -
    -
    top
    -
    -

    Request Notes

    - -

    mod_ssl sets "notes" for the request which can be -used in logging with the %{name}n format -string in mod_log_config.

    - -

    The notes supported are as follows:

    - -
    -
    ssl-access-forbidden
    -
    This note is set to the value 1 if access was - denied due to an SSLRequire - or SSLRequireSSL directive.
    - -
    ssl-secure-reneg
    -
    If mod_ssl is built against a version of - OpenSSL which supports the secure renegotiation extension, this note - is set to the value 1 if SSL is in used for the current - connection, and the client also supports the secure renegotiation - extension. If the client does not support the secure renegotiation - extension, the note is set to the value 0. - If mod_ssl is not built against a version of - OpenSSL which supports secure renegotiation, or if SSL is not in use - for the current connection, the note is not set.
    -
    - -
    top
    -
    -

    Authorization providers for use with Require

    - -

    mod_ssl provides a few authentication providers for use - with mod_authz_core's - Require directive.

    - -

    Require ssl

    - -

    The ssl provider denies access if a connection is not - encrypted with SSL. This is similar to the - SSLRequireSSL directive.

    - - 
    Require ssl
    - - - - -

    Require ssl-verify-client

    - -

    The ssl provider allows access if the user is - authenticated with a valid client certificate. This is only - useful if SSLVerifyClient optional is in effect.

    - -

    The following example grants access if the user is authenticated - either with a client certificate or by username and password.

    - - 
          Require ssl-verify-client
    
-      Require valid-user
    - - - - -
    -
    top

    SSLCACertificateFile Directive

    Description:File of concatenated PEM-encoded CA Certificates @@ -2559,6 +2364,201 @@ known to the server (i.e. the CA's certificate is under

    Example

    SSLVerifyDepth 10
    + +
    top
    +
    +

    Environment Variables

    + +

    This module can be configured to provide several items of SSL information +as additional environment variables to the SSI and CGI namespace. This +information is not provided by default for performance reasons. (See +SSLOptions StdEnvVars, below.) The generated variables +are listed in the table below. For backward compatibility the information can +be made available under different names, too. Look in the Compatibility chapter for details on the +compatibility variables.

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Variable Name:Value Type:Description:
    HTTPS flag HTTPS is being used.
    SSL_PROTOCOL string The SSL protocol version (SSLv3, TLSv1, TLSv1.1, TLSv1.2)
    SSL_SESSION_ID string The hex-encoded SSL session id
    SSL_SESSION_RESUMED string Initial or Resumed SSL Session. Note: multiple requests may be served over the same (Initial or Resumed) SSL session if HTTP KeepAlive is in use
    SSL_SECURE_RENEG string true if secure renegotiation is supported, else false
    SSL_CIPHER string The cipher specification name
    SSL_CIPHER_EXPORT string true if cipher is an export cipher
    SSL_CIPHER_USEKEYSIZE number Number of cipher bits (actually used)
    SSL_CIPHER_ALGKEYSIZE number Number of cipher bits (possible)
    SSL_COMPRESS_METHOD string SSL compression method negotiated
    SSL_VERSION_INTERFACE string The mod_ssl program version
    SSL_VERSION_LIBRARY string The OpenSSL program version
    SSL_CLIENT_M_VERSION string The version of the client certificate
    SSL_CLIENT_M_SERIAL string The serial of the client certificate
    SSL_CLIENT_S_DN string Subject DN in client's certificate
    SSL_CLIENT_S_DN_x509 string Component of client's Subject DN
    SSL_CLIENT_I_DN string Issuer DN of client's certificate
    SSL_CLIENT_I_DN_x509 string Component of client's Issuer DN
    SSL_CLIENT_V_START string Validity of client's certificate (start time)
    SSL_CLIENT_V_END string Validity of client's certificate (end time)
    SSL_CLIENT_V_REMAIN string Number of days until client's certificate expires
    SSL_CLIENT_A_SIG string Algorithm used for the signature of client's certificate
    SSL_CLIENT_A_KEY string Algorithm used for the public key of client's certificate
    SSL_CLIENT_CERT string PEM-encoded client certificate
    SSL_CLIENT_CERT_CHAIN_n string PEM-encoded certificates in client certificate chain
    SSL_CLIENT_CERT_RFC4523_CEA string Serial number and issuer of the certificate. The format matches that of the CertificateExactAssertion in RFC4523
    SSL_CLIENT_VERIFY string NONE, SUCCESS, GENEROUS or FAILED:reason
    SSL_SERVER_M_VERSION string The version of the server certificate
    SSL_SERVER_M_SERIAL string The serial of the server certificate
    SSL_SERVER_S_DN string Subject DN in server's certificate
    SSL_SERVER_S_DN_x509 string Component of server's Subject DN
    SSL_SERVER_I_DN string Issuer DN of server's certificate
    SSL_SERVER_I_DN_x509 string Component of server's Issuer DN
    SSL_SERVER_V_START string Validity of server's certificate (start time)
    SSL_SERVER_V_END string Validity of server's certificate (end time)
    SSL_SERVER_A_SIG string Algorithm used for the signature of server's certificate
    SSL_SERVER_A_KEY string Algorithm used for the public key of server's certificate
    SSL_SERVER_CERT string PEM-encoded server certificate
    SSL_SRP_USER string SRP username
    SSL_SRP_USERINFO string SRP user info
    SSL_TLS_SNI string Contents of the SNI TLS extension (if supplied with ClientHello)
    + +

    x509 specifies a component of an X.509 DN; one of +C,ST,L,O,OU,CN,T,I,G,S,D,UID,Email. In Apache 2.1 and +later, x509 may also include a numeric _n +suffix. If the DN in question contains multiple attributes of the +same name, this suffix is used as a zero-based index to select a +particular attribute. For example, where the server certificate +subject DN included two OU attributes, SSL_SERVER_S_DN_OU_0 +and +SSL_SERVER_S_DN_OU_1 could be used to reference each. A +variable name without a _n suffix is equivalent to that +name with a _0 suffix; the first (or only) attribute. +When the environment table is populated using +the StdEnvVars option of +the SSLOptions directive, the +first (or only) attribute of any DN is added only under a non-suffixed +name; i.e. no _0 suffixed entries are added.

    + +

    The format of the *_DN variables has changed in Apache HTTPD +2.3.11. See the LegacyDNStringFormat option for +SSLOptions for details.

    + +

    SSL_CLIENT_V_REMAIN is only available in version 2.1 +and later.

    + +

    A number of additional environment variables can also be used +in SSLRequire expressions, or in custom log +formats:

    + +
    HTTP_USER_AGENT        PATH_INFO             AUTH_TYPE
+HTTP_REFERER           QUERY_STRING          SERVER_SOFTWARE
+HTTP_COOKIE            REMOTE_HOST           API_VERSION
+HTTP_FORWARDED         REMOTE_IDENT          TIME_YEAR
+HTTP_HOST              IS_SUBREQ             TIME_MON
+HTTP_PROXY_CONNECTION  DOCUMENT_ROOT         TIME_DAY
+HTTP_ACCEPT            SERVER_ADMIN          TIME_HOUR
+THE_REQUEST            SERVER_NAME           TIME_MIN
+REQUEST_FILENAME       SERVER_PORT           TIME_SEC
+REQUEST_METHOD         SERVER_PROTOCOL       TIME_WDAY
+REQUEST_SCHEME         REMOTE_ADDR           TIME
+REQUEST_URI            REMOTE_USER
    + +

    In these contexts, two special formats can also be used:

    + +
    +
    ENV:variablename
    +
    This will expand to the standard environment + variable variablename.
    + +
    HTTP:headername
    +
    This will expand to the value of the request header with name + headername.
    +
    + +
    top
    +
    +

    Custom Log Formats

    + +

    When mod_ssl is built into Apache or at least +loaded (under DSO situation) additional functions exist for the Custom Log Format of +mod_log_config. First there is an +additional ``%{varname}x'' +eXtension format function which can be used to expand any variables +provided by any module, especially those provided by mod_ssl which can +you find in the above table.

    +

    +For backward compatibility there is additionally a special +``%{name}c'' cryptography format function +provided. Information about this function is provided in the Compatibility chapter.

    +

    Example

    CustomLog "logs/ssl_request_log" "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
    +
    +
    top
    +
    +

    Request Notes

    + +

    mod_ssl sets "notes" for the request which can be +used in logging with the %{name}n format +string in mod_log_config.

    + +

    The notes supported are as follows:

    + +
    +
    ssl-access-forbidden
    +
    This note is set to the value 1 if access was + denied due to an SSLRequire + or SSLRequireSSL directive.
    + +
    ssl-secure-reneg
    +
    If mod_ssl is built against a version of + OpenSSL which supports the secure renegotiation extension, this note + is set to the value 1 if SSL is in used for the current + connection, and the client also supports the secure renegotiation + extension. If the client does not support the secure renegotiation + extension, the note is set to the value 0. + If mod_ssl is not built against a version of + OpenSSL which supports secure renegotiation, or if SSL is not in use + for the current connection, the note is not set.
    +
    + +
    top
    +
    +

    Authorization providers for use with Require

    + +

    mod_ssl provides a few authentication providers for use + with mod_authz_core's + Require directive.

    + +

    Require ssl

    + +

    The ssl provider denies access if a connection is not + encrypted with SSL. This is similar to the + SSLRequireSSL directive.

    + + 
    Require ssl
    + + + + +

    Require ssl-verify-client

    + +

    The ssl provider allows access if the user is + authenticated with a valid client certificate. This is only + useful if SSLVerifyClient optional is in effect.

    + +

    The following example grants access if the user is authenticated + either with a client certificate or by username and password.

    + + 
          Require ssl-verify-client
    
+      Require valid-user
    + + + +
    diff --git a/docs/manual/mod/mod_ssl.html.fr b/docs/manual/mod/mod_ssl.html.fr index b993bfb4d30..d9b8fead499 100644 --- a/docs/manual/mod/mod_ssl.html.fr +++ b/docs/manual/mod/mod_ssl.html.fr @@ -125,266 +125,6 @@ personnalis disponibles avec Require
    top
    -
    -

    Variables d'environnement

    - -

    Ce module peut être configuré pour fournir aux espaces de nommage SSI -et CGI de nombreux éléments d'informations concernant SSL par le biais -de variables d'environnement supplémentaires. Par défaut, et pour -des raisons de performances, ces informations ne sont pas fournies (Voir -la directive SSLOptions StdEnvVars ci-dessous). -Les variables générées se trouvent dans la table ci-dessous. -Ces informations peuvent également être disponible sous des noms différents -à des fins de compatibilité ascendante. Reportez-vous au chapitre Compatibilité pour plus de détails à -propos des variables de compatibilité.

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Nom de la variable :Type de valeur :Description :
    HTTPS drapeauHTTPS est utilisé.
    SSL_PROTOCOL chaîneLa version du protocole SSL (SSLv3, TLSv1, TLSv1.1, TLSv1.2)
    SSL_SESSION_ID chaîneL'identifiant de session SSL codé en hexadécimal
    SSL_SESSION_RESUMED chaîneSession SSL initiale ou reprise. Note : plusieurs requêtes peuvent -être servies dans le cadre de la même session SSL (initiale ou reprise) -si les connexions persistantes (HTTP KeepAlive) sont utilisées
    SSL_SECURE_RENEG chaînetrue si la renégociation sécurisée est supportée, -false dans le cas contraire
    SSL_CIPHER chaîneLe nom de l'algorithme de chiffrement
    SSL_CIPHER_EXPORT chaînetrue si l'algorithme de chiffrement est un algorithme -exporté
    SSL_CIPHER_USEKEYSIZE nombreNombre de bits de chiffrement (réellement utilisés)
    SSL_CIPHER_ALGKEYSIZE nombreNombre de bits de chiffrement (possible)
    SSL_COMPRESS_METHOD chaîneMéthode de compression SSL négociée
    SSL_VERSION_INTERFACE chaîneLa version du programme mod_ssl
    SSL_VERSION_LIBRARY chaîneLa version du programme OpenSSL
    SSL_CLIENT_M_VERSION chaîneLa version du certificat client
    SSL_CLIENT_M_SERIAL chaîneLe numéro de série du certificat client
    SSL_CLIENT_S_DN chaîneLe DN sujet du certificat client
    SSL_CLIENT_S_DN_x509 chaîneElément du DN sujet du client
    SSL_CLIENT_I_DN chaîneDN de l'émetteur du certificat du client
    SSL_CLIENT_I_DN_x509 chaîneElément du DN de l'émetteur du certificat du client
    SSL_CLIENT_V_START chaîneValidité du certificat du client (date de début)
    SSL_CLIENT_V_END chaîneValidité du certificat du client (date de fin)
    SSL_CLIENT_V_REMAIN chaîneNombre de jours avant expiration du certificat du client
    SSL_CLIENT_A_SIG chaîneAlgorithme utilisé pour la signature du certificat du client
    SSL_CLIENT_A_KEY chaîneAlgorithme utilisé pour la clé publique du certificat du client
    SSL_CLIENT_CERT chaîneCertificat du client au format PEM
    SSL_CLIENT_CERT_CHAIN_nchaîne Certificats de la chaîne de certification du -client au format PEM
    SSL_CLIENT_CERT_RFC4523_CEA chaîneNuméro de série et fournisseur du certificat. le format correspond à -celui de la CertificateExactAssertion dans la RFC4523
    SSL_CLIENT_VERIFY chaîneNONE, SUCCESS, GENEROUS ou -FAILED:raison
    SSL_SERVER_M_VERSION chaîneLa version du certificat du serveur
    SSL_SERVER_M_SERIAL chaîne - -The serial of the server certificate
    SSL_SERVER_S_DN chaîneDN sujet du certificat du serveur
    SSL_SERVER_S_DN_x509 chaîneElément du DN sujet du certificat du serveur
    SSL_SERVER_I_DN chaîneDN de l'émetteur du certificat du serveur
    SSL_SERVER_I_DN_x509 chaîneElément du DN de l'émetteur du certificat du serveur
    SSL_SERVER_V_START chaîneValidité du certificat du serveur (date de dédut)
    SSL_SERVER_V_END chaîneValidité du certificat du serveur (date de fin)
    SSL_SERVER_A_SIG chaîneAlgorithme utilisé pour la signature du certificat du serveur
    SSL_SERVER_A_KEY chaîneAlgorithme utilisé pour la clé publique du certificat du serveur
    SSL_SERVER_CERT chaîneCertificat du serveur au format PEM
    SSL_SRP_USER chaînenom d'utilisateur SRP
    SSL_SRP_USERINFO chaîneinformations sur l'utilisateur SRP
    SSL_TLS_SNI stringContenu de l'extension SNI TLS (si supporté par ClientHello)
    - -

    x509 spécifie un élément de DN X.509 parmi -C,ST,L,O,OU,CN,T,I,G,S,D,UID,Email. A partir de la version -2.1 d'Apache, x509 peut aussi comporter un suffixe numérique -_n. Si le DN en question comporte plusieurs attributs de -noms identiques, ce suffixe constitue un index débutant à zéro et -permettant de sélectionner un -attribut particulier. Par exemple, si le DN sujet du certificat du -serveur comporte deux champs OU, on peut utiliser -SSL_SERVER_S_DN_OU_0 et SSL_SERVER_S_DN_OU_1 -pour référencer chacun d'entre eux. Un nom de variable sans suffixe -_n est équivalent au même nom avec le suffixe -_0, ce qui correspond au premier attribut (ou au seul) -caractérisant le DN. -Lorsque la table d'environnement est remplie en utilisant l'option -StdEnvVars de la directive SSLOptions, le premier attribut (ou le -seul) caractérisant le DN est enregistré avec un nom sans suffixe ; -autrement dit, aucune entrée possédant comme suffixe _0 -n'est enregistrée.

    - -

    Le format des variables *_DN a changé depuis la version -2.3.11 d'Apache HTTPD. Voir l'option LegacyDNStringFormat -de la directive SSLOptions pour -plus de détails.

    - -

    SSL_CLIENT_V_REMAIN n'est disponible qu'à partir de la -version 2.1.

    - -

    Plusieurs variables d'environnement additionnelles peuvent être -utilisées dans les expressions SSLRequire, ou -dans les formats de journalisation personnalisés :

    - -
    HTTP_USER_AGENT        PATH_INFO             AUTH_TYPE
-HTTP_REFERER           QUERY_STRING          SERVER_SOFTWARE
-HTTP_COOKIE            REMOTE_HOST           API_VERSION
-HTTP_FORWARDED         REMOTE_IDENT          TIME_YEAR
-HTTP_HOST              IS_SUBREQ             TIME_MON
-HTTP_PROXY_CONNECTION  DOCUMENT_ROOT         TIME_DAY
-HTTP_ACCEPT            SERVER_ADMIN          TIME_HOUR
-THE_REQUEST            SERVER_NAME           TIME_MIN
-REQUEST_FILENAME       SERVER_PORT           TIME_SEC
-REQUEST_METHOD         SERVER_PROTOCOL       TIME_WDAY
-REQUEST_SCHEME         REMOTE_ADDR           TIME
-REQUEST_URI            REMOTE_USER
    - -

    Dans ces contextes, deux formats spéciaux peuvent aussi être utilisés -:

    - -
    -
    ENV:nom_variable
    -
    Correspond à la variable d'environnement standard - nom_variable.
    - -
    HTTP:nom_en-tête
    -
    Correspond à la valeur de l'en-tête de requête dont le nom est - nom_en-tête.
    -
    - -
    top
    -
    -

    Formats de journaux -personnalisés

    - -

    Lorsque mod_ssl est compilé dans le serveur Apache -ou même chargé (en mode DSO), des fonctions supplémentaires sont -disponibles pour le Format de journal personnalisé du -module mod_log_config. A ce titre, la fonction de -format d'eXtension ``%{nom-var}x'' -peut être utilisée pour présenter en extension toute variable fournie -par tout module, et en particulier celles fournies par mod_ssl et que -vous trouverez dans la table ci-dessus.

    -

    -A des fins de compatibilité ascendante, il existe une fonction de format -cryptographique supplémentaire -``%{nom}c''. Vous trouverez toutes -les informations à propos de cette fonction dans le chapitre Compatibilité.

    -

    Exemple

    CustomLog logs/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
    -
    -
    top
    -
    -

    Information à propos de la requête

    - -

    mod_ssl enregistre des informations à propos de la -requête que l'on peut restituer dans les journaux avec la chaîne de -format %{nom}n via le module -mod_log_config.

    - -

    Les informations enregistrées sont les suivantes :

    - -
    -
    ssl-access-forbidden
    -
    Cette information contient la valeur 1 si l'accès a - été refusé suite à une directive SSLRequire ou - SSLRequireSSL.
    - -
    ssl-secure-reneg
    -
    Si mod_ssl a été compilé avec une version - d'OpenSSL qui supporte la renégociation sécurisée, si SSL est utilisé - pour la connexion courante et si le client supporte lui aussi la - renégociation sécurisée, cette information contiendra la valeur - 1. Si le client ne supporte pas la renégociation - sécurisée, l'information contiendra la valeur 0. Si - mod_ssl n'a pas été compilé avec une version - d'OpenSSL qui supporte la renégociation sécurisée, ou si SSL n'est pas - utilisé pour la connexion courante, le contenu de l'information ne - sera pas défini.
    -
    - -
    top
    -
    -

    Fournisseurs d'autorisation -disponibles avec Require

    - -

    mod_ssl propose quelques fournisseurs - d'autorisation à utiliser avec la directive Require du module - mod_authz_core.

    - -

    Require ssl

    - -

    Le fournisseur ssl refuse l'accès si une connexion - n'est pas chiffrée avec SSL. L'effet est similaire à celui de la - directive SSLRequireSSL.

    - - - 
    Require ssl
    - - - - - -

    Require ssl-verify-client

    - -

    Le fournisseur ssl autorise l'accès si - l'utilisateur est authentifié via un certificat client valide. Ceci - n'a un effet que si SSLVerifyClient optional est actif.

    - -

    Dans l'exemple suivant, l'accès est autorisé si le client est - authentifié via un certificat client ou par nom d'utilisateur/mot de - passe :

    - - 
          Require ssl-verify-client
    
-      Require valid-user
    - - - - -
    -
    top

    Directive SSLCACertificateFile

    Description:Fichier contenant une concaténation des certificats de CA @@ -1614,1231 +1354,1491 @@ validation r erreur "CRL introuvable".

    -

    Exemple

    SSLProxyCARevocationCheck chain
    +

    Exemple

    SSLProxyCARevocationCheck chain
    +
    + +
    +
    top
    +

    Directive SSLProxyCARevocationFile

    + + + + + + +
    Description:Fichier contenant la concaténation des CRLs de CA codés en +PEM pour l'authentification des serveurs distants
    Syntaxe:SSLProxyCARevocationFile chemin-fichier
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    +

    +Cette directive permet de définir le fichier tout-en-un où sont +rassemblées les Listes de Révocation de Certificats (CRLs) des Autorités +de certification (CAs) pour les serveurs distants auxquels vous +avez à faire. On les utilise pour l'authentification des serveurs +distants. Un tel fichier contient la simple concaténation des différents +fichiers de CRLs codés en PEM, classés par ordre de préférence. Cette +directive peut être utilisée à la place et/ou en complément de la +directive SSLProxyCARevocationPath.

    +

    Exemple

    SSLProxyCARevocationFile
+/usr/local/apache2/conf/ssl.crl/ca-bundle-serveur.distant.crl
    +
    + +
    +
    top
    +

    Directive SSLProxyCARevocationPath

    + + + + + + +
    Description:Répertoire des CRLs de CA codés en PEM pour +l'authentification des serveurs distants
    Syntaxe:SSLProxyCARevocationPath chemin-répertoire
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    +

    +Cette directive permet de définir le répertoire où sont stockées les +Listes de Révocation de Certificats (CRL) des Autorités de Certification +(CAs) pour les serveurs distants auxquels vous avez à faire. On les +utilise pour révoquer les certificats des serveurs distants au cours de +l'authentification de ces derniers.

    +

    +Les fichiers de ce répertoire doivent être codés en PEM et ils sont +accédés via des noms de fichier sous forme de condensés ou hash. Il ne +suffit donc pas de placer les fichiers de CRL dans ce répertoire +: vous devez aussi créer des liens symboliques nommés +valeur-de-hashage.rN, et vous devez toujours vous +assurer que ce répertoire contient les liens symboliques appropriés.

    +

    Exemple

    SSLProxyCARevocationPath /usr/local/apache2/conf/ssl.crl/
    +
    + +
    +
    top
    +

    Directive SSLProxyCheckPeerCN

    + + + + + + + +
    Description:Configuration de la vérification du champ CN du certificat +du serveur distant +
    Syntaxe:SSLProxyCheckPeerCN on|off
    Défaut:SSLProxyCheckPeerCN on
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    +

    +Cette directive permet de définir si le champ CN du certificat +du serveur distant doit être comparé au nom de serveur de l'URL de la +requête. S'ils ne correspondent pas, un +code d'état 502 (Bad Gateway) est envoyé. +

    +

    +A partir de la version 2.4.5, SSLProxyCheckPeerCN a été remplacé par SSLProxyCheckPeerName, et sa définition +n'est prise en compte que si SSLProxyCheckPeerName off a +été spécifié. +

    +

    Exemple

    SSLProxyCheckPeerCN on
    +
    + +
    +
    top
    +

    Directive SSLProxyCheckPeerExpire

    + + + + + + + +
    Description:Configuration de la vérification de l'expiration du +certificat du serveur distant +
    Syntaxe:SSLProxyCheckPeerExpire on|off
    Défaut:SSLProxyCheckPeerExpire on
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    +

    +Cette directive permet de définir si l'expiration du certificat du +serveur distant doit être vérifiée ou non. Si la vérification échoue, un +code d'état 502 (Bad Gateway) est envoyé. +

    +

    Exemple

    SSLProxyCheckPeerExpire on
    +
    + +
    +
    top
    +

    Directive SSLProxyCheckPeerName

    + + + + + + + + +
    Description:Configure la vérification du nom d'hôte dans les +certificats serveur distants +
    Syntaxe:SSLProxyCheckPeerName on|off
    Défaut:SSLProxyCheckPeerName on
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible à partir de la version 2.4.5 du serveur HTTP +Apache
    +

    +Cette directive permet de configurer la vérification du nom d'hôte dans +les certificats de serveur lorsque mod_ssl agit en tant que client SSL. +La vérification est concluante si le nom d'hôte de l'URI de la requête +correspond soit à l'extension subjectAltName, soit à l'un des attributs +CN dans le sujet du certificat. Si la vérification échoue, la requête +SSL est annulée et un code d'erreur 502 (Bad Gateway) est renvoyé. Cette +directive remplace la directive SSLProxyCheckPeerCN qui ne prenait en +compte que le premier attribut CN pour la vérification du nom d'hôte. +

    +

    +La vérification du nom d'hôte avec caractères générique est supportée de +la manière suivante : les entrées subjectAltName de type dNSName ou les +attributs CN commençant par *. correspondront à tout nom +DNS comportant le même nombre d'éléments et le même suffixe (par +exemple, *.example.org correspondra à +foo.example.org, mais pas à +foo.bar.example.org). +

    + +
    +
    top
    +

    Directive SSLProxyCipherSuite

    + + + + + + + + +
    Description:Algorithmes de chiffrement disponibles pour la négociation +lors de l'initialisation d'une connexion SSL de mandataire
    Syntaxe:SSLProxyCipherSuite algorithmes
    Défaut:SSLProxyCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_ssl
    +

    Cette directive est équivalente à la directive +SSLCipherSuite, mais s'applique à une connexion de +mandataire. Veuillez vous reporter à la directive SSLCipherSuite pour plus +d'informations.

    + +
    +
    top
    +

    Directive SSLProxyEngine

    + + + + + + + +
    Description:Interrupteur marche/arrêt du moteur de mandataire +SSL
    Syntaxe:SSLProxyEngine on|off
    Défaut:SSLProxyEngine off
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    +

    +Cette directive permet d'activer/désactiver l'utilisation du moteur de +protocole SSL/TLS pour le mandataire. On l'utilise en général à +l'intérieur d'une section <VirtualHost> pour activer le protocole SSL/TLS +dans le cadre d'un mandataire pour un serveur virtuel particulier. Par +défaut, le moteur de protocole SSL/TLS est désactivé pour la fonction de +mandataire du serveur principal et de tous les serveurs virtuels +configurés.

    + +

    Notez que la directive SSLProxyEngine ne doit généralement pas être +utilisée dans le cadre d'un serveur virtuel qui agit en tant que +mandataire direct (via les directives <Proxy> ou +<ProxyRequest>). SSLProxyEngine n'est pas nécessaire pour activer +un serveur mandataire direct pour les requêtes SSL/TLS.

    + + +

    Exemple

    <VirtualHost _default_:443>
+    SSLProxyEngine on
+    #...
+</VirtualHost>
    +
    + +
    +
    top
    +

    Directive SSLProxyMachineCertificateChainFile

    + + + + + + + +
    Description:Fichier de certificats de CA encodés PEM concaténés permettant au +mandataire de choisir un certificat
    Syntaxe:SSLProxyMachineCertificateChainFile nom-fichier
    Contexte:configuration du serveur
    AllowOverride:Sans objet
    Statut:Extension
    Module:mod_ssl
    +

    +Cette directive permet de définir le fichier global où est enregistrée +la chaîne de certification pour tous les certificats clients utilisés. +Elle est nécessaire si le serveur distant présente une liste de +certificats de CA qui ne sont pas les signataires directs d'un des +certificats clients configurés. +

    +

    +Ce fichier contient tout simplement la concaténation des différents +fichiers de certificats encodés PEM. Au démarrage, chaque certificat +client configuré est examiné et une chaîne de certification est +construite. +

    +

    Avertissement en matière de sécurité

    +

    Si cette directive est définie, tous les certificats contenus dans le +fichier spécifié seront considérés comme étant de confiance, comme s'ils +étaient aussi désignés dans la directive SSLProxyCACertificateFile.

    +
    +

    Exemple

    SSLProxyMachineCertificateChainFile /usr/local/apache2/conf/ssl.crt/proxyCA.pem
    +
    + +
    +
    top
    +

    Directive SSLProxyMachineCertificateFile

    + + + + + + + +
    Description:Fichier contenant la concaténation des clés et certificats +clients codés en PEM que le mandataire doit utiliser
    Syntaxe:SSLProxyMachineCertificateFile chemin-fichier
    Contexte:configuration du serveur
    AllowOverride:Sans objet
    Statut:Extension
    Module:mod_ssl
    +

    +Cette directive permet de définir le fichier tout-en-un où sont stockés +les clés et certificats permettant au serveur mandataire de +s'authentifier auprès des serveurs distants. +

    +

    +Le fichier spécifié est la simple concaténation des différents fichiers +de certificats codés en PEM, classés par ordre de préférence. Cette +directive s'utilise à la place ou en complément de la directive +SSLProxyMachineCertificatePath. +

    +
    +

    Actuellement, les clés privées chiffrées ne sont pas supportées.

    +
    +

    Exemple

    SSLProxyMachineCertificateFile /usr/local/apache2/conf/ssl.crt/proxy.pem
    top
    -

    Directive SSLProxyCARevocationFile

    +

    Directive SSLProxyMachineCertificatePath

    - - - + + + +
    Description:Fichier contenant la concaténation des CRLs de CA codés en -PEM pour l'authentification des serveurs distants
    Syntaxe:SSLProxyCARevocationFile chemin-fichier
    Contexte:configuration du serveur, serveur virtuel
    Description:Répertoire des clés et certificats clients codés en PEM que +le mandataire doit utiliser
    Syntaxe:SSLProxyMachineCertificatePath chemin-répertoire
    Contexte:configuration du serveur
    AllowOverride:Sans objet
    Statut:Extension
    Module:mod_ssl

    -Cette directive permet de définir le fichier tout-en-un où sont -rassemblées les Listes de Révocation de Certificats (CRLs) des Autorités -de certification (CAs) pour les serveurs distants auxquels vous -avez à faire. On les utilise pour l'authentification des serveurs -distants. Un tel fichier contient la simple concaténation des différents -fichiers de CRLs codés en PEM, classés par ordre de préférence. Cette -directive peut être utilisée à la place et/ou en complément de la -directive SSLProxyCARevocationPath.

    -

    Exemple

    SSLProxyCARevocationFile
-/usr/local/apache2/conf/ssl.crl/ca-bundle-serveur.distant.crl
    +Cette directive permet de définir le répertoire où sont stockés les clés +et certificats permettant au serveur mandataire de s'authentifier auprès +des serveurs distants. +

    +

    Les fichiers de ce répertoire doivent être codés en PEM et ils sont +accédés via des noms de fichier sous forme de condensés ou hash. Vous +devez donc aussi créer des liens symboliques nommés +valeur-de-hashage.N, et vous devez toujours vous +assurer que ce répertoire contient les liens symboliques appropriés.

    +
    +

    Actuellement, les clés privées chiffrées ne sont pas supportées.

    +
    +

    Exemple

    SSLProxyMachineCertificatePath /usr/local/apache2/conf/proxy.crt/
    top
    -

    Directive SSLProxyCARevocationPath

    +

    Directive SSLProxyProtocol

    - - + + + +
    Description:Répertoire des CRLs de CA codés en PEM pour -l'authentification des serveurs distants
    Syntaxe:SSLProxyCARevocationPath chemin-répertoire
    Description:Définit les protocoles SSL disponibles pour la fonction de +mandataire
    Syntaxe:SSLProxyProtocol [+|-]protocole ...
    Défaut:SSLProxyProtocol all
    Contexte:configuration du serveur, serveur virtuel
    AllowOverride:Options
    Statut:Extension
    Module:mod_ssl
    +

    -Cette directive permet de définir le répertoire où sont stockées les -Listes de Révocation de Certificats (CRL) des Autorités de Certification -(CAs) pour les serveurs distants auxquels vous avez à faire. On les -utilise pour révoquer les certificats des serveurs distants au cours de -l'authentification de ces derniers.

    -

    -Les fichiers de ce répertoire doivent être codés en PEM et ils sont -accédés via des noms de fichier sous forme de condensés ou hash. Il ne -suffit donc pas de placer les fichiers de CRL dans ce répertoire -: vous devez aussi créer des liens symboliques nommés -valeur-de-hashage.rN, et vous devez toujours vous -assurer que ce répertoire contient les liens symboliques appropriés.

    -

    Exemple

    SSLProxyCARevocationPath /usr/local/apache2/conf/ssl.crl/
    -
    +Cette directive permet de définir les protocoles SSL que mod_ssl peut +utiliser lors de l'élaboration de son environnement de serveur pour la +fonction de mandataire. Il ne se connectera qu'aux serveurs utilisant un +des protocoles spécifiés.

    +

    Veuillez vous reporter à la directive SSLProtocol pour plus d'informations. +

    top
    -

    Directive SSLProxyCheckPeerCN

    +

    Directive SSLProxyVerify

    - - - + + +
    Description:Configuration de la vérification du champ CN du certificat -du serveur distant -
    Syntaxe:SSLProxyCheckPeerCN on|off
    Défaut:SSLProxyCheckPeerCN on
    Description:Niveau de vérification du certificat du serveur +distant
    Syntaxe:SSLProxyVerify niveau
    Défaut:SSLProxyVerify none
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    + +

    Lorsqu'un mandataire est configuré pour faire suivre les requêtes +vers un serveur SSL distant, cette directive permet de configurer la +vérification du certificat de ce serveur distant.

    +

    -Cette directive permet de définir si le champ CN du certificat -du serveur distant doit être comparé au nom de serveur de l'URL de la -requête. S'ils ne correspondent pas, un -code d'état 502 (Bad Gateway) est envoyé. -

    -

    -A partir de la version 2.4.5, SSLProxyCheckPeerCN a été remplacé par SSLProxyCheckPeerName, et sa définition -n'est prise en compte que si SSLProxyCheckPeerName off a -été spécifié. -

    -

    Exemple

    SSLProxyCheckPeerCN on
    +Les valeurs de niveaux disponibles sont les suivantes :

    +
      +
    • none: + aucun certificat n'est requis pour le serveur distant
      • +
    • optional: + le serveur distant peut présenter un certificat valide
      • +
    • require: + le serveur distant doit présenter un certificat valide
      • +
    • optional_no_ca: + le serveur distant peut présenter un certificat valide
      + mais il n'est pas nécessaire qu'il soit vérifiable (avec succès).
      • +
    +

    En pratique, seuls les niveaux none et +require sont vraiment intéressants, car le niveau +optional ne fonctionne pas avec tous les serveurs, et +le niveau optional_no_ca va tout à fait à l'encontre de +l'idée que l'on peut se faire de l'authentification (mais peut tout de +même être utilisé pour établir des pages de test SSL, etc...).

    + +

    Exemple

    SSLProxyVerify require
    top
    -

    Directive SSLProxyCheckPeerExpire

    +

    Directive SSLProxyVerifyDepth

    - - - + + + +
    Description:Configuration de la vérification de l'expiration du -certificat du serveur distant -
    Syntaxe:SSLProxyCheckPeerExpire on|off
    Défaut:SSLProxyCheckPeerExpire on
    Description:Niveau de profondeur maximum dans les certificats de CA +lors de la vérification du certificat du serveur distant
    Syntaxe:SSLProxyVerifyDepth niveau
    Défaut:SSLProxyVerifyDepth 1
    Contexte:configuration du serveur, serveur virtuel
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_ssl

    -Cette directive permet de définir si l'expiration du certificat du -serveur distant doit être vérifiée ou non. Si la vérification échoue, un -code d'état 502 (Bad Gateway) est envoyé. -

    -

    Exemple

    SSLProxyCheckPeerExpire on
    +Cette directive permet de définir le niveau de profondeur maximum +jusqu'auquel mod_ssl doit aller au cours de sa vérification avant de +décider que le serveur distant ne possède pas de certificat valide.

    +

    +La profondeur correspond en fait au nombre maximum de fournisseurs de +certificats intermédiaires, c'est à dire le nombre maximum de +certificats +de CA que l'on peut consulter lors de la vérification du certificat du +serveur distant. Une profondeur de 0 signifie que seuls les certificats +de serveurs distants auto-signés sont acceptés, et la profondeur par +défaut de 1 que le certificat du serveur distant peut être soit +auto-signé, soit signé par une CA connue directement du serveur (en +d'autres termes, le certificat de CA est référencé par la directive +SSLProxyCACertificatePath), +etc...

    +

    Exemple

    SSLProxyVerifyDepth 10
    top
    -

    Directive SSLProxyCheckPeerName

    +

    Directive SSLRandomSeed

    - - - - + + + -
    Description:Configure la vérification du nom d'hôte dans les -certificats serveur distants -
    Syntaxe:SSLProxyCheckPeerName on|off
    Défaut:SSLProxyCheckPeerName on
    Contexte:configuration du serveur, serveur virtuel
    Description:Source de déclenchement du Générateur de Nombres +Pseudo-Aléatoires (PRNG)
    Syntaxe:SSLRandomSeed contexte source +[nombre]
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible à partir de la version 2.4.5 du serveur HTTP -Apache

    -Cette directive permet de configurer la vérification du nom d'hôte dans -les certificats de serveur lorsque mod_ssl agit en tant que client SSL. -La vérification est concluante si le nom d'hôte de l'URI de la requête -correspond soit à l'extension subjectAltName, soit à l'un des attributs -CN dans le sujet du certificat. Si la vérification échoue, la requête -SSL est annulée et un code d'erreur 502 (Bad Gateway) est renvoyé. Cette -directive remplace la directive SSLProxyCheckPeerCN qui ne prenait en -compte que le premier attribut CN pour la vérification du nom d'hôte. -

    +Cette directive permet de définir une ou plusieurs sources de +déclenchement du Générateur de Nombres Pseudo-Aléatoires (PRNG) dans +OpenSSL au démarrage du serveur (si contexte a pour valeur +startup) et/ou juste avant l'établissement d'une nouvelle +connexion SSL (si contexte a pour valeur connect). +Cette directive ne peut être utilisée qu'au niveau du serveur global car +le PRNG est un service global.

    -La vérification du nom d'hôte avec caractères générique est supportée de -la manière suivante : les entrées subjectAltName de type dNSName ou les -attributs CN commençant par *. correspondront à tout nom -DNS comportant le même nombre d'éléments et le même suffixe (par -exemple, *.example.org correspondra à -foo.example.org, mais pas à -foo.bar.example.org). -

    +Les différentes valeurs de source disponibles sont :

    +
      +
    • builtin +

      Cette source de déclenchement intégrée est toujours disponible. + Son utilisation consomme un minimum de cycles CPU en cours + d'exécution, et son utilisation ne présente de ce fait aucun + problème. La source utilisée pour déclencher le PRNG contient la + date courante, l'identifiant du processus courant et (si disponible) + un extrait de 1Ko aléatoirement choisi de la structure d'Apache pour + les échanges inter-processus. Ceci présente un inconvénient car le + caractère aléatoire de cette source n'est pas vraiment fort, et au + démarrage (lorsque la structure d'échanges n'est pas encore + disponible), cette source ne produit que quelques octets d'entropie. + Vous devez donc toujours utiliser une source de déclenchement + additionnelle, au moins pour le démarrage.

      • +
    • file:/chemin/vers/source +

      + Cette variante utilise un fichier externe + file:/chemin/vers/source comme source de déclenchement + du PRNG. Lorsque nombre est spécifié, seuls les + nombre premiers octets du fichier forment l'entropie (et + nombre est fourni comme premier argument à + /chemin/vers/source). Lorsque nombre n'est pas + spécifié, l'ensemble du fichier forme l'entropie (et 0 + est fourni comme premier argument à + /chemin/vers/source). Utilisez cette source en + particulier au démarrage, par exemple avec un fichier de + périphérique /dev/random et/ou + /dev/urandom (qui sont en général présent sur les + plate-formes dérivées d'Unix modernes comme FreeBSD et Linux).

      +

      Soyez cependant prudent : en général, + /dev/random ne fournit que l'entropie dont il dispose + réellement ; en d'autres termes, lorsque vous demandez 512 octets + d'entropie, si le périphérique ne dispose que de 100 octets, deux + choses peuvent se produire : sur certaines plates-formes, vous ne + recevez que les 100 octets, alors que sur d'autres, la lecture se + bloque jusqu'à ce qu'un nombre suffisant d'octets soit disponible + (ce qui peut prendre beaucoup de temps). Il est préférable ici + d'utiliser le périphérique /dev/urandom, car il ne se + bloque jamais et fournit vraiment la quantité de données demandées. + Comme inconvénient, les données reçues ne sont pas forcément de la + meilleure qualité.

      • +
    • exec:/chemin/vers/programme +

      + Cette variante utilise un exécutable externe + /chemin/vers/programme comme source de déclenchement du + PRNG. Lorsque nombre est spécifié, seules les + nombre premiers octets de son flux stdout + forment l'entropie. Lorsque nombre n'est pas spécifié, + l'intégralité des données produites sur stdout forment + l'entropie. N'utilisez cette variante qu'au démarrage où une source + de déclenchement fortement aléatoire est nécessaire, en utilisant + un programme externe (comme dans l'exemple + ci-dessous avec l'utilitaire truerand basé sur la + bibliothèque truerand de AT&T que vous trouverez + dans la distribution de mod_ssl). Bien entendu, l'utilisation de + cette variante dans un contexte "connection" ralentit le serveur de + manière trop importante, et en général, vous devez donc éviter + d'utiliser des programmes externes dans ce contexte.

      • +
    • egd:/chemin/vers/socket-egd (Unix seulement) +

      Cette variante utilise le socket de domaine Unix du Démon + Générateur d'Entropie externe ou Entropy Gathering Daemon ou EGD + (voir http://www.lothar.com/tech + /crypto/) pour déclencher le PRNG. N'utilisez cette variante que + si votre plate-forme ne possède pas de périphérique random ou + urandom.

      • +
    +

    Exemple

    SSLRandomSeed startup builtin
+SSLRandomSeed startup file:/dev/random
+SSLRandomSeed startup file:/dev/urandom 1024
+SSLRandomSeed startup exec:/usr/local/bin/truerand 16
+SSLRandomSeed connect builtin
+SSLRandomSeed connect file:/dev/random
+SSLRandomSeed connect file:/dev/urandom 1024
    -
    top
    -

    Directive SSLProxyCipherSuite

    - - - - - - - - -
    Description:Algorithmes de chiffrement disponibles pour la négociation -lors de l'initialisation d'une connexion SSL de mandataire
    Syntaxe:SSLProxyCipherSuite algorithmes
    Défaut:SSLProxyCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_ssl
    -

    Cette directive est équivalente à la directive -SSLCipherSuite, mais s'applique à une connexion de -mandataire. Veuillez vous reporter à la directive SSLCipherSuite pour plus -d'informations.

    top
    -

    Directive SSLProxyEngine

    +

    Directive SSLRenegBufferSize

    - - - - + + + +
    Description:Interrupteur marche/arrêt du moteur de mandataire +
    Description:Définit la taille du tampon de renégociation SSL
    Syntaxe:SSLProxyEngine on|off
    Défaut:SSLProxyEngine off
    Contexte:configuration du serveur, serveur virtuel
    Syntaxe:SSLRenegBufferSize taille
    Défaut:SSLRenegBufferSize 131072
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_ssl
    -

    -Cette directive permet d'activer/désactiver l'utilisation du moteur de -protocole SSL/TLS pour le mandataire. On l'utilise en général à -l'intérieur d'une section <VirtualHost> pour activer le protocole SSL/TLS -dans le cadre d'un mandataire pour un serveur virtuel particulier. Par -défaut, le moteur de protocole SSL/TLS est désactivé pour la fonction de -mandataire du serveur principal et de tous les serveurs virtuels -configurés.

    -

    Notez que la directive SSLProxyEngine ne doit généralement pas être -utilisée dans le cadre d'un serveur virtuel qui agit en tant que -mandataire direct (via les directives <Proxy> ou -<ProxyRequest>). SSLProxyEngine n'est pas nécessaire pour activer -un serveur mandataire direct pour les requêtes SSL/TLS.

    +

    Si une renégociation SSL est requise dans un contexte de répertoire, +par exemple avec l'utilisation de SSLVerifyClient dans un bloc Directory ou +Location, mod_ssl doit mettre en tampon en mémoire tout corps de requête +HTTP en attendant qu'une nouvelle initialisation de connexion SSL puisse +être effectuée. Cette directive permet de définir la quantité de mémoire +à allouer pour ce tampon.

    +

    +Notez que dans de nombreuses configurations, le client qui envoie un +corps de requête n'est pas forcément digne de confiance, et l'on doit +par conséquent prendre en considération la possibilité d'une attaque de +type déni de service lorsqu'on modifie la valeur de cette directive. +

    -

    Exemple

    <VirtualHost _default_:443>
-    SSLProxyEngine on
-    #...
-</VirtualHost>
    +

    Exemple

    SSLRenegBufferSize 262144
    top
    -

    Directive SSLProxyMachineCertificateChainFile

    +

    Directive SSLRequire

    - - - - + + + +
    Description:Fichier de certificats de CA encodés PEM concaténés permettant au -mandataire de choisir un certificat
    Syntaxe:SSLProxyMachineCertificateChainFile nom-fichier
    Contexte:configuration du serveur
    AllowOverride:Sans objet
    Description:N'autorise l'accès que lorsqu'une expression booléenne +complexe et arbitraire est vraie
    Syntaxe:SSLRequire expression
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_ssl
    -

    -Cette directive permet de définir le fichier global où est enregistrée -la chaîne de certification pour tous les certificats clients utilisés. -Elle est nécessaire si le serveur distant présente une liste de -certificats de CA qui ne sont pas les signataires directs d'un des -certificats clients configurés. -

    -

    -Ce fichier contient tout simplement la concaténation des différents -fichiers de certificats encodés PEM. Au démarrage, chaque certificat -client configuré est examiné et une chaîne de certification est -construite. -

    -

    Avertissement en matière de sécurité

    -

    Si cette directive est définie, tous les certificats contenus dans le -fichier spécifié seront considérés comme étant de confiance, comme s'ils -étaient aussi désignés dans la directive SSLProxyCACertificateFile.

    -
    -

    Exemple

    SSLProxyMachineCertificateChainFile /usr/local/apache2/conf/ssl.crt/proxyCA.pem
    -
    +

    SSLRequire est obsolète

    +

    SSLRequire est obsolète et doit en général être +remplacée par l'expression Require. La syntaxe ap_expr de l'expression Require est +une extension de la syntaxe de SSLRequire, avec les +différences suivantes :

    -
    -
    top
    -

    Directive SSLProxyMachineCertificateFile

    - - - - - - - -
    Description:Fichier contenant la concaténation des clés et certificats -clients codés en PEM que le mandataire doit utiliser
    Syntaxe:SSLProxyMachineCertificateFile chemin-fichier
    Contexte:configuration du serveur
    AllowOverride:Sans objet
    Statut:Extension
    Module:mod_ssl
    -

    -Cette directive permet de définir le fichier tout-en-un où sont stockés -les clés et certificats permettant au serveur mandataire de -s'authentifier auprès des serveurs distants. -

    -

    -Le fichier spécifié est la simple concaténation des différents fichiers -de certificats codés en PEM, classés par ordre de préférence. Cette -directive s'utilise à la place ou en complément de la directive -SSLProxyMachineCertificatePath. +

    Avec SSLRequire, les opérateurs de comparaison +<, <=, ... sont strictement équivalents +aux opérateurs lt, le, ... , et fonctionnent +selon une méthode qui compare tout d'abord la longueur des deux chaînes, +puis l'ordre alphabétique. Les expressions ap_expr, quant à elles, possèdent deux jeux +d'opérateurs de comparaison : les opérateurs <, +<=, ... effectuent une comparaison alphabétique de +chaînes, alors que les opérateurs -lt, -le, +... effectuent une comparaison d'entiers. Ces derniers possèdent aussi +des alias sans tiret initial : lt, le, ...

    -
    -

    Actuellement, les clés privées chiffrées ne sont pas supportées.

    -
    -

    Exemple

    SSLProxyMachineCertificateFile /usr/local/apache2/conf/ssl.crt/proxy.pem
    -
    -
    top
    -

    Directive SSLProxyMachineCertificatePath

    - - - - - - - -
    Description:Répertoire des clés et certificats clients codés en PEM que -le mandataire doit utiliser
    Syntaxe:SSLProxyMachineCertificatePath chemin-répertoire
    Contexte:configuration du serveur
    AllowOverride:Sans objet
    Statut:Extension
    Module:mod_ssl
    + +

    Cette directive permet de spécifier une condition générale d'accès +qui doit être entièrement satisfaite pour que l'accès soit autorisé. +C'est une directive très puissante, car la condition d'accès spécifiée +est une expression booléenne complexe et arbitraire contenant un nombre +quelconque de vérifications quant aux autorisations d'accès.

    -Cette directive permet de définir le répertoire où sont stockés les clés -et certificats permettant au serveur mandataire de s'authentifier auprès -des serveurs distants. -

    -

    Les fichiers de ce répertoire doivent être codés en PEM et ils sont -accédés via des noms de fichier sous forme de condensés ou hash. Vous -devez donc aussi créer des liens symboliques nommés -valeur-de-hashage.N, et vous devez toujours vous -assurer que ce répertoire contient les liens symboliques appropriés.

    -
    -

    Actuellement, les clés privées chiffrées ne sont pas supportées.

    -
    -

    Exemple

    SSLProxyMachineCertificatePath /usr/local/apache2/conf/proxy.crt/
    -
    +L'expression doit respecter la syntaxe suivante (fournie ici +sous la forme d'une notation dans le style de la grammaire BNF) :

    +
    +
    expr     ::= "true" | "false"
+           | "!" expr
+           | expr "&&" expr
+           | expr "||" expr
+           | "(" expr ")"
+           | comp
 
-
    -
    top
    -

    Directive SSLProxyProtocol

    - - - - - - - - -
    Description:Définit les protocoles SSL disponibles pour la fonction de -mandataire
    Syntaxe:SSLProxyProtocol [+|-]protocole ...
    Défaut:SSLProxyProtocol all
    Contexte:configuration du serveur, serveur virtuel
    AllowOverride:Options
    Statut:Extension
    Module:mod_ssl
    +comp ::= word "==" word | word "eq" word + | word "!=" word | word "ne" word + | word "<" word | word "lt" word + | word "<=" word | word "le" word + | word ">" word | word "gt" word + | word ">=" word | word "ge" word + | word "in" "{" wordlist "}" + | word "in" "PeerExtList(" word ")" + | word "=~" regex + | word "!~" regex -

    -Cette directive permet de définir les protocoles SSL que mod_ssl peut -utiliser lors de l'élaboration de son environnement de serveur pour la -fonction de mandataire. Il ne se connectera qu'aux serveurs utilisant un -des protocoles spécifiés.

    -

    Veuillez vous reporter à la directive SSLProtocol pour plus d'informations. -

    +wordlist ::= word + | wordlist "," word + +word ::= digit + | cstring + | variable + | function + +digit ::= [0-9]+ +cstring ::= "..." +variable ::= "%{" varname "}" +function ::= funcname "(" funcargs ")" + +

    Pour varname, toute variable décrite dans Variables d'environnement pourra être utilisée. +Pour funcname, vous trouverez la liste des fonctions +disponibles dans la documentation +ap_expr.

    +

    expression est interprétée et traduite +sous une forme machine interne lors du chargement de la configuration, +puis évaluée lors du traitement de la requête. Dans le contexte des +fichiers .htaccess, expression est interprétée et exécutée +chaque fois que le fichier .htaccess intervient lors du traitement de la +requête.

    +

    Exemple

    SSLRequire (    %{SSL_CIPHER} !~ m/^(EXP|NULL)-/                   \
+            and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd."          \
+            and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}    \
+            and %{TIME_WDAY} -ge 1 and %{TIME_WDAY} -le 5          \
+            and %{TIME_HOUR} -ge 8 and %{TIME_HOUR} -le 20       ) \
+           or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
    -
    top
    -

    Directive SSLProxyVerify

    - - - - - - - -
    Description:Niveau de vérification du certificat du serveur -distant
    Syntaxe:SSLProxyVerify niveau
    Défaut:SSLProxyVerify none
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    -

    Lorsqu'un mandataire est configuré pour faire suivre les requêtes -vers un serveur SSL distant, cette directive permet de configurer la -vérification du certificat de ce serveur distant.

    -

    -Les valeurs de niveaux disponibles sont les suivantes :

    +

    La fonction PeerExtList(identifiant objet) +recherche une instance d'extension de certificat X.509 identifiée par +identifiant objet (OID) dans le certificat client. L'expression est +évaluée à true si la partie gauche de la chaîne correspond exactement à +la valeur d'une extension identifiée par cet OID (Si plusieurs +extensions possèdent le même OID, l'une d'entre elles au moins doit +correspondre). +

    + +

    Exemple

    SSLRequire "foobar" in PeerExtList("1.2.3.4.5.6")
    +
    + +

    Notes à propos de la fonction PeerExtList

    +
      -
    • none: - aucun certificat n'est requis pour le serveur distant
      • -
    • optional: - le serveur distant peut présenter un certificat valide
      • -
    • require: - le serveur distant doit présenter un certificat valide
      • -
    • optional_no_ca: - le serveur distant peut présenter un certificat valide
      - mais il n'est pas nécessaire qu'il soit vérifiable (avec succès).
      • -
    -

    En pratique, seuls les niveaux none et -require sont vraiment intéressants, car le niveau -optional ne fonctionne pas avec tous les serveurs, et -le niveau optional_no_ca va tout à fait à l'encontre de -l'idée que l'on peut se faire de l'authentification (mais peut tout de -même être utilisé pour établir des pages de test SSL, etc...).

    -

    Exemple

    SSLProxyVerify require
    +

  • L'identifiant objet peut être spécifié soit comme un nom +descriptif reconnu par la bibliothèque SSL, tel que +"nsComment", soit comme un OID numérique tel que +"1.2.3.4.5.6".

    • + +

  • Les expressions contenant des types connus de la bibliothèque +SSL sont transformées en chaînes avant comparaison. Pour les extensions +contenant un type non connu de la bibliothèque SSL, mod_ssl va essayer +d'interpréter la valeur s'il s'agit d'un des types ASN.1 primaires UTF8String, +IA5String, VisibleString, ou BMPString. Si l'extension correspond à un +de ces types, la chaîne sera convertie en UTF-8 si nécessaire, puis +comparée avec la partie gauche de l'expression.

    • + +
    + +

    Voir aussi

    +
    top
    -

    Directive SSLProxyVerifyDepth

    +

    Directive SSLRequireSSL

    - - - - + + +
    Description:Niveau de profondeur maximum dans les certificats de CA -lors de la vérification du certificat du serveur distant
    Syntaxe:SSLProxyVerifyDepth niveau
    Défaut:SSLProxyVerifyDepth 1
    Contexte:configuration du serveur, serveur virtuel
    Description:Interdit l'accès lorsque la requête HTTP n'utilise pas +SSL
    Syntaxe:SSLRequireSSL
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_ssl

    -Cette directive permet de définir le niveau de profondeur maximum -jusqu'auquel mod_ssl doit aller au cours de sa vérification avant de -décider que le serveur distant ne possède pas de certificat valide.

    -

    -La profondeur correspond en fait au nombre maximum de fournisseurs de -certificats intermédiaires, c'est à dire le nombre maximum de -certificats -de CA que l'on peut consulter lors de la vérification du certificat du -serveur distant. Une profondeur de 0 signifie que seuls les certificats -de serveurs distants auto-signés sont acceptés, et la profondeur par -défaut de 1 que le certificat du serveur distant peut être soit -auto-signé, soit signé par une CA connue directement du serveur (en -d'autres termes, le certificat de CA est référencé par la directive -SSLProxyCACertificatePath), -etc...

    -

    Exemple

    SSLProxyVerifyDepth 10
    +Cette directive interdit l'accès si HTTP sur SSL (c'est à dire HTTPS) +n'est pas activé pour la connexion courante. Ceci est très pratique dans +un serveur virtuel où SSL est activé ou dans un répertoire pour se +protéger des erreurs de configuration qui pourraient donner accès à des +ressources protégées. Lorsque cette directive est présente, toutes les +requêtes qui n'utilisent pas SSL sont rejetées.

    +

    Exemple

    SSLRequireSSL
    top
    -

    Directive SSLRandomSeed

    +

    Directive SSLSessionCache

    - - + + +
    Description:Source de déclenchement du Générateur de Nombres -Pseudo-Aléatoires (PRNG)
    Syntaxe:SSLRandomSeed contexte source -[nombre]
    Description:Type du cache de session SSL global et +inter-processus
    Syntaxe:SSLSessionCache type
    Défaut:SSLSessionCache none
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ssl

    -Cette directive permet de définir une ou plusieurs sources de -déclenchement du Générateur de Nombres Pseudo-Aléatoires (PRNG) dans -OpenSSL au démarrage du serveur (si contexte a pour valeur -startup) et/ou juste avant l'établissement d'une nouvelle -connexion SSL (si contexte a pour valeur connect). -Cette directive ne peut être utilisée qu'au niveau du serveur global car -le PRNG est un service global.

    +Cette directive permet de configurer le type de stockage du cache de +session SSL global et inter-processus. Ce cache est une fonctionnalité +optionnelle qui accélère le traitement parallèle des requêtes. Pour ce +qui est des requêtes vers un même processus du serveur (via HTTP +keep-alive), OpenSSL met en cache les informations de session SSL en +interne. Mais comme les clients modernes demandent des images en ligne +et d'autres données via des requêtes parallèles (un nombre de quatre +requêtes parallèles est courant), ces requêtes vont être servies par +plusieurs processus du serveur pré-déclenchés. Ici, un cache +inter-processus permet d'éviter des négociations de session +inutiles.

    -Les différentes valeurs de source disponibles sont :

    +Les quatre types de stockage suivants sont actuellement +supportés :

      -
    • builtin -

      Cette source de déclenchement intégrée est toujours disponible. - Son utilisation consomme un minimum de cycles CPU en cours - d'exécution, et son utilisation ne présente de ce fait aucun - problème. La source utilisée pour déclencher le PRNG contient la - date courante, l'identifiant du processus courant et (si disponible) - un extrait de 1Ko aléatoirement choisi de la structure d'Apache pour - les échanges inter-processus. Ceci présente un inconvénient car le - caractère aléatoire de cette source n'est pas vraiment fort, et au - démarrage (lorsque la structure d'échanges n'est pas encore - disponible), cette source ne produit que quelques octets d'entropie. - Vous devez donc toujours utiliser une source de déclenchement - additionnelle, au moins pour le démarrage.

      • -
    • file:/chemin/vers/source -

      - Cette variante utilise un fichier externe - file:/chemin/vers/source comme source de déclenchement - du PRNG. Lorsque nombre est spécifié, seuls les - nombre premiers octets du fichier forment l'entropie (et - nombre est fourni comme premier argument à - /chemin/vers/source). Lorsque nombre n'est pas - spécifié, l'ensemble du fichier forme l'entropie (et 0 - est fourni comme premier argument à - /chemin/vers/source). Utilisez cette source en - particulier au démarrage, par exemple avec un fichier de - périphérique /dev/random et/ou - /dev/urandom (qui sont en général présent sur les - plate-formes dérivées d'Unix modernes comme FreeBSD et Linux).

      -

      Soyez cependant prudent : en général, - /dev/random ne fournit que l'entropie dont il dispose - réellement ; en d'autres termes, lorsque vous demandez 512 octets - d'entropie, si le périphérique ne dispose que de 100 octets, deux - choses peuvent se produire : sur certaines plates-formes, vous ne - recevez que les 100 octets, alors que sur d'autres, la lecture se - bloque jusqu'à ce qu'un nombre suffisant d'octets soit disponible - (ce qui peut prendre beaucoup de temps). Il est préférable ici - d'utiliser le périphérique /dev/urandom, car il ne se - bloque jamais et fournit vraiment la quantité de données demandées. - Comme inconvénient, les données reçues ne sont pas forcément de la - meilleure qualité.

      • +
    • none + +

      Cette valeur désactive le cache de session global et + inter-processus, ce qui va ralentir le serveur de manière sensible + et peut poser problème avec certains navigateurs, en particulier si + les certificats clients sont activés. Cette configuration n'est pas + recommandée.

      • + +
    • nonenotnull + +

      Cette valeur désactive tout cache de session global et + inter-processus. Cependant, elle force OpenSSL à envoyer un + identifiant de session non nul afin de s'adapter aux clients bogués + qui en nécessitent un.

      • + +
    • dbm:/chemin/vers/fichier-données + +

      Cette valeur utilise un fichier de hashage DBM sur disque local + pour synchroniser les caches OpenSSL locaux en mémoire des processus + du serveur. Ce cache de session peut être sujet à des problèmes de + fiabilité sous forte charge. Pour l'utiliser, le module + mod_socache_dbm doit être chargé.

      • + +
    • shmcb:/chemin/vers/fichier-données[(nombre)] + +

      Cette valeur utilise un tampon cyclique à hautes performances + (d'une taille d'environ nombre octets) dans un segment de + mémoire partagée en RAM (établi via + /chemin/vers/fichier-données, pour synchroniser les + caches OpenSSL locaux en mémoire des processus du serveur. C'est le + type de cache de session recommandé. Pour l'utiliser, le module + mod_socache_shmcb doit être chargé.

      • + +
    • dc:UNIX:/chemin/vers/socket + +

      Cette valeur utilise les bibliothèques de mise en cache de + sessions distribuée sur cache distant "distcache". + L'argument doit spécifier le serveur ou mandataire à utiliser en + utilisant la syntaxe d'adressage distcache ; par exemple, + UNIX:/chemin/vers/socket spécifie une socket de domaine + Unix (en général un mandataire de dc_client local) ; + IP:serveur.example.com:9001 spécifie une adresse IP. + Pour l'utiliser, le module mod_socache_dc doit être + chargé.

      • -
    • exec:/chemin/vers/programme -

      - Cette variante utilise un exécutable externe - /chemin/vers/programme comme source de déclenchement du - PRNG. Lorsque nombre est spécifié, seules les - nombre premiers octets de son flux stdout - forment l'entropie. Lorsque nombre n'est pas spécifié, - l'intégralité des données produites sur stdout forment - l'entropie. N'utilisez cette variante qu'au démarrage où une source - de déclenchement fortement aléatoire est nécessaire, en utilisant - un programme externe (comme dans l'exemple - ci-dessous avec l'utilitaire truerand basé sur la - bibliothèque truerand de AT&T que vous trouverez - dans la distribution de mod_ssl). Bien entendu, l'utilisation de - cette variante dans un contexte "connection" ralentit le serveur de - manière trop importante, et en général, vous devez donc éviter - d'utiliser des programmes externes dans ce contexte.

      • -
    • egd:/chemin/vers/socket-egd (Unix seulement) -

      Cette variante utilise le socket de domaine Unix du Démon - Générateur d'Entropie externe ou Entropy Gathering Daemon ou EGD - (voir http://www.lothar.com/tech - /crypto/) pour déclencher le PRNG. N'utilisez cette variante que - si votre plate-forme ne possède pas de périphérique random ou - urandom.

    -

    Exemple

    SSLRandomSeed startup builtin
-SSLRandomSeed startup file:/dev/random
-SSLRandomSeed startup file:/dev/urandom 1024
-SSLRandomSeed startup exec:/usr/local/bin/truerand 16
-SSLRandomSeed connect builtin
-SSLRandomSeed connect file:/dev/random
-SSLRandomSeed connect file:/dev/urandom 1024
    + +

    Exemples

    SSLSessionCache dbm:/usr/local/apache/logs/ssl_gcache_data
+SSLSessionCache shmcb:/usr/local/apache/logs/ssl_gcache_data(512000)
    +
    + +

    Le mutex ssl-cache permet de sérialiser l'accès au cache +de session afin d'éviter toute corruption. Ce mutex peut être configuré +via la directive Mutex.

    + +
    +
    top
    +

    Directive SSLSessionCacheTimeout

    + + + + + + + + +
    Description:Nombre de secondes avant l'expiration d'une session SSL +dans le cache de sessions
    Syntaxe:SSLSessionCacheTimeout secondes
    Défaut:SSLSessionCacheTimeout 300
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:S'applique aussi à la reprise de session TLS (RFC 5077) à +partir de la version 2.4.10 du serveur HTTP Apache
    +

    +Cette directive permet de définir la durée de vie en secondes des +informations stockées dans le cache de sessions SSL global et +inter-processus, dans le cache OpenSSL interne en mémoire et pour +les sessions réinitialisées par la reprise de session TLS (RFC 5077). elle peut +être définie à une valeur d'environ 15 à des fins de test, mais à une +valeur très supérieure comme 300 en production.

    +

    Exemple

    SSLSessionCacheTimeout 600
    top
    -

    Directive SSLRenegBufferSize

    +

    Directive SSLSessionTicketKeyFile

    - - - - - + + + +
    Description:Définit la taille du tampon de renégociation -SSL
    Syntaxe:SSLRenegBufferSize taille
    Défaut:SSLRenegBufferSize 131072
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Description:Clé de chiffrement/déchiffrement permanente pour les +tickets de session TLS
    Syntaxe:SSLSessionTicketKeyFile chemin-fichier
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible depuis la version 2.4.0 du serveur HTTP +Apache, sous réserve que l'on utilise une version 0.9.8h ou supérieure +d'OpenSSL
    +

    Cette directive permet de définir une clé secrète pour le chiffrement +et le déchiffrement des tickets de session TLS selon les préconisations +de la RFC 5077. Elle a +été conçue à l'origine pour les environnements de clusters où les +données des sessions TLS doivent être partagées entre plusieurs noeuds. +Pour les configurations ne comportant qu'une seule instance de httpd, il +est préférable d'utiliser les clés (aléatoires) générées par mod_ssl au +démarrage du serveur.

    +

    Le fichier doit contenir 48 octets de données aléatoires créées de +préférence par une source à haute entropie. Sur un système de type UNIX, +il est possible de créer le fichier contenant la clé de la manière +suivante :

    -

    Si une renégociation SSL est requise dans un contexte de répertoire, -par exemple avec l'utilisation de SSLVerifyClient dans un bloc Directory ou -Location, mod_ssl doit mettre en tampon en mémoire tout corps de requête -HTTP en attendant qu'une nouvelle initialisation de connexion SSL puisse -être effectuée. Cette directive permet de définir la quantité de mémoire -à allouer pour ce tampon.

    +

    +dd if=/dev/random of=/chemin/vers/fichier.tkey bs=1 count=48 +

    -

    -Notez que dans de nombreuses configurations, le client qui envoie un -corps de requête n'est pas forcément digne de confiance, et l'on doit -par conséquent prendre en considération la possibilité d'une attaque de -type déni de service lorsqu'on modifie la valeur de cette directive. -

    +

    Ces clés doivent être renouvelées fréquemment, car il s'agit du seul +moyen d'invalider un ticket de session existant - OpenSSL ne permet pas +actuellement de spécifier une limite à la durée de vie des tickets.

    -

    Exemple

    SSLRenegBufferSize 262144
    +
    +

    Ce fichier contient des données sensibles et doit donc être protégé +par des permissions similaires à celles du fichier spécifié par la +directive SSLCertificateKeyFile.

    top
    -

    Directive SSLRequire

    +

    Directive SSLSessionTickets

    - - - - + + + + +
    Description:N'autorise l'accès que lorsqu'une expression booléenne -complexe et arbitraire est vraie
    Syntaxe:SSLRequire expression
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Description:Active ou désactive les tickets de session TLS
    Syntaxe:SSLSessionTickets on|off
    Défaut:SSLSessionTickets on
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible à partir de la version 2.4.11 du serveur HTTP +Apache, sous réserve d'utiliser OpenSSL version 0.9.8f ou supérieure. +
    -

    SSLRequire est obsolète

    -

    SSLRequire est obsolète et doit en général être -remplacée par l'expression Require. La syntaxe ap_expr de l'expression Require est -une extension de la syntaxe de SSLRequire, avec les -différences suivantes :

    +

    Cette directive permet d'activer ou de désactiver l'utilisation des +tickets de session TLS (RFC 5077).

    +
    +

    Les tickets de session TLS sont activés par défaut. Les utiliser sans +redémarrer le serveur selon une périodicité appropriée (par exemple +quotidiennement) compromet cependant le niveau de confidentialité.

    +
    -

    Avec SSLRequire, les opérateurs de comparaison -<, <=, ... sont strictement équivalents -aux opérateurs lt, le, ... , et fonctionnent -selon une méthode qui compare tout d'abord la longueur des deux chaînes, -puis l'ordre alphabétique. Les expressions ap_expr, quant à elles, possèdent deux jeux -d'opérateurs de comparaison : les opérateurs <, -<=, ... effectuent une comparaison alphabétique de -chaînes, alors que les opérateurs -lt, -le, -... effectuent une comparaison d'entiers. Ces derniers possèdent aussi -des alias sans tiret initial : lt, le, ... +

    +
    top
    +

    Directive SSLSRPUnknownUserSeed

    + + + + + + + +
    Description:Source d'aléa pour utilisateur SRP inconnu
    Syntaxe:SSLSRPUnknownUserSeed secret-string
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible depuis la version 2.4.4 du serveur HTTP +Apache, si la version 1.0.1 ou supérieure d'OpenSSL est utilisée.
    +

    +Cette directive permet de définir la source d'aléa à utiliser +pour les utilisateurs SRP inconnus, ceci afin de combler les manques en +cas d'existence d'un tel utilisateur. Elle définit une chaîne secrète. Si +cette directive n'est pas définie, Apache renverra une alerte +UNKNOWN_PSK_IDENTITY aux clients qui fournissent un nom d'utilisateur +inconnu.

    +

    Exemple

    +SSLSRPUnknownUserSeed "secret" +

    - -

    Cette directive permet de spécifier une condition générale d'accès -qui doit être entièrement satisfaite pour que l'accès soit autorisé. -C'est une directive très puissante, car la condition d'accès spécifiée -est une expression booléenne complexe et arbitraire contenant un nombre -quelconque de vérifications quant aux autorisations d'accès.

    +
    top
    +

    Directive SSLSRPVerifierFile

    + + + + + + + +
    Description:Chemin du fichier de vérification SRP
    Syntaxe:SSLSRPVerifierFile file-path
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible depuis la version 2.4.4 du serveur HTTP +Apache, si la version 1.0.1 ou supérieure d'OpenSSL est utilisée.

    -L'expression doit respecter la syntaxe suivante (fournie ici -sous la forme d'une notation dans le style de la grammaire BNF) :

    -
    -
    expr     ::= "true" | "false"
-           | "!" expr
-           | expr "&&" expr
-           | expr "||" expr
-           | "(" expr ")"
-           | comp
-
-comp     ::= word "==" word | word "eq" word
-           | word "!=" word | word "ne" word
-           | word "<"  word | word "lt" word
-           | word "<=" word | word "le" word
-           | word ">"  word | word "gt" word
-           | word ">=" word | word "ge" word
-           | word "in" "{" wordlist "}"
-           | word "in" "PeerExtList(" word ")"
-           | word "=~" regex
-           | word "!~" regex
+Cette directive permet d'activer TLS-SRP et de définir le chemin du
+fichier de vérification OpenSSL SRP (Mot de passe distant sécurisé)
+contenant les noms d'utilisateurs TLS-SRP, les vérificateurs, les
+"grains de sel" (salts), ainsi que les paramètres de groupe.
    
+
    Exemple
    
+SSLSRPVerifierFile "/path/to/file.srpv"
+
    
+
    
+Le fichier de vérification peut être créé via l'utilitaire en ligne de
+commande openssl :
    
+
    Création du fichier de vérification SRP
    
+openssl srp -srpvfile passwd.srpv -userinfo "some info" -add username
+
    
+
    La valeur affectée au paramètre optionnel -userinfo est
+enregistrée dans la variable d'environnement
+SSL_SRP_USERINFO.
    
 
-wordlist ::= word
-           | wordlist "," word
 
-word     ::= digit
-           | cstring
-           | variable
-           | function
+
    +
    top
    +

    Directive SSLStaplingCache

    + + + + + + + +
    Description:Configuration du cache pour l'agrafage OCSP
    Syntaxe:SSLStaplingCache type
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible si on utilise OpenSSL version 0.9.8h ou supérieure
    +

    Si SSLUseStapling est à "on", +cette directive permet de configurer le cache destiné à stocker les +réponses OCSP incluses dans la négociation TLS. La configuration d'un +cache est obligatoire pour pouvoir utiliser l'agrafage OCSP. A +l'exception de none et nonenotnull, cette +directive supporte les mêmes types de stockage que la directive +SSLSessionCache.

    -digit ::= [0-9]+ -cstring ::= "..." -variable ::= "%{" varname "}" -function ::= funcname "(" funcargs ")" - -

    Pour varname, toute variable décrite dans Variables d'environnement pourra être utilisée. -Pour funcname, vous trouverez la liste des fonctions -disponibles dans la documentation -ap_expr.

    +

    Le mutex ssl-stapling permet de sérialiser l'accès au +cache d'agrafage OCSP afin d'en prévenir la corruption. Ce mutex peut +être configuré via la directive Mutex.

    -

    expression est interprétée et traduite -sous une forme machine interne lors du chargement de la configuration, -puis évaluée lors du traitement de la requête. Dans le contexte des -fichiers .htaccess, expression est interprétée et exécutée -chaque fois que le fichier .htaccess intervient lors du traitement de la -requête.

    -

    Exemple

    SSLRequire (    %{SSL_CIPHER} !~ m/^(EXP|NULL)-/                   \
-            and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd."          \
-            and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}    \
-            and %{TIME_WDAY} -ge 1 and %{TIME_WDAY} -le 5          \
-            and %{TIME_HOUR} -ge 8 and %{TIME_HOUR} -le 20       ) \
-           or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
    +
    top
    +

    Directive SSLStaplingErrorCacheTimeout

    + + + + + + + + +
    Description:Durée de vie des réponses invalides dans le cache pour +agrafage OCSP
    Syntaxe:SSLStaplingErrorCacheTimeout secondes
    Défaut:SSLStaplingErrorCacheTimeout 600
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible si on utilise OpenSSL version 0.9.8h ou supérieure
    +

    Cette directive permet de définir la durée de vie des réponses +invalides dans le cache pour agrafage OCSP configuré via la +directive SSLStaplingCache. Pour +définir la durée de vie des réponses valides, voir la directive +SSLStaplingStandardCacheTimeout.

    +
    +
    top
    +

    Directive SSLStaplingFakeTryLater

    + + + + + + + + +
    Description:Génère une réponse "tryLater" pour les requêtes OCSP échouées
    Syntaxe:SSLStaplingFakeTryLater on|off
    Défaut:SSLStaplingFakeTryLater on
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible si on utilise OpenSSL version 0.9.8h ou supérieure
    +

    Lorsque cette directive est activée, et si une requête vers un +serveur OCSP à des fins d'inclusion dans une négociation TLS échoue, +mod_ssl va générer une réponse "tryLater" pour le client (SSLStaplingReturnResponderErrors doit être +activée).

    -

    La fonction PeerExtList(identifiant objet) -recherche une instance d'extension de certificat X.509 identifiée par -identifiant objet (OID) dans le certificat client. L'expression est -évaluée à true si la partie gauche de la chaîne correspond exactement à -la valeur d'une extension identifiée par cet OID (Si plusieurs -extensions possèdent le même OID, l'une d'entre elles au moins doit -correspondre). -

    - -

    Exemple

    SSLRequire "foobar" in PeerExtList("1.2.3.4.5.6")
    +
    top
    +

    Directive SSLStaplingForceURL

    + + + + + + + +
    Description:Remplace l'URI du serveur OCSP spécifié dans l'extension +AIA du certificat
    Syntaxe:SSLStaplingForceURL uri
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible si on utilise OpenSSL version 0.9.8h ou supérieure
    +

    Cette directive permet de remplacer l'URI du serveur OCSP extraite de +l'extension authorityInfoAccess (AIA) du certificat. Elle peut s'avérer +utile lorsqu'on passe par un mandataire

    -

    Notes à propos de la fonction PeerExtList

    - -
      - -

    • L'identifiant objet peut être spécifié soit comme un nom -descriptif reconnu par la bibliothèque SSL, tel que -"nsComment", soit comme un OID numérique tel que -"1.2.3.4.5.6".

      • - -

    • Les expressions contenant des types connus de la bibliothèque -SSL sont transformées en chaînes avant comparaison. Pour les extensions -contenant un type non connu de la bibliothèque SSL, mod_ssl va essayer -d'interpréter la valeur s'il s'agit d'un des types ASN.1 primaires UTF8String, -IA5String, VisibleString, ou BMPString. Si l'extension correspond à un -de ces types, la chaîne sera convertie en UTF-8 si nécessaire, puis -comparée avec la partie gauche de l'expression.

      • +
    +
    top
    +

    Directive SSLStaplingResponderTimeout

    + + + + + + + + +
    Description:Temps d'attente maximum pour les requêtes vers les serveurs +OCSP
    Syntaxe:SSLStaplingResponderTimeout secondes
    Défaut:SSLStaplingResponderTimeout 10
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible si on utilise OpenSSL version 0.9.8h ou supérieure
    +

    Cette directive permet de définir le temps d'attente maximum lorsque +mod_ssl envoie une requête vers un serveur OCSP afin d'obtenir une +réponse destinée à être incluse dans les négociations TLS avec les +clients (SSLUseStapling doit +avoir été activée au préalable).

    -
    +
    top
    +

    Directive SSLStaplingResponseMaxAge

    + + + + + + + + +
    Description:Age maximum autorisé des réponses OCSP incluses dans la +négociation TLS
    Syntaxe:SSLStaplingResponseMaxAge secondes
    Défaut:SSLStaplingResponseMaxAge -1
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible si on utilise OpenSSL version 0.9.8h ou supérieure
    +

    Cette directive permet de définir l'âge maximum autorisé +("fraîcheur") des réponses OCSP incluses dans la négociation TLS +(SSLUseStapling doit +avoir été activée au préalable). La valeur par défaut (-1) +ne définit aucun âge maximum, ce qui signifie que les réponses OCSP sont +considérées comme valides à partir du moment où le contenu de leur champ +nextUpdate se trouve dans le futur.

    +
    +
    top
    +

    Directive SSLStaplingResponseTimeSkew

    + + + + + + + + +
    Description:Durée de vie maximale autorisée des réponses OCSP incluses dans la +négociation TLS
    Syntaxe:SSLStaplingResponseTimeSkew secondes
    Défaut:SSLStaplingResponseTimeSkew 300
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible si on utilise OpenSSL version 0.9.8h ou supérieure
    +

    Cette directive permet de spécifier l'intervalle de temps maximum que +mod_ssl va calculer en faisant la différence entre les contenus des +champs nextUpdate et thisUpdate des réponses +OCSP incluses dans la négociation TLS. Pour pouvoir utiliser cette +directive, SSLUseStapling doit +être à "on".

    -

    Voir aussi

    -
    top
    -

    Directive SSLRequireSSL

    +

    Directive SSLStaplingReturnResponderErrors

    - - - - + + + + +
    Description:Interdit l'accès lorsque la requête HTTP n'utilise pas -SSL
    Syntaxe:SSLRequireSSL
    Contexte:répertoire, .htaccess
    AllowOverride:AuthConfig
    Description:Transmet au client les erreurs survenues lors des requêtes +OCSP
    Syntaxe:SSLStaplingReturnResponderErrors on|off
    Défaut:SSLStaplingReturnResponderErrors on
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible si on utilise OpenSSL version 0.9.8h ou supérieure
    -

    -Cette directive interdit l'accès si HTTP sur SSL (c'est à dire HTTPS) -n'est pas activé pour la connexion courante. Ceci est très pratique dans -un serveur virtuel où SSL est activé ou dans un répertoire pour se -protéger des erreurs de configuration qui pourraient donner accès à des -ressources protégées. Lorsque cette directive est présente, toutes les -requêtes qui n'utilisent pas SSL sont rejetées.

    -

    Exemple

    SSLRequireSSL
    +

    Lorsque cette directive est activée, mod_ssl va transmettre au client les +réponses concernant les requêtes OCSP échouées (erreurs d'état, réponses +périmées, etc...). Lorsqu'elle est à off, aucune réponse +concernant les requêtes OCSP échouées ne sera incluse dans les +négociation TLS avec les clients.

    +
    +
    top
    +

    Directive SSLStaplingStandardCacheTimeout

    + + + + + + + + +
    Description:Durée de vie des réponses OCSP dans le cache
    Syntaxe:SSLStaplingStandardCacheTimeout secondes
    Défaut:SSLStaplingStandardCacheTimeout 3600
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible si on utilise OpenSSL version 0.9.8h ou supérieure
    +

    Cette directive permet de définir la durée de vie des réponses OCSP +dans le cache configuré via la directive SSLStaplingCache. Elle ne s'applique qu'aux +réponse valides, alors que la directive SSLStaplingErrorCacheTimeout s'applique aux +réponses invalides ou non disponibles. +

    top
    -

    Directive SSLSessionCache

    +

    Directive SSLStrictSNIVHostCheck

    - - - - + + + + +
    Description:Type du cache de session SSL global et -inter-processus
    Syntaxe:SSLSessionCache type
    Défaut:SSLSessionCache none
    Contexte:configuration du serveur
    Description:Contrôle de l'accès des clients non-SNI à un serveur virtuel à +base de nom. +
    Syntaxe:SSLStrictSNIVHostCheck on|off
    Défaut:SSLStrictSNIVHostCheck off
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible depuis la version 2.2.12 d'Apache

    -Cette directive permet de configurer le type de stockage du cache de -session SSL global et inter-processus. Ce cache est une fonctionnalité -optionnelle qui accélère le traitement parallèle des requêtes. Pour ce -qui est des requêtes vers un même processus du serveur (via HTTP -keep-alive), OpenSSL met en cache les informations de session SSL en -interne. Mais comme les clients modernes demandent des images en ligne -et d'autres données via des requêtes parallèles (un nombre de quatre -requêtes parallèles est courant), ces requêtes vont être servies par -plusieurs processus du serveur pré-déclenchés. Ici, un cache -inter-processus permet d'éviter des négociations de session -inutiles.

    -

    -Les quatre types de stockage suivants sont actuellement -supportés :

    -
      -
    • none - -

      Cette valeur désactive le cache de session global et - inter-processus, ce qui va ralentir le serveur de manière sensible - et peut poser problème avec certains navigateurs, en particulier si - les certificats clients sont activés. Cette configuration n'est pas - recommandée.

      • - -
    • nonenotnull - -

      Cette valeur désactive tout cache de session global et - inter-processus. Cependant, elle force OpenSSL à envoyer un - identifiant de session non nul afin de s'adapter aux clients bogués - qui en nécessitent un.

      • - -
    • dbm:/chemin/vers/fichier-données - -

      Cette valeur utilise un fichier de hashage DBM sur disque local - pour synchroniser les caches OpenSSL locaux en mémoire des processus - du serveur. Ce cache de session peut être sujet à des problèmes de - fiabilité sous forte charge. Pour l'utiliser, le module - mod_socache_dbm doit être chargé.

      • - -
    • shmcb:/chemin/vers/fichier-données[(nombre)] +Cette directive permet de contrôler l'accès des clients non-SNI à un serveur +virtuel à base de nom. Si elle est définie à on dans le +serveur virtuel à base de nom par défaut, les +clients non-SNI ne seront autorisés à accéder à aucun serveur virtuel +appartenant à cette combinaison IP/port. Par +contre, si elle est définie à on dans un serveur virtuel +quelconque, les clients non-SNI ne se verront interdire l'accès qu'à ce +serveur. +

      -

      Cette valeur utilise un tampon cyclique à hautes performances - (d'une taille d'environ nombre octets) dans un segment de - mémoire partagée en RAM (établi via - /chemin/vers/fichier-données, pour synchroniser les - caches OpenSSL locaux en mémoire des processus du serveur. C'est le - type de cache de session recommandé. Pour l'utiliser, le module - mod_socache_shmcb doit être chargé.

      • +

      +Cette option n'est disponible que si httpd a été compilé avec une +version d'OpenSSL supportant SNI. +

      -
    • dc:UNIX:/chemin/vers/socket +

      Exemple

      SSLStrictSNIVHostCheck on
      +
      -

      Cette valeur utilise les bibliothèques de mise en cache de - sessions distribuée sur cache distant "distcache". - L'argument doit spécifier le serveur ou mandataire à utiliser en - utilisant la syntaxe d'adressage distcache ; par exemple, - UNIX:/chemin/vers/socket spécifie une socket de domaine - Unix (en général un mandataire de dc_client local) ; - IP:serveur.example.com:9001 spécifie une adresse IP. - Pour l'utiliser, le module mod_socache_dc doit être - chargé.

      • +
    +
    top
    +

    Directive SSLUserName

    + + + + + + + +
    Description:Nom de la variable servant à déterminer le nom de +l'utilisateur
    Syntaxe:SSLUserName nom-var
    Contexte:configuration du serveur, répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_ssl
    +

    +Cette variable permet de définir le champ "user" de l'objet de la +requête Apache. Ce champ est utilisé par des modules de plus bas niveau +pour identifier l'utilisateur avec une chaîne de caractères. En +particulier, l'utilisation de cette directive peut provoquer la +définition de la variable d'environnement REMOTE_USER. +La valeur de l'argument nom-var peut correspondre à toute variable d'environnement SSL.

    - +

    Notez que cette directive est sans effet si l'option +FakeBasicAuth est utilisée (voir SSLOptions).

    + +

    Exemple

    SSLUserName SSL_CLIENT_S_DN_CN
    +
    -

    Exemples

    SSLSessionCache dbm:/usr/local/apache/logs/ssl_gcache_data
-SSLSessionCache shmcb:/usr/local/apache/logs/ssl_gcache_data(512000)
    +
    top
    +

    Directive SSLUseStapling

    + + + + + + + + +
    Description:Active l'ajout des réponses OCSP à la négociation TLS
    Syntaxe:SSLUseStapling on|off
    Défaut:SSLUseStapling off
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible si on utilise OpenSSL version 0.9.8h ou supérieure
    +

    Cette directive permet d'activer l'"Agrafage OCSP" (OCSP stapling) +selon la définition de l'extension TLS "Certificate Status Request" +fournie dans la RFC 6066. Si elle est activée et si le client le +demande, mod_ssl va inclure une réponse OCSP à propos de son propre +certificat dans la négociation TLS. Pour pouvoir activer l'Agrafage +OCSP, il est nécessaire de configurer un SSLStaplingCache.

    -

    Le mutex ssl-cache permet de sérialiser l'accès au cache -de session afin d'éviter toute corruption. Ce mutex peut être configuré -via la directive Mutex.

    +

    L'agrafage OCSP dispense le client de requérir le serveur OCSP +directement ; il faut cependant noter que selon les spécifications de la +RFC 6066, la réponse CertificateStatus du serveur ne peut +inclure une réponse OCSP que pour un seul certificat. Pour les +certificats de serveur comportant des certificats de CA intermédiaires +dans leur chaîne (c'est un cas typique de nos jours), l'implémentation +actuelle de l'agrafage OCSP n'atteint que partiellement l'objectif d' +"économie en questions/réponse et en ressources". Pour plus de détails, +voir la RFC 6961 (TLS +Multiple Certificate Status Extension). +

    top
    -

    Directive SSLSessionCacheTimeout

    +

    Directive SSLVerifyClient

    - - - - + + + + + -
    Description:Nombre de secondes avant l'expiration d'une session SSL -dans le cache de sessions
    Syntaxe:SSLSessionCacheTimeout secondes
    Défaut:SSLSessionCacheTimeout 300
    Contexte:configuration du serveur, serveur virtuel
    Description:Niveau de vérification du certificat client
    Syntaxe:SSLVerifyClient niveau
    Défaut:SSLVerifyClient none
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_ssl
    Compatibilité:S'applique aussi à la reprise de session TLS (RFC 5077) à -partir de la version 2.4.10 du serveur HTTP Apache

    -Cette directive permet de définir la durée de vie en secondes des -informations stockées dans le cache de sessions SSL global et -inter-processus, dans le cache OpenSSL interne en mémoire et pour -les sessions réinitialisées par la reprise de session TLS (RFC 5077). elle peut -être définie à une valeur d'environ 15 à des fins de test, mais à une -valeur très supérieure comme 300 en production.

    -

    Exemple

    SSLSessionCacheTimeout 600
    +Cette directive permet de définir le niveau de vérification du +certificat pour l'authentification du client. Notez que cette directive +peut être utilisée à la fois dans les contextes du serveur principal et +du répertoire. Dans le contexte du serveur principal, elle s'applique au +processus d'authentification du client utilisé au cours de la +négociation SSL standard lors de l'établissement d'une connexion. Dans +un contexte de répertoire, elle force une renégociation SSL avec le +niveau de vérification du client spécifié, après la lecture d'une +requête HTTP, mais avant l'envoi de la réponse HTTP.

    +

    +Les valeurs de niveau disponibles sont les suivantes :

    +
      +
    • none: + aucun certificat client n'est requis
      • +
    • optional: + le client peut présenter un certificat valide
      • +
    • require: + le client doit présenter un certificat valide
      • +
    • optional_no_ca: + le client peut présenter un certificat valide, mais il n'est pas + nécessaire que ce dernier soit vérifiable (avec succès).
      • +
    +

    En pratique, seuls les niveaux none et +require sont vraiment intéressants, car le niveau +optional ne fonctionne pas avec tous les navigateurs, +et le niveau optional_no_ca va vraiment à l'encontre de +l'idée que l'on peut se faire de l'authentification (mais peut tout de +même être utilisé pour établir des pages de test SSL, etc...)

    +

    Exemple

    SSLVerifyClient require
    top
    -

    Directive SSLSessionTicketKeyFile

    +

    Directive SSLVerifyDepth

    - - - + + + + + -
    Description:Clé de chiffrement/déchiffrement permanente pour les -tickets de session TLS
    Syntaxe:SSLSessionTicketKeyFile chemin-fichier
    Contexte:configuration du serveur, serveur virtuel
    Description:Profondeur maximale des certificats de CA pour la +vérification des certificats clients
    Syntaxe:SSLVerifyDepth nombre
    Défaut:SSLVerifyDepth 1
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible depuis la version 2.4.0 du serveur HTTP -Apache, sous réserve que l'on utilise une version 0.9.8h ou supérieure -d'OpenSSL
    -

    Cette directive permet de définir une clé secrète pour le chiffrement -et le déchiffrement des tickets de session TLS selon les préconisations -de la RFC 5077. Elle a -été conçue à l'origine pour les environnements de clusters où les -données des sessions TLS doivent être partagées entre plusieurs noeuds. -Pour les configurations ne comportant qu'une seule instance de httpd, il -est préférable d'utiliser les clés (aléatoires) générées par mod_ssl au -démarrage du serveur.

    -

    Le fichier doit contenir 48 octets de données aléatoires créées de -préférence par une source à haute entropie. Sur un système de type UNIX, -il est possible de créer le fichier contenant la clé de la manière -suivante :

    +

    +Cette directive permet de spécifier la profondeur maximale à laquelle +mod_ssl va effectuer sa vérification avant de décider que le client ne +possède pas de certificat valide. Notez que cette directive peut être +utilisée à la fois dans les contextes du serveur principal et de +répertoire. Dans le contexte du serveur principal, elle s'applique au +processus d'authentification du client utilisé au cours de la +négociation SSL standard lors de l'établissement d'une connexion. Dans +un contexte de répertoire, elle force une renégociation SSL avec le +client selon la nouvelle profondeur spécifiée, après la lecture d'une +requête HTTP, mais avant l'envoi de la réponse HTTP.

    +

    +La profondeur correspond au nombre maximum de fournisseurs de +certificats intermédiaires, c'est à dire le nombre maximum de +certificats de CA que l'on est autorisé à suivre lors de la vérification +du certificat du client. Une profondeur de 0 signifie que seuls les +certificats clients auto-signés sont acceptés ; la profondeur par défaut +de 1 signifie que le certificat client peut être soit auto-signé, soit +signé par une CA connue directement du serveur (c'est à dire que le +certificat de la CA doit être référencé par la directive SSLCACertificatePath), etc...

    +

    Exemple

    SSLVerifyDepth 10
    +
    + +
    +
    top
    +
    +

    Variables d'environnement

    + +

    Ce module peut être configuré pour fournir aux espaces de nommage SSI +et CGI de nombreux éléments d'informations concernant SSL par le biais +de variables d'environnement supplémentaires. Par défaut, et pour +des raisons de performances, ces informations ne sont pas fournies (Voir +la directive SSLOptions StdEnvVars ci-dessous). +Les variables générées se trouvent dans la table ci-dessous. +Ces informations peuvent également être disponible sous des noms différents +à des fins de compatibilité ascendante. Reportez-vous au chapitre Compatibilité pour plus de détails à +propos des variables de compatibilité.

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Nom de la variable :Type de valeur :Description :
    HTTPS drapeauHTTPS est utilisé.
    SSL_PROTOCOL chaîneLa version du protocole SSL (SSLv3, TLSv1, TLSv1.1, TLSv1.2)
    SSL_SESSION_ID chaîneL'identifiant de session SSL codé en hexadécimal
    SSL_SESSION_RESUMED chaîneSession SSL initiale ou reprise. Note : plusieurs requêtes peuvent +être servies dans le cadre de la même session SSL (initiale ou reprise) +si les connexions persistantes (HTTP KeepAlive) sont utilisées
    SSL_SECURE_RENEG chaînetrue si la renégociation sécurisée est supportée, +false dans le cas contraire
    SSL_CIPHER chaîneLe nom de l'algorithme de chiffrement
    SSL_CIPHER_EXPORT chaînetrue si l'algorithme de chiffrement est un algorithme +exporté
    SSL_CIPHER_USEKEYSIZE nombreNombre de bits de chiffrement (réellement utilisés)
    SSL_CIPHER_ALGKEYSIZE nombreNombre de bits de chiffrement (possible)
    SSL_COMPRESS_METHOD chaîneMéthode de compression SSL négociée
    SSL_VERSION_INTERFACE chaîneLa version du programme mod_ssl
    SSL_VERSION_LIBRARY chaîneLa version du programme OpenSSL
    SSL_CLIENT_M_VERSION chaîneLa version du certificat client
    SSL_CLIENT_M_SERIAL chaîneLe numéro de série du certificat client
    SSL_CLIENT_S_DN chaîneLe DN sujet du certificat client
    SSL_CLIENT_S_DN_x509 chaîneElément du DN sujet du client
    SSL_CLIENT_I_DN chaîneDN de l'émetteur du certificat du client
    SSL_CLIENT_I_DN_x509 chaîneElément du DN de l'émetteur du certificat du client
    SSL_CLIENT_V_START chaîneValidité du certificat du client (date de début)
    SSL_CLIENT_V_END chaîneValidité du certificat du client (date de fin)
    SSL_CLIENT_V_REMAIN chaîneNombre de jours avant expiration du certificat du client
    SSL_CLIENT_A_SIG chaîneAlgorithme utilisé pour la signature du certificat du client
    SSL_CLIENT_A_KEY chaîneAlgorithme utilisé pour la clé publique du certificat du client
    SSL_CLIENT_CERT chaîneCertificat du client au format PEM
    SSL_CLIENT_CERT_CHAIN_nchaîne Certificats de la chaîne de certification du +client au format PEM
    SSL_CLIENT_CERT_RFC4523_CEA chaîneNuméro de série et fournisseur du certificat. le format correspond à +celui de la CertificateExactAssertion dans la RFC4523
    SSL_CLIENT_VERIFY chaîneNONE, SUCCESS, GENEROUS ou +FAILED:raison
    SSL_SERVER_M_VERSION chaîneLa version du certificat du serveur
    SSL_SERVER_M_SERIAL chaîne + +The serial of the server certificate
    SSL_SERVER_S_DN chaîneDN sujet du certificat du serveur
    SSL_SERVER_S_DN_x509 chaîneElément du DN sujet du certificat du serveur
    SSL_SERVER_I_DN chaîneDN de l'émetteur du certificat du serveur
    SSL_SERVER_I_DN_x509 chaîneElément du DN de l'émetteur du certificat du serveur
    SSL_SERVER_V_START chaîneValidité du certificat du serveur (date de dédut)
    SSL_SERVER_V_END chaîneValidité du certificat du serveur (date de fin)
    SSL_SERVER_A_SIG chaîneAlgorithme utilisé pour la signature du certificat du serveur
    SSL_SERVER_A_KEY chaîneAlgorithme utilisé pour la clé publique du certificat du serveur
    SSL_SERVER_CERT chaîneCertificat du serveur au format PEM
    SSL_SRP_USER chaînenom d'utilisateur SRP
    SSL_SRP_USERINFO chaîneinformations sur l'utilisateur SRP
    SSL_TLS_SNI stringContenu de l'extension SNI TLS (si supporté par ClientHello)
    + +

    x509 spécifie un élément de DN X.509 parmi +C,ST,L,O,OU,CN,T,I,G,S,D,UID,Email. A partir de la version +2.1 d'Apache, x509 peut aussi comporter un suffixe numérique +_n. Si le DN en question comporte plusieurs attributs de +noms identiques, ce suffixe constitue un index débutant à zéro et +permettant de sélectionner un +attribut particulier. Par exemple, si le DN sujet du certificat du +serveur comporte deux champs OU, on peut utiliser +SSL_SERVER_S_DN_OU_0 et SSL_SERVER_S_DN_OU_1 +pour référencer chacun d'entre eux. Un nom de variable sans suffixe +_n est équivalent au même nom avec le suffixe +_0, ce qui correspond au premier attribut (ou au seul) +caractérisant le DN. +Lorsque la table d'environnement est remplie en utilisant l'option +StdEnvVars de la directive SSLOptions, le premier attribut (ou le +seul) caractérisant le DN est enregistré avec un nom sans suffixe ; +autrement dit, aucune entrée possédant comme suffixe _0 +n'est enregistrée.

    -

    -dd if=/dev/random of=/chemin/vers/fichier.tkey bs=1 count=48 -

    +

    Le format des variables *_DN a changé depuis la version +2.3.11 d'Apache HTTPD. Voir l'option LegacyDNStringFormat +de la directive SSLOptions pour +plus de détails.

    -

    Ces clés doivent être renouvelées fréquemment, car il s'agit du seul -moyen d'invalider un ticket de session existant - OpenSSL ne permet pas -actuellement de spécifier une limite à la durée de vie des tickets.

    +

    SSL_CLIENT_V_REMAIN n'est disponible qu'à partir de la +version 2.1.

    -
    -

    Ce fichier contient des données sensibles et doit donc être protégé -par des permissions similaires à celles du fichier spécifié par la -directive SSLCertificateKeyFile.

    -
    +

    Plusieurs variables d'environnement additionnelles peuvent être +utilisées dans les expressions SSLRequire, ou +dans les formats de journalisation personnalisés :

    -
    -
    top
    -

    Directive SSLSessionTickets

    - - - - - - - - -
    Description:Active ou désactive les tickets de session TLS
    Syntaxe:SSLSessionTickets on|off
    Défaut:SSLSessionTickets on
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible à partir de la version 2.4.11 du serveur HTTP -Apache, sous réserve d'utiliser OpenSSL version 0.9.8f ou supérieure. -
    -

    Cette directive permet d'activer ou de désactiver l'utilisation des -tickets de session TLS (RFC 5077).

    -
    -

    Les tickets de session TLS sont activés par défaut. Les utiliser sans -redémarrer le serveur selon une périodicité appropriée (par exemple -quotidiennement) compromet cependant le niveau de confidentialité.

    -
    +
    HTTP_USER_AGENT        PATH_INFO             AUTH_TYPE
+HTTP_REFERER           QUERY_STRING          SERVER_SOFTWARE
+HTTP_COOKIE            REMOTE_HOST           API_VERSION
+HTTP_FORWARDED         REMOTE_IDENT          TIME_YEAR
+HTTP_HOST              IS_SUBREQ             TIME_MON
+HTTP_PROXY_CONNECTION  DOCUMENT_ROOT         TIME_DAY
+HTTP_ACCEPT            SERVER_ADMIN          TIME_HOUR
+THE_REQUEST            SERVER_NAME           TIME_MIN
+REQUEST_FILENAME       SERVER_PORT           TIME_SEC
+REQUEST_METHOD         SERVER_PROTOCOL       TIME_WDAY
+REQUEST_SCHEME         REMOTE_ADDR           TIME
+REQUEST_URI            REMOTE_USER
    -
    -
    top
    -

    Directive SSLSRPUnknownUserSeed

    - - - - - - - -
    Description:Source d'aléa pour utilisateur SRP inconnu
    Syntaxe:SSLSRPUnknownUserSeed secret-string
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible depuis la version 2.4.4 du serveur HTTP -Apache, si la version 1.0.1 ou supérieure d'OpenSSL est utilisée.
    -

    -Cette directive permet de définir la source d'aléa à utiliser -pour les utilisateurs SRP inconnus, ceci afin de combler les manques en -cas d'existence d'un tel utilisateur. Elle définit une chaîne secrète. Si -cette directive n'est pas définie, Apache renverra une alerte -UNKNOWN_PSK_IDENTITY aux clients qui fournissent un nom d'utilisateur -inconnu. -

    -

    Exemple

    -SSLSRPUnknownUserSeed "secret" -

    +

    Dans ces contextes, deux formats spéciaux peuvent aussi être utilisés +:

    -
    -
    top
    -

    Directive SSLSRPVerifierFile

    - - - - - - - -
    Description:Chemin du fichier de vérification SRP
    Syntaxe:SSLSRPVerifierFile file-path
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible depuis la version 2.4.4 du serveur HTTP -Apache, si la version 1.0.1 ou supérieure d'OpenSSL est utilisée.
    -

    -Cette directive permet d'activer TLS-SRP et de définir le chemin du -fichier de vérification OpenSSL SRP (Mot de passe distant sécurisé) -contenant les noms d'utilisateurs TLS-SRP, les vérificateurs, les -"grains de sel" (salts), ainsi que les paramètres de groupe.

    -

    Exemple

    -SSLSRPVerifierFile "/path/to/file.srpv" -

    -

    -Le fichier de vérification peut être créé via l'utilitaire en ligne de -commande openssl :

    -

    Création du fichier de vérification SRP

    -openssl srp -srpvfile passwd.srpv -userinfo "some info" -add username -

    -

    La valeur affectée au paramètre optionnel -userinfo est -enregistrée dans la variable d'environnement -SSL_SRP_USERINFO.

    +
    +
    ENV:nom_variable
    +
    Correspond à la variable d'environnement standard + nom_variable.
    +
    HTTP:nom_en-tête
    +
    Correspond à la valeur de l'en-tête de requête dont le nom est + nom_en-tête.
    +
    + +
    top
    +
    +

    Formats de journaux +personnalisés

    +

    Lorsque mod_ssl est compilé dans le serveur Apache +ou même chargé (en mode DSO), des fonctions supplémentaires sont +disponibles pour le Format de journal personnalisé du +module mod_log_config. A ce titre, la fonction de +format d'eXtension ``%{nom-var}x'' +peut être utilisée pour présenter en extension toute variable fournie +par tout module, et en particulier celles fournies par mod_ssl et que +vous trouverez dans la table ci-dessus.

    +

    +A des fins de compatibilité ascendante, il existe une fonction de format +cryptographique supplémentaire +``%{nom}c''. Vous trouverez toutes +les informations à propos de cette fonction dans le chapitre Compatibilité.

    +

    Exemple

    CustomLog logs/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
    -
    top
    -

    Directive SSLStaplingCache

    - - - - - - - -
    Description:Configuration du cache pour l'agrafage OCSP
    Syntaxe:SSLStaplingCache type
    Contexte:configuration du serveur
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible si on utilise OpenSSL version 0.9.8h ou supérieure
    -

    Si SSLUseStapling est à "on", -cette directive permet de configurer le cache destiné à stocker les -réponses OCSP incluses dans la négociation TLS. La configuration d'un -cache est obligatoire pour pouvoir utiliser l'agrafage OCSP. A -l'exception de none et nonenotnull, cette -directive supporte les mêmes types de stockage que la directive -SSLSessionCache.

    +
    top
    +
    +

    Information à propos de la requête

    -

    Le mutex ssl-stapling permet de sérialiser l'accès au -cache d'agrafage OCSP afin d'en prévenir la corruption. Ce mutex peut -être configuré via la directive Mutex.

    +

    mod_ssl enregistre des informations à propos de la +requête que l'on peut restituer dans les journaux avec la chaîne de +format %{nom}n via le module +mod_log_config.

    -
    -
    top
    -

    Directive SSLStaplingErrorCacheTimeout

    - - - - - - - - -
    Description:Durée de vie des réponses invalides dans le cache pour -agrafage OCSP
    Syntaxe:SSLStaplingErrorCacheTimeout secondes
    Défaut:SSLStaplingErrorCacheTimeout 600
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible si on utilise OpenSSL version 0.9.8h ou supérieure
    -

    Cette directive permet de définir la durée de vie des réponses -invalides dans le cache pour agrafage OCSP configuré via la -directive SSLStaplingCache. Pour -définir la durée de vie des réponses valides, voir la directive -SSLStaplingStandardCacheTimeout.

    +

    Les informations enregistrées sont les suivantes :

    -
    -
    top
    -

    Directive SSLStaplingFakeTryLater

    - - - - - - - - -
    Description:Génère une réponse "tryLater" pour les requêtes OCSP échouées
    Syntaxe:SSLStaplingFakeTryLater on|off
    Défaut:SSLStaplingFakeTryLater on
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible si on utilise OpenSSL version 0.9.8h ou supérieure
    -

    Lorsque cette directive est activée, et si une requête vers un -serveur OCSP à des fins d'inclusion dans une négociation TLS échoue, -mod_ssl va générer une réponse "tryLater" pour le client (SSLStaplingReturnResponderErrors doit être -activée).

    +
    +
    ssl-access-forbidden
    +
    Cette information contient la valeur 1 si l'accès a + été refusé suite à une directive SSLRequire ou + SSLRequireSSL.
    -
    -
    top
    -

    Directive SSLStaplingForceURL

    - - - - - - - -
    Description:Remplace l'URI du serveur OCSP spécifié dans l'extension -AIA du certificat
    Syntaxe:SSLStaplingForceURL uri
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible si on utilise OpenSSL version 0.9.8h ou supérieure
    -

    Cette directive permet de remplacer l'URI du serveur OCSP extraite de -l'extension authorityInfoAccess (AIA) du certificat. Elle peut s'avérer -utile lorsqu'on passe par un mandataire

    +
    ssl-secure-reneg
    +
    Si mod_ssl a été compilé avec une version + d'OpenSSL qui supporte la renégociation sécurisée, si SSL est utilisé + pour la connexion courante et si le client supporte lui aussi la + renégociation sécurisée, cette information contiendra la valeur + 1. Si le client ne supporte pas la renégociation + sécurisée, l'information contiendra la valeur 0. Si + mod_ssl n'a pas été compilé avec une version + d'OpenSSL qui supporte la renégociation sécurisée, ou si SSL n'est pas + utilisé pour la connexion courante, le contenu de l'information ne + sera pas défini.
    + -
    -
    top
    -

    Directive SSLStaplingResponderTimeout

    - - - - - - - - -
    Description:Temps d'attente maximum pour les requêtes vers les serveurs -OCSP
    Syntaxe:SSLStaplingResponderTimeout secondes
    Défaut:SSLStaplingResponderTimeout 10
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible si on utilise OpenSSL version 0.9.8h ou supérieure
    -

    Cette directive permet de définir le temps d'attente maximum lorsque -mod_ssl envoie une requête vers un serveur OCSP afin d'obtenir une -réponse destinée à être incluse dans les négociations TLS avec les -clients (SSLUseStapling doit -avoir été activée au préalable).

    +
    top
    +
    +

    Fournisseurs d'autorisation +disponibles avec Require

    -
    -
    top
    -

    Directive SSLStaplingResponseMaxAge

    - - - - - - - - -
    Description:Age maximum autorisé des réponses OCSP incluses dans la -négociation TLS
    Syntaxe:SSLStaplingResponseMaxAge secondes
    Défaut:SSLStaplingResponseMaxAge -1
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible si on utilise OpenSSL version 0.9.8h ou supérieure
    -

    Cette directive permet de définir l'âge maximum autorisé -("fraîcheur") des réponses OCSP incluses dans la négociation TLS -(SSLUseStapling doit -avoir été activée au préalable). La valeur par défaut (-1) -ne définit aucun âge maximum, ce qui signifie que les réponses OCSP sont -considérées comme valides à partir du moment où le contenu de leur champ -nextUpdate se trouve dans le futur.

    +

    mod_ssl propose quelques fournisseurs + d'autorisation à utiliser avec la directive Require du module + mod_authz_core.

    -
    -
    top
    -

    Directive SSLStaplingResponseTimeSkew

    - - - - - - - - -
    Description:Durée de vie maximale autorisée des réponses OCSP incluses dans la -négociation TLS
    Syntaxe:SSLStaplingResponseTimeSkew secondes
    Défaut:SSLStaplingResponseTimeSkew 300
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible si on utilise OpenSSL version 0.9.8h ou supérieure
    -

    Cette directive permet de spécifier l'intervalle de temps maximum que -mod_ssl va calculer en faisant la différence entre les contenus des -champs nextUpdate et thisUpdate des réponses -OCSP incluses dans la négociation TLS. Pour pouvoir utiliser cette -directive, SSLUseStapling doit -être à "on".

    +

    Require ssl

    -
    -
    top
    -

    Directive SSLStaplingReturnResponderErrors

    - - - - - - - - -
    Description:Transmet au client les erreurs survenues lors des requêtes -OCSP
    Syntaxe:SSLStaplingReturnResponderErrors on|off
    Défaut:SSLStaplingReturnResponderErrors on
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible si on utilise OpenSSL version 0.9.8h ou supérieure
    -

    Lorsque cette directive est activée, mod_ssl va transmettre au client les -réponses concernant les requêtes OCSP échouées (erreurs d'état, réponses -périmées, etc...). Lorsqu'elle est à off, aucune réponse -concernant les requêtes OCSP échouées ne sera incluse dans les -négociation TLS avec les clients.

    +

    Le fournisseur ssl refuse l'accès si une connexion + n'est pas chiffrée avec SSL. L'effet est similaire à celui de la + directive SSLRequireSSL.

    -
    -
    top
    -

    Directive SSLStaplingStandardCacheTimeout

    - - - - - - - - -
    Description:Durée de vie des réponses OCSP dans le cache
    Syntaxe:SSLStaplingStandardCacheTimeout secondes
    Défaut:SSLStaplingStandardCacheTimeout 3600
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible si on utilise OpenSSL version 0.9.8h ou supérieure
    -

    Cette directive permet de définir la durée de vie des réponses OCSP -dans le cache configuré via la directive SSLStaplingCache. Elle ne s'applique qu'aux -réponse valides, alors que la directive SSLStaplingErrorCacheTimeout s'applique aux -réponses invalides ou non disponibles. -

    -
    -
    top
    -

    Directive SSLStrictSNIVHostCheck

    - - - - - - - - -
    Description:Contrôle de l'accès des clients non-SNI à un serveur virtuel à -base de nom. -
    Syntaxe:SSLStrictSNIVHostCheck on|off
    Défaut:SSLStrictSNIVHostCheck off
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible depuis la version 2.2.12 d'Apache
    -

    -Cette directive permet de contrôler l'accès des clients non-SNI à un serveur -virtuel à base de nom. Si elle est définie à on dans le -serveur virtuel à base de nom par défaut, les -clients non-SNI ne seront autorisés à accéder à aucun serveur virtuel -appartenant à cette combinaison IP/port. Par -contre, si elle est définie à on dans un serveur virtuel -quelconque, les clients non-SNI ne se verront interdire l'accès qu'à ce -serveur. -

    + 
    Require ssl
    -

    -Cette option n'est disponible que si httpd a été compilé avec une -version d'OpenSSL supportant SNI. -

    -

    Exemple

    SSLStrictSNIVHostCheck on
    -
    -
    -
    top
    -

    Directive SSLUserName

    - - - - - - - -
    Description:Nom de la variable servant à déterminer le nom de -l'utilisateur
    Syntaxe:SSLUserName nom-var
    Contexte:configuration du serveur, répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_ssl
    -

    -Cette variable permet de définir le champ "user" de l'objet de la -requête Apache. Ce champ est utilisé par des modules de plus bas niveau -pour identifier l'utilisateur avec une chaîne de caractères. En -particulier, l'utilisation de cette directive peut provoquer la -définition de la variable d'environnement REMOTE_USER. -La valeur de l'argument nom-var peut correspondre à toute variable d'environnement SSL.

    + -

    Notez que cette directive est sans effet si l'option -FakeBasicAuth est utilisée (voir SSLOptions).

    +

    Require ssl-verify-client

    -

    Exemple

    SSLUserName SSL_CLIENT_S_DN_CN
    -
    +

    Le fournisseur ssl autorise l'accès si + l'utilisateur est authentifié via un certificat client valide. Ceci + n'a un effet que si SSLVerifyClient optional est actif.

    -
    -
    top
    -

    Directive SSLUseStapling

    - - - - - - - - -
    Description:Active l'ajout des réponses OCSP à la négociation TLS
    Syntaxe:SSLUseStapling on|off
    Défaut:SSLUseStapling off
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_ssl
    Compatibilité:Disponible si on utilise OpenSSL version 0.9.8h ou supérieure
    -

    Cette directive permet d'activer l'"Agrafage OCSP" (OCSP stapling) -selon la définition de l'extension TLS "Certificate Status Request" -fournie dans la RFC 6066. Si elle est activée et si le client le -demande, mod_ssl va inclure une réponse OCSP à propos de son propre -certificat dans la négociation TLS. Pour pouvoir activer l'Agrafage -OCSP, il est nécessaire de configurer un SSLStaplingCache.

    +

    Dans l'exemple suivant, l'accès est autorisé si le client est + authentifié via un certificat client ou par nom d'utilisateur/mot de + passe :

    -

    L'agrafage OCSP dispense le client de requérir le serveur OCSP -directement ; il faut cependant noter que selon les spécifications de la -RFC 6066, la réponse CertificateStatus du serveur ne peut -inclure une réponse OCSP que pour un seul certificat. Pour les -certificats de serveur comportant des certificats de CA intermédiaires -dans leur chaîne (c'est un cas typique de nos jours), l'implémentation -actuelle de l'agrafage OCSP n'atteint que partiellement l'objectif d' -"économie en questions/réponse et en ressources". Pour plus de détails, -voir la RFC 6961 (TLS -Multiple Certificate Status Extension). -

    + 
          Require ssl-verify-client
    
+      Require valid-user
    -
    -
    top
    -

    Directive SSLVerifyClient

    - - - - - - - - -
    Description:Niveau de vérification du certificat client
    Syntaxe:SSLVerifyClient niveau
    Défaut:SSLVerifyClient none
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_ssl
    -

    -Cette directive permet de définir le niveau de vérification du -certificat pour l'authentification du client. Notez que cette directive -peut être utilisée à la fois dans les contextes du serveur principal et -du répertoire. Dans le contexte du serveur principal, elle s'applique au -processus d'authentification du client utilisé au cours de la -négociation SSL standard lors de l'établissement d'une connexion. Dans -un contexte de répertoire, elle force une renégociation SSL avec le -niveau de vérification du client spécifié, après la lecture d'une -requête HTTP, mais avant l'envoi de la réponse HTTP.

    -

    -Les valeurs de niveau disponibles sont les suivantes :

    -
      -
    • none: - aucun certificat client n'est requis
      • -
    • optional: - le client peut présenter un certificat valide
      • -
    • require: - le client doit présenter un certificat valide
      • -
    • optional_no_ca: - le client peut présenter un certificat valide, mais il n'est pas - nécessaire que ce dernier soit vérifiable (avec succès).
      • -
    -

    En pratique, seuls les niveaux none et -require sont vraiment intéressants, car le niveau -optional ne fonctionne pas avec tous les navigateurs, -et le niveau optional_no_ca va vraiment à l'encontre de -l'idée que l'on peut se faire de l'authentification (mais peut tout de -même être utilisé pour établir des pages de test SSL, etc...)

    -

    Exemple

    SSLVerifyClient require
    -
    -
    -
    top
    -

    Directive SSLVerifyDepth

    - - - - - - - - -
    Description:Profondeur maximale des certificats de CA pour la -vérification des certificats clients
    Syntaxe:SSLVerifyDepth nombre
    Défaut:SSLVerifyDepth 1
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    AllowOverride:AuthConfig
    Statut:Extension
    Module:mod_ssl
    -

    -Cette directive permet de spécifier la profondeur maximale à laquelle -mod_ssl va effectuer sa vérification avant de décider que le client ne -possède pas de certificat valide. Notez que cette directive peut être -utilisée à la fois dans les contextes du serveur principal et de -répertoire. Dans le contexte du serveur principal, elle s'applique au -processus d'authentification du client utilisé au cours de la -négociation SSL standard lors de l'établissement d'une connexion. Dans -un contexte de répertoire, elle force une renégociation SSL avec le -client selon la nouvelle profondeur spécifiée, après la lecture d'une -requête HTTP, mais avant l'envoi de la réponse HTTP.

    -

    -La profondeur correspond au nombre maximum de fournisseurs de -certificats intermédiaires, c'est à dire le nombre maximum de -certificats de CA que l'on est autorisé à suivre lors de la vérification -du certificat du client. Une profondeur de 0 signifie que seuls les -certificats clients auto-signés sont acceptés ; la profondeur par défaut -de 1 signifie que le certificat client peut être soit auto-signé, soit -signé par une CA connue directement du serveur (c'est à dire que le -certificat de la CA doit être référencé par la directive SSLCACertificatePath), etc...

    -

    Exemple

    SSLVerifyDepth 10
    -
    +
    diff --git a/docs/manual/mod/mod_substitute.html.en b/docs/manual/mod/mod_substitute.html.en index 79b4d3b7c67..ad377ed3b4e 100644 --- a/docs/manual/mod/mod_substitute.html.en +++ b/docs/manual/mod/mod_substitute.html.en @@ -44,7 +44,6 @@
  • SubstituteMaxLineLength
    • -
    top

    Substitute Directive

    @@ -158,6 +157,7 @@ Substitute "s|http://internal.blog.example.com/|http://www.example.com/blog/|i"< +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_substitute.html.fr b/docs/manual/mod/mod_substitute.html.fr index cad85489415..073f639a431 100644 --- a/docs/manual/mod/mod_substitute.html.fr +++ b/docs/manual/mod/mod_substitute.html.fr @@ -48,7 +48,6 @@ du serveur HTTP Apache

  • SubstituteMaxLineLength
    • -
    top

    Directive Substitute

    @@ -175,6 +174,7 @@ Apache +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_suexec.html.en b/docs/manual/mod/mod_suexec.html.en index 1638989b766..59033112a30 100644 --- a/docs/manual/mod/mod_suexec.html.en +++ b/docs/manual/mod/mod_suexec.html.en @@ -48,7 +48,6 @@ and Group

    -
    top

    SuexecUserGroup Directive

    @@ -73,6 +72,7 @@ and Group
  • Suexec
    • +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_suexec.html.fr b/docs/manual/mod/mod_suexec.html.fr index 235cf0a5cd2..7c7b635f608 100644 --- a/docs/manual/mod/mod_suexec.html.fr +++ b/docs/manual/mod/mod_suexec.html.fr @@ -49,7 +49,6 @@ le groupe sp

    -
    top

    Directive SuexecUserGroup

    @@ -78,6 +77,7 @@ doivent s'ex
  • Suexec
    • +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_suexec.html.ja.utf8 b/docs/manual/mod/mod_suexec.html.ja.utf8 index 294347caef0..a983caefec9 100644 --- a/docs/manual/mod/mod_suexec.html.ja.utf8 +++ b/docs/manual/mod/mod_suexec.html.ja.utf8 @@ -53,7 +53,6 @@

    -
    top

    SuexecUserGroup ディレクティブ

    @@ -77,6 +76,7 @@ +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_suexec.html.ko.euc-kr b/docs/manual/mod/mod_suexec.html.ko.euc-kr index 4ef54cd243a..f7c62122462 100644 --- a/docs/manual/mod/mod_suexec.html.ko.euc-kr +++ b/docs/manual/mod/mod_suexec.html.ko.euc-kr @@ -51,7 +51,6 @@

    -
    top

    SuexecUserGroup Áö½Ã¾î

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

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_suexec.html.tr.utf8 b/docs/manual/mod/mod_suexec.html.tr.utf8 index b1dfb263ccc..ca3fa01984e 100644 --- a/docs/manual/mod/mod_suexec.html.tr.utf8 +++ b/docs/manual/mod/mod_suexec.html.tr.utf8 @@ -49,7 +49,6 @@

    -
    top

    SuexecUserGroup Yönergesi

    @@ -77,6 +76,7 @@
  • Suexec
    • +

    Mevcut Diller:  en  | diff --git a/docs/manual/mod/mod_unixd.html.en b/docs/manual/mod/mod_unixd.html.en index ebfd44de718..c1f5d711105 100644 --- a/docs/manual/mod/mod_unixd.html.en +++ b/docs/manual/mod/mod_unixd.html.en @@ -44,7 +44,6 @@

    -
    top

    ChrootDir Directive

    @@ -177,6 +176,7 @@ requests
  • SuexecUserGroup
    • +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_unixd.html.fr b/docs/manual/mod/mod_unixd.html.fr index 385612e3d18..0203f25188e 100644 --- a/docs/manual/mod/mod_unixd.html.fr +++ b/docs/manual/mod/mod_unixd.html.fr @@ -45,7 +45,6 @@ famille Unix.

    -
    top

    Directive ChrootDir

    @@ -192,6 +191,7 @@ requ
  • SuexecUserGroup
    • +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_unixd.html.tr.utf8 b/docs/manual/mod/mod_unixd.html.tr.utf8 index d435097e80a..c80f0703a58 100644 --- a/docs/manual/mod/mod_unixd.html.tr.utf8 +++ b/docs/manual/mod/mod_unixd.html.tr.utf8 @@ -44,7 +44,6 @@

    -
    top

    ChrootDir Yönergesi

    @@ -180,6 +179,7 @@
  • SuexecUserGroup
    • +

    Mevcut Diller:  en  | diff --git a/docs/manual/mod/mod_userdir.html.en b/docs/manual/mod/mod_userdir.html.en index 5e1bec00eaf..0650f87957b 100644 --- a/docs/manual/mod/mod_userdir.html.en +++ b/docs/manual/mod/mod_userdir.html.en @@ -50,7 +50,6 @@ Filesystem

  • public_html tutorial
    • -
    top

    UserDir Directive

    @@ -179,6 +178,7 @@ UserDir enabled user1 user2 user3 +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_userdir.html.fr b/docs/manual/mod/mod_userdir.html.fr index ebb56d88a48..b29b522bd5b 100644 --- a/docs/manual/mod/mod_userdir.html.fr +++ b/docs/manual/mod/mod_userdir.html.fr @@ -50,7 +50,6 @@ avec le syst

  • Tutoriel public_html
    • -
    top

    Directive UserDir

    @@ -190,6 +189,7 @@ UserDir enabled user1 user2 user3 +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_userdir.html.ja.utf8 b/docs/manual/mod/mod_userdir.html.ja.utf8 index 94efdd1af4b..efa0ccbf882 100644 --- a/docs/manual/mod/mod_userdir.html.ja.utf8 +++ b/docs/manual/mod/mod_userdir.html.ja.utf8 @@ -56,7 +56,6 @@

  • public_html チュートリアル
    • -
    top

    UserDir ディレクティブ

    @@ -183,6 +182,7 @@ Apache はリダイレクトが成功するかどうかを決めることはで チュートリアル +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_userdir.html.ko.euc-kr b/docs/manual/mod/mod_userdir.html.ko.euc-kr index 6a76d45a747..177b97da325 100644 --- a/docs/manual/mod/mod_userdir.html.ko.euc-kr +++ b/docs/manual/mod/mod_userdir.html.ko.euc-kr @@ -51,7 +51,6 @@

  • public_html ÅõÅ丮¾ó
    • -
    top

    UserDir Áö½Ã¾î

    @@ -155,6 +154,7 @@ http://www.foo.com/bob/one/two.html ÅõÅ丮¾ó +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_userdir.html.tr.utf8 b/docs/manual/mod/mod_userdir.html.tr.utf8 index e7f72d44e19..189a2edad73 100644 --- a/docs/manual/mod/mod_userdir.html.tr.utf8 +++ b/docs/manual/mod/mod_userdir.html.tr.utf8 @@ -53,7 +53,6 @@ public_html eğitmeni

    -
    top

    UserDir Yönergesi

    @@ -176,6 +175,7 @@ UserDir enabled birey1 birey2 birey3 +

    Mevcut Diller:  en  | diff --git a/docs/manual/mod/mod_usertrack.html.en b/docs/manual/mod/mod_usertrack.html.en index 18412fa876f..b29cc71a15f 100644 --- a/docs/manual/mod/mod_usertrack.html.en +++ b/docs/manual/mod/mod_usertrack.html.en @@ -51,19 +51,6 @@

  • Logging
    • top
    -
    -

    Logging

    - - -

    mod_usertrack sets a cookie which can be logged - via mod_log_config configurable logging formats:

    - - 
    LogFormat "%{Apache}n %r %t" usertrack
-CustomLog logs/clickstream.log usertrack
    - - -
    -
    top

    CookieDomain Directive

    @@ -207,6 +194,19 @@ CustomLog logs/clickstream.log usertrack + +
    top
    +
    +

    Logging

    + + +

    mod_usertrack sets a cookie which can be logged + via mod_log_config configurable logging formats:

    + + 
    LogFormat "%{Apache}n %r %t" usertrack
+CustomLog logs/clickstream.log usertrack
    + +
    diff --git a/docs/manual/mod/mod_usertrack.html.fr b/docs/manual/mod/mod_usertrack.html.fr index d4f3a76aef1..44874bc6d9d 100644 --- a/docs/manual/mod/mod_usertrack.html.fr +++ b/docs/manual/mod/mod_usertrack.html.fr @@ -52,21 +52,6 @@ utilisateur sur un site
  • Journalisation
    • top
    -
    -

    Journalisation

    - - -

    mod_usertrack définit un cookie qui peut être - journalisé via les formats configurables du module - mod_log_config :

    - - 
    LogFormat "%{Apache}n %r %t" usertrack
-CustomLog logs/clickstream.log usertrack
    - - - -
    -
    top

    Directive CookieDomain

    Description:The domain to which the tracking cookie applies
    + +
    top
    +
    +

    Journalisation

    + + +

    mod_usertrack définit un cookie qui peut être + journalisé via les formats configurables du module + mod_log_config :

    + + 
    LogFormat "%{Apache}n %r %t" usertrack
+CustomLog logs/clickstream.log usertrack
    + + +
    diff --git a/docs/manual/mod/mod_version.html.en b/docs/manual/mod/mod_version.html.en index 72015741332..8b447c4f094 100644 --- a/docs/manual/mod/mod_version.html.en +++ b/docs/manual/mod/mod_version.html.en @@ -56,7 +56,6 @@
  • <IfVersion>
    • -
    top

    <IfVersion> Directive

    Description:Le domaine auquel le cookie traceur @@ -215,6 +200,21 @@ s'applique
    @@ -128,6 +127,7 @@ =.

    +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_version.html.ja.utf8 b/docs/manual/mod/mod_version.html.ja.utf8 index 3504c24f0ee..afc86d74fa8 100644 --- a/docs/manual/mod/mod_version.html.ja.utf8 +++ b/docs/manual/mod/mod_version.html.ja.utf8 @@ -56,7 +56,6 @@

  • <IfVersion>
    • -
    top

    <IfVersion> ディレクティブ

    @@ -126,6 +125,7 @@ みなされます。

    +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_version.html.ko.euc-kr b/docs/manual/mod/mod_version.html.ko.euc-kr index fb0f12aa2ae..13229fa516b 100644 --- a/docs/manual/mod/mod_version.html.ko.euc-kr +++ b/docs/manual/mod/mod_version.html.ko.euc-kr @@ -64,7 +64,6 @@

  • <IfVersion>
    • -
    top

    <IfVersion> Áö½Ã¾î

    @@ -142,6 +141,7 @@ »ý°¢ÇÑ´Ù.

    +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_vhost_alias.html.en b/docs/manual/mod/mod_vhost_alias.html.en index 7fb59b2f97a..cb1baed83b2 100644 --- a/docs/manual/mod/mod_vhost_alias.html.en +++ b/docs/manual/mod/mod_vhost_alias.html.en @@ -72,6 +72,96 @@ VirtualScriptAlias "/never/found/%0/cgi-bin/" virtual hosting

    top
    +

    VirtualDocumentRoot Directive

    +
    + + + + + + +
    Description:Dynamically configure the location of the document root +for a given virtual host
    Syntax:VirtualDocumentRoot interpolated-directory|none
    Default:VirtualDocumentRoot none
    Context:server config, virtual host
    Status:Extension
    Module:mod_vhost_alias
    + +

    The VirtualDocumentRoot directive allows you to + determine where Apache HTTP Server will find your documents based on the + value of the server name. The result of expanding + interpolated-directory is used as the root of the + document tree in a similar manner to the DocumentRoot directive's argument. + If interpolated-directory is none then + VirtualDocumentRoot is turned off. This directive + cannot be used in the same context as VirtualDocumentRootIP.

    + +

    Note

    +VirtualDocumentRoot will override any DocumentRoot directives you may have put in the same +context or child contexts. Putting a VirtualDocumentRoot +in the global server scope will effectively override DocumentRoot directives in any virtual hosts defined later +on, unless you set VirtualDocumentRoot to None +in each virtual host. +
    + + +
    +
    top
    +

    VirtualDocumentRootIP Directive

    + + + + + + + +
    Description:Dynamically configure the location of the document root +for a given virtual host
    Syntax:VirtualDocumentRootIP interpolated-directory|none
    Default:VirtualDocumentRootIP none
    Context:server config, virtual host
    Status:Extension
    Module:mod_vhost_alias
    + +

    The VirtualDocumentRootIP directive is like the + VirtualDocumentRoot + directive, except that it uses the IP address of the server end + of the connection for directory interpolation instead of the server + name.

    + +
    +
    top
    +

    VirtualScriptAlias Directive

    + + + + + + + +
    Description:Dynamically configure the location of the CGI directory for +a given virtual host
    Syntax:VirtualScriptAlias interpolated-directory|none
    Default:VirtualScriptAlias none
    Context:server config, virtual host
    Status:Extension
    Module:mod_vhost_alias
    + +

    The VirtualScriptAlias directive allows you to + determine where Apache httpd will find CGI scripts in a similar + manner to VirtualDocumentRoot does for other documents. It matches + requests for URIs starting /cgi-bin/, much like ScriptAlias + /cgi-bin/ would.

    + + +
    +
    top
    +

    VirtualScriptAliasIP Directive

    + + + + + + + +
    Description:Dynamically configure the location of the CGI directory for +a given virtual host
    Syntax:VirtualScriptAliasIP interpolated-directory|none
    Default:VirtualScriptAliasIP none
    Context:server config, virtual host
    Status:Extension
    Module:mod_vhost_alias
    + +

    The VirtualScriptAliasIP directive is like the + VirtualScriptAlias + directive, except that it uses the IP address of the server end + of the connection for directory interpolation instead of the server + name.

    + + +
    +
    top

    Directory Name Interpolation

    @@ -236,96 +326,6 @@ VirtualScriptAliasIP "/usr/local/apache/vhosts/%1/%2/%3/%4/cgi-bin"

    The LogFormat directives %V and %A are useful in conjunction with this module.

    -
    -
    top
    -

    VirtualDocumentRoot Directive

    - - - - - - - -
    Description:Dynamically configure the location of the document root -for a given virtual host
    Syntax:VirtualDocumentRoot interpolated-directory|none
    Default:VirtualDocumentRoot none
    Context:server config, virtual host
    Status:Extension
    Module:mod_vhost_alias
    - -

    The VirtualDocumentRoot directive allows you to - determine where Apache HTTP Server will find your documents based on the - value of the server name. The result of expanding - interpolated-directory is used as the root of the - document tree in a similar manner to the DocumentRoot directive's argument. - If interpolated-directory is none then - VirtualDocumentRoot is turned off. This directive - cannot be used in the same context as VirtualDocumentRootIP.

    - -

    Note

    -VirtualDocumentRoot will override any DocumentRoot directives you may have put in the same -context or child contexts. Putting a VirtualDocumentRoot -in the global server scope will effectively override DocumentRoot directives in any virtual hosts defined later -on, unless you set VirtualDocumentRoot to None -in each virtual host. -
    - - -
    -
    top
    -

    VirtualDocumentRootIP Directive

    - - - - - - - -
    Description:Dynamically configure the location of the document root -for a given virtual host
    Syntax:VirtualDocumentRootIP interpolated-directory|none
    Default:VirtualDocumentRootIP none
    Context:server config, virtual host
    Status:Extension
    Module:mod_vhost_alias
    - -

    The VirtualDocumentRootIP directive is like the - VirtualDocumentRoot - directive, except that it uses the IP address of the server end - of the connection for directory interpolation instead of the server - name.

    - -
    -
    top
    -

    VirtualScriptAlias Directive

    - - - - - - - -
    Description:Dynamically configure the location of the CGI directory for -a given virtual host
    Syntax:VirtualScriptAlias interpolated-directory|none
    Default:VirtualScriptAlias none
    Context:server config, virtual host
    Status:Extension
    Module:mod_vhost_alias
    - -

    The VirtualScriptAlias directive allows you to - determine where Apache httpd will find CGI scripts in a similar - manner to VirtualDocumentRoot does for other documents. It matches - requests for URIs starting /cgi-bin/, much like ScriptAlias - /cgi-bin/ would.

    - - -
    -
    top
    -

    VirtualScriptAliasIP Directive

    - - - - - - - -
    Description:Dynamically configure the location of the CGI directory for -a given virtual host
    Syntax:VirtualScriptAliasIP interpolated-directory|none
    Default:VirtualScriptAliasIP none
    Context:server config, virtual host
    Status:Extension
    Module:mod_vhost_alias
    - -

    The VirtualScriptAliasIP directive is like the - VirtualScriptAlias - directive, except that it uses the IP address of the server end - of the connection for directory interpolation instead of the server - name.

    - -
    diff --git a/docs/manual/mod/mod_vhost_alias.html.fr b/docs/manual/mod/mod_vhost_alias.html.fr index 26a9e83987c..88cb894a2ff 100644 --- a/docs/manual/mod/mod_vhost_alias.html.fr +++ b/docs/manual/mod/mod_vhost_alias.html.fr @@ -76,6 +76,101 @@ VirtualScriptAlias /never/found/%0/cgi-bin/ l'hébergement virtuel de masse
    top
    +

    Directive VirtualDocumentRoot

    + + + + + + + +
    Description:Permet une configuration dynamique de la racine des +documents d'un serveur virtuel donné
    Syntaxe:VirtualDocumentRoot répertoire-interpolé|none
    Défaut:VirtualDocumentRoot none
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_vhost_alias
    + +

    La directive VirtualDocumentRoot vous + permet de spécifier où le serveur HTTP Apache pourra trouver vos + documents en se basant + sur le nom du serveur. Le résultat de l'expansion du + répertoire-interpolé est utilisé comme racine de + l'arborescence des documents d'une manière similaire à l'argument de + la directive DocumentRoot. Si + répertoire-interpolé a pour valeur none, la + directive VirtualDocumentRoot est désactivée. + Cette directive ne peut pas être utilisée dans le même contexte que + la directive VirtualDocumentRootIP.

    + +

    Note

    +La directive VirtualDocumentRoot l'emporte sur +toute directive DocumentRoot +définie dans le même contexte ou dans des contextes enfants. Le fait de +définir une directive VirtualDocumentRoot dans le +contexte du serveur principal va effectivement l'emporter sur toute +directive DocumentRoot définie dans +un serveur virtuel quelconque, si vous n'avez pas défini +VirtualDocumentRoot à None dans ce +serveur virtuel. +
    + + +
    +
    top
    +

    Directive VirtualDocumentRootIP

    + + + + + + + +
    Description:Configuration dynamique de la racine des documents pour un +serveur virtuel donné
    Syntaxe:VirtualDocumentRootIP répertoire-interpolé|none
    Défaut:VirtualDocumentRootIP none
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_vhost_alias
    + +

    La directive VirtualDocumentRootIP est +identique à la directive VirtualDocumentRoot à l'exception +près qu'elle utilise l'adresse IP du serveur virtuel pour +l'interpolation du répertoire à la place du nom du serveur.

    + +
    +
    top
    +

    Directive VirtualScriptAlias

    + + + + + + + +
    Description:Configuration dynamique du répertoire des scripts CGI pour +un serveur virtuel donné
    Syntaxe:VirtualScriptAlias répertoire-interpolé|none
    Défaut:VirtualScriptAlias none
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_vhost_alias
    + +

    La directive VirtualScriptAlias vous + permet de spécifier où Apache httpd pourra trouver les scripts CGI selon une + méthode similaire à celle qu'utilise la directive VirtualDocumentRoot pour les + autres documents. Elle recherche des requêtes dont l'URI commence + par /cgi-bin/, comme le ferait la directive ScriptAlias.

    + + +
    +
    top
    +

    Directive VirtualScriptAliasIP

    + + + + + + + +
    Description:Configuration dynamique du répertoire des scripts CGI pour +un serveur virtuel donné
    Syntaxe:VirtualScriptAliasIP répertoire-interpolé|none
    Défaut:VirtualScriptAliasIP none
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_vhost_alias
    + +

    La directive VirtualScriptAliasIP est + identique à la directive VirtualScriptAlias à + l'exception près qu'elle utilise l'adresse IP du serveur virtuel + pour l'interpolation du répertoire à la place du nom du serveur.

    + + +
    +
    top

    Interpolation du nom de répertoire

    @@ -257,101 +352,6 @@ VirtualScriptAliasIP /usr/local/apache/vhosts/%1/%2/%3/%4/cgi-bin

    Les spécificateurs de format %V et %A de la directive LogFormat s'avèrent très utiles lorsqu'ils sont utilisés en conjonction avec ce module.

    -
    -
    top
    -

    Directive VirtualDocumentRoot

    - - - - - - - -
    Description:Permet une configuration dynamique de la racine des -documents d'un serveur virtuel donné
    Syntaxe:VirtualDocumentRoot répertoire-interpolé|none
    Défaut:VirtualDocumentRoot none
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_vhost_alias
    - -

    La directive VirtualDocumentRoot vous - permet de spécifier où le serveur HTTP Apache pourra trouver vos - documents en se basant - sur le nom du serveur. Le résultat de l'expansion du - répertoire-interpolé est utilisé comme racine de - l'arborescence des documents d'une manière similaire à l'argument de - la directive DocumentRoot. Si - répertoire-interpolé a pour valeur none, la - directive VirtualDocumentRoot est désactivée. - Cette directive ne peut pas être utilisée dans le même contexte que - la directive VirtualDocumentRootIP.

    - -

    Note

    -La directive VirtualDocumentRoot l'emporte sur -toute directive DocumentRoot -définie dans le même contexte ou dans des contextes enfants. Le fait de -définir une directive VirtualDocumentRoot dans le -contexte du serveur principal va effectivement l'emporter sur toute -directive DocumentRoot définie dans -un serveur virtuel quelconque, si vous n'avez pas défini -VirtualDocumentRoot à None dans ce -serveur virtuel. -
    - - -
    -
    top
    -

    Directive VirtualDocumentRootIP

    - - - - - - - -
    Description:Configuration dynamique de la racine des documents pour un -serveur virtuel donné
    Syntaxe:VirtualDocumentRootIP répertoire-interpolé|none
    Défaut:VirtualDocumentRootIP none
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_vhost_alias
    - -

    La directive VirtualDocumentRootIP est -identique à la directive VirtualDocumentRoot à l'exception -près qu'elle utilise l'adresse IP du serveur virtuel pour -l'interpolation du répertoire à la place du nom du serveur.

    - -
    -
    top
    -

    Directive VirtualScriptAlias

    - - - - - - - -
    Description:Configuration dynamique du répertoire des scripts CGI pour -un serveur virtuel donné
    Syntaxe:VirtualScriptAlias répertoire-interpolé|none
    Défaut:VirtualScriptAlias none
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_vhost_alias
    - -

    La directive VirtualScriptAlias vous - permet de spécifier où Apache httpd pourra trouver les scripts CGI selon une - méthode similaire à celle qu'utilise la directive VirtualDocumentRoot pour les - autres documents. Elle recherche des requêtes dont l'URI commence - par /cgi-bin/, comme le ferait la directive ScriptAlias.

    - - -
    -
    top
    -

    Directive VirtualScriptAliasIP

    - - - - - - - -
    Description:Configuration dynamique du répertoire des scripts CGI pour -un serveur virtuel donné
    Syntaxe:VirtualScriptAliasIP répertoire-interpolé|none
    Défaut:VirtualScriptAliasIP none
    Contexte:configuration du serveur, serveur virtuel
    Statut:Extension
    Module:mod_vhost_alias
    - -

    La directive VirtualScriptAliasIP est - identique à la directive VirtualScriptAlias à - l'exception près qu'elle utilise l'adresse IP du serveur virtuel - pour l'interpolation du répertoire à la place du nom du serveur.

    - -
    diff --git a/docs/manual/mod/mod_vhost_alias.html.tr.utf8 b/docs/manual/mod/mod_vhost_alias.html.tr.utf8 index 113dc50e215..18e651bbb3e 100644 --- a/docs/manual/mod/mod_vhost_alias.html.tr.utf8 +++ b/docs/manual/mod/mod_vhost_alias.html.tr.utf8 @@ -72,6 +72,93 @@ VirtualScriptAlias /nerede/bilinmiyor/%0/cgi-bin/ Sanal Barındırma
    top
    +

    VirtualDocumentRoot Yönergesi

    + + + + + + + +
    Açıklama:Bir sanal konağın belge kök dizinini devingen olarak yapılandırır. +
    Sözdizimi:VirtualDocumentRoot hesaplanan-dizin|none
    Öntanımlı:VirtualDocumentRoot none
    Bağlam:sunucu geneli, sanal konak
    Durum:Eklenti
    Modül:mod_vhost_alias
    + +

    VirtualDocumentRoot yönergesi sunucu ismine göre + belgelerin bulunacağı yeri Apache HTTP Sunucusunun saptamasını sağlar. + hesaplanan-dizin’in dönüşüm sonucu DocumentRoot yönergesinin değeriymiş gibi + belge ağacının kök dizini olarak kullanılır. + hesaplanan-dizin yerine none + belirtilmişse VirtualDocumentRoot iptal edilmiş + olur. Bu yönerge VirtualDocumentRootIP yönergesinin kullanıldığı bağlamda + yer alamaz.

    + +

    Bilginize

    + VirtualDocumentRoot yönergesi aynı bağlamda veya + alt bağlamlarda da kullanılabilen DocumentRoot yönergelerini geçersiz kılar. + Genel sunucu etki alanına bir VirtualDocumentRoot + konulması, daha sonra yer alan her sanal konak tanımı içinde + VirtualDocumentRoot yönergesine None + atamadıkça bu sanal konaklarda yapılmış DocumentRoot atamalarını geçersiz kılacaktır. +
    + +
    +
    top
    +

    VirtualDocumentRootIP Yönergesi

    + + + + + + + +
    Açıklama:Bir sanal konağın belge kök dizinini devingen olarak yapılandırır. +
    Sözdizimi:VirtualDocumentRootIP hesaplanan-dizin|none
    Öntanımlı:VirtualDocumentRootIP none
    Bağlam:sunucu geneli, sanal konak
    Durum:Eklenti
    Modül:mod_vhost_alias
    + +

    VirtualDocumentRootIP yönergesi, dizinin + saptanmasında sunucu ismi yerine bağlantının sonlandığı sunucunun IP + adresini kullanması dışında VirtualDocumentRoot gibidir.

    + +
    +
    top
    +

    VirtualScriptAlias Yönergesi

    + + + + + + + +
    Açıklama:Bir sanal konağın CGI dizinini devingen olarak yapılandırır. +
    Sözdizimi:VirtualScriptAlias hesaplanan-dizin|none
    Öntanımlı:VirtualScriptAlias none
    Bağlam:sunucu geneli, sanal konak
    Durum:Eklenti
    Modül:mod_vhost_alias
    + +

    VirtualScriptAlias yönergesi, CGI betiklerinin + bulunacağı yeri Apache httpd’nin saptamasını sağlamak bakımından + VirtualDocumentRoot + yönergesinin yaptığını yapar. /cgi-bin/ ile başlayan + istekler için ise ScriptAlias + yönergesinin yaptığını yapar.

    + + +
    +
    top
    +

    VirtualScriptAliasIP Yönergesi

    + + + + + + + +
    Açıklama:Bir sanal konağın CGI dizinini devingen olarak yapılandırır. +
    Sözdizimi:VirtualScriptAliasIP hesaplanan-dizin|none
    Öntanımlı:VirtualScriptAliasIP none
    Bağlam:sunucu geneli, sanal konak
    Durum:Eklenti
    Modül:mod_vhost_alias
    + +

    VirtualScriptAliasIP yönergesi, dizinin + saptanmasında sunucu ismi yerine bağlantının sonlandığı sunucunun IP + adresini kullanması dışında VirtualScriptAlias gibidir.

    + + +
    +
    top

    Dizin Ä°simlerinin Elde Edilmesi

    @@ -233,93 +320,6 @@ VirtualScriptAliasIP /usr/local/apache/sankonlar/%1/%2/%3/%4/cgi-bin

    LogFormat yönergesinin %V ve %A biçem belirteçleri bu modülle birlikte kullanıldığında çok yararlı olurlar.

    -
    -
    top
    -

    VirtualDocumentRoot Yönergesi

    - - - - - - - -
    Açıklama:Bir sanal konağın belge kök dizinini devingen olarak yapılandırır. -
    Sözdizimi:VirtualDocumentRoot hesaplanan-dizin|none
    Öntanımlı:VirtualDocumentRoot none
    Bağlam:sunucu geneli, sanal konak
    Durum:Eklenti
    Modül:mod_vhost_alias
    - -

    VirtualDocumentRoot yönergesi sunucu ismine göre - belgelerin bulunacağı yeri Apache HTTP Sunucusunun saptamasını sağlar. - hesaplanan-dizin’in dönüşüm sonucu DocumentRoot yönergesinin değeriymiş gibi - belge ağacının kök dizini olarak kullanılır. - hesaplanan-dizin yerine none - belirtilmişse VirtualDocumentRoot iptal edilmiş - olur. Bu yönerge VirtualDocumentRootIP yönergesinin kullanıldığı bağlamda - yer alamaz.

    - -

    Bilginize

    - VirtualDocumentRoot yönergesi aynı bağlamda veya - alt bağlamlarda da kullanılabilen DocumentRoot yönergelerini geçersiz kılar. - Genel sunucu etki alanına bir VirtualDocumentRoot - konulması, daha sonra yer alan her sanal konak tanımı içinde - VirtualDocumentRoot yönergesine None - atamadıkça bu sanal konaklarda yapılmış DocumentRoot atamalarını geçersiz kılacaktır. -
    - -
    -
    top
    -

    VirtualDocumentRootIP Yönergesi

    - - - - - - - -
    Açıklama:Bir sanal konağın belge kök dizinini devingen olarak yapılandırır. -
    Sözdizimi:VirtualDocumentRootIP hesaplanan-dizin|none
    Öntanımlı:VirtualDocumentRootIP none
    Bağlam:sunucu geneli, sanal konak
    Durum:Eklenti
    Modül:mod_vhost_alias
    - -

    VirtualDocumentRootIP yönergesi, dizinin - saptanmasında sunucu ismi yerine bağlantının sonlandığı sunucunun IP - adresini kullanması dışında VirtualDocumentRoot gibidir.

    - -
    -
    top
    -

    VirtualScriptAlias Yönergesi

    - - - - - - - -
    Açıklama:Bir sanal konağın CGI dizinini devingen olarak yapılandırır. -
    Sözdizimi:VirtualScriptAlias hesaplanan-dizin|none
    Öntanımlı:VirtualScriptAlias none
    Bağlam:sunucu geneli, sanal konak
    Durum:Eklenti
    Modül:mod_vhost_alias
    - -

    VirtualScriptAlias yönergesi, CGI betiklerinin - bulunacağı yeri Apache httpd’nin saptamasını sağlamak bakımından - VirtualDocumentRoot - yönergesinin yaptığını yapar. /cgi-bin/ ile başlayan - istekler için ise ScriptAlias - yönergesinin yaptığını yapar.

    - - -
    -
    top
    -

    VirtualScriptAliasIP Yönergesi

    - - - - - - - -
    Açıklama:Bir sanal konağın CGI dizinini devingen olarak yapılandırır. -
    Sözdizimi:VirtualScriptAliasIP hesaplanan-dizin|none
    Öntanımlı:VirtualScriptAliasIP none
    Bağlam:sunucu geneli, sanal konak
    Durum:Eklenti
    Modül:mod_vhost_alias
    - -

    VirtualScriptAliasIP yönergesi, dizinin - saptanmasında sunucu ismi yerine bağlantının sonlandığı sunucunun IP - adresini kullanması dışında VirtualScriptAlias gibidir.

    - -
    diff --git a/docs/manual/mod/mod_watchdog.html.en b/docs/manual/mod/mod_watchdog.html.en index 0c5c65e07d1..a273e1a3058 100644 --- a/docs/manual/mod/mod_watchdog.html.en +++ b/docs/manual/mod/mod_watchdog.html.en @@ -53,7 +53,6 @@ core or, if a dynamic module, be loaded before the calling module.
  • WatchdogInterval
    • -
    top

    WatchdogInterval Directive

    @@ -68,6 +67,7 @@ core or, if a dynamic module, be loaded before the calling module. second.

    +

    Available Languages:  en 

    diff --git a/docs/manual/mod/mod_xml2enc.html.en b/docs/manual/mod/mod_xml2enc.html.en index 30cc39fe20a..76f7c777e5c 100644 --- a/docs/manual/mod/mod_xml2enc.html.en +++ b/docs/manual/mod/mod_xml2enc.html.en @@ -59,6 +59,58 @@ for 2.2.x versions
  • Unsupported Encodings
    • top
    +

    xml2EncAlias Directive

    + + + + + + +
    Description:Recognise Aliases for encoding values
    Syntax:xml2EncAlias charset alias [alias ...]
    Context:server config
    Status:Base
    Module:mod_xml2enc
    +

    This server-wide directive aliases one or more encoding to another + encoding. This enables encodings not recognised by libxml2 to be handled + internally by libxml2's encoding support using the translation table for + a recognised encoding. This serves two purposes: to support character sets + (or names) not recognised either by libxml2 or iconv, and to skip + conversion for an encoding where it is known to be unnecessary.

    + +
    +
    top
    +

    xml2EncDefault Directive

    + + + + + + + +
    Description:Sets a default encoding to assume when absolutely no information +can be automatically detected
    Syntax:xml2EncDefault name
    Context:server config, virtual host, directory, .htaccess
    Status:Base
    Module:mod_xml2enc
    Compatibility:Version 2.4.0 and later; available as a third-party +module for earlier versions.
    +

    If you are processing data with known encoding but no encoding + information, you can set this default to help mod_xml2enc process + the data correctly. For example, to work with the default value + of Latin1 (iso-8859-1 specified in HTTP/1.0, use

    + 
    xml2EncDefault iso-8859-1
    + + +
    +
    top
    +

    xml2StartParse Directive

    + + + + + + +
    Description:Advise the parser to skip leading junk.
    Syntax:xml2StartParse element [element ...]
    Context:server config, virtual host, directory, .htaccess
    Status:Base
    Module:mod_xml2enc
    +

    Specify that the markup parser should start at the first instance + of any of the elements specified. This can be used as a workaround + where a broken backend inserts leading junk that messes up the parser (example here).

    +

    It should never be used for XML, nor well-formed HTML.

    + +
    +
    top

    Usage

    There are two usage scenarios: with modules programmed to work @@ -133,58 +185,6 @@ the server of an unnecessary conversion.

    If you are working with encodings that are not supported by any of the conversion methods available on your platform, you can still alias them to a supported encoding using xml2EncAlias.

    -
    -
    top
    -

    xml2EncAlias Directive

    - - - - - - -
    Description:Recognise Aliases for encoding values
    Syntax:xml2EncAlias charset alias [alias ...]
    Context:server config
    Status:Base
    Module:mod_xml2enc
    -

    This server-wide directive aliases one or more encoding to another - encoding. This enables encodings not recognised by libxml2 to be handled - internally by libxml2's encoding support using the translation table for - a recognised encoding. This serves two purposes: to support character sets - (or names) not recognised either by libxml2 or iconv, and to skip - conversion for an encoding where it is known to be unnecessary.

    - -
    -
    top
    -

    xml2EncDefault Directive

    - - - - - - - -
    Description:Sets a default encoding to assume when absolutely no information -can be automatically detected
    Syntax:xml2EncDefault name
    Context:server config, virtual host, directory, .htaccess
    Status:Base
    Module:mod_xml2enc
    Compatibility:Version 2.4.0 and later; available as a third-party -module for earlier versions.
    -

    If you are processing data with known encoding but no encoding - information, you can set this default to help mod_xml2enc process - the data correctly. For example, to work with the default value - of Latin1 (iso-8859-1 specified in HTTP/1.0, use

    - 
    xml2EncDefault iso-8859-1
    - - -
    -
    top
    -

    xml2StartParse Directive

    - - - - - - -
    Description:Advise the parser to skip leading junk.
    Syntax:xml2StartParse element [element ...]
    Context:server config, virtual host, directory, .htaccess
    Status:Base
    Module:mod_xml2enc
    -

    Specify that the markup parser should start at the first instance - of any of the elements specified. This can be used as a workaround - where a broken backend inserts leading junk that messes up the parser (example here).

    -

    It should never be used for XML, nor well-formed HTML.

    -
    diff --git a/docs/manual/mod/mod_xml2enc.html.fr b/docs/manual/mod/mod_xml2enc.html.fr index e322d530bc2..25f7b5eaad4 100644 --- a/docs/manual/mod/mod_xml2enc.html.fr +++ b/docs/manual/mod/mod_xml2enc.html.fr @@ -61,6 +61,65 @@ Disponible en tant que module tiers dans les versions 2.2.x
  • Codages non supportés
    • top
    +

    Directive xml2EncAlias

    + + + + + + +
    Description:Définit des alias pour les valeurs d'encodage
    Syntaxe:xml2EncAlias jeu-de-caractères alias [alias ...]
    Contexte:configuration du serveur
    Statut:Base
    Module:mod_xml2enc
    +

    Cette directive de niveau serveur permet de définir un ou + plusieurs alias pour un encodage. Elle permet au support d'encodage de + libxml2 de traiter en interne des encodages non reconnus par libxml2 + en utilisant la table de conversion pour un encodage reconnu. Elle + permet d'atteindre deux objectifs : supporter des jeux (ou noms) de + caractères non reconnus par libxml2 ou iconv, et éviter une + conversion pour un encodage lorsque cela n'est pas nécessaire.

    + +
    +
    top
    +

    Directive xml2EncDefault

    + + + + + + + +
    Description:Définit un encodage par défaut à utiliser lorsqu'aucune +information ne peut être automatiquement détectée
    Syntaxe:xml2EncDefault nom
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    Statut:Base
    Module:mod_xml2enc
    Compatibilité:Disponible depuis la version 2.4.0 du serveur HTTP Apache +; disponible depuis un module tiers dans les versions antérieures.
    +

    Si vous traitez des données dont l'encodage est connu, mais ne + contenant aucune information à propos de ce dernier, vous pouvez + définir une valeur par défaut afin d'aider mod_xml2enc à traiter + correctement les données. Par exemple, pour définir la valeur par + défaut Latin1 (iso-8859-1 specifiée dans HTTP/1.0), + utilisez :

    + 
    xml2EncDefault iso-8859-1
    + + +
    +
    top
    +

    Directive xml2StartParse

    + + + + + + +
    Description:Indique à l'interpréteur à partir de quelle balise il doit +commencer son traitement.
    Syntaxe:xml2StartParse élément [élément ...]
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    Statut:Base
    Module:mod_xml2enc
    +

    Cette directive permet de spécifier à partir de quelle balise, + parmi les éléments spécifiés, l'interpréteur de balise doit + commencer son traitement. Ccei permet de contourner le problème des + serveurs d'arrière-plan qui insèrent des éléments non conformes en + début de données, ce qui a pour effet de perturber l'interpréteur (voir un exemple ici).

    +

    Elle ne doit être utilisée ni pour les documents XML, ni pour les + documents HTML correctement formatés.

    + +
    +
    top

    Utilisation

    Il existe deux scénarios d'utilisation : le cas des modules @@ -146,65 +205,6 @@ n méthodes de conversion disponibles sur votre plateforme, vous pouvez tout de même leur associer un alias vers un code supporté via la directive xml2EncAlias.

    -
    -
    top
    -

    Directive xml2EncAlias

    - - - - - - -
    Description:Définit des alias pour les valeurs d'encodage
    Syntaxe:xml2EncAlias jeu-de-caractères alias [alias ...]
    Contexte:configuration du serveur
    Statut:Base
    Module:mod_xml2enc
    -

    Cette directive de niveau serveur permet de définir un ou - plusieurs alias pour un encodage. Elle permet au support d'encodage de - libxml2 de traiter en interne des encodages non reconnus par libxml2 - en utilisant la table de conversion pour un encodage reconnu. Elle - permet d'atteindre deux objectifs : supporter des jeux (ou noms) de - caractères non reconnus par libxml2 ou iconv, et éviter une - conversion pour un encodage lorsque cela n'est pas nécessaire.

    - -
    -
    top
    -

    Directive xml2EncDefault

    - - - - - - - -
    Description:Définit un encodage par défaut à utiliser lorsqu'aucune -information ne peut être automatiquement détectée
    Syntaxe:xml2EncDefault nom
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    Statut:Base
    Module:mod_xml2enc
    Compatibilité:Disponible depuis la version 2.4.0 du serveur HTTP Apache -; disponible depuis un module tiers dans les versions antérieures.
    -

    Si vous traitez des données dont l'encodage est connu, mais ne - contenant aucune information à propos de ce dernier, vous pouvez - définir une valeur par défaut afin d'aider mod_xml2enc à traiter - correctement les données. Par exemple, pour définir la valeur par - défaut Latin1 (iso-8859-1 specifiée dans HTTP/1.0), - utilisez :

    - 
    xml2EncDefault iso-8859-1
    - - -
    -
    top
    -

    Directive xml2StartParse

    - - - - - - -
    Description:Indique à l'interpréteur à partir de quelle balise il doit -commencer son traitement.
    Syntaxe:xml2StartParse élément [élément ...]
    Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
    Statut:Base
    Module:mod_xml2enc
    -

    Cette directive permet de spécifier à partir de quelle balise, - parmi les éléments spécifiés, l'interpréteur de balise doit - commencer son traitement. Ccei permet de contourner le problème des - serveurs d'arrière-plan qui insèrent des éléments non conformes en - début de données, ce qui a pour effet de perturber l'interpréteur (voir un exemple ici).

    -

    Elle ne doit être utilisée ni pour les documents XML, ni pour les - documents HTML correctement formatés.

    -
    diff --git a/docs/manual/mod/mpm_common.html.de b/docs/manual/mod/mpm_common.html.de index ebdf4a5aabe..7cfcff9d778 100644 --- a/docs/manual/mod/mpm_common.html.de +++ b/docs/manual/mod/mpm_common.html.de @@ -61,7 +61,6 @@
  • ThreadStackSize
    • -
    top

    CoreDumpDirectory-Direktive

    @@ -723,6 +722,7 @@ verwendet wird, die Client-Verbindungen bearbeiten. +

    Verfügbare Sprachen:  de  | diff --git a/docs/manual/mod/mpm_common.html.en b/docs/manual/mod/mpm_common.html.en index 8b1c87d5e98..6052f3b2047 100644 --- a/docs/manual/mod/mpm_common.html.en +++ b/docs/manual/mod/mpm_common.html.en @@ -58,7 +58,6 @@ more than one multi-processing module (MPM)

  • ThreadStackSize
    • -
    top

    CoreDumpDirectory Directive

    @@ -751,6 +750,7 @@ client connections causes crashes with some common modules. +

    Available Languages:  de  | diff --git a/docs/manual/mod/mpm_common.html.fr b/docs/manual/mod/mpm_common.html.fr index a48c62f90d1..e3bc56f29a6 100644 --- a/docs/manual/mod/mpm_common.html.fr +++ b/docs/manual/mod/mpm_common.html.fr @@ -58,7 +58,6 @@ modules multi-processus (MPM)

  • ThreadStackSize
    • -
    top

    Directive CoreDumpDirectory

    @@ -829,6 +828,7 @@ du serveur HTTP Apache basse et provoque des crashes avec certains modules courants. +

    Langues Disponibles:  de  | diff --git a/docs/manual/mod/mpm_common.html.ja.utf8 b/docs/manual/mod/mpm_common.html.ja.utf8 index 741d6b6d44f..4dc96d246f5 100644 --- a/docs/manual/mod/mpm_common.html.ja.utf8 +++ b/docs/manual/mod/mpm_common.html.ja.utf8 @@ -62,7 +62,6 @@

  • ThreadStackSize
    • -
    top

    CoreDumpDirectory ディレクティブ

    @@ -744,6 +743,7 @@ simultaneously +

    翻訳済み言語:  de  | diff --git a/docs/manual/mod/mpm_common.html.tr.utf8 b/docs/manual/mod/mpm_common.html.tr.utf8 index 5712a0cd60d..dd7a00f9de3 100644 --- a/docs/manual/mod/mpm_common.html.tr.utf8 +++ b/docs/manual/mod/mpm_common.html.tr.utf8 @@ -58,7 +58,6 @@

  • ThreadStackSize
    • -
    top

    CoreDumpDirectory Yönergesi

    @@ -772,6 +771,7 @@ açıklaması da azaltmak bazı modüllerle çökmeye sebep olur. +

    Mevcut Diller:  de  | diff --git a/docs/manual/mod/mpm_netware.html.en b/docs/manual/mod/mpm_netware.html.en index d40d0bf10ca..da544161780 100644 --- a/docs/manual/mod/mpm_netware.html.en +++ b/docs/manual/mod/mpm_netware.html.en @@ -84,7 +84,6 @@ ports Apache httpd uses

    -
    top

    MaxThreads Directive

    @@ -105,6 +104,7 @@

    +

    Available Languages:  en  | diff --git a/docs/manual/mod/mpm_netware.html.fr b/docs/manual/mod/mpm_netware.html.fr index 0bf021b63de..bca8fd012c8 100644 --- a/docs/manual/mod/mpm_netware.html.fr +++ b/docs/manual/mod/mpm_netware.html.fr @@ -85,7 +85,6 @@ NetWare qu'utilise Apache httpd

    -
    top

    Directive MaxThreads

    @@ -107,6 +106,7 @@ qu'utilise Apache httpd

    +

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/prefork.html.de b/docs/manual/mod/prefork.html.de index a189f7cb171..e6d64b69818 100644 --- a/docs/manual/mod/prefork.html.de +++ b/docs/manual/mod/prefork.html.de @@ -85,48 +85,6 @@ und Ports

    top
    -
    -

    Arbeitsweise

    -

    Ein einzelner Steuerprozess ist für den Start von - Kindprozessen verantwortlich, die auf Verbindungen warten und diese - bedienen, sobald sie eintreffen. Der Apache versucht immer, mehrere - freie oder unbeschäftigte Serverprozesse vorzuhalten, - die zur Bedienung eingehender Anfragen bereit stehen. Auf diese Weise - müssen Clients nicht darauf warten, dass neue Kindprozesse - geforkt werden, bevor ihre Anfrage bearbeitet werden kann.

    - -

    StartServers, - MinSpareServers, - MaxSpareServers und - MaxClients regulieren, - wie der Elternprozess Kindprozesse zur Bedienung von Anfragen erstellt. - Im Allgemeinen ist der Apache sehr selbstregulierend, so dass die meisten - Angebote die Voreinstellung dieser Direktiven nicht verändern - müssen. Systeme, die mehr als 256 gleichzeitige Anfragen bedienen - müssen, können MaxClients erhöhen, während - Systeme mit begrenztem Arbeitsspeicher möglicherweise - MaxClients heruntersetzen - müssen, um den Server vor Flatterverhalten (Arbeitsspeicherinhalte auf - Platte auslagern - und zurück) zu schützen. Weitere - Informationen zur Feinabstimmung der Prozesserstellung sind in den - Performance-Hinweisen zu - finden.

    - -

    Währen der Elternprozess unter Unix normalerweise als - root gestartet wird, um sich an Port 80 binden zu können, - werden die Kindprozesse unter einem weniger privilegierten Benutzer - gestartet. Die Direktiven User - und Group werden dazu - verwendet, die Privilegien der Apache-Kindprozesse festzulegen. Die - Kindprozesse müssen in der Lage sein, alle Inhalte zu lesen, die - sie ausliefern sollen, sollten darüber hinaus jedoch so wenig wie - möglich Rechte besitzen.

    - -

    MaxRequestsPerChild - bestimmt, wie häufig der Server Prozesse erneuert, indem er alte - beendet und neue startet.

    -
    -
    top

    MaxSpareServers-Direktive

    Beschreibung:Maximale Anzahl der unbeschäftigten Kindprozesse des @@ -186,6 +144,48 @@
  • StartServers
    • +
    top
    +
    +

    Arbeitsweise

    +

    Ein einzelner Steuerprozess ist für den Start von + Kindprozessen verantwortlich, die auf Verbindungen warten und diese + bedienen, sobald sie eintreffen. Der Apache versucht immer, mehrere + freie oder unbeschäftigte Serverprozesse vorzuhalten, + die zur Bedienung eingehender Anfragen bereit stehen. Auf diese Weise + müssen Clients nicht darauf warten, dass neue Kindprozesse + geforkt werden, bevor ihre Anfrage bearbeitet werden kann.

    + +

    StartServers, + MinSpareServers, + MaxSpareServers und + MaxClients regulieren, + wie der Elternprozess Kindprozesse zur Bedienung von Anfragen erstellt. + Im Allgemeinen ist der Apache sehr selbstregulierend, so dass die meisten + Angebote die Voreinstellung dieser Direktiven nicht verändern + müssen. Systeme, die mehr als 256 gleichzeitige Anfragen bedienen + müssen, können MaxClients erhöhen, während + Systeme mit begrenztem Arbeitsspeicher möglicherweise + MaxClients heruntersetzen + müssen, um den Server vor Flatterverhalten (Arbeitsspeicherinhalte auf + Platte auslagern - und zurück) zu schützen. Weitere + Informationen zur Feinabstimmung der Prozesserstellung sind in den + Performance-Hinweisen zu + finden.

    + +

    Währen der Elternprozess unter Unix normalerweise als + root gestartet wird, um sich an Port 80 binden zu können, + werden die Kindprozesse unter einem weniger privilegierten Benutzer + gestartet. Die Direktiven User + und Group werden dazu + verwendet, die Privilegien der Apache-Kindprozesse festzulegen. Die + Kindprozesse müssen in der Lage sein, alle Inhalte zu lesen, die + sie ausliefern sollen, sollten darüber hinaus jedoch so wenig wie + möglich Rechte besitzen.

    + +

    MaxRequestsPerChild + bestimmt, wie häufig der Server Prozesse erneuert, indem er alte + beendet und neue startet.

    +

    Verfügbare Sprachen:  de  | diff --git a/docs/manual/mod/prefork.html.en b/docs/manual/mod/prefork.html.en index 54b7457616e..61606ae3fc1 100644 --- a/docs/manual/mod/prefork.html.en +++ b/docs/manual/mod/prefork.html.en @@ -80,49 +80,6 @@ uses

    top
    -
    -

    How it Works

    -

    A single control process is responsible for launching child - processes which listen for connections and serve them when they - arrive. Apache httpd always tries to maintain several spare - or idle server processes, which stand ready to serve incoming - requests. In this way, clients do not need to wait for a new - child processes to be forked before their requests can be - served.

    - -

    The StartServers, - MinSpareServers, - MaxSpareServers, and - MaxRequestWorkers regulate how - the parent process creates children to serve requests. In general, - Apache httpd is very self-regulating, so most sites do not need to - adjust these directives from their default values. Sites which - need to serve more than 256 simultaneous requests may need to - increase MaxRequestWorkers, - while sites with limited memory may need to decrease MaxRequestWorkers to keep the server from - thrashing (swapping memory to disk and back). More information - about tuning process creation is provided in the performance hints - documentation.

    - -

    While the parent process is usually started as root - under Unix in order to bind to port 80, the child processes are - launched by Apache httpd as a less-privileged user. The User and Group directives are used to set - the privileges of the Apache httpd child processes. The child processes - must be able to read all the content that will be served, but - should have as few privileges beyond that as possible.

    - -

    MaxConnectionsPerChild - controls how frequently the server recycles processes by killing - old ones and launching new ones.

    - -

    This MPM uses the mpm-accept mutex to serialize - access to incoming connections when subject to the thundering herd - problem (generally, when there are multiple listening sockets). - The implementation aspects of this mutex can be configured with the - Mutex directive. The performance hints - documentation has additional information about this mutex.

    -
    -
    top

    MaxSpareServers Directive

    @@ -182,6 +139,49 @@ uses
  • MinSpareThreads
    • +
    top
    +
    +

    How it Works

    +

    A single control process is responsible for launching child + processes which listen for connections and serve them when they + arrive. Apache httpd always tries to maintain several spare + or idle server processes, which stand ready to serve incoming + requests. In this way, clients do not need to wait for a new + child processes to be forked before their requests can be + served.

    + +

    The StartServers, + MinSpareServers, + MaxSpareServers, and + MaxRequestWorkers regulate how + the parent process creates children to serve requests. In general, + Apache httpd is very self-regulating, so most sites do not need to + adjust these directives from their default values. Sites which + need to serve more than 256 simultaneous requests may need to + increase MaxRequestWorkers, + while sites with limited memory may need to decrease MaxRequestWorkers to keep the server from + thrashing (swapping memory to disk and back). More information + about tuning process creation is provided in the performance hints + documentation.

    + +

    While the parent process is usually started as root + under Unix in order to bind to port 80, the child processes are + launched by Apache httpd as a less-privileged user. The User and Group directives are used to set + the privileges of the Apache httpd child processes. The child processes + must be able to read all the content that will be served, but + should have as few privileges beyond that as possible.

    + +

    MaxConnectionsPerChild + controls how frequently the server recycles processes by killing + old ones and launching new ones.

    + +

    This MPM uses the mpm-accept mutex to serialize + access to incoming connections when subject to the thundering herd + problem (generally, when there are multiple listening sockets). + The implementation aspects of this mutex can be configured with the + Mutex directive. The performance hints + documentation has additional information about this mutex.

    +

    Available Languages:  de  | diff --git a/docs/manual/mod/prefork.html.fr b/docs/manual/mod/prefork.html.fr index 7eb89f02982..39f79ead128 100644 --- a/docs/manual/mod/prefork.html.fr +++ b/docs/manual/mod/prefork.html.fr @@ -83,52 +83,6 @@ processus, sans thread qu'utilise le serveur HTTP Apache

    top
    -
    -

    Comment ça marche

    -

    Un processus de contrôle unique a pour tâche de lancer les - processus enfants qui attendent les connexions et les traitent au - fur et à mesure qu'elles arrivent. Apache httpd essaie toujours de - maintenir plusieurs processus serveurs inactifs ou en - réserve, afin de pouvoir traiter les requêtes entrantes. De - cette façon, les clients n'ont pas besoin d'attendre le démarrage - d'un nouveau processus enfant pour que leurs requêtes puissent être - traitées.

    - -

    Les directives StartServers, MinSpareServers, MaxSpareServers et MaxRequestWorkers permettent de contrôler - la manière dont le processus parent crée les processus enfants pour - traiter les requêtes. En général, Apache httpd s'auto-contrôle de manière - efficace, de sorte que la plupart des sites peuvent conserver les - valeurs par défaut des directives. Les sites qui doivent traiter - plus de 256 requêtes simultanées doivent augmenter la valeur de - MaxRequestWorkers, alors que les - sites dont la ressource mémoire est limitée doivent la diminuer afin - d'éviter une hyperactivité du serveur (utilisation excessive de la - mémoire virtuelle sur disque). Vous trouverez plus d'informations à - propos du contrôle de la création de processus dans le document conseils en matière de - performances

    - -

    Alors que le processus parent est en général démarré en tant que - root sous Unix afin de pouvoir se mettre à l'écoute sur le port 80, les - processus enfants sont lancés par Apache httpd sous un utilisateur avec - privilèges restreints. On peut contrôler les privilèges accordés aux - processus enfants d'Apache httpd à l'aide des directives User et Group. Les processus enfants doivent - être en mesure de lire tous les contenus destinés à être servis, - mais leurs privilèges doivent être aussi bas que possible.

    - -

    La directive MaxConnectionsPerChild permet de - contrôler la fréquence à laquelle le serveur recycle ses processus - en arrêtant les plus anciens et en en lançant de nouveaux.

    - -

    Ce module MPM utilise le mutex mpm-accept pour - sérialiser l'accès aux connexions entrantes lorsque peut se - présenter un problème d'afflux de requêtes (en général quand il y a - plusieurs sockets en écoute). Les aspects de l'implémentation de ce - mutex peuvent être configurés via la directive Mutex. Vous trouverez des informations - supplémentaires à propos de ce mutex dans la documentation à propos - des conseils en matière de - performances

    -
    -
    top

    Directive MaxSpareServers

    Description:Maximum number of idle child server processes
  • MinSpareThreads
    • +
    top
    +
    +

    Comment ça marche

    +

    Un processus de contrôle unique a pour tâche de lancer les + processus enfants qui attendent les connexions et les traitent au + fur et à mesure qu'elles arrivent. Apache httpd essaie toujours de + maintenir plusieurs processus serveurs inactifs ou en + réserve, afin de pouvoir traiter les requêtes entrantes. De + cette façon, les clients n'ont pas besoin d'attendre le démarrage + d'un nouveau processus enfant pour que leurs requêtes puissent être + traitées.

    + +

    Les directives StartServers, MinSpareServers, MaxSpareServers et MaxRequestWorkers permettent de contrôler + la manière dont le processus parent crée les processus enfants pour + traiter les requêtes. En général, Apache httpd s'auto-contrôle de manière + efficace, de sorte que la plupart des sites peuvent conserver les + valeurs par défaut des directives. Les sites qui doivent traiter + plus de 256 requêtes simultanées doivent augmenter la valeur de + MaxRequestWorkers, alors que les + sites dont la ressource mémoire est limitée doivent la diminuer afin + d'éviter une hyperactivité du serveur (utilisation excessive de la + mémoire virtuelle sur disque). Vous trouverez plus d'informations à + propos du contrôle de la création de processus dans le document conseils en matière de + performances

    + +

    Alors que le processus parent est en général démarré en tant que + root sous Unix afin de pouvoir se mettre à l'écoute sur le port 80, les + processus enfants sont lancés par Apache httpd sous un utilisateur avec + privilèges restreints. On peut contrôler les privilèges accordés aux + processus enfants d'Apache httpd à l'aide des directives User et Group. Les processus enfants doivent + être en mesure de lire tous les contenus destinés à être servis, + mais leurs privilèges doivent être aussi bas que possible.

    + +

    La directive MaxConnectionsPerChild permet de + contrôler la fréquence à laquelle le serveur recycle ses processus + en arrêtant les plus anciens et en en lançant de nouveaux.

    + +

    Ce module MPM utilise le mutex mpm-accept pour + sérialiser l'accès aux connexions entrantes lorsque peut se + présenter un problème d'afflux de requêtes (en général quand il y a + plusieurs sockets en écoute). Les aspects de l'implémentation de ce + mutex peuvent être configurés via la directive Mutex. Vous trouverez des informations + supplémentaires à propos de ce mutex dans la documentation à propos + des conseils en matière de + performances

    +

    Langues Disponibles:  de  | diff --git a/docs/manual/mod/prefork.html.ja.utf8 b/docs/manual/mod/prefork.html.ja.utf8 index f3a750ef37b..867ef5c05d6 100644 --- a/docs/manual/mod/prefork.html.ja.utf8 +++ b/docs/manual/mod/prefork.html.ja.utf8 @@ -87,51 +87,6 @@ が使用するアドレスとポートの設定

    top
    -
    -

    動作方法

    -

    一つのコントロールプロセスが、 - コネクションに対して listen して、しかるべき時に応答する - 子プロセスを起動します。Apache は常に幾つかのスペア - かアイドルなサーバプロセスを維持していて、それらは入ってきた - リクエストに応答できるように待機しています。 - このようにしてクライアントは、リクエストが応答される前に、 - 新しい子プロセスが fork されるのを待たなくてもよいように - なっています。

    - -

    親プロセスがリクエストに応答するの子プロセスを - どのように生成するかは、 - StartServers, - MinSpareServers, - MaxSpareServers, - MaxClients - で調整します。一般的に、Apache は非常に自律的なので、 - 大抵のサイトではこれらのディレクティブをデフォルト値から調整する - 必要はないでしょう。 - 同時に 256 を超えるリクエストに応答しないといけないサイトでは、 - MaxClients - を増やす必要があるでしょう。 - 一方、メモリの限られているサイトでは、スラッシング - (メモリとディスク間で何度もスワップ) が起こるのを防ぐために - MaxClients - を減らす必要があるでしょう。プロセス生成のチューニングに関する - 詳しい情報は、性能に関するヒント - にあります。

    - -

    通常 Unix では親プロセスは 80 番ポートにバインドするために - root で起動されますが、子プロセスやスレッドは - もっと低い権限のユーザで Apache によって起動されます。 - User と - Group - ディレクティブは - Apache の子プロセスの権限を設定するのに用いられます。 - 子プロセスはクライアントに送るコンテンツ全てを読めないといけませんが、 - 可能な限り必要最小限の権限のみを持っているようにするべきです。

    - -

    MaxRequestsPerChild - は、古いプロセスを停止して新しいプロセスを起動することによって、 - どの程度の頻度でサーバがプロセスをリサイクルするかを制御します。

    -
    -
    top

    MaxSpareServers ディレクティブ

    Description:Nombre maximum de processus serveurs enfants @@ -197,6 +151,52 @@ inactifs
    @@ -184,6 +139,51 @@
  • StartServers
    • +
    top
    +
    +

    動作方法

    +

    一つのコントロールプロセスが、 + コネクションに対して listen して、しかるべき時に応答する + 子プロセスを起動します。Apache は常に幾つかのスペア + かアイドルなサーバプロセスを維持していて、それらは入ってきた + リクエストに応答できるように待機しています。 + このようにしてクライアントは、リクエストが応答される前に、 + 新しい子プロセスが fork されるのを待たなくてもよいように + なっています。

    + +

    親プロセスがリクエストに応答するの子プロセスを + どのように生成するかは、 + StartServers, + MinSpareServers, + MaxSpareServers, + MaxClients + で調整します。一般的に、Apache は非常に自律的なので、 + 大抵のサイトではこれらのディレクティブをデフォルト値から調整する + 必要はないでしょう。 + 同時に 256 を超えるリクエストに応答しないといけないサイトでは、 + MaxClients + を増やす必要があるでしょう。 + 一方、メモリの限られているサイトでは、スラッシング + (メモリとディスク間で何度もスワップ) が起こるのを防ぐために + MaxClients + を減らす必要があるでしょう。プロセス生成のチューニングに関する + 詳しい情報は、性能に関するヒント + にあります。

    + +

    通常 Unix では親プロセスは 80 番ポートにバインドするために + root で起動されますが、子プロセスやスレッドは + もっと低い権限のユーザで Apache によって起動されます。 + User と + Group + ディレクティブは + Apache の子プロセスの権限を設定するのに用いられます。 + 子プロセスはクライアントに送るコンテンツ全てを読めないといけませんが、 + 可能な限り必要最小限の権限のみを持っているようにするべきです。

    + +

    MaxRequestsPerChild + は、古いプロセスを停止して新しいプロセスを起動することによって、 + どの程度の頻度でサーバがプロセスをリサイクルするかを制御します。

    +

    翻訳済み言語:  de  | diff --git a/docs/manual/mod/prefork.html.tr.utf8 b/docs/manual/mod/prefork.html.tr.utf8 index 1b8d6af1c9f..8459c1f4179 100644 --- a/docs/manual/mod/prefork.html.tr.utf8 +++ b/docs/manual/mod/prefork.html.tr.utf8 @@ -80,47 +80,6 @@ portların ayarlanması

    top
    -
    -

    Nasıl çalışır?

    -

    Bağlantıları dinleyip gerektiğinde onlara hizmet sunan çocuk süreçleri - devreye almak tek bir denetim sürecinin sorumluluğundadır. Apache httpd - daima, gelen isteklere hizmet vermeye hazır bekleyen en fazla sayıda - sunucu sürecini yedekte tutmaya veya boşta bekletmeye - çalışır. Bu suretle, istemcilere isteklerinin sunulması için yeni çocuk - süreçlerin çatallanmasını beklemek gerekmez.

    - -

    Ana sürecin istekleri sunacak çocuk süreçleri oluşturma işlemini nasıl - gerçekleştireceği StartServers, MinSpareServers, MaxSpareServers ve MaxRequestWorkers yönergeleri ile düzenlenir. Apache httpd - kendiliğinden her duruma çok iyi uyum sağladığından, genelde, çoğu - sitenin bu yönergelerin öntanımlı değerlerini değiştirmesi gerekmez. - Aynı anda 256’dan fazla isteğe hizmet sunacak sitelerin MaxRequestWorkers değerini arttırmaları - gerekebilir. Ancak, fiziksel belleği yeterli olmayan sitelerin de - sunucunun belleği diske takaslamasını önlemek için bu değeri - azaltmaları gerekebilir. Süreç oluşturmanın ayarlanması ile ilgili daha - fazla bilgi edinmek için başarım - arttırma ipuçları belgesine bakınız.

    - -

    Unix altında 80. portu dinleyebilmek için ana sürecin - root tarafından çalıştırılmış olması gerekirse de çocuk - süreçler Apache httpd tarafından daha az yetkili bir kullanıcının - aidiyetinde çalıştırılırlar. Apache httpd’nin çocuk süreçlerinin - kullanıcı ve gruplarını ayarlamak için User ve Group - yönergeleri kullanılır. Çocuk süreçlerin sunacakları içeriği okumaya - yetkili olmaları gerekir, fakat bu yetkinin mümkün olduğunca kısıtlı - tutulmasına çalışılmalıdır.

    - -

    MaxConnectionsPerChild - yönergesi ana sunucunun eski süreçleri öldürüp yenilerini oluşturmayı - ne kadar sıklıkla yapacağını denetler.

    - -

    Bu MPM, gürleyen sürü sorunu ortaya çıktığında (genelde çok sayıda - dinlenen soket varlığında) gelen bağlantılara erişimi dizgileştirmek için - mpm-accept muteksini kullanır. Bu muteksin gerçeklenimle - ilgili hususları Mutex yönergesi ile - yapılandırılabilir. Bu muteks hakkında ek bilgi için başarımın arttırılması - belgesine bakınız.

    -
    -
    top

    MaxSpareServers Yönergesi

    説明:アイドルな子サーバプロセスの最大個数
    @@ -181,6 +140,47 @@
  • MinSpareThreads
    • +
    top
    +
    +

    Nasıl çalışır?

    +

    Bağlantıları dinleyip gerektiğinde onlara hizmet sunan çocuk süreçleri + devreye almak tek bir denetim sürecinin sorumluluğundadır. Apache httpd + daima, gelen isteklere hizmet vermeye hazır bekleyen en fazla sayıda + sunucu sürecini yedekte tutmaya veya boşta bekletmeye + çalışır. Bu suretle, istemcilere isteklerinin sunulması için yeni çocuk + süreçlerin çatallanmasını beklemek gerekmez.

    + +

    Ana sürecin istekleri sunacak çocuk süreçleri oluşturma işlemini nasıl + gerçekleştireceği StartServers, MinSpareServers, MaxSpareServers ve MaxRequestWorkers yönergeleri ile düzenlenir. Apache httpd + kendiliğinden her duruma çok iyi uyum sağladığından, genelde, çoğu + sitenin bu yönergelerin öntanımlı değerlerini değiştirmesi gerekmez. + Aynı anda 256’dan fazla isteğe hizmet sunacak sitelerin MaxRequestWorkers değerini arttırmaları + gerekebilir. Ancak, fiziksel belleği yeterli olmayan sitelerin de + sunucunun belleği diske takaslamasını önlemek için bu değeri + azaltmaları gerekebilir. Süreç oluşturmanın ayarlanması ile ilgili daha + fazla bilgi edinmek için başarım + arttırma ipuçları belgesine bakınız.

    + +

    Unix altında 80. portu dinleyebilmek için ana sürecin + root tarafından çalıştırılmış olması gerekirse de çocuk + süreçler Apache httpd tarafından daha az yetkili bir kullanıcının + aidiyetinde çalıştırılırlar. Apache httpd’nin çocuk süreçlerinin + kullanıcı ve gruplarını ayarlamak için User ve Group + yönergeleri kullanılır. Çocuk süreçlerin sunacakları içeriği okumaya + yetkili olmaları gerekir, fakat bu yetkinin mümkün olduğunca kısıtlı + tutulmasına çalışılmalıdır.

    + +

    MaxConnectionsPerChild + yönergesi ana sunucunun eski süreçleri öldürüp yenilerini oluşturmayı + ne kadar sıklıkla yapacağını denetler.

    + +

    Bu MPM, gürleyen sürü sorunu ortaya çıktığında (genelde çok sayıda + dinlenen soket varlığında) gelen bağlantılara erişimi dizgileştirmek için + mpm-accept muteksini kullanır. Bu muteksin gerçeklenimle + ilgili hususları Mutex yönergesi ile + yapılandırılabilir. Bu muteks hakkında ek bilgi için başarımın arttırılması + belgesine bakınız.

    +

    Mevcut Diller:  de  |

    Açıklama:Boştaki çocuk süreçlerin azami sayısı