From: Rich Bowen Date: Wed, 15 Apr 2015 16:33:41 +0000 (+0000) Subject: Rebuilds Daniel's change to the order of directictives vs topics in X-Git-Tag: 2.5.0-alpha~3285 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=cf8ed4e44a1bc1c51d7e7df4f631a7c44f7e29f6;p=apache 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/trunk@1673854 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/core.html.de b/docs/manual/mod/core.html.de index c287b322a3..c574b61e1b 100644 --- a/docs/manual/mod/core.html.de +++ b/docs/manual/mod/core.html.de @@ -124,7 +124,6 @@ Servers
  • Warning
    • -
    top

    AcceptFilter-Direktive

    @@ -3661,6 +3660,7 @@ IP-Adressen angewendet werden

    Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

    +

    Verfügbare Sprachen:  de  | diff --git a/docs/manual/mod/core.html.en b/docs/manual/mod/core.html.en index c9a49fac4d..ce3ff4da0b 100644 --- a/docs/manual/mod/core.html.en +++ b/docs/manual/mod/core.html.en @@ -121,7 +121,6 @@ available

  • Warning
    • -
    top

    AcceptFilter Directive

    @@ -4640,6 +4639,7 @@ hostname or IP address +

    Available Languages:  de  | diff --git a/docs/manual/mod/core.html.es b/docs/manual/mod/core.html.es index 61acd5605a..98d1915621 100644 --- a/docs/manual/mod/core.html.es +++ b/docs/manual/mod/core.html.es @@ -124,7 +124,6 @@

  • Warning
    • -
    top

    AcceptFilter Directiva

    @@ -4360,6 +4359,7 @@ hostname or IP address

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

    +

    Idiomas disponibles:  de  | diff --git a/docs/manual/mod/core.html.fr b/docs/manual/mod/core.html.fr index 8a3c7dcd7b..ea2eb10b58 100644 --- a/docs/manual/mod/core.html.fr +++ b/docs/manual/mod/core.html.fr @@ -123,7 +123,6 @@ disponibles

  • Warning
    • -
    top

    Directive AcceptFilter

    @@ -4961,6 +4960,7 @@ Apache. +

    Langues Disponibles:  de  | diff --git a/docs/manual/mod/core.html.ja.utf8 b/docs/manual/mod/core.html.ja.utf8 index 00e11a9aca..f8aee4e117 100644 --- a/docs/manual/mod/core.html.ja.utf8 +++ b/docs/manual/mod/core.html.ja.utf8 @@ -124,7 +124,6 @@

  • Warning
    • -
    top

    AcceptFilter ディレクティブ

    @@ -3576,6 +3575,7 @@ of a request or the last 63, assuming the request itself is greater than

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

    +

    翻訳済み言語:  de  | diff --git a/docs/manual/mod/core.html.tr.utf8 b/docs/manual/mod/core.html.tr.utf8 index 06df756384..2466055c6e 100644 --- a/docs/manual/mod/core.html.tr.utf8 +++ b/docs/manual/mod/core.html.tr.utf8 @@ -122,7 +122,6 @@

  • Warning
    • -
    top

    AcceptFilter Yönergesi

    @@ -4511,6 +4510,7 @@ gerçekleşmesi için sunucunun geçmesini bekleyeceği süre.
    Uyumluluk:2.5 and later

    Bu yönergenin belgesi henüz Türkçeye çevrilmedi. Lütfen İngilizce sürümüne bakınız.

    +

    Mevcut Diller:  de  | diff --git a/docs/manual/mod/event.html.en b/docs/manual/mod/event.html.en index e50d2db5f1..3b4746a904 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 baa5edc252..7f674fe799 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 2bcb79ca8b..ce8c254358 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

    @@ -457,6 +456,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 4a729fd150..b8ce55d420 100644 --- a/docs/manual/mod/mod_access_compat.html.fr +++ b/docs/manual/mod/mod_access_compat.html.fr @@ -96,7 +96,6 @@ ce module sont devenues obsol

  • mod_authz_host
  • mod_authz_core
    • -
    top

    Directive Allow

    @@ -481,6 +480,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 1b21dde70e..1a9ba5cfa3 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 75bf752204..cf360ed5f1 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 7a8d286b61..0dffd02393 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

    @@ -148,6 +147,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 7ef602376b..6a489ce49c 100644 --- a/docs/manual/mod/mod_actions.html.fr +++ b/docs/manual/mod/mod_actions.html.fr @@ -56,7 +56,6 @@ type de m

  • Utilisation des gestionnaires d'Apache httpd
    • -
    top

    Directive Action

    @@ -158,6 +157,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 ba212c5a55..a22b43485c 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 a287e02122..b3284ca2d7 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 afce203558..0fb0c74922 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 083e374787..eb8fc64099 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 6abb9c5404..44129cbc44 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 @@ -607,6 +567,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 b8469e61b6..db6fb49c06 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 aabd10b5db..d6e65c8b44 100644 --- a/docs/manual/mod/mod_alias.html.tr.utf8 +++ b/docs/manual/mod/mod_alias.html.tr.utf8 @@ -76,40 +76,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 /gaz -

    - -

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

    - -
    -
    top

    Alias Yönergesi

    ¼³¸í:URLÀ» ƯÁ¤ ÆÄÀϽýºÅÛ Àå¼Ò·Î ´ëÀÀÇÑ´Ù
    @@ -527,6 +493,40 @@ 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 /gaz +

    + +

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

    + +

    Mevcut Diller:  en  | diff --git a/docs/manual/mod/mod_allowhandlers.html.en b/docs/manual/mod/mod_allowhandlers.html.en index 51d92d99bc..e770dca70d 100644 --- a/docs/manual/mod/mod_allowhandlers.html.en +++ b/docs/manual/mod/mod_allowhandlers.html.en @@ -54,7 +54,6 @@ returns 403 FORBIDDEN to the client. This can be used with directives like

  • SetHandler
  • AddHandler
    • -
    top

    AllowHandlers Directive

    Açıklama:URL’leri dosya sistemi konumlarıyla eşler.
    @@ -81,6 +80,7 @@ earlier in the configuration merge order:

    +

    Available Languages:  en 

    diff --git a/docs/manual/mod/mod_allowmethods.html.en b/docs/manual/mod/mod_allowmethods.html.en index 1631406ebe..b5eb35cdda 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

    @@ -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 bc50398c72..21bdb70d0c 100644 --- a/docs/manual/mod/mod_allowmethods.html.fr +++ b/docs/manual/mod/mod_allowmethods.html.fr @@ -48,7 +48,6 @@ est du style :

  • AllowMethods
    • -
    top

    Directive AllowMethods

    @@ -82,6 +81,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 0e78f816d6..d4885e8434 100644 --- a/docs/manual/mod/mod_auth_basic.html.en +++ b/docs/manual/mod/mod_auth_basic.html.en @@ -57,7 +57,6 @@

  • Require
  • Authentication howto
    • -
    top

    AuthBasicAuthoritative Directive

    @@ -252,6 +251,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 c2aa3f9a64..92c5cbd031 100644 --- a/docs/manual/mod/mod_auth_basic.html.fr +++ b/docs/manual/mod/mod_auth_basic.html.fr @@ -61,7 +61,6 @@

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

    Directive AuthBasicAuthoritative

    @@ -281,6 +280,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 9f55380602..a8934c7c47 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 6edd089b4e..5860430e82 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 c9df7ecb40..919449ab9f 100644 --- a/docs/manual/mod/mod_auth_digest.html.en +++ b/docs/manual/mod/mod_auth_digest.html.en @@ -68,48 +68,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

    - + +
    top
    +

    AuthLDAPSubGroupClass Directive

    +
    Description:Selects the algorithm used to calculate the challenge and @@ -298,6 +256,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 c3f051da34..7354f919c1 100644 --- a/docs/manual/mod/mod_auth_digest.html.fr +++ b/docs/manual/mod/mod_auth_digest.html.fr @@ -74,48 +74,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

    - +

    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

    +
    Description:Sélectionne l'algorithme utilisé pour calculer les @@ -320,6 +278,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 b3ef665e4d..e79a403995 100644 --- a/docs/manual/mod/mod_auth_digest.html.ko.euc-kr +++ b/docs/manual/mod/mod_auth_digest.html.ko.euc-kr @@ -62,75 +62,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 Áö½Ã¾î

    - + +
    top
    +

    AuthLDAPSearchAsUser Directive

    +
    ¼³¸í:digest authentication¿¡¼­ challenge¿Í response @@ -315,6 +246,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 2f38a4774b..5091fe9368 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 cdbc78e5bd..1d47e5d234 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
    +

    AuthLDAPRemoteUserIsDN 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 75c2dbd80e..5644f9abe1 100644 --- a/docs/manual/mod/mod_authn_anon.html.en +++ b/docs/manual/mod/mod_authn_anon.html.en @@ -67,49 +67,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 638725b1d2..959aceac65 100644 --- a/docs/manual/mod/mod_authn_anon.html.fr +++ b/docs/manual/mod/mod_authn_anon.html.fr @@ -72,51 +72,6 @@ authentifi
  • 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 @@ -208,6 +165,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 80dd1d24b6..c145264dc0 100644 --- a/docs/manual/mod/mod_authn_anon.html.ja.utf8 +++ b/docs/manual/mod/mod_authn_anon.html.ja.utf8 @@ -72,49 +72,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 à @@ -225,6 +180,51 @@ email fournie comme mot de passe est correct
    - +

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

    - - +

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

    - - +

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

    - - -
    説明:パスワードの検査無しでアクセスを許可する userID を指定する @@ -212,6 +169,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 a0897fcded..686d382397 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 Áö½Ã¾î

  • mod_authz_groupfile
    • top
    -
    -

    Contents

    - -
    ¼³¸í:¾ÏÈ£°Ë»ç¾øÀÌ Á¢±ÙÀ» Çã¿ëÇÒ »ç¿ëÀÚ ¾ÆÀ̵ðµéÀ» @@ -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 b68c3a16cc..b3adf6f79d 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 264885bfd2..72d5537fe3 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 @@ -248,6 +176,78 @@ the specified alias
    passe
    top
    +

    Directive AuthDBDUserPWQuery

    +
    Description:L'identifiant de l'autorisation à utiliser avec @@ -264,6 +186,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 92766b3a8a..0290cda004 100644 --- a/docs/manual/mod/mod_authn_dbd.html.en +++ b/docs/manual/mod/mod_authn_dbd.html.en @@ -74,6 +74,70 @@
  • Password Formats
    • top
    +

    AuthDBDUserPWQuery Directive

    + + + + + + +
    Description:SQL query to look up a password for a user
    Syntax:AuthDBDUserPWQuery query
    Context:directory
    Status:Extension
    Module:mod_authn_dbd
    +

    The AuthDBDUserPWQuery specifies an + SQL query to look up a password for a specified 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.

    + 
    AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
    + +

    The first column value of the first row returned by the query + statement should be a string containing the encrypted password. + Subsequent rows will be ignored. If no rows are returned, the user + will not be authenticated through mod_authn_dbd.

    +

    If httpd was built against APR version 1.3.0 + or higher, any additional column values in the first row returned by + the query statement will be stored as environment variables with + names of the form AUTHENTICATE_COLUMN. +

    +

    The encrypted password format depends on which authentication + frontend (e.g. mod_auth_basic or + mod_auth_digest) is being used. See Password Formats for + more information.

    + +
    +
    top
    +

    AuthDBDUserRealmQuery Directive

    + + + + + + +
    Description:SQL query to look up a password hash for a user and realm. +
    Syntax:AuthDBDUserRealmQuery query
    Context:directory
    Status:Extension
    Module:mod_authn_dbd
    +

    The AuthDBDUserRealmQuery specifies an + SQL query to look up a password for a specified user and realm in a + digest authentication process. + The user's ID and the realm, in that order, will be passed as string + parameters when the SQL query is executed. They may be referenced + within the query statement using %s format specifiers.

    + 
    AuthDBDUserRealmQuery "SELECT password FROM authn WHERE user = %s AND realm = %s"
    + +

    The first column value of the first row returned by the query + statement should be a string containing the encrypted password. + Subsequent rows will be ignored. If no rows are returned, the user + will not be authenticated through mod_authn_dbd.

    +

    If httpd was built against APR version 1.3.0 + or higher, any additional column values in the first row returned by + the query statement will be stored as environment variables with + names of the form AUTHENTICATE_COLUMN. +

    +

    The encrypted password format depends on which authentication + frontend (e.g. mod_auth_basic or + mod_auth_digest) is being used. See Password Formats for + more information.

    + +
    +
    top

    Performance and Cacheing

    @@ -148,70 +212,6 @@ configuration required in some web applications.

    Please read mod_dbd documentation for more information about security on this scope.

    -
    top
    -

    AuthDBDUserPWQuery Directive

    - - - - - - -
    Description:SQL query to look up a password for a user
    Syntax:AuthDBDUserPWQuery query
    Context:directory
    Status:Extension
    Module:mod_authn_dbd
    -

    The AuthDBDUserPWQuery specifies an - SQL query to look up a password for a specified 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.

    - 
    AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
    - -

    The first column value of the first row returned by the query - statement should be a string containing the encrypted password. - Subsequent rows will be ignored. If no rows are returned, the user - will not be authenticated through mod_authn_dbd.

    -

    If httpd was built against APR version 1.3.0 - or higher, any additional column values in the first row returned by - the query statement will be stored as environment variables with - names of the form AUTHENTICATE_COLUMN. -

    -

    The encrypted password format depends on which authentication - frontend (e.g. mod_auth_basic or - mod_auth_digest) is being used. See Password Formats for - more information.

    - -
    -
    top
    -

    AuthDBDUserRealmQuery Directive

    - - - - - - -
    Description:SQL query to look up a password hash for a user and realm. -
    Syntax:AuthDBDUserRealmQuery query
    Context:directory
    Status:Extension
    Module:mod_authn_dbd
    -

    The AuthDBDUserRealmQuery specifies an - SQL query to look up a password for a specified user and realm in a - digest authentication process. - The user's ID and the realm, in that order, will be passed as string - parameters when the SQL query is executed. They may be referenced - within the query statement using %s format specifiers.

    - 
    AuthDBDUserRealmQuery "SELECT password FROM authn WHERE user = %s AND realm = %s"
    - -

    The first column value of the first row returned by the query - statement should be a string containing the encrypted password. - Subsequent rows will be ignored. If no rows are returned, the user - will not be authenticated through mod_authn_dbd.

    -

    If httpd was built against APR version 1.3.0 - or higher, any additional column values in the first row returned by - the query statement will be stored as environment variables with - names of the form AUTHENTICATE_COLUMN. -

    -

    The encrypted password format depends on which authentication - frontend (e.g. mod_auth_basic or - mod_auth_digest) is being used. See Password Formats for - more information.

    - -

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_authn_dbd.html.fr b/docs/manual/mod/mod_authn_dbd.html.fr index 8a422e1f7a..e4a127f927 100644 --- a/docs/manual/mod/mod_authn_dbd.html.fr +++ b/docs/manual/mod/mod_authn_dbd.html.fr @@ -75,6 +75,81 @@ SQL

    + + + + + +
    Description:Requête SQL servant à vérifier le mot de passe d'un +utilisateur
    Syntaxe:AuthDBDUserPWQuery requête
    Contexte:répertoire
    Statut:Extension
    Module:mod_authn_dbd
    +

    La directive AuthDBDUserPWQuery permet de + spécifier une requête servant à vérifier le mot de passe d'un + utilisateur donné. L'identifiant utilisateur sera transmis comme + paramètre sous forme d'une seule chaîne de caractères lorsque la + requête sera exécutée. Cet identifiant est référencé dans la requête + en utilisant le spécificateur de format %s.

    + 
    AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
    + +

    La première colonne du premier enregistrement renvoyé par la + requête se présentera sous la forme d'une chaîne de caractères + contenant le mot de passe chiffré. Les enregistrements suivants sont + ignorés. Si aucun enregistrement n'est renvoyé, l'utilisateur ne + sera pas authentifié par mod_authn_dbd.

    +

    Si httpd a été compilé avec la version 1.3.0 ou supérieure de + l'APR, toute valeur de colonne supplémentaire + du premier enregistrement renvoyé par la requête sera stockée dans + une variable d'environnement dont le nom aura la forme + AUTHENTICATE_valeur-colonne. +

    +

    Le format du mot de passe chiffré dépend du frontal + d'authentification utilisé (par exemple + mod_auth_basic ou + mod_auth_digest). Voir la documentation sur les Formats de mots de passe pour + plus de détails.

    + +
    +
    top
    +

    Directive AuthDBDUserRealmQuery

    + + + + + + +
    Description:Requête SQL servant à vérifier une empreinte de mot de +passe pour un utilisateur et un identifiant d'authentification. +
    Syntaxe:AuthDBDUserRealmQuery requête
    Contexte:répertoire
    Statut:Extension
    Module:mod_authn_dbd
    +

    La directive AuthDBDUserRealmQuery spécifie + une requête SQL servant à vérifier une empreinte de mot + de passe pour un utilisateur et un identifiant d'authentification + donnés au cours d'un processus d'authentification digest. Les + identifiants de l'utilisateur et de l'authentification + sont passés dans cet ordre comme paramètres à l'exécution de la + requête. Ils sont référencés dans la chaîne de la requête en + utilisant des spécificateurs de format %s.

    + 
    AuthDBDUserRealmQuery "SELECT password FROM authn WHERE user = %s AND realm = %s"
    + +

    La première colonne du premier enregistrement renvoyé par la + requête se présentera sous la forme d'une chaîne de caractères + contenant le mot de passe chiffré. Les enregistrements suivants + seront ignorés. Si aucun enregistrement n'est renvoyé, l'utilisateur + ne sera pas authentifié par mod_authn_dbd.

    +

    Si httpd a été compilé avec une version 1.3.0 ou supérieure de + l'APR, toute valeur de colonne supplémentaire + du premier enregistrement renvoyé par la requête sera stockée dans + une variable d'environnement avec un nom de la forme + AUTHENTICATE_COLONNE. +

    +

    Le format du mot de passe chiffré dépend du frontal + d'authentification utilisé (par exemple + mod_auth_basic ou + mod_auth_digest). Voir la documentation sur les Formats de mots de passe pour + plus de détails.

    + +
    +
    top

    Performances et mise en cache

    @@ -158,81 +233,6 @@ configuration n mod_dbd pour plus d'informations à propos de la sécurité dans ce domaine.

    -
    top
    -

    Directive AuthDBDUserPWQuery

    - - - - - - -
    Description:Requête SQL servant à vérifier le mot de passe d'un -utilisateur
    Syntaxe:AuthDBDUserPWQuery requête
    Contexte:répertoire
    Statut:Extension
    Module:mod_authn_dbd
    -

    La directive AuthDBDUserPWQuery permet de - spécifier une requête servant à vérifier le mot de passe d'un - utilisateur donné. L'identifiant utilisateur sera transmis comme - paramètre sous forme d'une seule chaîne de caractères lorsque la - requête sera exécutée. Cet identifiant est référencé dans la requête - en utilisant le spécificateur de format %s.

    - 
    AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
    - -

    La première colonne du premier enregistrement renvoyé par la - requête se présentera sous la forme d'une chaîne de caractères - contenant le mot de passe chiffré. Les enregistrements suivants sont - ignorés. Si aucun enregistrement n'est renvoyé, l'utilisateur ne - sera pas authentifié par mod_authn_dbd.

    -

    Si httpd a été compilé avec la version 1.3.0 ou supérieure de - l'APR, toute valeur de colonne supplémentaire - du premier enregistrement renvoyé par la requête sera stockée dans - une variable d'environnement dont le nom aura la forme - AUTHENTICATE_valeur-colonne. -

    -

    Le format du mot de passe chiffré dépend du frontal - d'authentification utilisé (par exemple - mod_auth_basic ou - mod_auth_digest). Voir la documentation sur les Formats de mots de passe pour - plus de détails.

    - -
    -
    top
    -

    Directive AuthDBDUserRealmQuery

    - - - - - - -
    Description:Requête SQL servant à vérifier une empreinte de mot de -passe pour un utilisateur et un identifiant d'authentification. -
    Syntaxe:AuthDBDUserRealmQuery requête
    Contexte:répertoire
    Statut:Extension
    Module:mod_authn_dbd
    -

    La directive AuthDBDUserRealmQuery spécifie - une requête SQL servant à vérifier une empreinte de mot - de passe pour un utilisateur et un identifiant d'authentification - donnés au cours d'un processus d'authentification digest. Les - identifiants de l'utilisateur et de l'authentification - sont passés dans cet ordre comme paramètres à l'exécution de la - requête. Ils sont référencés dans la chaîne de la requête en - utilisant des spécificateurs de format %s.

    - 
    AuthDBDUserRealmQuery "SELECT password FROM authn WHERE user = %s AND realm = %s"
    - -

    La première colonne du premier enregistrement renvoyé par la - requête se présentera sous la forme d'une chaîne de caractères - contenant le mot de passe chiffré. Les enregistrements suivants - seront ignorés. Si aucun enregistrement n'est renvoyé, l'utilisateur - ne sera pas authentifié par mod_authn_dbd.

    -

    Si httpd a été compilé avec une version 1.3.0 ou supérieure de - l'APR, toute valeur de colonne supplémentaire - du premier enregistrement renvoyé par la requête sera stockée dans - une variable d'environnement avec un nom de la forme - AUTHENTICATE_COLONNE. -

    -

    Le format du mot de passe chiffré dépend du frontal - d'authentification utilisé (par exemple - mod_auth_basic ou - mod_auth_digest). Voir la documentation sur les Formats de mots de passe pour - plus de détails.

    - -

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_authn_dbm.html.en b/docs/manual/mod/mod_authn_dbm.html.en index 59671c91cf..66cf82cbc7 100644 --- a/docs/manual/mod/mod_authn_dbm.html.en +++ b/docs/manual/mod/mod_authn_dbm.html.en @@ -66,7 +66,6 @@

  • htdbm
  • Password Formats
    • -
    top

    AuthDBMType Directive

    @@ -138,6 +137,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 fba73c24d2..da49cd1670 100644 --- a/docs/manual/mod/mod_authn_dbm.html.fr +++ b/docs/manual/mod/mod_authn_dbm.html.fr @@ -66,7 +66,6 @@ passe

  • htpasswd
  • htdbm
    • -
    top

    Directive AuthDBMType

    @@ -145,6 +144,7 @@ des utilisateurs et de leurs mots de passe utilitaire permettant de maintenir les fichiers DBM.

    +

    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 1f2892ab15..797ea0ced7 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 82b3e74b4e..3b7cbd0492 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 b221c885ba..e9f8a77755 100644 --- a/docs/manual/mod/mod_authn_file.html.en +++ b/docs/manual/mod/mod_authn_file.html.en @@ -62,7 +62,6 @@

  • htdigest
  • Password Formats
    • -
    top

    AuthUserFile Directive

    @@ -128,6 +127,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 2eba3a8034..91dd1d299f 100644 --- a/docs/manual/mod/mod_authn_file.html.fr +++ b/docs/manual/mod/mod_authn_file.html.fr @@ -63,7 +63,6 @@ texte

  • Formats de mots de passe
    • -
    top

    Directive AuthUserFile

    @@ -136,6 +135,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 30070d0155..71dde525f8 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 e4cba5699f..a0c8410e8c 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 438475ab34..eb9e2198fc 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 45f69285e7..8368987404 100644 --- a/docs/manual/mod/mod_authn_socache.html.fr +++ b/docs/manual/mod/mod_authn_socache.html.fr @@ -53,73 +53,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 8c64aa8a87..8100e61ac5 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 @@ -251,6 +184,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 cc55e99061..4a32d9cee0 100644 --- a/docs/manual/mod/mod_authnz_ldap.html.en +++ b/docs/manual/mod/mod_authnz_ldap.html.en @@ -101,1323 +101,1323 @@ 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.

    -
  • - The Require Directives +

    Note

    + No authorization variables are set when a user is authorized on the basis of + Require valid-user. +
    - -
    • +
    +
    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.

    -
  • Examples
    • -
  • Using TLS
    • -
  • Using SSL
    • -
  • Exposing Login Information
    • -
  • Using Active Directory
    • -
  • - Using Microsoft FrontPage with - mod_authnz_ldap +

    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.

    - - - -
    top
    -
    -

    Operation

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

    -

    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.

    +

    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
 
-    
    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.
    
+#Run /path/to/program to get my password
+AuthLDAPBindPassword exec:/path/to/program
 
-
    The Authentication
-    Phase
    
+#Run /path/to/otherProgram and provide arguments
+AuthLDAPBindPassword "exec:/path/to/otherProgram argument1"
    -

    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.

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

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

    The file contains lines in the following format:

    -

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

    +

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

    - - - - +

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

    - - + +
    top
    +

    AuthLDAPCompareAsUser Directive

    +
    AuthLDAPURLSpecifies the LDAP server, the - base DN, the attribute to use in the search, as well as the - extra search filter to use.
    + + + + + + + + +
    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.

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

    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.

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

    -

    The Authorization Phase

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

    -

    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:

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

    -
      -
    • Grant access if there is a Require ldap-user directive, and the - username in the directive matches the username passed by the - client.
      • +
    +
    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.

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

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

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

    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 ldap-attribute - directive, and the attribute fetched from the LDAP directory - matches the given value.
    • +

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

    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 if there is a - Require ldap-search - directive, and the search filter successfully returns a single - matching object with any distinguished name.
    • +

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

    -
  • otherwise, deny or decline access
    • - +

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

    -

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

    + 
    AuthLDAPInitialBindPattern (.+) $1@example.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

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

    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.

    -

    mod_authnz_ldap uses the following directives during the - compare phase:

    +

    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, keep + AuthLDAPMaxSubGroupDepth set to zero.

    +
    - - - - - - + +
    top
    +

    AuthLDAPRemoteUserAttribute Directive

    +
    AuthLDAPURL The attribute specified in the - URL is used in compare operations for the Require - ldap-user operation.
    + + + + + + + +
    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.

    +

    This directive only has effect when this module is used for + authentication.

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

    +

    This directive only has effect when this module is used for + authentication.

    -
    		Determines the behavior of the - Require ldap-dn 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.

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

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

    - Determines the maximum depth of sub-groups that will be evaluated - during comparisons in the Require ldap-group directive. - +
    +
    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=..."
    - - AuthLDAPSubGroupAttribute +

    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.

    - Determines the attribute to use when obtaining sub-group members - of the current group during comparisons in the Require ldap-group - directive. - +
    +
    ldap
    - - AuthLDAPSubGroupClass +
    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.
    - 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. - - +
    host:port
    -
    top
    -
    -

    The Require Directives

    +
    +

    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.

    -

    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.

    +

    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.

    -

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

    +

    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.

    +
    -

    Require ldap-user

    +
    basedn
    -

    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"
    +
    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.
    +
    attribute
    -

    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.

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

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

    Require ldap-group

    +
    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. The keyword + none disables the use of a filter; this is required + by some primitive LDAP servers.
    + -

    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
    +

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

    -

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

    -
    Require ldap-group cn=Administrators, 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)).

    +

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

    -

    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
+
    
+    
    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.
    
+
    
 
-dn: cn=Managers, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Bob Ellis, o=Example
-uniqueMember: cn=Tom Jackson, o=Example
+    
    See above for examples of AuthLDAPURL URLs.
    
 
-dn: cn=Administrators, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Barbara Jenson, o=Example
-uniqueMember: cn=Fred User, o=Example
+
    +
    top
    +
    +

    Contents

    -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 +
      +
    • + Operation -dn: cn=Temporary Employees, o=Example -objectClass: groupOfUniqueNames -uniqueMember: cn=Jim Swenson, o=Example -uniqueMember: cn=Elliot Rhodes, o=Example
    + + +
  • + The Require Directives -

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

    + +
    • +
  • Examples
    • +
  • Using TLS
    • +
  • Using SSL
    • +
  • Exposing Login Information
    • +
  • Using Active Directory
    • +
  • + Using Microsoft FrontPage with + mod_authnz_ldap -

    Require ldap-dn

    + +
    • + +
    top
    +
    +

    Operation

    -

    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.

    +

    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.

    -

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

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

    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 Authentication + Phase

    -

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

    +

    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.

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

      Require ldap-attribute

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

      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.

      +
    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 attribute employeeType = active

    +

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

    - 
    Require ldap-attribute "employeeType=active"
    + + + + + + -

    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"
    + + + + +
    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 Authorization Phase

    -

    Require ldap-filter

    +

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

    + +

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

    + -

    The Require ldap-search directive allows the - administrator to grant access based on a generic LDAP search filter using an - expression. If there is exactly one match to the search filter, - regardless of the distinguished name, access is granted.

    -

    The following directive would grant access to URLs that match the given objects in the - LDAP server:

    +

    mod_authnz_ldap uses the following directives during the + compare phase:

    -
    <LocationMatch "^/dav/(?<SITENAME>[^/]+)/">
-Require ldap-search "(cn=%{ldap:%{unescape:%{env:MATCH_SITENAME}} Website)"
-</LocationMatch>
    + + + + + + -

    Note: care must be taken to ensure that any expressions are properly escaped to guard - against LDAP injection. The ldap function can be used as per the example - above.

    + + + + + + -
    top
    -
    -

    Examples

    +
    + - + - + + -
  • - 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
    +
    • + - + + -
  • - 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 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
    +
    • + - + + +
    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.
    -
  • - 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
    +
    • 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_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.

    -
  • - 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
    +

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

    -
    • +

    Require ldap-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
    +

    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"
    -

    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

    +

    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.

    -

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

    +

    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
    -

    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

    +

    Require ldap-group

    -

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

    +

    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
    -

    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 following directive would grant access to both Fred and + Barbara:

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

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

    -

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

    -
    top
    -
    -

    Exposing Login Information

    +

    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
 
-    
    when this module performs authentication, ldap attributes specified
-    in the authldapurl
-    directive are placed in environment variables with the prefix "AUTHENTICATE_".
    
+dn: cn=Managers, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Bob Ellis, o=Example
+uniqueMember: cn=Tom Jackson, o=Example
 
-    
    when this module performs authorization, ldap attributes specified
-    in the authldapurl
-    directive are placed in environment variables with the prefix "AUTHORIZE_".
    
+dn: cn=Administrators, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Barbara Jenson, o=Example
+uniqueMember: cn=Fred User, o=Example
 
-    
    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.
    
+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
 
-    
    This has the potential to dramatically simplify the coding and
-    configuration required in some web applications.
    
+dn: cn=Temporary Employees, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Jim Swenson, o=Example
+uniqueMember: cn=Elliot Rhodes, o=Example
    -
    top
    -
    -

    Using Active Directory

    +

    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
    -

    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.

    -

    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.

    +

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

    -

    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:

    +

    Require ldap-dn

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

    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 following directive would grant access to a specific + DN:

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

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

    -
    top
    -
    -

    Using Microsoft - FrontPage with mod_authnz_ldap

    +

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

    -

    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.

    -

    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
    +

    Require ldap-attribute

    +

    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.

    -

    How It Works

    +

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

    -

    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.

    + 
    Require ldap-attribute "employeeType=active"
    -

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

    +

    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.

    -

    Caveats

    +

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

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

    +

    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.

    -

    Note

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

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

    -
    -
    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-filter "&(cell=*)(department=marketing)"
    -

    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.

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

    -

    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
+    
    When using an expression within the filter, care
+    must be taken to ensure that LDAP filters are escaped correctly to guard against
+    LDAP injection. The ldap function can be used for this purpose.
    
 
-#Run /path/to/program to get my password
-AuthLDAPBindPassword exec:/path/to/program
+
    <LocationMatch "^/dav/(?<SITENAME>[^/]+)/">
+  Require ldap-filter "(memberOf=cn=%{ldap:%{unescape:%{env:MATCH_SITENAME}},ou=Websites,o=Example)"
+</LocationMatch>
    
 
-#Run /path/to/otherProgram and provide arguments
-AuthLDAPBindPassword "exec:/path/to/otherProgram argument1"
    -
    -
    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.

    +

    Require ldap-search

    -

    The file contains lines in the following format:

    +

    The Require ldap-search directive allows the + administrator to grant access based on a generic LDAP search filter using an + expression. If there is exactly one match to the search filter, + regardless of the distinguished name, access is granted.

    -

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

    +

    The following directive would grant access to URLs that match the given objects in the + LDAP server:

    -

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

    +
    <LocationMatch "^/dav/(?<SITENAME>[^/]+)/">
+Require ldap-search "(cn=%{ldap:%{unescape:%{env:MATCH_SITENAME}} Website)"
+</LocationMatch>
    -
    -
    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 ldap-attribute, ldap-user, and ldap-group (single-level only) - authorization checks use comparisons.

    +

    Note: care must be taken to ensure that any expressions are properly escaped to guard + against LDAP injection. The ldap function can be used as per the example + above.

    -

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

    -

    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.

    +
    top
    +
    +

    Examples

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

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

    + -

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

    +
  • + 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
    -

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

    +
    • -

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

    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.

    +
  • + 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
    -

    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
    +
  • +

    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
    - 
    AuthLDAPInitialBindPattern (.+) cn=$1,dc=example,dc=com
    +

    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

    -

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

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

    -

    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 0
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Extension
    Module:mod_authnz_ldap
    Compatibility:Available in version 2.3.0 and later, defaulted to 10 in 2.4.x and early 2.5
    -

    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.

    +

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

    -

    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, keep - AuthLDAPMaxSubGroupDepth set to zero.

    -
    +

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

    +

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

    + + +
    top
    +
    +

    Using TLS

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

    -

    This directive only has effect when this module is used for - authentication.

    +

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

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

    -

    This directive only has effect when this module is used for - authentication.

    +

    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

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

    +

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

    -

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

    +

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

    +
    top
    +
    +

    Exposing Login Information

    -

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

    +

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

    -

    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 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. The keyword - none disables the use of a filter; this is 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)).

    +
    diff --git a/docs/manual/mod/mod_authnz_ldap.html.fr b/docs/manual/mod/mod_authnz_ldap.html.fr index d92122188d..a3f86653b5 100644 --- a/docs/manual/mod/mod_authnz_ldap.html.fr +++ b/docs/manual/mod/mod_authnz_ldap.html.fr @@ -107,1480 +107,1480 @@ Directory
  • mod_authz_groupfile
    • top
    -
    -

    Sommaire

    - -
    +
    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 commence par exec:, la commande résultante sera + exécutée, et la première ligne renvoyée sur la sortie standard sera + utilisée comme mot de passe.

    +
    #Mot de passe utilisé tel quel
+AuthLDAPBindPassword secret
 
-        
-
    • - -
    top
    -
    -

    Mode opératoire

    +#Exécute /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écute /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

    +

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

    -

    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 :

    +

    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.

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

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

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

    -
  • 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.
    • +
    +
    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 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é.
    • +

    Si le nom d'utilisateur ne peut pas s'authentifier directement + et nécessite de légères modifications, voir la directive AuthLDAPInitialBindPattern.

    -
  • Avec la directive - Require ldap-search, l'autorisation d'accès - est accordée si le filtre de recherche renvoie avec succès - un seul objet correspondant aux critères avec tout nom distinctif - (DN).
    • +

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

    -
  • dans tous les autres cas, refus ou restriction de - l'accès.
    • - +

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

    Sous réserve du chargement de modules d'autorisation - supplémentaires, d'autres valeurs de la directive Require peuvent être - spécifiées.

    +

    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.

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

    Durant la phase de comparaison, mod_authnz_ldap - utilise les directives suivantes :

    - - - - +

    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.
    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.
    AuthLDAPSubGroupAttribute
    + + + + + + + + +
    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 0
    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 ; la valeur par défaut était 10 dans les versions 2.4.x et les +premières versions 2.5
    +

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

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

    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.

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

    +

    Cette directive n'a d'effet que si l'on utilise ce module pour + l'authentification.

    -
    top
    -
    -

    Les directives requises

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

    +

    Cette directive n'a d'effet que si l'on utilise ce module pour + l'authentification.

    -

    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.

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

    -

    A partir de la version 2.4.8, les directives require LDAP - supportent les expressions.

    +

    Les vérifications d'autorisation ldap-filter et + ldap-dn utilisent des recherches.

    -

    Require ldap-user

    +

    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.

    -

    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"
    +

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

    -

    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.

    +

    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.

    -

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

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

    -

    Require ldap-group

    +
    +
    ldap
    -

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

    La directive suivante autoriserait alors l'accès à Fred et - Barbara :

    -
    Require ldap-group cn=Administrators, o=Example
    +
    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.

    -

    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
+          
    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.
    
 
-dn: cn=Managers, o=Example
-objectClass: groupOfUniqueNames
-uniqueMember: cn=Bob Ellis, o=Example
-uniqueMember: cn=Tom Jackson, 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.
    
+
    -dn: cn=Administrators, o=Example -objectClass: groupOfUniqueNames -uniqueMember: cn=Barbara Jenson, o=Example -uniqueMember: cn=Fred User, 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.
    -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 +
    attribut
    -dn: cn=Temporary Employees, o=Example -objectClass: groupOfUniqueNames -uniqueMember: cn=Jim Swenson, o=Example -uniqueMember: cn=Elliot Rhodes, 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.
    -

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

    Le comportement de cette directive est modifié par les directives - AuthLDAPGroupAttribute, - AuthLDAPGroupAttributeIsDN, - AuthLDAPMaxSubGroupDepth, - AuthLDAPSubGroupAttribute, et - AuthLDAPSubGroupClass.

    +
    filtre
    +
    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. Le mot-clé none permet de désactiver + l'utilisation des filtres, ce qui peut s'avérer nécessaire avec + certains serveurs LDAP primitifs.
    + -

    Require ldap-dn

    +

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

    -

    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.

    +

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

    -

    La directive suivante accorderait l'accès à un DN spécifique - :

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

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

    Le comportement ce cette directive est modifié par la directive - AuthLDAPCompareDNOnServer.

    +

    Voir plus haut pour des exemples d'URLs définies par la directive + AuthLDAPURL.

    + +
    top
    +
    +

    Sommaire

    -

    Require ldap-attribute

    + +
    top
    +
    +

    Mode opératoire

    - 
    Require ldap-attribute city="San Jose" status=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.

    +

    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 :

    -

    Require ldap-filter

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

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

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

      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" :

      +
    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. +
    - 
    Require ldap-filter &(cell=*)(department=marketing)
    +

    Les directives utilisées durant la phase de recherche/connexion + sont les suivantes :

    + + + + -

    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.

    + + -

    Lorsqu'on utilise une expression - rationnelle au sein d'un filtre, il faut bien s'assurer que les - filtres LDAP sont correctement échappés afin de se prémunir contre - toute injection LDAP. A cet effet, il est possible d'utiliser la - fonction ldap.

    + + -
    <LocationMatch ^/dav/(?<SITENAME>[^/]+)/>
-  Require ldap-filter (memberOf=cn=%{ldap:%{unescape:%{env:MATCH_SITENAME}},ou=Websites,o=Example)
-</LocationMatch>
    + + + + + + +
    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.
    -

    Require ldap-search

    +

    La phase d'autorisation

    -

    La directive Require ldap-search permet à - l'administrateur d'autoriser l'accès en fonction d'un filtre de - recherche LDAP générique contenant une expression rationnelle. Si le filtre de - recherche renvoie une et une seule correspondance, l'accès est - accordé sans tenir compte du DN.

    +

    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 :

    -

    La directive suivante accorderait l'accès aux URLs correspondant - aux objets spécifiés dans le serveur LDAP :

    + -
    top
    -
    -

    Exemples

    +

    Sous réserve du chargement de modules d'autorisation + supplémentaires, d'autres valeurs de la directive Require peuvent être + spécifiées.

    - -
  • - 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
    +

    Durant la phase de comparaison, mod_authnz_ldap + utilise les directives suivantes :

    -
    • + + + + + + + -
  • - 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
    +
    • + - + + -
  • - 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
    +
    • + - + + -
  • - 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
    +
    • + - + + -
  • -

    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
    +
    • + + + -

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

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

    Un recherche avec le filtre ci-dessus retournera un - résultat positif que jmanager dispose d'un - bippeur ou non

    - -
    top
    -

    Utilisation de TLS

    +

    Les directives requises

    -

    Pour l'utilisation de TLS, voir les directives du module - mod_ldap LDAPTrustedClientCert, LDAPTrustedGlobalCert et LDAPTrustedMode.

    +

    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.

    -

    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

    +

    A partir de la version 2.4.8, les directives require LDAP + supportent les expressions.

    -

    Pour l'utilisation de SSL, voir les directives du module - mod_ldap LDAPTrustedClientCert, LDAPTrustedGlobalCert et LDAPTrustedMode.

    +

    Require ldap-user

    -

    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

    +

    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"
    -

    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_".

    +

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

    +

    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
    -

    Ceci a pour effet de simplifier considérablement le code et la - configuration nécessaire de certaines applications web.

    -
    top
    -
    -

    Utilisation d'Active -Directory

    -

    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.

    +

    Require ldap-group

    -

    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.

    +

    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
    -

    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.

    +

    La directive suivante autoriserait alors l'accès à Fred et + Barbara :

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

    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 :

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

    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
+
+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
+
+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
+
+dn: cn=Temporary Employees, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Jim Swenson, o=Example
+uniqueMember: cn=Elliot Rhodes, o=Example
    + +

    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
    -

    Les utilisateurs devront s'authentifier en entrant leur UPN, de - la formeuntel@nz.example.com.

    +

    Le comportement de cette directive est modifié par les directives + AuthLDAPGroupAttribute, + AuthLDAPGroupAttributeIsDN, + AuthLDAPMaxSubGroupDepth, + AuthLDAPSubGroupAttribute, et + AuthLDAPSubGroupClass.

    -
    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-dn

    -

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

    +

    La directive suivante accorderait l'accès à un DN spécifique + :

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

    Comment ça marche

    -

    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.

    +

    Le comportement ce cette directive est modifié par la directive + AuthLDAPCompareDNOnServer.

    -

    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.

    +

    Require ldap-attribute

    -

    Avertissements

    +

    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.

    - +

    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.

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

    +

    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" :

    -

    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. -
    + 
    Require ldap-attribute city="San Jose" status=active
    -
    -
    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.

    -

    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.

    -

    Si la valeur commence par exec:, la commande résultante sera - exécutée, et la première ligne renvoyée sur la sortie standard sera - utilisée comme mot de passe.

    -
    #Mot de passe utilisé tel quel
-AuthLDAPBindPassword secret
+
    Require ldap-filter
    
 
-#Exécute /path/to/program pour obtenir le mot de passe
-AuthLDAPBindPassword exec:/path/to/program
+    
    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é.
    
 
-#Exécute /path/to/otherProgram avec un argument pour obtenir le mot de passe
-AuthLDAPBindPassword "exec:/path/to/otherProgram argument1"
    +

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

    +

    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.

    -

    Le fichier contient des lignes au format suivant :

    +

    Lorsqu'on utilise une expression + rationnelle au sein d'un filtre, il faut bien s'assurer que les + filtres LDAP sont correctement échappés afin de se prémunir contre + toute injection LDAP. A cet effet, il est possible d'utiliser la + fonction ldap.

    -

    - extension de langage jeu de caractères - [Nom du langage] ... -

    +
    <LocationMatch ^/dav/(?<SITENAME>[^/]+)/>
+  Require ldap-filter (memberOf=cn=%{ldap:%{unescape:%{env:MATCH_SITENAME}},ou=Websites,o=Example)
+</LocationMatch>
    -

    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-search

    -

    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-search permet à + l'administrateur d'autoriser l'accès en fonction d'un filtre de + recherche LDAP générique contenant une expression rationnelle. Si le filtre de + recherche renvoie une et une seule correspondance, l'accès est + accordé sans tenir compte du DN.

    -

    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'accès aux URLs correspondant + aux objets spécifiés dans le serveur LDAP :

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

    +
    <LocationMatch ^/dav/(?<SITENAME>[^/]+)/>
+Require ldap-search (cn=%{ldap:%{unescape:%{env:MATCH_SITENAME}} Website)
+</LocationMatch>
    -
    -
    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.

    +

    Note : il faut bien s'assurer que les + expressions sont correctement échappés afin de se prémunir contre + toute injection LDAP. A cet effet, il est possible d'utiliser la + fonction ldap comme dans l'exemple ci-dessus.

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

    +
    • - 
    AuthLDAPInitialBindPattern (.+) $1@example.com
    +
  • + 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
    + +
    • + +
  • + 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
    - 
    AuthLDAPInitialBindPattern (.+) cn=$1,dc=example,dc=com
    +
    • +
  • + 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
    -

    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

    - - - - - - - - - -
    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 0
    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 ; la valeur par défaut était 10 dans les versions 2.4.x et les -premières versions 2.5
    -

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

    +
  • + 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
    -

    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.

    -
    +
    • +
  • +

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

    -

    Cette directive n'a d'effet que si l'on utilise ce module pour - l'authentification.

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

    -

    Cette directive n'a d'effet que si l'on utilise ce module pour - l'authentification.

    +

    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 à :

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

    +

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

    -

    Les vérifications d'autorisation ldap-filter et - ldap-dn utilisent des recherches.

    +

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

    +

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

    -

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

    +

    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.

    -

    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.

    +

    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

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

    +

    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. Le mot-clé none permet de désactiver - l'utilisation des filtres, ce qui peut s'avérer nécessaire 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 3f0c16c5ce..512dc5663d 100644 --- a/docs/manual/mod/mod_authz_core.html.en +++ b/docs/manual/mod/mod_authz_core.html.en @@ -61,210 +61,6 @@
  • Creating Authorization Provider Aliases
    • 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
    -
    -

    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

    AuthMerging Directive

  • Authentication, Authorization, and Access Control
    • + +
    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
    +
    +

    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>
    + + +
    diff --git a/docs/manual/mod/mod_authz_core.html.fr b/docs/manual/mod/mod_authz_core.html.fr index 3395e39234..0374e8c3cc 100644 --- a/docs/manual/mod/mod_authz_core.html.fr +++ b/docs/manual/mod/mod_authz_core.html.fr @@ -65,208 +65,6 @@ d'Apache HTTPD
    Description:Controls the manner in which each configuration section's @@ -631,6 +427,210 @@ must succeed for the enclosing directive to not fail.
    d'autorisation
    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 construire 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, soit 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=Administrateurs,o=Airius
-                <RequireAny>
-                Require group ventes
-                Require ldap-attribute dept="ventes"
-                </RequireAny>
-            </RequireAll>
-        </RequireAny>
-        <RequireNone>
-            Require group temps
-            Require ldap-group cn=Employés temporaires,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 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
    -
    -

    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 diverses 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
-
-    #Opération logique implicite : OU inclusif
-    Require ldap-group-alias1
-    Require ldap-group-alias2
-</Directory>
    - - - -
    -
    top

    Directive AuthMerging

  • Authentification, autorisation et contrôle d'accès
    • + +
    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 construire 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, soit 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=Administrateurs,o=Airius
+                <RequireAny>
+                Require group ventes
+                Require ldap-attribute dept="ventes"
+                </RequireAny>
+            </RequireAll>
+        </RequireAny>
+        <RequireNone>
+            Require group temps
+            Require ldap-group cn=Employés temporaires,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 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
    +
    +

    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 diverses 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
+
+    #Opération logique implicite : OU inclusif
+    Require ldap-group-alias1
+    Require ldap-group-alias2
+</Directory>
    + + +
    diff --git a/docs/manual/mod/mod_authz_dbd.html.en b/docs/manual/mod/mod_authz_dbd.html.en index 1bf8e09f74..3b1400128b 100644 --- a/docs/manual/mod/mod_authz_dbd.html.en +++ b/docs/manual/mod/mod_authz_dbd.html.en @@ -71,6 +71,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

    @@ -210,90 +294,6 @@ DBDExptime 300

    Please read mod_dbd documentation for more information about security on this scope.

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

    - -

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_authz_dbd.html.fr b/docs/manual/mod/mod_authz_dbd.html.fr index 6d5b95db5d..2f306d22af 100644 --- a/docs/manual/mod/mod_authz_dbd.html.fr +++ b/docs/manual/mod/mod_authz_dbd.html.fr @@ -73,6 +73,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 une en-tête +de requête Referer est présente
    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

    @@ -223,99 +316,6 @@ DBDExptime 300 mod_dbd pour plus d'informations à propos de la sécurité dans ce domaine.

    -
    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 une en-tête -de requête Referer est présente
    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.

    - -

    Langues Disponibles:  en  | diff --git a/docs/manual/mod/mod_authz_dbm.html.en b/docs/manual/mod/mod_authz_dbm.html.en index a24da7b959..cb1036d0f5 100644 --- a/docs/manual/mod/mod_authz_dbm.html.en +++ b/docs/manual/mod/mod_authz_dbm.html.en @@ -53,55 +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_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 3f22f98444..001b01cdb6 100644 --- a/docs/manual/mod/mod_authz_dbm.html.fr +++ b/docs/manual/mod/mod_authz_dbm.html.fr @@ -56,56 +56,6 @@
  • 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

    Description:Sets the name of the database file containing the list @@ -179,6 +130,55 @@ store list of user groups
    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 6cf0d2201b..43511705c6 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 qui liste @@ -187,6 +137,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 167ed9ac1d..7adb8a3335 100644 --- a/docs/manual/mod/mod_authz_groupfile.html.en +++ b/docs/manual/mod/mod_authz_groupfile.html.en @@ -52,40 +52,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 b9318a3435..f05ebbb4ba 100644 --- a/docs/manual/mod/mod_authz_groupfile.html.fr +++ b/docs/manual/mod/mod_authz_groupfile.html.fr @@ -53,40 +53,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 @@ -118,6 +84,40 @@ of user groups for authorization
    | sed -e 's/.*/mmapfile &/' > /www/conf/mmap.conf

    - -
    top
    -

    Directive CacheFile

    -
    Description:Définit le nom d'un fichier texte contenant la liste des @@ -124,6 +90,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 a58b83c2f9..39d9989a66 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 eeb65c8fc5..65d7dfbd8e 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 ae57b39ca7..cffac6be58 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 eb98fbdec7..03008e29d0 100644 --- a/docs/manual/mod/mod_autoindex.html.fr +++ b/docs/manual/mod/mod_autoindex.html.fr @@ -101,115 +101,6 @@ shell Win32 dir
  • Utilisation de mod_file_cache
    • top
    +

    Directive CacheFile

    +
    Description:Texte optionnel à afficher à la place d'un icône pour un @@ -1097,6 +988,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 562e97755d..b5d266829c 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 98d9e1f1e5..052bec6450 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 73fd30bf84..cdc4875038 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

    ¼³¸í:ÆÄÀϸíÀ¸·Î ¼±ÅÃÇÑ ¾ÆÀÌÄÜ´ë½Å »ç¿ëÇÒ ÆÄÀÏ ¼³¸í±Û

    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 4a7d679174..507d1d9a3c 100644 --- a/docs/manual/mod/mod_buffer.html.en +++ b/docs/manual/mod/mod_buffer.html.en @@ -78,7 +78,6 @@
    -
    top

    BufferSize Directive

    Açıklama:Dosyaya göre seçilen simgenin yerinde gösterilecek metni belirler. @@ -1036,6 +944,98 @@ belirler.
    @@ -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 2427fa24ea..61e3e38450 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 fa37464a1e..a1d0f3df36 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 authorization 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 authorization 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

    @@ -1040,6 +855,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 authorization 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 authorization 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 27d7f6d447..43a87e57c8 100644 --- a/docs/manual/mod/mod_cache.html.fr +++ b/docs/manual/mod/mod_cache.html.fr @@ -172,218 +172,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 @@ -1156,6 +944,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 5a6b55e600..bd64661148 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 ディレクティブ

    @@ -645,6 +601,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 f1a0071987..4126129c3b 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 8ae17a0644..6d75fb9530 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 11cd30a607..24d422594e 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 e4ff0c5fb4..37a1816b9d 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 1c8db897b6..9ff53df588 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 19bdec9b45..046e53a0c1 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 361c1a363c..e60328c97c 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 d35da811ca..87b06172c6 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 12847614d8..43b62f8804 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 2321089e28..f96af0eb04 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 6b9d1879c1..2fce05aa43 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 00b4b5150c..850a31baad 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 définit + 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 soit le + répertoire dans lequel se trouve le journal doit être accessible en + écriture pour cet utilisateur, soit le fichier doit être 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 PAS 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 ce qui concerne la vitesse et l'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 limite 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 modifie 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 + définit 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 définit - 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 soit le - répertoire dans lequel se trouve le journal doit être accessible en - écriture pour cet utilisateur, soit le fichier doit être 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 PAS 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 ce qui concerne la vitesse et l'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 limite 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 modifie 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 - définit 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 4360f63064..b7e179758f 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 4583fdf3b7..c068484eaa 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 1c0c3d9351..3a27551b07 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 74a8728c75..d50993facf 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 c2f9e5996c..e6e6fc35b1 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 19764fc02d..bf77d552dc 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 51141a4150..c1a592140f 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 8527c0e7c6..54ccb6aa0d 100644 --- a/docs/manual/mod/mod_charset_lite.html.fr +++ b/docs/manual/mod/mod_charset_lite.html.fr @@ -62,47 +62,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 @@ -215,6 +174,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 d5baae270f..90214c3f58 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 8a89b2c511..3a60361c4d 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 5fa6e53ac2..25e2bd4671 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 active 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 + autorise 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 requête, et le serveur peut l'ignorer ou informer le client + qu'il va utiliser une valeur arbitraire.

    + +

    La directive DavMinTimeout + spécifie, 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 active 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 - autorise 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 requête, et le serveur peut l'ignorer ou informer le client - qu'il va utiliser une valeur arbitraire.

    - -

    La directive DavMinTimeout - spécifie, 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 d594b1a19d..636e67c22d 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 4a77c6245c..160f41561d 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 @@ -176,85 +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
    »ç¿ëÀå¼Ò: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 e2219841fb..9b7e3f7c9a 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 3c462b94ca..fe68e94f43 100644 --- a/docs/manual/mod/mod_dav_fs.html.fr +++ b/docs/manual/mod/mod_dav_fs.html.fr @@ -58,7 +58,6 @@

    -
    top

    Directive DavLockDB

    @@ -94,6 +93,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 6f36f29526..2ff1247c90 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 b2d540fb43..12457389b7 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 31e3c4063d..e6fa6defb8 100644 --- a/docs/manual/mod/mod_dav_lock.html.en +++ b/docs/manual/mod/mod_dav_lock.html.en @@ -63,7 +63,6 @@

    -
    top

    DavGenericLockDB Directive

    @@ -93,6 +92,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 55b97ce63b..4546d0dd3e 100644 --- a/docs/manual/mod/mod_dav_lock.html.fr +++ b/docs/manual/mod/mod_dav_lock.html.fr @@ -68,7 +68,6 @@

    -
    top

    Directive DavGenericLockDB

    @@ -102,6 +101,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 1e87181265..4fc1e706a5 100644 --- a/docs/manual/mod/mod_dav_lock.html.ja.utf8 +++ b/docs/manual/mod/mod_dav_lock.html.ja.utf8 @@ -66,7 +66,6 @@

    -
    top

    DavGenericLockDB ディレクティブ

    @@ -97,6 +96,7 @@ +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_dbd.html.en b/docs/manual/mod/mod_dbd.html.en index 4cb913f729..05eefa48a5 100644 --- a/docs/manual/mod/mod_dbd.html.en +++ b/docs/manual/mod/mod_dbd.html.en @@ -66,120 +66,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

    @@ -337,6 +223,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 4163059dda..a100ce2b7a 100644 --- a/docs/manual/mod/mod_dbd.html.fr +++ b/docs/manual/mod/mod_dbd.html.fr @@ -68,133 +68,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 DEVRA être 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 DEVRA PAS être 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 DEVRA PAS être 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 pour - le compte 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 sûres 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 de - Perl (NdT : taint checking). Chaque entrée est comparée - à une expression rationnelle, et - seules les entrées qui correspondent sont utilisées, en accord avec - le raccourci 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 - en échec. 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 ainsi désormais 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
    @@ -364,6 +237,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 DEVRA être 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 DEVRA PAS être 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 DEVRA PAS être 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 pour + le compte 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 sûres 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 de + Perl (NdT : taint checking). Chaque entrée est comparée + à une expression rationnelle, et + seules les entrées qui correspondent sont utilisées, en accord avec + le raccourci 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 + en échec. 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 ainsi désormais 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 14579885c5..446f44097e 100644 --- a/docs/manual/mod/mod_deflate.html.en +++ b/docs/manual/mod/mod_deflate.html.en @@ -65,172 +65,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

    DeflateAlterETag Directive

    Description:Durée de vie des connexions inactives
    @@ -428,6 +262,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 b317ea0eb1..14c4b9a7ca 100644 --- a/docs/manual/mod/mod_deflate.html.fr +++ b/docs/manual/mod/mod_deflate.html.fr @@ -64,147 +64,6 @@ client
  • Les filtres
    • top
    -
    -

    Exemples de configurations

    -

    Compression et TLS

    -

    Certaines applications web sont vulnérables à une attaque pour - vol d'informations lorsqu'une connexion TLS transporte des - données compressées par deflate. Pour plus de détails, - documentez-vous sur la famille d'attaques "BREACH".

    -
    -

    Voici un exemple simple de configuration qui permet de comprimer - les types de contenu à base de texte.

    - -

    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 à une attaque pour - vol d'informations lorsqu'une connexion TLS transporte des - données compressées par deflate. Pour plus de détails, - documentez-vous sur la famille d'attaques "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 DeflateAlterETag

    Description:How the outgoing ETag header should be modified during compression
    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 à une attaque pour + vol d'informations lorsqu'une connexion TLS transporte des + données compressées par deflate. Pour plus de détails, + documentez-vous sur la famille d'attaques "BREACH".

    +
    +

    Voici un exemple simple de configuration qui permet de comprimer + les types de contenu à base de texte.

    + +

    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 à une attaque pour + vol d'informations lorsqu'une connexion TLS transporte des + données compressées par deflate. Pour plus de détails, + documentez-vous sur la famille d'attaques "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 f7cfab9923..d7ef309010 100644 --- a/docs/manual/mod/mod_deflate.html.ja.utf8 +++ b/docs/manual/mod/mod_deflate.html.ja.utf8 @@ -65,6 +65,178 @@
  • Filters
    • top
    +

    DeflateAlterETag ディレクティブ

    +
    Description:Comment l'en-tête sortant ETag doit être modifié au cours @@ -425,6 +284,147 @@ compression
    + + + + + + +
    説明:How the outgoing ETag header should be modified during compression
    構文:DeflateAlterETag AddSuffix|NoChange|Remove
    デフォルト:DeflateAlterETag AddSuffix
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Extension
    モジュール:mod_deflate

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

    +
    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 にするのが良いでしょう。)

    + +
    +
    top

    サンプル設定

    下にせっかちな人向けの簡単な設定例を示します。

    @@ -259,178 +431,6 @@ Header set Vary *

    -
    top
    -

    DeflateAlterETag ディレクティブ

    - - - - - - - -
    説明:How the outgoing ETag header should be modified during compression
    構文:DeflateAlterETag AddSuffix|NoChange|Remove
    デフォルト:DeflateAlterETag AddSuffix
    コンテキスト:サーバ設定ファイル, バーチャルホスト
    ステータス:Extension
    モジュール:mod_deflate

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

    -
    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 4aa3a5fc29..f17eacda4d 100644 --- a/docs/manual/mod/mod_deflate.html.ko.euc-kr +++ b/docs/manual/mod/mod_deflate.html.ko.euc-kr @@ -63,6 +63,172 @@

  • ÇÊÅÍ
    • top
    +

    DeflateAlterETag Áö½Ã¾î

    + + + + + + + +
    ¼³¸í:How the outgoing ETag header should be modified during compression
    ¹®¹ý:DeflateAlterETag AddSuffix|NoChange|Remove
    ±âº»°ª:DeflateAlterETag AddSuffix
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Extension
    ¸ðµâ:mod_deflate

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

    +
    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

    °ßº» ¼³Á¤

    ±ÞÇÑ »ç¶÷À» À§ÇÑ °ßº» ¼³Á¤ÀÌ´Ù.

    @@ -251,172 +417,6 @@ Header set Vary *

    -
    top
    -

    DeflateAlterETag Áö½Ã¾î

    - - - - - - - -
    ¼³¸í:How the outgoing ETag header should be modified during compression
    ¹®¹ý:DeflateAlterETag AddSuffix|NoChange|Remove
    ±âº»°ª:DeflateAlterETag AddSuffix
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®
    »óÅÂ:Extension
    ¸ðµâ:mod_deflate

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

    -
    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 358cfcffb2..d58e305524 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 2011124df8..5d974fbf03 100644 --- a/docs/manual/mod/mod_dialup.html.fr +++ b/docs/manual/mod/mod_dialup.html.fr @@ -58,7 +58,6 @@ client.

  • ModemStandard
    • -
    top

    Directive ModemStandard

    @@ -78,6 +77,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 138d1f4d54..bfe3bbc9fa 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

    @@ -306,6 +305,7 @@ later +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_dir.html.fr b/docs/manual/mod/mod_dir.html.fr index 8b5d3f14ba..92dd8b3af4 100644 --- a/docs/manual/mod/mod_dir.html.fr +++ b/docs/manual/mod/mod_dir.html.fr @@ -69,7 +69,6 @@ de r

  • FallbackResource
    • -
    top

    Directive DirectoryCheckHandler

    @@ -342,6 +341,7 @@ 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 41dbde181a..59c1040904 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 9eadb0c13a..c9cc4324b6 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 6471f0cc60..bcf87a2b1b 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

    @@ -273,6 +272,7 @@ act as if "DirectoryCheckHandler ON" was specified.

    +

    Mevcut Diller:  en  | diff --git a/docs/manual/mod/mod_dumpio.html.en b/docs/manual/mod/mod_dumpio.html.en index 4d8db68bcf..53ea998323 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

    @@ -98,6 +84,20 @@

    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 c3c8e383bc..3554670bc0 100644 --- a/docs/manual/mod/mod_dumpio.html.fr +++ b/docs/manual/mod/mod_dumpio.html.fr @@ -56,20 +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 ce36a42b64..bb69938946 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 @@ -102,6 +88,20 @@ erreurs
    @@ -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 463f30444a..ef0ff03096 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 574ce8d1f9..b15fcdf908 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 a60914f51c..98322b234f 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 6284319b9f..6e7f91e14c 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 2aea58f0b9..63c8fae450 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 0a9afc6d1b..14a1a1dde6 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 20d1d67065..b312f17b7e 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 ed80e82462..e712d5c446 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 6c0996a253..2c0745db19 100644 --- a/docs/manual/mod/mod_env.html.tr.utf8 +++ b/docs/manual/mod/mod_env.html.tr.utf8 @@ -57,7 +57,6 @@ etmek için kullanılır.

  • Ortam Değişkenleri
  • SetEnvIf
    • -
    top

    PassEnv Yönergesi

    @@ -131,6 +130,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 cf6e951007..596fed8f81 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 ef9c71e969..edd73b6755 100644 --- a/docs/manual/mod/mod_example_hooks.html.fr +++ b/docs/manual/mod/mod_example_hooks.html.fr @@ -62,6 +62,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

    @@ -140,27 +161,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 164c690e3f..9479ba2d90 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 a7546b0688..5144634e99 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 82ee346565..1e78b09e3d 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 fef2c58fff..07265ff0a2 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 f8d4c3a9d2..da9eb2c1c3 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 7578e00559..7e69fe9354 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 3dbd85b8ff..1099c59e56 100644 --- a/docs/manual/mod/mod_ext_filter.html.fr +++ b/docs/manual/mod/mod_ext_filter.html.fr @@ -75,140 +75,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
    @@ -347,6 +213,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 cb2ab5306c..62f6cc343d 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 670e331f14..ea1af9b358 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 83a03231ed..9932442495 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 b5f7e6f7df..290ea06f27 100644 --- a/docs/manual/mod/mod_file_cache.html.fr +++ b/docs/manual/mod/mod_file_cache.html.fr @@ -77,6 +77,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 associe + des gestionnaires à un ou plusieurs fichiers (séparés par des + espaces), et place 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 est inacceptable. + 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 provoque le chargement d'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 est inacceptable. + 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

    @@ -167,72 +233,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 associe - des gestionnaires à un ou plusieurs fichiers (séparés par des - espaces), et place 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 est inacceptable. - 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 provoque le chargement d'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 est inacceptable. - 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 07c2c4618b..f73a037981 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 132813ed6b..501f468ca0 100644 --- a/docs/manual/mod/mod_filter.html.en +++ b/docs/manual/mod/mod_filter.html.en @@ -64,200 +64,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:

    - - - -

    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

    @@ -488,6 +294,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_firehose.html.en b/docs/manual/mod/mod_firehose.html.en index 570e943898..222f0f0ce7 100644 --- a/docs/manual/mod/mod_firehose.html.en +++ b/docs/manual/mod/mod_firehose.html.en @@ -70,96 +70,6 @@
  • firehose
    • top
    -
    -

    Enabling a Firehose

    - - -

    To enable the module, it should be compiled and loaded - in to your running Apache configuration, and the directives below - used to record the data you are interested in.

    - -

    It is possible to record both incoming and outgoing data to - the same filename if desired, as the direction of flow is recorded - within each fragment.

    - -

    It is possible to write to both normal files and fifos (pipes). - In the case of fifos, mod_firehose ensures that the packet size is - no larger than PIPE_BUF to ensure writes are atomic.

    - -

    If a pipe is being used, something must be reading from the pipe - before httpd is started for the pipe to be successfully opened for - write. If the request to open the pipe fails, mod_firehose will - silently stand down and not record anything, and the server will - keep running as normal.

    - -

    By default, all attempts to write will block the server. If the - webserver has been built against APR v2.0 or later, and an optional - "nonblock" parameter is specified all file writes will be non - blocking, and buffer overflows will cause debugging data to be lost. - In this case it is possible to prioritise the running of the server - over the recording of firehose data.

    - -
    top
    -
    -

    Stream Format

    - - -

    The server typically serves multiple connections simultaneously, - and as a result requests and responses need to be multiplexed before - being written to the firehose.

    - -

    The fragment format is designed as clear text, so that a firehose - can be opened with and inspected by a normal text editor. - Alternatively, the firehose tool can be used to - demultiplex the firehose back into individual requests or - connections.

    - -

    The size of the multiplexed fragments is governed by PIPE_BUF, - the maximum size of write the system is prepared to perform - atomically. By keeping the multiplexed fragments below PIPE_BUF in - size, the module guarantees that data from different fragments does - not interleave. The size of PIPE_BUF varies on different operating - systems.

    - -

    The BNF for the fragment format is as follows:

    - - 
     stream = 0*(fragment)
-
- fragment = header CRLF body CRLF
-
- header = length SPC timestamp SPC ( request | response ) SPC uuid SPC count
-
- length = <up to 16 byte hex fragment length>
- timestamp = <up to 16 byte hex timestamp microseconds since 1970>
- request = "<"
- response = ">"
- uuid = <formatted uuid of the connection>
- count = <hex fragment number in the connection>
-
- body = <the binary content of the fragment>
-
- SPC = <a single space>
- CRLF = <a carriage return, followed by a line feed>
    - -

    All fragments for a connection or a request will share the same - UUID, depending on whether connections or requests are being recorded. - If connections are being recorded, multiple requests may appear within - a connection. A fragment with a zero length indicates the end of the - connection.

    - -

    Fragments may go missing or be dropped if the process reading the - fragments is too slow. If this happens, gaps will exist in the - connection counter numbering. A warning will be logged in the error - log to indicate the UUID and counter of the dropped fragment, so it - can be confirmed the fragment was dropped.

    - -

    It is possible that the terminating empty fragment may not appear, - caused by the httpd process crashing, or being terminated ungracefully. - The terminating fragment may be dropped if the process reading the - fragments is not fast enough.

    - -
    -
    top

    FirehoseConnectionInput Directive

    Description:assigns an output filter to a particular media-type
    @@ -272,6 +182,96 @@ later.

    Example

    FirehoseRequestOutput request-output.firehose
    + +
    top
    +
    +

    Enabling a Firehose

    + + +

    To enable the module, it should be compiled and loaded + in to your running Apache configuration, and the directives below + used to record the data you are interested in.

    + +

    It is possible to record both incoming and outgoing data to + the same filename if desired, as the direction of flow is recorded + within each fragment.

    + +

    It is possible to write to both normal files and fifos (pipes). + In the case of fifos, mod_firehose ensures that the packet size is + no larger than PIPE_BUF to ensure writes are atomic.

    + +

    If a pipe is being used, something must be reading from the pipe + before httpd is started for the pipe to be successfully opened for + write. If the request to open the pipe fails, mod_firehose will + silently stand down and not record anything, and the server will + keep running as normal.

    + +

    By default, all attempts to write will block the server. If the + webserver has been built against APR v2.0 or later, and an optional + "nonblock" parameter is specified all file writes will be non + blocking, and buffer overflows will cause debugging data to be lost. + In this case it is possible to prioritise the running of the server + over the recording of firehose data.

    + +
    top
    +
    +

    Stream Format

    + + +

    The server typically serves multiple connections simultaneously, + and as a result requests and responses need to be multiplexed before + being written to the firehose.

    + +

    The fragment format is designed as clear text, so that a firehose + can be opened with and inspected by a normal text editor. + Alternatively, the firehose tool can be used to + demultiplex the firehose back into individual requests or + connections.

    + +

    The size of the multiplexed fragments is governed by PIPE_BUF, + the maximum size of write the system is prepared to perform + atomically. By keeping the multiplexed fragments below PIPE_BUF in + size, the module guarantees that data from different fragments does + not interleave. The size of PIPE_BUF varies on different operating + systems.

    + +

    The BNF for the fragment format is as follows:

    + + 
     stream = 0*(fragment)
+
+ fragment = header CRLF body CRLF
+
+ header = length SPC timestamp SPC ( request | response ) SPC uuid SPC count
+
+ length = <up to 16 byte hex fragment length>
+ timestamp = <up to 16 byte hex timestamp microseconds since 1970>
+ request = "<"
+ response = ">"
+ uuid = <formatted uuid of the connection>
+ count = <hex fragment number in the connection>
+
+ body = <the binary content of the fragment>
+
+ SPC = <a single space>
+ CRLF = <a carriage return, followed by a line feed>
    + +

    All fragments for a connection or a request will share the same + UUID, depending on whether connections or requests are being recorded. + If connections are being recorded, multiple requests may appear within + a connection. A fragment with a zero length indicates the end of the + connection.

    + +

    Fragments may go missing or be dropped if the process reading the + fragments is too slow. If this happens, gaps will exist in the + connection counter numbering. A warning will be logged in the error + log to indicate the UUID and counter of the dropped fragment, so it + can be confirmed the fragment was dropped.

    + +

    It is possible that the terminating empty fragment may not appear, + caused by the httpd process crashing, or being terminated ungracefully. + The terminating fragment may be dropped if the process reading the + fragments is not fast enough.

    +
    diff --git a/docs/manual/mod/mod_headers.html.en b/docs/manual/mod/mod_headers.html.en index 54407dd4bf..7d3b7a456f 100644 --- a/docs/manual/mod/mod_headers.html.en +++ b/docs/manual/mod/mod_headers.html.en @@ -52,158 +52,6 @@ headers
  • 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:Capture traffic coming into the server on each connection
    @@ -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 d618e9ce22..8b787e7ae0 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 86aef298f0..c0240ca021 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 2d971a65e0..e0f254d950 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 9694c18fac..493920f96b 100644 --- a/docs/manual/mod/mod_heartbeat.html.en +++ b/docs/manual/mod/mod_heartbeat.html.en @@ -60,6 +60,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

    @@ -79,25 +98,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_heartmonitor.html.en b/docs/manual/mod/mod_heartmonitor.html.en index 4d6ffb07b0..9207378d9e 100644 --- a/docs/manual/mod/mod_heartmonitor.html.en +++ b/docs/manual/mod/mod_heartmonitor.html.en @@ -60,7 +60,6 @@ use mod_slotmem_shm HeartbeatStorage
    -
    top

    HeartbeatListen Directive

    @@ -115,6 +114,7 @@ heartbeat requests to this servermod_slotmem_shm is not loaded.

    +

    Available Languages:  en 

    diff --git a/docs/manual/mod/mod_ident.html.en b/docs/manual/mod/mod_ident.html.en index ad48c18505..38d65dccf7 100644 --- a/docs/manual/mod/mod_ident.html.en +++ b/docs/manual/mod/mod_ident.html.en @@ -47,7 +47,6 @@
    -
    top

    IdentityCheck Directive

    @@ -94,6 +93,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 77eb07f5d8..985e026195 100644 --- a/docs/manual/mod/mod_ident.html.fr +++ b/docs/manual/mod/mod_ident.html.fr @@ -49,7 +49,6 @@

    -
    top

    Directive IdentityCheck

    @@ -102,6 +101,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 989cee6dd1..f33a34b8d6 100644 --- a/docs/manual/mod/mod_ident.html.ja.utf8 +++ b/docs/manual/mod/mod_ident.html.ja.utf8 @@ -47,7 +47,6 @@

    -
    top

    IdentityCheck ディレクティブ

    @@ -94,6 +93,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 e1ad5da038..846d1cddaa 100644 --- a/docs/manual/mod/mod_ident.html.ko.euc-kr +++ b/docs/manual/mod/mod_ident.html.ko.euc-kr @@ -51,7 +51,6 @@

    -
    top

    IdentityCheck Áö½Ã¾î

    @@ -95,6 +94,7 @@ ¼öÁ¤ÇÒ ¼ö ÀÖ´Ù.

    +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_imagemap.html.en b/docs/manual/mod/mod_imagemap.html.en index 51bde2087f..9a6bc349f6 100644 --- a/docs/manual/mod/mod_imagemap.html.en +++ b/docs/manual/mod/mod_imagemap.html.en @@ -69,6 +69,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

    @@ -290,94 +378,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.ko.euc-kr b/docs/manual/mod/mod_imagemap.html.ko.euc-kr index 5b29a2ddce..2c99fa5488 100644 --- a/docs/manual/mod/mod_imagemap.html.ko.euc-kr +++ b/docs/manual/mod/mod_imagemap.html.ko.euc-kr @@ -66,6 +66,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

    »õ·Î¿î ±â´É

    @@ -273,88 +355,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 775cb91a29..17cacb52ab 100644 --- a/docs/manual/mod/mod_include.html.en +++ b/docs/manual/mod/mod_include.html.en @@ -69,1013 +69,1013 @@
  • SSI Tutorial
    • top
    -
    -

    Enabling Server-Side Includes

    - +

    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.

    -

    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:

    + 
    SSIEndTag "%>"
    - 
    AddType text/html .shtml
-AddOutputFilter INCLUDES .shtml
    -

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

    +

    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.

    - 
    Options +Includes
    +

    This directive has the same effect as the <!--#config + errmsg=message --> element.

    + 
    SSIErrorMsg "<!-- Error -->"
    -

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

    -

    For more information, see our Tutorial on Server Side Includes.

    -
    top
    -
    -

    PATH_INFO with Server Side Includes

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

    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.

    -

    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:

    +

    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:

    -

    - <!--#element attribute=value - attribute=value ... --> -

    +
    -

    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.

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

    The allowed elements are listed in the following table:

    +
    on
    +
    Existing ETags will be respected, and ETags generated by the server will + be passed on in the response.
    - - - - - - - - - - - - - - - - - - -
    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:

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

    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.

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

    +

    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:

    -

    - <!--#config echomsg="[Value Undefined]" --> -

    -
    +
    -
    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.]" --> -

    -
    +
    off
    +
    The Last-Modified header will be stripped from responses, + unless the XBitHack directive + is set to full as described below.
    -
    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" --> -

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

    The value is a string to be used by the - strftime(3) library routine when printing - dates.

    - -

    - <!--#config timefmt=""%R, %B %d, %Y"" --> -

    - -
    - - -

    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:

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

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

    - # Simple example
    - <!--#include virtual="/not-exist.html" onerror="/error.html" --> + <!--#config echomsg="[Value Undefined]" --> +

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

    +

    - # Dedicated onerror paths
    - <!--#include virtual="/path-a.html" onerror="/error-a.html" virtual="/path-b.html" onerror="/error-b.html" --> + <!--#config sizefmt="abbrev" -->

    + +
    +
    timefmt
    +

    The value is a string to be used by the + strftime(3) library routine when printing + dates.

    + +

    + <!--#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
    -

    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
    -

    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.ja.utf8 b/docs/manual/mod/mod_include.html.ja.utf8 index 701f64bd2c..ea5ac87b95 100644 --- a/docs/manual/mod/mod_include.html.ja.utf8 +++ b/docs/manual/mod/mod_include.html.ja.utf8 @@ -72,6 +72,223 @@
  • 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

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

    +
    top
    +

    SSILastModified ディレクティブ

    + + + + + + + +
    説明:Controls whether Last-Modified headers are generated by the +server.
    構文:SSILastModified on|off
    デフォルト:SSILastModified off
    コンテキスト:ディレクトリ, .htaccess
    ステータス:Base
    モジュール:mod_include

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

    +
    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 を有効にする

    @@ -646,223 +863,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

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

    -
    top
    -

    SSILastModified ディレクティブ

    - - - - - - - -
    説明:Controls whether Last-Modified headers are generated by the -server.
    構文:SSILastModified on|off
    デフォルト:SSILastModified off
    コンテキスト:ディレクトリ, .htaccess
    ステータス:Base
    モジュール:mod_include

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

    -
    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 64724a8b8d..e4b1521391 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/trunk/mod/mod_deflate.html">\
+    http://httpd.apache.org/docs/trunk/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/trunk/mod/mod_deflate.html">\
-    http://httpd.apache.org/docs/trunk/mod/mod_deflate.html</a>'
    - -
    diff --git a/docs/manual/mod/mod_info.html.fr b/docs/manual/mod/mod_info.html.fr index 9cae75aa5f..fabe6ee2e9 100644 --- a/docs/manual/mod/mod_info.html.fr +++ b/docs/manual/mod/mod_info.html.fr @@ -70,6 +70,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/trunk/mod/mod_deflate.html">\
+    http://httpd.apache.org/docs/trunk/mod/mod_deflate.html</a>'
    + + +
    +
    top

    Problèmes liés à la sécurité

    Une fois mod_info chargé dans le serveur, sa @@ -175,26 +195,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/trunk/mod/mod_deflate.html">\
-    http://httpd.apache.org/docs/trunk/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 03c4c45003..35db11dbe2 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/trunk/mod/mod_deflate.html">\
    + http://www.apache.org/docs/trunk/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/trunk/mod/mod_deflate.html">\
    - http://www.apache.org/docs/trunk/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 26882900d7..3dd9230183 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/trunk/mod/mod_deflate.html">\
    + http://www.apache.org/docs/docs/trunk/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/trunk/mod/mod_deflate.html">\
    - http://www.apache.org/docs/docs/trunk/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 42d9a50ef6..ebec827448 100644 --- a/docs/manual/mod/mod_isapi.html.en +++ b/docs/manual/mod/mod_isapi.html.en @@ -62,6 +62,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

    @@ -231,109 +334,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.ko.euc-kr b/docs/manual/mod/mod_isapi.html.ko.euc-kr index e1c2b754ef..23021a54a4 100644 --- a/docs/manual/mod/mod_isapi.html.ko.euc-kr +++ b/docs/manual/mod/mod_isapi.html.ko.euc-kr @@ -62,6 +62,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

    »ç¿ë¹ý

    @@ -212,106 +312,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_journald.html.en b/docs/manual/mod/mod_journald.html.en index 7cbc3de5c7..c4ca6ef809 100644 --- a/docs/manual/mod/mod_journald.html.en +++ b/docs/manual/mod/mod_journald.html.en @@ -45,6 +45,28 @@

  • Examples
    • top
    +

    JournaldCustomLog Directive

    + + + + + + + +
    Description:Enable logging of CustomLog/TransferLog to systemd-journald
    Syntax:JournaldCustomLog on|off
    Default:JournaldCustomLog off
    Context:server config
    Status:Extension
    Module:mod_journald
    + +

    The JournaldCustomLog directive enables logging + of CustomLog and TransferLog messages to systemd-journald. +

    + +

    Performance warning

    + Currently, systemd-journald is not designed for high-throughput logging + and logging access_log to systemd-journald could decrease the performance + a lot. +

    + +
    +
    top

    Structured logging

    @@ -92,28 +114,6 @@ 
    ErrorLog journald
    -
    -
    top
    -

    JournaldCustomLog Directive

    - - - - - - - -
    Description:Enable logging of CustomLog/TransferLog to systemd-journald
    Syntax:JournaldCustomLog on|off
    Default:JournaldCustomLog off
    Context:server config
    Status:Extension
    Module:mod_journald
    - -

    The JournaldCustomLog directive enables logging - of CustomLog and TransferLog messages to systemd-journald. -

    - -

    Performance warning

    - Currently, systemd-journald is not designed for high-throughput logging - and logging access_log to systemd-journald could decrease the performance - a lot. -

    -
    diff --git a/docs/manual/mod/mod_lbmethod_heartbeat.html.en b/docs/manual/mod/mod_lbmethod_heartbeat.html.en index dd7cd819e2..7a2e31d12f 100644 --- a/docs/manual/mod/mod_lbmethod_heartbeat.html.en +++ b/docs/manual/mod/mod_lbmethod_heartbeat.html.en @@ -52,7 +52,6 @@ assumption that they are not fully initialized.

  • mod_heartbeat
  • mod_heartmonitor
    • -
    top

    HeartbeatStorage Directive

    @@ -68,6 +67,7 @@ assumption that they are not fully initialized.

    mod_slotmem_shm is not loaded.

    +

    Available Languages:  en 

    diff --git a/docs/manual/mod/mod_ldap.html.en b/docs/manual/mod/mod_ldap.html.en index 75dfc34d35..cb3afeb420 100644 --- a/docs/manual/mod/mod_ldap.html.en +++ b/docs/manual/mod/mod_ldap.html.en @@ -85,233 +85,442 @@ by other LDAP modules
  • SSL/TLS Certificates
    • top
    -
    -

    Example Configuration

    -

    The following is an example configuration that uses - mod_ldap to increase the performance of HTTP Basic - authentication provided by mod_authnz_ldap.

    - - 
    # Enable the LDAP connection pool and shared
-# memory cache. Enable the LDAP cache status
-# handler. Requires that mod_ldap and mod_authnz_ldap
-# be loaded. Change the "yourdomain.example.com" to
-# match your domain.
+
    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.

    -LDAPSharedCacheSize 500000 -LDAPCacheEntries 1024 -LDAPCacheTTL 600 -LDAPOpCacheEntries 1024 -LDAPOpCacheTTL 600 +
    +
    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).

    -<Location /ldap-status> - SetHandler ldap-status +
    +
    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.

    - Require host yourdomain.example.com +

    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.

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

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

    LDAP Connection Pool

    +

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

    -

    LDAP connections are pooled from request to request. This - allows the LDAP server to remain connected and bound ready for - the next request, without the need to unbind/connect/rebind. - The performance advantages are similar to the effect of HTTP - keepalives.

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

    -

    On a busy server it is possible that many requests will try - and access the same LDAP server connection simultaneously. - Where an LDAP connection is in use, Apache will create a new - connection alongside the original one. This ensures that the - connection pool does not become a bottleneck.

    +

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

    -

    There is no need to manually enable connection pooling in - the Apache configuration. Any module using this module for - access to LDAP services will share the connection pool.

    +

    The default is 10 seconds, if the LDAP client library linked with the + server supports the LDAP_OPT_NETWORK_TIMEOUT option.

    -

    LDAP connections can keep track of the ldap client - credentials used when binding to an LDAP server. These - credentials can be provided to LDAP servers that do not - allow anonymous binds during referral chasing. To control - this feature, see the - LDAPReferrals and - LDAPReferralHopLimit - directives. By default, this feature is enabled.

    -
    top
    -
    -

    LDAP Cache

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

    For improved performance, mod_ldap uses an aggressive - caching strategy to minimize the number of times that the LDAP - server must be contacted. Caching can easily double or triple - the throughput of Apache when it is serving pages protected - with mod_authnz_ldap. In addition, the load on the LDAP server - will be significantly decreased.

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

    -

    mod_ldap supports two types of LDAP caching during - the search/bind phase with a search/bind cache and - during the compare phase with two operation - caches. Each LDAP URL that is used by the server has - its own set of these three caches.

    +

    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 Search/Bind Cache

    -

    The process of doing a search and then a bind is the - most time-consuming aspect of LDAP operation, especially if - the directory is large. The search/bind cache is used to - cache all searches that resulted in successful binds. - Negative results (i.e., unsuccessful searches, or searches - that did not result in a successful bind) are not cached. - The rationale behind this decision is that connections with - invalid credentials are only a tiny percentage of the total - number of connections, so by not caching invalid - credentials, the size of the cache is reduced.

    +
    +

    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.

    +
    -

    mod_ldap stores the username, the DN - retrieved, the password used to bind, and the time of the bind - in the cache. Whenever a new connection is initiated with the - same username, mod_ldap compares the password - of the new connection with the password in the cache. If the - passwords match, and if the cached entry is not too old, - mod_ldap bypasses the search/bind phase.

    -

    The search and bind cache is controlled with the LDAPCacheEntries and LDAPCacheTTL directives.

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

    -

    Operation Caches

    -

    During attribute and distinguished name comparison - functions, mod_ldap uses two operation caches - to cache the compare operations. The first compare cache is - used to cache the results of compares done to test for LDAP - group membership. The second compare cache is used to cache - the results of comparisons done between distinguished - names.

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

    -

    Note that, when group membership is being checked, any sub-group - comparison results are cached to speed future sub-group comparisons.

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

    -

    The behavior of both of these caches is controlled with - the LDAPOpCacheEntries - and LDAPOpCacheTTL - directives.

    - +
    +

    Support for this tunable is uncommon in LDAP SDKs.

    +
    -

    Monitoring the Cache

    -

    mod_ldap has a content handler that allows - administrators to monitor the cache performance. The name of - the content handler is ldap-status, so the - following directives could be used to access the - mod_ldap cache information:

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

    - 
    <Location /server/cache-info>
-    SetHandler ldap-status
-</Location>
    +

    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.

    +
    -

    By fetching the URL http://servername/cache-info, - the administrator can get a status report of every cache that is used - by mod_ldap cache. Note that if Apache does not - support shared memory, then each httpd instance has its - own cache, so reloading the URL will result in different - information each time, depending on which httpd - instance processes the request.

    - -
    top
    -
    -

    Using SSL/TLS

    +

    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.

    -

    The ability to create an SSL and TLS connections to an LDAP server - is defined by the directives - LDAPTrustedGlobalCert, - LDAPTrustedClientCert - and LDAPTrustedMode. - These directives specify the CA and optional client certificates to be used, - as well as the type of encryption to be used on the connection (none, SSL or - TLS/STARTTLS).

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

    - 
    # Establish an SSL LDAP connection on port 636. Requires that
-# mod_ldap and mod_authnz_ldap be loaded. Change the
-# "yourdomain.example.com" to match your domain.
+
    +
    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.

    -LDAPTrustedGlobalCert CA_DER /certs/certfile.der +

    LDAP errors such as timeouts and refused connections are retryable.

    -<Location /ldap-status> - SetHandler ldap-status +
    +
    top
    +

    LDAPSharedCacheFile Directive

    + + + + + + +
    Description:Sets the shared memory cache file
    Syntax:LDAPSharedCacheFile file-path
    Context:server config
    Status:Extension
    Module:mod_ldap
    +

    Specifies the path of the shared memory cache file. If not set, + anonymous shared memory will be used if the platform supports it.

    - Require host yourdomain.example.com +

    If file-path is not an absolute path, the location specified + will be relative to the value of + DefaultRuntimeDir.

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

    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.

    - 
    # 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.
+    
     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.
    
 
-LDAPTrustedGlobalCert CA_DER /certs/certfile.der
+    
    
+    
    Timeouts for ldap compare operations requires an SDK with LDAP_OPT_TIMEOUT, such as OpenLDAP >= 2.4.4.
    
+    
    
 
-<Location /ldap-status>
-    SetHandler ldap-status
 
-    Require host yourdomain.example.com
+
    +
    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
      • +
    - 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
    +

    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
      • +
    -
    top
    -
    -

    SSL/TLS Certificates

    +

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

    -

    The different LDAP SDKs have widely different methods of setting - and handling both CA and client side certificates.

    +

    If an ldaps:// URL is specified, the mode becomes SSL and the setting + of LDAPTrustedMode is ignored.

    -

    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.

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

    -

    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.

    +
    +
    top
    +
    +

    Example Configuration

    +

    The following is an example configuration that uses + mod_ldap to increase the performance of HTTP Basic + authentication provided by mod_authnz_ldap.

    -

    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.

    + 
    # Enable the LDAP connection pool and shared
+# memory cache. Enable the LDAP cache status
+# handler. Requires that mod_ldap and mod_authnz_ldap
+# be loaded. Change the "yourdomain.example.com" to
+# match your domain.
 
-        
    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.
    
+LDAPSharedCacheSize 500000
+LDAPCacheEntries 1024
+LDAPCacheTTL 600
+LDAPOpCacheEntries 1024
+LDAPOpCacheTTL 600
 
-        
    # 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
 
@@ -321,524 +530,315 @@ LDAPTrustedGlobalCert CA_SECMOD /certs/secmod
     AuthType Basic
     AuthName "LDAP Protected"
     AuthBasicProvider ldap
-    LDAPTrustedClientCert CERT_NICKNAME <nickname> [password]
-    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
    +
    +

    LDAP Connection Pool

    - +

    LDAP connections are pooled from request to request. This + allows the LDAP server to remain connected and bound ready for + the next request, without the need to unbind/connect/rebind. + The performance advantages are similar to the effect of HTTP + keepalives.

    -

    Novell SDK

    +

    On a busy server it is possible that many requests will try + and access the same LDAP server connection simultaneously. + Where an LDAP connection is in use, Apache will create a new + connection alongside the original one. This ensures that the + connection pool does not become a bottleneck.

    -

    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.

    +

    There is no need to manually enable connection pooling in + the Apache configuration. Any module using this module for + access to LDAP services will share the connection pool.

    -

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

    +

    LDAP connections can keep track of the ldap client + credentials used when binding to an LDAP server. These + credentials can be provided to LDAP servers that do not + allow anonymous binds during referral chasing. To control + this feature, see the + LDAPReferrals and + LDAPReferralHopLimit + directives. By default, this feature is enabled.

    +
    top
    +
    +

    LDAP Cache

    -

    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.

    +

    For improved performance, mod_ldap uses an aggressive + caching strategy to minimize the number of times that the LDAP + server must be contacted. Caching can easily double or triple + the throughput of Apache when it is serving pages protected + with mod_authnz_ldap. In addition, the load on the LDAP server + will be significantly decreased.

    - 
    # 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
    +

    mod_ldap supports two types of LDAP caching during + the search/bind phase with a search/bind cache and + during the compare phase with two operation + caches. Each LDAP URL that is used by the server has + its own set of these three caches.

    + +

    The Search/Bind Cache

    +

    The process of doing a search and then a bind is the + most time-consuming aspect of LDAP operation, especially if + the directory is large. The search/bind cache is used to + cache all searches that resulted in successful binds. + Negative results (i.e., unsuccessful searches, or searches + that did not result in a successful bind) are not cached. + The rationale behind this decision is that connections with + invalid credentials are only a tiny percentage of the total + number of connections, so by not caching invalid + credentials, the size of the cache is reduced.

    +

    mod_ldap stores the username, the DN + retrieved, the password used to bind, and the time of the bind + in the cache. Whenever a new connection is initiated with the + same username, mod_ldap compares the password + of the new connection with the password in the cache. If the + passwords match, and if the cached entry is not too old, + mod_ldap bypasses the search/bind phase.

    +

    The search and bind cache is controlled with the LDAPCacheEntries and LDAPCacheTTL directives.

    -

    OpenLDAP SDK

    +

    Operation Caches

    +

    During attribute and distinguished name comparison + functions, mod_ldap uses two operation caches + to cache the compare operations. The first compare cache is + used to cache the results of compares done to test for LDAP + group membership. The second compare cache is used to cache + the results of comparisons done between distinguished + names.

    -

    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.

    +

    Note that, when group membership is being checked, any sub-group + comparison results are cached to speed future sub-group comparisons.

    -

    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 behavior of both of these caches is controlled with + the LDAPOpCacheEntries + and LDAPOpCacheTTL + directives.

    + -

    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.

    +

    Monitoring the Cache

    +

    mod_ldap has a content handler that allows + administrators to monitor the cache performance. The name of + the content handler is ldap-status, so the + following directives could be used to access the + mod_ldap cache information:

    - 
    # Specify two CA certificate files
-LDAPTrustedGlobalCert CA_DER /certs/cacert1.der
-LDAPTrustedGlobalCert CA_BASE64 /certs/cacert2.pem
-<Location /ldap-status>
+      
    <Location /server/cache-info>
     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>
    
 
 
+      
    By fetching the URL http://servername/cache-info,
+      the administrator can get a status report of every cache that is used
+      by mod_ldap cache. Note that if Apache does not
+      support shared memory, then each httpd instance has its
+      own cache, so reloading the URL will result in different
+      information each time, depending on which httpd
+      instance processes the request.
    
     
+
    top
    +
    +

    Using SSL/TLS

    -

    Solaris SDK

    - -

    SSL/TLS for the native Solaris LDAP libraries is not yet - supported. If required, install and use the OpenLDAP libraries - instead.

    - - +

    The ability to create an SSL and TLS connections to an LDAP server + is defined by the directives + LDAPTrustedGlobalCert, + LDAPTrustedClientCert + and LDAPTrustedMode. + These directives specify the CA and optional client certificates to be used, + as well as the type of encryption to be used on the connection (none, SSL or + TLS/STARTTLS).

    -

    Microsoft SDK

    + 
    # Establish an SSL LDAP connection on port 636. Requires that
+# mod_ldap and mod_authnz_ldap be loaded. Change the
+# "yourdomain.example.com" to match your domain.
 
-        
    SSL/TLS certificate configuration for the native Microsoft
-        LDAP libraries is done inside the system registry, and no
-        configuration directives are required.
    
+LDAPTrustedGlobalCert CA_DER /certs/certfile.der
 
-        
    Both SSL and TLS are supported by using the ldaps:// URL
-        format, or by using the LDAPTrustedMode directive accordingly.
    
+<Location /ldap-status>
+    SetHandler ldap-status
 
-        
    Note: The status of support for client certificates is not yet known
-        for this toolkit.
    
+    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
    -

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

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

    +LDAPTrustedGlobalCert CA_DER /certs/certfile.der -

    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.

    +<Location /ldap-status> + SetHandler ldap-status -

    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.

    + Require host yourdomain.example.com -

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

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

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

    +
    top
    +
    +

    SSL/TLS Certificates

    -

    The default is 10 seconds, if the LDAP client library linked with the - server supports the LDAP_OPT_NETWORK_TIMEOUT option.

    +

    The different LDAP SDKs have widely different methods of setting + and handling both CA and client side certificates.

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

    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.

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

    +

    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.

    -

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

    +

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

    -
    +

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

    + Require host yourdomain.example.com -
    -
    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.

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

    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.

    +

    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.

    -

    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.

    -
    +

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

    +

    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.

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

    + 
    # 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
    -
    -
    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 file-path
    Context:server config
    Status:Extension
    Module:mod_ldap
    -

    Specifies the path of the shared memory cache file. If not set, - anonymous shared memory will be used if the platform supports it.

    +

    OpenLDAP SDK

    -

    If file-path is not an absolute path, the location specified - will be relative to the value of - DefaultRuntimeDir.

    +

    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
    -

    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.

    +

    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.

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

    +

    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.

    -

    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.

    + 
    # Specify two CA certificate files
+LDAPTrustedGlobalCert CA_DER /certs/cacert1.der
+LDAPTrustedGlobalCert CA_BASE64 /certs/cacert2.pem
+<Location /ldap-status>
+    SetHandler ldap-status
 
-    
    
-    
    Timeouts for ldap compare operations requires an SDK with LDAP_OPT_TIMEOUT, such as OpenLDAP >= 2.4.4.
    
-    
    
+    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
    -

    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)
      • -
    +

    Solaris 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
      • -
    +

    SSL/TLS for the native Solaris LDAP libraries is not yet + supported. If required, install and use the OpenLDAP libraries + instead.

    -

    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.

    +

    Microsoft SDK

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

    +

    SSL/TLS certificate configuration for the native Microsoft + LDAP libraries is done inside the system registry, and no + configuration directives are required.

    + +

    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.

    + +
    diff --git a/docs/manual/mod/mod_ldap.html.fr b/docs/manual/mod/mod_ldap.html.fr index ed2766b514..f3e8b38230 100644 --- a/docs/manual/mod/mod_ldap.html.fr +++ b/docs/manual/mod/mod_ldap.html.fr @@ -84,850 +84,850 @@ 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 +

    Si chemin-fichier n'est pas un chemin absolu, il sera + relatif au répertoire défini via la directive DefaultRuntimeDir.

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

    - +

    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.

    -

    SDK Solaris

    +

    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.

    -

    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.

    +

    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.

    - +

    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

    -

    SDK Microsoft

    +

    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.

    -

    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.

    +

    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.

    -

    SSL et TLS sont tous deux supportés en utilisant des URLs de - type ldaps://, ou en définissant la directive LDAPTrustedMode à - cet effet.

    +

    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.

    -

    Note: L'état du support des certificats clients n'est pas - encore connu pour ce SDK.

    +

    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.

    +

    Le cache de recherche/identification est contrôlé par les + directives LDAPCacheEntries et LDAPCacheTTL.

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

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

    -

    Si chemin-fichier n'est pas un chemin absolu, il sera - relatif au répertoire défini via la directive DefaultRuntimeDir.

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

    + -

    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.

    +

    SDK OpenLDAP

    -
    -

    Les délais pour les opérations de comparaison LDAP nécessitent un - SDK avec LDAP_OPT_TIMEOUT, comme OpenLDAP >= 2.4.4.

    -
    +

    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 certificats clients sont spécifiés pour chaque connexion + à l'aide de la directive LDAPTrustedClientCert.

    -
    -
    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
      • -
    +

    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 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
+<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 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 Solaris

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

    +

    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.

    + + + +

    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 0d4a3c200e..b9557eea38 100644 --- a/docs/manual/mod/mod_log_config.html.en +++ b/docs/manual/mod/mod_log_config.html.en @@ -65,6 +65,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

    @@ -355,186 +535,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.ja.utf8 b/docs/manual/mod/mod_log_config.html.ja.utf8 index 1073ab2a1f..57c39b7e95 100644 --- a/docs/manual/mod/mod_log_config.html.ja.utf8 +++ b/docs/manual/mod/mod_log_config.html.ja.utf8 @@ -71,6 +71,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

    カスタムログ書式

    @@ -278,185 +457,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 8a1f3a776f..8cc2912e46 100644 --- a/docs/manual/mod/mod_log_config.html.ko.euc-kr +++ b/docs/manual/mod/mod_log_config.html.ko.euc-kr @@ -65,6 +65,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

    ·Î±× Çü½Ä ÁöÁ¤Çϱâ

    @@ -241,153 +388,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 b74ccba6a5..9d58c4e3dc 100644 --- a/docs/manual/mod/mod_log_config.html.tr.utf8 +++ b/docs/manual/mod/mod_log_config.html.tr.utf8 @@ -67,6 +67,181 @@

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

    + +

    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 yerel-atif
    + CustomLog referer.log referer env=!yerel-atif +

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

    + +

    Örnek

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

    + +

    Örnek

    + 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

    @@ -326,181 +501,6 @@ 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.

    - -

    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 yerel-atif
    - CustomLog referer.log referer env=!yerel-atif -

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

    - -

    Örnek

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

    - -

    Örnek

    - LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" - \"%{User-agent}i\""
    - TransferLog logs/access_log -

    - -

    Mevcut Diller:  en  | diff --git a/docs/manual/mod/mod_log_debug.html.en b/docs/manual/mod/mod_log_debug.html.en index 1c0e923740..5d3aa36351 100644 --- a/docs/manual/mod/mod_log_debug.html.en +++ b/docs/manual/mod/mod_log_debug.html.en @@ -41,53 +41,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

  • Exemples
    • top
    +

    Directive <Macro>

    +
    Description:Log user-defined message to error log @@ -134,6 +87,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_forensic.html.en b/docs/manual/mod/mod_log_forensic.html.en index 2143613a79..a9dd5892d1 100644 --- a/docs/manual/mod/mod_log_forensic.html.en +++ b/docs/manual/mod/mod_log_forensic.html.en @@ -66,6 +66,52 @@
  • 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 @@ -112,52 +158,6 @@ 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.ja.utf8 b/docs/manual/mod/mod_log_forensic.html.ja.utf8 index dbb3840d59..47ac727a7a 100644 --- a/docs/manual/mod/mod_log_forensic.html.ja.utf8 +++ b/docs/manual/mod/mod_log_forensic.html.ja.utf8 @@ -70,50 +70,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 ディレクティブ

    @@ -161,6 +117,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 f892ac6929..e552c1a14c 100644 --- a/docs/manual/mod/mod_log_forensic.html.tr.utf8 +++ b/docs/manual/mod/mod_log_forensic.html.tr.utf8 @@ -66,50 +66,6 @@

  • mod_log_config
    • top
    -
    -

    Adli Günlük Biçemi

    -

    Her istek günlüğe iki defa kaydedilir. İlki, işlemin başlangıcında - (yani, başlıklar alındıktan hemen sonra), ikincisi ise istek işlem - gördükten sonra normal günlüklemenin yapıldığı sırada yapılır.

    - -

    Her isteği betimlemek için eşsiz bir istek kimliği atanır. Bu adli - kimliğin normal günlüğe de yazılması istenirse bu - %{forensic-id}n biçem dizgesi ile yapılabilir. - mod_unique_id kullanılıyorsa, onun ürettiği kimlik - kullanılır.

    - -

    İlk satır günlüğe, adli kimliği, istek satırını ve alınan tüm - başlıkları boru karakterleri (|) ile ayrılmış olarak - kaydeder. Aşağıda bir örneğe yer verilmiştir (hepsi bir satırdadır):

    - -

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

    - -

    Başlangıçtaki artı imi bu günlük satırının istekle ilgili ilk günlük - kaydı olduğunu belirtir. İkinci satırda bunun yerini bir eksi imi - alır:

    - -

    - -yQtJf8CoAB4AAFNXBIEAAAAA -

    - -

    check_forensic betiği komut satırı argümanı olarak günlük - dosyasının ismini alır. Bu +/- kimlik - çiftlerine bakarak tamamlanmamış istekler varsa bunlar hakkında - uyarır.

    -
    top
    -
    -

    Güvenlik Kaygıları

    -

    Günlük dosyarının kaydedildiği dizine sunucuyu başlatan kullanıcı - 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

    ForensicLog Yönergesi

    説明:Forensic ログのファイル名を設定する
    @@ -156,6 +112,50 @@ +
    top
    +
    +

    Adli Günlük Biçemi

    +

    Her istek günlüğe iki defa kaydedilir. İlki, işlemin başlangıcında + (yani, başlıklar alındıktan hemen sonra), ikincisi ise istek işlem + gördükten sonra normal günlüklemenin yapıldığı sırada yapılır.

    + +

    Her isteği betimlemek için eşsiz bir istek kimliği atanır. Bu adli + kimliğin normal günlüğe de yazılması istenirse bu + %{forensic-id}n biçem dizgesi ile yapılabilir. + mod_unique_id kullanılıyorsa, onun ürettiği kimlik + kullanılır.

    + +

    İlk satır günlüğe, adli kimliği, istek satırını ve alınan tüm + başlıkları boru karakterleri (|) ile ayrılmış olarak + kaydeder. Aşağıda bir örneğe yer verilmiştir (hepsi bir satırdadır):

    + +

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

    + +

    Başlangıçtaki artı imi bu günlük satırının istekle ilgili ilk günlük + kaydı olduğunu belirtir. İkinci satırda bunun yerini bir eksi imi + alır:

    + +

    + -yQtJf8CoAB4AAFNXBIEAAAAA +

    + +

    check_forensic betiği komut satırı argümanı olarak günlük + dosyasının ismini alır. Bu +/- kimlik + çiftlerine bakarak tamamlanmamış istekler varsa bunlar hakkında + uyarır.

    +
    top
    +
    +

    Güvenlik Kaygıları

    +

    Günlük dosyarının kaydedildiği dizine sunucuyu başlatan kullanıcı + 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.

    +

    Mevcut Diller:  en  | diff --git a/docs/manual/mod/mod_logio.html.en b/docs/manual/mod/mod_logio.html.en index b8c997f731..e924fa4581 100644 --- a/docs/manual/mod/mod_logio.html.en +++ b/docs/manual/mod/mod_logio.html.en @@ -64,6 +64,23 @@

  • Apache Log Files
    • top
    +

    LogIOTrackTTFB Directive

    +
    Açıklama:Adli günlük için dosya ismini belirler.
    + + + + + + + +
    Description:Enable tracking of time to first byte (TTFB)
    Syntax:LogIOTrackTTFB ON|OFF
    Default:LogIOTrackTTFB OFF
    Context:server config, virtual host, directory, .htaccess
    Override:none
    Status:Extension
    Module:mod_logio
    +

    This directive configures whether this module tracks the delay + between the request being read and the first byte of the response + headers being written. The resulting value may be logged with the + %^FB format.

    + +
    +
    top

    Custom Log Formats

    @@ -99,23 +116,6 @@ \"%{User-agent}i\" %I %O"
    -
    top
    -

    LogIOTrackTTFB Directive

    - - - - - - - - -
    Description:Enable tracking of time to first byte (TTFB)
    Syntax:LogIOTrackTTFB ON|OFF
    Default:LogIOTrackTTFB OFF
    Context:server config, virtual host, directory, .htaccess
    Override:none
    Status:Extension
    Module:mod_logio
    -

    This directive configures whether this module tracks the delay - between the request being read and the first byte of the response - headers being written. The resulting value may be logged with the - %^FB format.

    - -

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_logio.html.ja.utf8 b/docs/manual/mod/mod_logio.html.ja.utf8 index 2223e1dab7..12bb026e1e 100644 --- a/docs/manual/mod/mod_logio.html.ja.utf8 +++ b/docs/manual/mod/mod_logio.html.ja.utf8 @@ -64,6 +64,19 @@

  • Apache ログファイル
    • top
    +

    LogIOTrackTTFB ディレクティブ

    + + + + + + + + +
    説明:Enable tracking of time to first byte (TTFB)
    構文:LogIOTrackTTFB ON|OFF
    デフォルト:LogIOTrackTTFB OFF
    コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
    上書き:none
    ステータス:Extension
    モジュール:mod_logio

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

    +
    top

    カスタムログ書式

    @@ -90,19 +103,6 @@ \"%{User-agent}i\" %I %O"
    -
    top
    -

    LogIOTrackTTFB ディレクティブ

    - - - - - - - - -
    説明:Enable tracking of time to first byte (TTFB)
    構文:LogIOTrackTTFB ON|OFF
    デフォルト:LogIOTrackTTFB OFF
    コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ, .htaccess
    上書き:none
    ステータス:Extension
    モジュール:mod_logio

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

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_logio.html.ko.euc-kr b/docs/manual/mod/mod_logio.html.ko.euc-kr index cc5aceeea1..f7bd76c41a 100644 --- a/docs/manual/mod/mod_logio.html.ko.euc-kr +++ b/docs/manual/mod/mod_logio.html.ko.euc-kr @@ -61,6 +61,19 @@

  • ¾ÆÆÄÄ¡ ·Î±×ÆÄÀÏ
    • top
    +

    LogIOTrackTTFB Áö½Ã¾î

    + + + + + + + + +
    ¼³¸í:Enable tracking of time to first byte (TTFB)
    ¹®¹ý:LogIOTrackTTFB ON|OFF
    ±âº»°ª:LogIOTrackTTFB OFF
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    Override ¿É¼Ç:none
    »óÅÂ:Extension
    ¸ðµâ:mod_logio

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

    +
    top

    »ç¿ëÀÚÁ¤ÀÇ ·Î±× Çü½Ä

    @@ -89,19 +102,6 @@
    -
    top
    -

    LogIOTrackTTFB Áö½Ã¾î

    - - - - - - - - -
    ¼³¸í:Enable tracking of time to first byte (TTFB)
    ¹®¹ý:LogIOTrackTTFB ON|OFF
    ±âº»°ª:LogIOTrackTTFB OFF
    »ç¿ëÀå¼Ò:ÁÖ¼­¹ö¼³Á¤, °¡»óÈ£½ºÆ®, directory, .htaccess
    Override ¿É¼Ç:none
    »óÅÂ:Extension
    ¸ðµâ:mod_logio

    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_logio.html.tr.utf8 b/docs/manual/mod/mod_logio.html.tr.utf8 index 839845251c..ec18d1c252 100644 --- a/docs/manual/mod/mod_logio.html.tr.utf8 +++ b/docs/manual/mod/mod_logio.html.tr.utf8 @@ -66,6 +66,18 @@

  • Apache Günlük Dosyaları
    • top
    +

    LogIOTrackTTFB Yönergesi

    + + + + + + + + +
    Açıklama:Enable tracking of time to first byte (TTFB)
    Sözdizimi:LogIOTrackTTFB ON|OFF
    Öntanımlı:LogIOTrackTTFB OFF
    Bağlam:sunucu geneli, sanal konak, dizin, .htaccess
    Geçersizleştirme:none
    Durum:Eklenti
    Modül:mod_logio

    Bu yönergenin belgesi henüz Türkçeye çevrilmedi. + Lütfen İngilizce sürümüne bakınız.

    +
    top

    Özel Günlük Biçemleri

    @@ -91,18 +103,6 @@ \"%{User-agent}i\" %I %O"
    -
    top
    -

    LogIOTrackTTFB Yönergesi

    - - - - - - - - -
    Açıklama:Enable tracking of time to first byte (TTFB)
    Sözdizimi:LogIOTrackTTFB ON|OFF
    Öntanımlı:LogIOTrackTTFB OFF
    Bağlam:sunucu geneli, sanal konak, dizin, .htaccess
    Geçersizleştirme:none
    Durum:Eklenti
    Modül:mod_logio

    Bu yönergenin belgesi henüz Türkçeye çevrilmedi. - Lütfen İngilizce sürümüne bakınız.

    Mevcut Diller:  en  | diff --git a/docs/manual/mod/mod_lua.html.en b/docs/manual/mod/mod_lua.html.en index 6db6d67177..ae2c46f1aa 100644 --- a/docs/manual/mod/mod_lua.html.en +++ b/docs/manual/mod/mod_lua.html.en @@ -95,283 +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
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua
    +
    +
    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
    -
    -

    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 - has the same fields as the request_rec struct, many of which are writable as +

    +
    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 + has the same fields as the request_rec struct, many of which are writable as well as readable. (The table fields' content can be changed, but the fields themselves cannot be set to different tables.)

    @@ -672,1207 +1295,584 @@ while we_have_stuff_to_send do 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
    - - -
    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
    - - -
    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
    
 
 
-
    r:wspeek() -- Checks if any data is ready to be read
-
--- Sleep while nothing is being sent to us...
-while r:wspeek() == false do
-   r.usleep(50000)
-end
--- We have data ready!
-local line = r:wsread()
    
-
-
+
    r:expr(string) -- Evaluates an expr string.
 
-
    r:config() -- Get a walkable tree of the entire httpd configuration
    
+if r:expr("%{HTTP_HOST} =~ /^www/") then
+    r:puts("This host name starts with www")
+end
    
 
 
-
    r:activeconfig() -- Get a walkable tree of the active (virtualhost-specific) httpd configuration
    
+
    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)
    
 
 
-
    top
    -
    -

    Logging Functions

    +
    r:scoreboard_worker(a, b) -- Queries for information about the worker thread, b, in process a:
 
-
            -- 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")
    
-
    
+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")
    -
    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
    -
    -

    (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
+
    r:clock() -- Returns the current time with microsecond precision
    
 
-    -- 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
    -
    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)
+
    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
    
 
-    
    
-    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:loaded_modules() -- Returns a list of modules loaded by httpd:
 
--- 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")
    
+for k, module in pairs(r:loaded_modules()) do
+    r:puts("I have loaded module " .. module .. "\n")
+end
    
 
-        
    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
    
+
    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.
    
 
-        
    Escaping values, closing databases etc:
    
-    
    -- Escape a value for use in a statement:
-local escaped = database:escape(r, [["'|blabla]])
 
--- Close a database connection and free up handles:
-database:close()
+
    r:server_info() -- Returns a table containing server information, such as 
+                -- the name of the httpd executable file, mpm used etc.
    
 
--- Check whether a database connection is up and running:
-local connected = database:active()
    
 
-    
-    
    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")
+
    r:set_document_root(file_path) -- Sets the document root for the request to file_path
    
 
-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.
    
 
-    
    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
 
-     -- fetch rows synchronously:
-    local result, err = statement:select(20)
-    if not err then
-        for index, row in rows(result, false) do
-            ....
-        end
-    end
+
    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
    
 
-    
-    
    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:set_keepalive() -- Sets the keepalive status for a request. Returns true if possible, false otherwise.
    
 
--- 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.
-    
    
-    
+
    r:make_etag() -- Constructs and returns the etag for the current request.
    
 
-
    -
    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:

    -
    LuaRoot /usr/local/apache2/lua
-LuaAuthzProvider foo authz.lua authz_check_foo
-<Location />
-  Require foo johndoe
-</Location>
    +
    r:send_interim_response(clear) -- Sends an interim (1xx) response to the client.
+                       -- if 'clear' is true, available headers will be sent and cleared.
    -
    require "apache2"
-function authz_check_foo(r, who)
-    if r.user ~= who then return apache2.AUTHZ_DENIED
-    return apache2.AUTHZ_GRANTED
-end
    +
    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:
 
-
    -
    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.

    +if r.exists_config_define("FOO") then + r:puts("httpd was probably run with -DFOO, or it was defined in the configuration") +end -

    In general stat or forever is good for production, and stat or never - for development.

    -

    Examples:

    LuaCodeCache stat
-LuaCodeCache forever
-LuaCodeCache never
    -
    +
    r:state_query(string) -- Queries the server for state information
    -
    -
    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:stat(filename [,wanted]) -- Runs stat() on a file, and returns a table with file information:
 
-
    -
    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'
+local info = r:stat("/var/www/foo.txt")
+if info then
+    r:puts("This file exists and was last modified at: " .. info.modified)
+end
    --- 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) - -- look for auth info - auth = r.headers_in['Authorization'] - if auth ~= nil then - -- fake the user - r.user = 'foo' - end +
    r:regex(string, pattern [,flags]) -- Runs a regular expression match on a string, returning captures if matched:
+
+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
+
+-- Example ignoring case sensitivity:
+local matches = r:regex("FOO bar BAz", [[(foo) bar]], 1)
 
-   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
    +-- Flags can be a bitwise combination of: +-- 0x01: Ignore case +-- 0x02: Multiline search -

    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
    Context:server config, virtual host, directory, .htaccess
    Override:All
    Status:Experimental
    Module:mod_lua
    -
    -
    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 -

    +
    r.usleep(number_of_microseconds) -- Puts the script to sleep for a given number of microseconds.
    -
    -
    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
    -
    -- /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.
+
    r:dbacquire(dbType[, dbParams]) -- Acquires a connection to a database and returns a database class.
+                        -- See 'Database connectivity' for details.
    
 
-    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.
+
+
    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
    
 
 
-
    -
    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
    +
    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).
    - 
    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:mkdir(dir [,mode]) -- Creates a directory and sets mode to optional mode paramter.
    
 
-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:mkrdir(dir [,mode]) -- Creates directories recursive and sets mode to optional mode paramter.
    
+
+
+
    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
-    return apache2.DECLINED -- If we had nothing to do, let others serve this.
+  end
 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.date_parse_rfc(string) -- Parses a date/time string and returns seconds since epoche.
    -

    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:getcookie(key) -- Gets a HTTP cookie
    -
    # httpd.conf
-LuaHookTranslateName /scripts/conf/hooks.lua silly_mapper
    +
    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
+}
    -
    -- /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
+
+
    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
    
 
 
-   
    Context
    This directive is not valid in <Directory>, <Files>, or htaccess
-   context.
    
+
    r:wsread() -- Reads a WebSocket frame from a WebSocket upgraded connection (see above):
+
+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:wswrite(line) -- Writes a frame to a WebSocket client:
+r:wswrite("Hello, world!")
    
+
 
-   
    Ordering
    The optional arguments "early" or "late" 
-   control when this script runs relative to other modules.
    
+
    r:wsclose() -- Closes a WebSocket request and terminates it for httpd:
 
+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
    
 
-
    -
    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
+
    r:wspeek() -- Checks if any data is ready to be read
 
-        return apache2.DECLINED
-    end
    
+-- Sleep while nothing is being sent to us...
+while r:wspeek() == false do
+   r.usleep(50000)
+end
+-- We have data ready!
+local line = r:wsread()
    -
    -
    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:config() -- Get a walkable tree of the entire httpd configuration
    -
    --[[
-    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
    +
    r:activeconfig() -- Get a walkable tree of the active (virtualhost-specific) httpd configuration
    -

    -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
    +
    top
    +
    +

    Logging Functions

    -

    This would invoke the "handle" function, which - is the default if no specific function name is - provided.

    +
            -- 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")
    
+
    -
    -
    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>
    +
    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
    -
    --[[
-    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
+
    +

    (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
    + +
    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 a170843ae0..19ecb4df82 100644 --- a/docs/manual/mod/mod_lua.html.fr +++ b/docs/manual/mod/mod_lua.html.fr @@ -101,1908 +101,1908 @@ 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 -SetHandler ou AddHandler :

    -
    <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 /path/to/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 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.

    -
    -translate_name.lua
    
--- exemple d'accroche qui réécrit un URI en chemin du système de fichiers.
+    
    Exemple :
    
 
-require 'apache2'
+
    # httpd.conf
+LuaHookTranslateName /scripts/conf/hooks.lua silly_mapper
    
 
-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.
    
 
-     Note: utilisez le drapeau early/late de la directive pour
-     l'exécuter avant ou après 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
    -
    -

    Structures de données

    - -
    -
    request_rec
    -
    -

    request_rec est considérée en tant que donnée utilisateur. - Elle possède une métatable qui vous permet d'accomplir des - choses intéressantes. Pour la plus grande partie, elle possède - les mêmes champs que la structure request_rec, la - plupart d'entre eux étant accessibles en lecture et écriture (le - contenu des champs de la table peut être modifié, mais les - champs eux-mêmes ne peuvent pas être établis en tant que tables - distinctes).

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

    +
    NomType LuaModifiableDescription
    allowoverridesstringnonL'option AllowOverride s'applique à la requête courante.
    ap_auth_typestringnonCe champ contient le type d'authentification effectuée - (par exemple basic)
    argsstringouiLa chaîne de paramètres de la requête (par exemple - foo=bar&name=johnsmith)
    assbackwardsbooleannoncontient true s'il s'agit d'une requête de style HTTP/0.9 - (par exemple GET /foo (sans champs d'en-tête) )
    auth_namestringnonLa chaîne d'identification utilisée pour la vérification - de l'autorisation d'accès (si elle est disponible).
    bannerstringnonLa bannière du serveur, par exemple Apache HTTP - Server/2.4.3 openssl/0.9.8c
    basic_auth_pwstringnonLe mot de passe pour l'authentification de base envoyé - avec la requête, s'il existe
    canonical_filenamestringnonLe nom de fichier canonique de la requête
    content_encodingstringnonLe type de codage du contenu de la requête courante
    content_typestringouiLe type de contenu de la requête courante, tel qu'il a été - déterminé au cours de la phase type_check (par exemple - image/gif ou text/html)
    context_prefixstringnon -
    context_document_rootstringnon -
    document_rootstringnonLa racine des documents du serveur
    err_headers_outtablenonL'en-tête MIME de l'environnement pour la réponse, écrit - même en cas d'erreur et conservé pendant les redirections - internes
    filenamestringouiLe nom de fichier correspondant à la requête, par exemple - /www/example.com/foo.txt. Il peut être modifié au cours des - phases translate-name ou map-to-storage du traitement de la - requête pour permettre au gestionnaire par défaut (ou aux - gestionnaires de script) de servir une version du fichier - autre que celle demandée.
    handlerstringouiLe nom du gestionnaire qui - doit traiter la requête, par exemple lua-script - si elle doit être traitée par mod_lua. Cette valeur est en - général définie via les directives AddHandler ou SetHandler, mais peut aussi l'être - via mod_lua pour permettre à un autre gestionnaire de traiter - une requête spécifique qui ne serait pas traitée par défaut - par ce dernier. -
    headers_intableouiLes en-têtes MIME de l'environnement de la requête. Il - s'agit des en-têtes comme Host, User-Agent, - Referer, etc...
    headers_outtableouiLes en-têtes MIME de l'environnement de la réponse.
    hostnamestringnonLe nom d'hôte, tel que défini par l'en-tête - Host: ou par un URI complet.
    is_httpsbooleannonIndique si la requête à été faite via HTTPS
    is_initial_reqbooleannonIndique si la requête courante est la requête initiale ou - une sous-requête.
    limit_req_bodynumbernonLa taille maximale du corps de la requête, ou 0 si aucune - limite.
    log_idstringnonL'identifiant de la requête dans les journaux d'accès ou - d'erreur.
    methodstringnonLa méthode de la requête, par exemple GET ou - POST.
    notestableouiUne liste de notes qui peuvent être transmises d'un module - à l'autre.
    optionsstringnonLa valeur de la directive Options pour la requête - courante.
    path_infostringnonLa valeur de PATH_INFO extraite de la requête.
    portnumbernonLe port du serveur utilisé par la requête.
    protocolstringnonLe protocole utilisé, par exemple HTTP/1.1
    proxyreqstringouiIndique 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.
    rangestringnonLe contenu de l'en-tête Range:.
    remainingnumbernonLe nombre d'octets du corps de la requête restant à lire.
    server_builtstringnonLa date de compilation du serveur.
    server_namestringnonLe nom du serveur pour cette requête.
    some_auth_requiredbooleannonIndique si une autorisation est/était requise pour cette - requête.
    subprocess_envtableouiLe jeu de variables d'environnement pour cette requête.
    startednumbernonLe moment où le serveur a été (re)démarré, en secondes - depuis epoch (1er janvier 1970)
    statusnumberouiLe code de retour (courant) pour cette requête, par - exemple 200 ou 404.
    the_requeststringnonLa 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_uristringnonLa partie URI non interprétée de la requête
    uristringouiL'URI après interprétation par httpd
    userstringouiSi une authentification a été effectuée, nom de - l'utilisateur authentifié.
    useragent_ipstringnonL'adresse IP de l'agent qui a envoyé la requête
    + + + + + +
    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
    - - -
    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.
+
    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 :
+
    
 
-local encoded = r:base64_encode("This is a test") -- returns VGhpcyBpcyBhIHRlc3Q=
    +
    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
    -
    r:base64_decode(string) -- Décode une chaîne codée en Base64.
+
    
+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
    
 
-local decoded = r:base64_decode("VGhpcyBpcyBhIHRlc3Q=") -- returns 'This is a test'
    +

    +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:md5(string) -- Calcule et renvoie le condensé MD5 d'une chaîne en mode binaire (binary safe).
+
    LuaMapHandler /bingo /scripts/wombat.lua
    
 
-local hash = r:md5("This is a test") -- returns ce114e4501d2f4e2dcea3e17b546f339
    +

    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 : +

    -
    r:sha1(string) -- Calcule et renvoie le condensé SHA1 d'une chaîne en mode binaire (binary safe).
+
    LuaOutputFilter myOutputFilter /www/filter.lua output_filter
+<Files *.lua>
+  SetOutputFilter myOutputFilter
+</Files>
    
 
-local hash = r:sha1("This is a test") -- returns a54d88e06612d820bc3be72877c74f257b561b19
    +
    --[[
+    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
    -
    r:escape(string) -- Echappe une chaîne de type URL.
+
    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.
+
     
    
 
-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'
    +

    +Voir "Modification de contenu avec les +filtres Lua" pour plus de détails. +

    -
    r:unescape(string) -- Déséchappe une chaîne de type URL.
+
    +
    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.

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

    -
    r:construct_url(string) -- Construit une URL à partir d'un URI
+    
    Exemples :
    LuaPackagePath /scripts/lib/?.lua
+LuaPackagePath /scripts/lib/?/init.lua
    
+
    
 
-local url = r:construct_url(r.uri)
    +
    +
    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.

    -
    r.mpm_query(number) -- Interroge le serveur à propos de son module MPM via la requête ap_mpm_query.
+
    +
    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".

    -local mpm = r.mpm_query(14) -if mpm == 1 then - r:puts("Ce serveur utilise le MPM Event") -end +
    +
    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.
    -
    r:expr(string) -- Evalue une chaîne de type expr.
+    
    conn:
     
    idem request, mais attaché à connection_rec
    
 
-if r:expr("%{HTTP_HOST} =~ /^www/") then
-    r:puts("Ce nom d'hôte commence par www")
-end
    +
    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. +

    -
    r:scoreboard_process(a) -- Interroge le serveur à propos du
-                        -- processus à la position a.
+
    +
    top
    +
    +

    Configuration de base

    -local process = r:scoreboard_process(1) -r:puts("Le serveur 1 a comme PID " .. process.pid) +

    La directive de base pour le chargement du module est

    +
    LoadModule lua_module modules/mod_lua.so
    -
    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)
    +

    +mod_lua fournit un gestionnaire nommé +lua-script qui peut être utilisé avec une directive +SetHandler ou AddHandler :

    +
    <Files *.lua>
+    SetHandler lua-script
+</Files>
    -
    r:clock() -- Renvoie l'heure courante avec une précision d'une microseconde.
    +

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

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

    -local input = r:requestbody() -r:puts("Vous m'avez envoyé le corps de requête suivant :\n") -r:puts(input) +

    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 :

    -
    r:add_input_filter(filter_name) -- Ajoute le filtre en entrée 'filter_name'.
    +
    +example.lua
    
+-- exemple de gestionnaire
 
+require "string"
 
-
    r:module_info(module_name) -- Interroge le serveur à propos d'un module.
+--[[
+     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"
 
-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.
+    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
    
 
 
-
    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.
    
-
+
    
+Ce gestionnaire se contente d'afficher les arguments codés d'un uri ou
+d'un formulaire dans un page au format texte.
+
    
 
-
    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...
    
+
    
+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

    -
    r:set_document_root(file_path) -- Définit la racine des documents
-                               -- pour la requête à file_path.
    +

    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.

    -
    r:add_version_component(component_string) -- Ajoute un élément à
-                                          -- la bannière du serveur.
    +

    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 :

    -
    r:set_context_info(prefix, docroot) -- Définit le préfixe et la
-                                    -- racine des documents du contexte pour une requête.
    +
    +authz_provider.lua
    
 
+require 'apache2'
 
-
    r:os_escape_path(file_path) -- Convertit un chemin du système de
-                            -- fichiers en URL indépendamment du système d'exploitation.
    
+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
    -
    r:escape_logitem(string) -- Echappe une chaîne pour journalisation.
    +

    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>
    -
    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' ?
+
    top
    +
    +

    Ecriture de fonctions d'accroche +(hooks)

    -local match = r.strcmp_match("foobar.com", "foo*.com") -if match then - r:puts("foobar.com matches foo*.com") -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 :

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

    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.

    -
    r:make_etag() -- Génère et renvoie le etag pour la requête courante.
    +
    +translate_name.lua
    
+-- exemple d'accroche qui réécrit un URI en chemin du système de fichiers.
 
+require 'apache2'
 
-
    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.
    
+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
    -
    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!")
    +
    +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.
+--]]
 
-
    r.exists_config_define(string) -- Vérifie si une définition de configuration existe.
+require 'apache2'
 
-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")
+function translate_name(r)
+    if r.uri == "/translate-name" then
+        r.uri = "/find_me.txt"
+        return apache2.DECLINED
+    end
+    return apache2.DECLINED
 end
    
 
+
    top
    +
    +

    Structures de données

    -
    r:state_query(string) -- Interroge le serveur à propos de son état.
    +
    +
    request_rec
    +
    +

    request_rec est considérée en tant que donnée utilisateur. + Elle possède une métatable qui vous permet d'accomplir des + choses intéressantes. Pour la plus grande partie, elle possède + les mêmes champs que la structure request_rec, la + plupart d'entre eux étant accessibles en lecture et écriture (le + contenu des champs de la table peut être modifié, mais les + champs eux-mêmes ne peuvent pas être établis en tant que tables + distinctes).

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    NomType LuaModifiableDescription
    allowoverridesstringnonL'option AllowOverride s'applique à la requête courante.
    ap_auth_typestringnonCe champ contient le type d'authentification effectuée + (par exemple basic)
    argsstringouiLa chaîne de paramètres de la requête (par exemple + foo=bar&name=johnsmith)
    assbackwardsbooleannoncontient true s'il s'agit d'une requête de style HTTP/0.9 + (par exemple GET /foo (sans champs d'en-tête) )
    auth_namestringnonLa chaîne d'identification utilisée pour la vérification + de l'autorisation d'accès (si elle est disponible).
    bannerstringnonLa bannière du serveur, par exemple Apache HTTP + Server/2.4.3 openssl/0.9.8c
    basic_auth_pwstringnonLe mot de passe pour l'authentification de base envoyé + avec la requête, s'il existe
    canonical_filenamestringnonLe nom de fichier canonique de la requête
    content_encodingstringnonLe type de codage du contenu de la requête courante
    content_typestringouiLe type de contenu de la requête courante, tel qu'il a été + déterminé au cours de la phase type_check (par exemple + image/gif ou text/html)
    context_prefixstringnon +
    context_document_rootstringnon +
    document_rootstringnonLa racine des documents du serveur
    err_headers_outtablenonL'en-tête MIME de l'environnement pour la réponse, écrit + même en cas d'erreur et conservé pendant les redirections + internes
    filenamestringouiLe nom de fichier correspondant à la requête, par exemple + /www/example.com/foo.txt. Il peut être modifié au cours des + phases translate-name ou map-to-storage du traitement de la + requête pour permettre au gestionnaire par défaut (ou aux + gestionnaires de script) de servir une version du fichier + autre que celle demandée.
    handlerstringouiLe nom du gestionnaire qui + doit traiter la requête, par exemple lua-script + si elle doit être traitée par mod_lua. Cette valeur est en + général définie via les directives AddHandler ou SetHandler, mais peut aussi l'être + via mod_lua pour permettre à un autre gestionnaire de traiter + une requête spécifique qui ne serait pas traitée par défaut + par ce dernier. +
    headers_intableouiLes en-têtes MIME de l'environnement de la requête. Il + s'agit des en-têtes comme Host, User-Agent, + Referer, etc...
    headers_outtableouiLes en-têtes MIME de l'environnement de la réponse.
    hostnamestringnonLe nom d'hôte, tel que défini par l'en-tête + Host: ou par un URI complet.
    is_httpsbooleannonIndique si la requête à été faite via HTTPS
    is_initial_reqbooleannonIndique si la requête courante est la requête initiale ou + une sous-requête.
    limit_req_bodynumbernonLa taille maximale du corps de la requête, ou 0 si aucune + limite.
    log_idstringnonL'identifiant de la requête dans les journaux d'accès ou + d'erreur.
    methodstringnonLa méthode de la requête, par exemple GET ou + POST.
    notestableouiUne liste de notes qui peuvent être transmises d'un module + à l'autre.
    optionsstringnonLa valeur de la directive Options pour la requête + courante.
    path_infostringnonLa valeur de PATH_INFO extraite de la requête.
    portnumbernonLe port du serveur utilisé par la requête.
    protocolstringnonLe protocole utilisé, par exemple HTTP/1.1
    proxyreqstringouiIndique 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.
    rangestringnonLe contenu de l'en-tête Range:.
    remainingnumbernonLe nombre d'octets du corps de la requête restant à lire.
    server_builtstringnonLa date de compilation du serveur.
    server_namestringnonLe nom du serveur pour cette requête.
    some_auth_requiredbooleannonIndique si une autorisation est/était requise pour cette + requête.
    subprocess_envtableouiLe jeu de variables d'environnement pour cette requête.
    startednumbernonLe moment où le serveur a été (re)démarré, en secondes + depuis epoch (1er janvier 1970)
    statusnumberouiLe code de retour (courant) pour cette requête, par + exemple 200 ou 404.
    the_requeststringnonLa 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_uristringnonLa partie URI non interprétée de la requête
    uristringouiL'URI après interprétation par httpd
    userstringouiSi une authentification a été effectuée, nom de + l'utilisateur authentifié.
    useragent_ipstringnonL'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:stat(filename [,wanted]) -- Exécute stat() sur un fichier, et renvoie une table contenant
-                           -- des informations à propos de ce fichier.
+
    r:flush()   -- vide le tampon de sortie
+            -- Renvoie true si le vidage a été effectué avec succès,
+	    -- false dans le cas contraire.
 
-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)
+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: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:addoutputfilter(name|function) -- ajoute un filtre en sortie
 
+r:addoutputfilter("fooFilter") -- insère le filtre fooFilter dans le flux de sortie
    
 
-
    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:sendfile(filename) -- envoie un fichier entier au client en utilisant sendfile s'il est
+                     -- supporté par la plateforme :
 
-
    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)
+if use_sendfile_thing then
+    r:sendfile("/var/www/large_file.img")
 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: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: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: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: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
-  end
-end
    
 
+
    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.
 
-
    r.date_parse_rfc(string) -- Interprète une chaîne date/heure et renvoie l'équivalent en secondes depuis epoche.
    
+local POST, POSTMULTI = r:parsebody(1024*1024)
+r:puts("Votre nom est : " .. POST['name'] or "Unknown")
    
 
 
-
    r:getcookie(key) -- Obtient un cookie HTTP
    
 
+
    r:puts("bonjour", " le monde", "!") -- affichage dans le corps de la réponse
    
 
-
    r:setcookie(key, value, secure, expires) -- Définit un cookie HTTP, par exemple :
-r:setcookie("foo", "bar and stuff", false, os.time() + 86400)
    
 
+
    r:write("une simple chaîne") -- affichage dans le corps de la réponse
    
 
-
    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:escape_html("<html>test</html>") -- Echappe le code HTML et renvoie le résultat
    
 
-
    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)
    
 
+
    r:base64_encode(string) -- Encode une chaîne à l'aide du standard de codage Base64.
 
-
    r:wswrite(line) -- écrit un cadre vers un client WebSocket :
-r:wswrite("Bonjour le Monde !")
    
+local encoded = r:base64_encode("This is a test") -- returns VGhpcyBpcyBhIHRlc3Q=
    
 
 
-
    r:wsclose() -- ferme une requête WebSocket et l'achève pour httpd :
+
    r:base64_decode(string) -- Décode une chaîne codée en Base64.
 
-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
    
+local decoded = r:base64_decode("VGhpcyBpcyBhIHRlc3Q=") -- returns 'This is a test'
    
 
-
    r:wspeek() -- Vérifie s'il y a des données à lire
 
--- Se met en sommeil tant que rien ne nous est envoyé ...
-while r:wspeek() == false do
-   r.usleep(50000)
-end
--- Il y a des données à lire !
-local line = r:wsread()
    
+
    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:config() -- Extrait une arborescence de l'ensemble de
-	   -- la configuration de httpd pouvant être parcourue
    
+
    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:activeconfig() -- Extrait une arborescence de la configuration active
-		 -- de httpd (pour le serveur virtuel sélectionné)
    
 
+
    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'
    
 
-
    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")
    
-
    +
    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'
    -
    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
-    -- 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.
+
    r:construct_url(string) -- Construit une URL à partir d'un URI
 
-    coroutine.yield([optional header to be prepended to the content])
+local url = r:construct_url(r.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
 
-    -- 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])
+
    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
    
 
-
    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: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
    
 
-    
    
-    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:scoreboard_process(a) -- Interroge le serveur à propos du
+                        -- processus à la position a.
 
--- 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")
    
+local process = r:scoreboard_process(1)
+r:puts("Le serveur 1 a comme PID " .. process.pid)
    
 
-        
    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_worker(a, b) -- Interroge le serveur à propos du
+                          -- thread b, dans le processus 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 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)
    
 
--- 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:clock() -- Renvoie l'heure courante avec une précision d'une microseconde.
    
 
-    
-    
    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 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.
    
+
    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.
 
-    
    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
+local input = r:requestbody()
+r:puts("Vous m'avez envoyé le corps de requête suivant :\n")
+r:puts(input)
    
 
-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
+
    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
    
 
-    
-    
    Fermeture d'une connexion à une base de données
    
-        
 
-    
    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
+
    r:loaded_modules() -- Renvoie une liste des modules chargés par httpd.
 
--- 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
    
+for k, module in pairs(r:loaded_modules()) do
+    r:puts("J'ai chargé le module " .. module .. "\n")
+end
    
 
-    
-    
    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: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.
    -
    LuaRoot /usr/local/apache2/lua
-LuaAuthzProvider foo authz.lua authz_check_foo
-<Location />
-  Require foo johndoe
-</Location>
    +
    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...
    -
    require "apache2"
-function authz_check_foo(r, who)
-    if r.user ~= who then return apache2.AUTHZ_DENIED
-    return apache2.AUTHZ_GRANTED
-end
    +
    r:set_document_root(file_path) -- Définit la racine des documents
+                               -- pour la requête à file_path.
    -
    -
    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:add_version_component(component_string) -- Ajoute un élément à
+                                          -- la bannière du serveur.
    -

    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:set_context_info(prefix, docroot) -- Définit le préfixe et la
+                                    -- racine des documents du contexte pour une requête.
    -
    -
    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:os_escape_path(file_path) -- Convertit un chemin du système de
+                            -- fichiers en URL indépendamment du système d'exploitation.
    -
    -
    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:escape_logitem(string) -- Echappe une chaîne pour journalisation.
    
 
-   -- 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
+
    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
    
 
-
    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 /path/to/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 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. -

    +
    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.
    -
    -
    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
    -
    -- /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.
+
    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.
    
+
 
-    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: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 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:state_query(string) -- Interroge le serveur à propos de son état.
    - 
    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:stat(filename [,wanted]) -- Exécute stat() sur un fichier, et renvoie une table contenant
+                           -- des informations à propos de ce fichier.
 
-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
+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
    
 
 
-    
-
    -
    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:regex(string, pattern [,flags]) -- Exécute une recherche à base d'expression rationnelle
+                                  -- sur une chaîne, et renvoie les éventuelles correspondances trouvées.
 
-    
    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.
    
+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 :
    
+-- Exemple avec insensibilité à la casse :
+local matches = r:regex("FOO bar BAz", [[(foo) bar]], 1)
 
-
    # httpd.conf
-LuaHookTranslateName /scripts/conf/hooks.lua silly_mapper
    
+-- les drapeaux peuvent être une combibaison bit à bit de :
+-- 0x01: insensibilité à la casse
+-- 0x02: recherche multiligne
    -
    -- /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.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.
    + + +
    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
+  end
+end
    + + +
    r.date_parse_rfc(string) -- Interprète une chaîne date/heure et renvoie l'équivalent en secondes depuis epoche.
    -
    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
+
    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
    
 
-
    
-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: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)
    
+
+
+
    r:wswrite(line) -- écrit un cadre vers un client WebSocket :
+r:wswrite("Bonjour le Monde !")
    
+
+
+
    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
    
 
-
    
-Voir "Modification de contenu avec les
-filtres Lua" pour plus de détails.
-
    
+
    r:wspeek() -- Vérifie s'il y a des données à lire
 
-
    -
    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.

    +-- Se met en sommeil tant que rien ne nous est envoyé ... +while r:wspeek() == false do + r.usleep(50000) +end +-- Il y a des données à lire ! +local line = r:wsread() -
    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 : -

    +
    r:config() -- Extrait une arborescence de l'ensemble de
+	   -- la configuration de httpd pouvant être parcourue
    -
    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
+
    r:activeconfig() -- Extrait une arborescence de la configuration active
+		 -- de httpd (pour le serveur virtuel sélectionné)
    
+
+
+
+
    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 b5e0b17ef7..d430089acf 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 d423470385..7195a4a43f 100644 --- a/docs/manual/mod/mod_macro.html.fr +++ b/docs/manual/mod/mod_macro.html.fr @@ -56,6 +56,75 @@ de configuration Apache.
    + + + + + +
    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 @@ -198,75 +267,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 5c593ab2f4..3604a1ad02 100644 --- a/docs/manual/mod/mod_mime.html.en +++ b/docs/manual/mod/mod_mime.html.en @@ -113,139 +113,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.ja.utf8 b/docs/manual/mod/mod_mime.html.ja.utf8 index 4c0dfba0b0..f24ea9da2a 100644 --- a/docs/manual/mod/mod_mime.html.ja.utf8 +++ b/docs/manual/mod/mod_mime.html.ja.utf8 @@ -122,135 +122,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:Maps the given filename extensions to the specified content @@ -1001,6 +868,139 @@ extensions
    @@ -975,6 +846,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 832b1444ef..fa53b6a44d 100644 --- a/docs/manual/mod/mod_mime_magic.html.en +++ b/docs/manual/mod/mod_mime_magic.html.en @@ -56,6 +56,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

    @@ -245,28 +267,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_negotiation.html.en b/docs/manual/mod/mod_negotiation.html.en index 6af381a5e9..41517c7b48 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 cdaadd278f..0e525b808a 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 8d98545499..db62196e93 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 5a6b211e8b..b106491c19 100644 --- a/docs/manual/mod/mod_nw_ssl.html.en +++ b/docs/manual/mod/mod_nw_ssl.html.en @@ -44,7 +44,6 @@

  • SecureListen
    • -
    top

    NWSSLTrustedCerts Directive

    @@ -91,6 +90,7 @@ parameter also enables mutual authentication.

    +

    Available Languages:  en 

    diff --git a/docs/manual/mod/mod_policy.html.en b/docs/manual/mod/mod_policy.html.en index b37a8dd3ed..ee6996b8f3 100644 --- a/docs/manual/mod/mod_policy.html.en +++ b/docs/manual/mod/mod_policy.html.en @@ -86,188 +86,6 @@
  • HTTP Protocol Compliance
    • top
    -
    -

    Actions

    - - -

    If a policy is violated, one of the following actions can be - taken:

    - -
    -
    ignore
    -
    The policy check will be ignored for the given URL space, even - if the filter is present.
    - -
    log
    -
    The policy check will be executed, and if a violation is detected - a warning will be logged to the server error_log, and a - Warning header added to the response for the benefit of - the client.
    - -
    enforce
    -
    The policy check will be executed, and if a violation is detected - an error will be logged to the server error_log, a - Warning header added to the response, and a 502 - Bad Gateway will be returned to the client. Optional links to - explanatory documentation can be added to each error message, - detailing the origin of each policy.
    - -
    - -

    It is also possible to selectively disable all policies for a - given URL space, should the need arise, using the - PolicyFilter directive.

    - -

    Alternatively, the - PolicyEnvironment - directive can be used to specify an environment variable, which if - present, will cause the policies to be selectively downgraded or - bypassed.

    - -
    top
    -
    -

    Policy Tests

    - - -

    The following policy filters are available:

    - -
    -
    POLICY_TYPE - : Enforce valid content types
    -
    Content types that are syntactically invalid or blank can be detected - and the request rejected. Types can be restricted to a specific list - containing optional wildcards ? and *.
    - -
    POLICY_LENGTH - : Enforce the presence of a Content-Length
    -
    The length of responses can be specified in one of three ways, by - specifying an explicit length in advance, using chunked encoding to set - the length, or by setting no length at all and terminating the request - when complete. The absence of a specific content length can affect the - cacheability of the response, and prevents the use of keepalive during - HTTP/1.0 requests. This policy enforces the presence of an explicit - content length on the response.
    - -
    POLICY_KEEPALIVE - : Enforce the option to keepalive
    -
    Less restrictive than the POLICY_LENGTH test, this policy enforces the - possibility that the response can be kept alive. If the response doesn't - have a protocol defined zero length, and the response isn't already an - error, and the response has neither a Content-Length or is declared - HTTP/1.1 and lacks Content-Encoding: chunked, then this response will be - rejected.
    - -
    POLICY_VARY - : Enforce the absence of certain headers within Vary headers
    -
    If the Vary header contains any of the headers specified, this policy - will reject the request. The typical case is the presence of the User-Agent - within Vary, which is likely to cause a denial of service condition to a - cache.
    - -
    - POLICY_VALIDATION: Enforce the presence of Etag and/or - Last-Modified
    -
    The ability for a cache to determine whether a cached entity can be - refreshed is dependent on whether a valid Etag and/or Last-Modified header - is present to revalidate against. The absence of both headers, or the - invalid syntax of a header will cause this policy to be rejected.
    - -
    - POLICY_CONDITIONAL: Enforce correct operation of conditional - requests
    -
    When conditional headers are present in the request, a server should - respond with a 304 Not Modified or 412 Precondition - Failed response where appropriate. A server may ignore conditional - headers, and this affects the efficiency of the HTTP caching mechanism. - This policy rejects requests where a conditional header is present, and - a 304 or 412 response code was expected, but a 2xx response was seen - instead.
    - -
    POLICY_NOCACHE - : Enforce cacheable responses
    -
    When a response is encountered that declares itself explicitly - uncacheable, the request is rejected. A response is considered - uncacheable if it specifies any of the following: -
    • Cache-Control: no-cache
      • -
    • Pragma: no-cache
      • -
    • Cache-Control: no-store
      • -
    • Cache-Control: private
      • -
    - -
    POLICY_MAXAGE - : Enforce a minimum maxage
    -
    When a response is encountered where the freshness lifetime is less - than the given value, or the freshness lifetime is heuristic, the request - is rejected. A response is checked in the following order: -
    • If s-maxage is present but too small; or
      • -
    • If max-age is present but too small; or
      • -
    • If Expires is present and invalid; or
      • -
    • Date is present and invalid; or
      • -
    • Expires minus Date is too small; or
      • -
    • No s-maxage, maxage, or - Expires/Date declared at all
      • -
    - -
    POLICY_VERSION - : Enforce a minimum HTTP version within a request
    -
    When a request is encountered with an HTTP version number less than - the required minimum version, the request is rejected. The following - version numbers are recognised: -
    • HTTP/1.1
      • -
    • HTTP/1.0
      • -
    • HTTP/0.9
      • -
    - -
    - -
    top
    -
    -

    Example Configuration

    - - -

    A typical configuration protecting a server serving static content - might be as follows:

    - - 
    <Location />
-  SetOutputFilter POLICY_TYPE;POLICY_LENGTH;POLICY_KEEPALIVE;POLICY_VARY;POLICY_VALIDATION; \
-    POLICY_CONDITIONAL;POLICY_NOCACHE;POLICY_MAXAGE;POLICY_VERSION
-  
-  # content type must be present and valid, but can be anything
-  PolicyType enforce */*
-  
-  # reject if no explicitly declared content length
-  PolicyLength enforce
-  
-  # covered by the policy length filter
-  PolicyKeepalive ignore
-  
-  # reject if User-Agent appears within Vary headers
-  PolicyVary enforce User-Agent
-  
-  # we want to enforce validation
-  PolicyValidation enforce
-  
-  # non-functional conditional responses should be rejected
-  PolicyConditional enforce
-  
-  # no-cache responses should be rejected
-  PolicyNocache enforce
-  
-  # maxage must be at least a day
-  PolicyMaxage enforce 86400
-  
-  # request version can be anything
-  PolicyVersion ignore HTTP/1.1
-</Location>
-
-# suppress policy protection for server-status
-<Location /server-status>
-  PolicyFilter off
-</Location>
    - - -
    -
    top

    PolicyConditional Directive

    @@ -656,6 +474,188 @@ later.

    Specify the URL of the documentation describing the minimum request HTTP version policy, to appear within error messages.

    + +
    top
    +
    +

    Actions

    + + +

    If a policy is violated, one of the following actions can be + taken:

    + +
    +
    ignore
    +
    The policy check will be ignored for the given URL space, even + if the filter is present.
    + +
    log
    +
    The policy check will be executed, and if a violation is detected + a warning will be logged to the server error_log, and a + Warning header added to the response for the benefit of + the client.
    + +
    enforce
    +
    The policy check will be executed, and if a violation is detected + an error will be logged to the server error_log, a + Warning header added to the response, and a 502 + Bad Gateway will be returned to the client. Optional links to + explanatory documentation can be added to each error message, + detailing the origin of each policy.
    + +
    + +

    It is also possible to selectively disable all policies for a + given URL space, should the need arise, using the + PolicyFilter directive.

    + +

    Alternatively, the + PolicyEnvironment + directive can be used to specify an environment variable, which if + present, will cause the policies to be selectively downgraded or + bypassed.

    + +
    top
    +
    +

    Policy Tests

    + + +

    The following policy filters are available:

    + +
    +
    POLICY_TYPE + : Enforce valid content types
    +
    Content types that are syntactically invalid or blank can be detected + and the request rejected. Types can be restricted to a specific list + containing optional wildcards ? and *.
    + +
    POLICY_LENGTH + : Enforce the presence of a Content-Length
    +
    The length of responses can be specified in one of three ways, by + specifying an explicit length in advance, using chunked encoding to set + the length, or by setting no length at all and terminating the request + when complete. The absence of a specific content length can affect the + cacheability of the response, and prevents the use of keepalive during + HTTP/1.0 requests. This policy enforces the presence of an explicit + content length on the response.
    + +
    POLICY_KEEPALIVE + : Enforce the option to keepalive
    +
    Less restrictive than the POLICY_LENGTH test, this policy enforces the + possibility that the response can be kept alive. If the response doesn't + have a protocol defined zero length, and the response isn't already an + error, and the response has neither a Content-Length or is declared + HTTP/1.1 and lacks Content-Encoding: chunked, then this response will be + rejected.
    + +
    POLICY_VARY + : Enforce the absence of certain headers within Vary headers
    +
    If the Vary header contains any of the headers specified, this policy + will reject the request. The typical case is the presence of the User-Agent + within Vary, which is likely to cause a denial of service condition to a + cache.
    + +
    + POLICY_VALIDATION: Enforce the presence of Etag and/or + Last-Modified
    +
    The ability for a cache to determine whether a cached entity can be + refreshed is dependent on whether a valid Etag and/or Last-Modified header + is present to revalidate against. The absence of both headers, or the + invalid syntax of a header will cause this policy to be rejected.
    + +
    + POLICY_CONDITIONAL: Enforce correct operation of conditional + requests
    +
    When conditional headers are present in the request, a server should + respond with a 304 Not Modified or 412 Precondition + Failed response where appropriate. A server may ignore conditional + headers, and this affects the efficiency of the HTTP caching mechanism. + This policy rejects requests where a conditional header is present, and + a 304 or 412 response code was expected, but a 2xx response was seen + instead.
    + +
    POLICY_NOCACHE + : Enforce cacheable responses
    +
    When a response is encountered that declares itself explicitly + uncacheable, the request is rejected. A response is considered + uncacheable if it specifies any of the following: +
    • Cache-Control: no-cache
      • +
    • Pragma: no-cache
      • +
    • Cache-Control: no-store
      • +
    • Cache-Control: private
      • +
    + +
    POLICY_MAXAGE + : Enforce a minimum maxage
    +
    When a response is encountered where the freshness lifetime is less + than the given value, or the freshness lifetime is heuristic, the request + is rejected. A response is checked in the following order: +
    • If s-maxage is present but too small; or
      • +
    • If max-age is present but too small; or
      • +
    • If Expires is present and invalid; or
      • +
    • Date is present and invalid; or
      • +
    • Expires minus Date is too small; or
      • +
    • No s-maxage, maxage, or + Expires/Date declared at all
      • +
    + +
    POLICY_VERSION + : Enforce a minimum HTTP version within a request
    +
    When a request is encountered with an HTTP version number less than + the required minimum version, the request is rejected. The following + version numbers are recognised: +
    • HTTP/1.1
      • +
    • HTTP/1.0
      • +
    • HTTP/0.9
      • +
    + +
    + +
    top
    +
    +

    Example Configuration

    + + +

    A typical configuration protecting a server serving static content + might be as follows:

    + + 
    <Location />
+  SetOutputFilter POLICY_TYPE;POLICY_LENGTH;POLICY_KEEPALIVE;POLICY_VARY;POLICY_VALIDATION; \
+    POLICY_CONDITIONAL;POLICY_NOCACHE;POLICY_MAXAGE;POLICY_VERSION
+  
+  # content type must be present and valid, but can be anything
+  PolicyType enforce */*
+  
+  # reject if no explicitly declared content length
+  PolicyLength enforce
+  
+  # covered by the policy length filter
+  PolicyKeepalive ignore
+  
+  # reject if User-Agent appears within Vary headers
+  PolicyVary enforce User-Agent
+  
+  # we want to enforce validation
+  PolicyValidation enforce
+  
+  # non-functional conditional responses should be rejected
+  PolicyConditional enforce
+  
+  # no-cache responses should be rejected
+  PolicyNocache enforce
+  
+  # maxage must be at least a day
+  PolicyMaxage enforce 86400
+  
+  # request version can be anything
+  PolicyVersion ignore HTTP/1.1
+</Location>
+
+# suppress policy protection for server-status
+<Location /server-status>
+  PolicyFilter off
+</Location>
    + +
    diff --git a/docs/manual/mod/mod_privileges.html.en b/docs/manual/mod/mod_privileges.html.en index 9f653a54b1..251bffac57 100644 --- a/docs/manual/mod/mod_privileges.html.en +++ b/docs/manual/mod/mod_privileges.html.en @@ -76,65 +76,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

    Description:Enable the conditional request policy.
    @@ -390,6 +331,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_proxy.html.en b/docs/manual/mod/mod_proxy.html.en index 963cbcbe3d..c53f6c1b67 100644 --- a/docs/manual/mod/mod_proxy.html.en +++ b/docs/manual/mod/mod_proxy.html.en @@ -145,1821 +145,1821 @@
  • 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:Determines whether the privileges required by dtrace are enabled.
    + + + + + + + +
    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 proxy Balancers/Workers defined 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" + Balancers and Workers 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
    -
    -

    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: -

    - -

    Reverse Proxy PHP scripts

    <FilesMatch \.php$>
-    SetHandler  "proxy:unix:/path/to/app.sock|fcgi://localhost/"
-</FilesMatch>
    +
    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
    +

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

    -

    This feature is available in Apache HTTP Server 2.4.10 and later.

    +

    Example

    ProxyRemote  *  http://firewall.example.com:81
+NoProxy         .example.com 192.168.112.0/21
    +
    -
    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.

    +

    The host arguments to the NoProxy + directive are one of the following type list:

    -

    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.

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

    -

    Explicitly configured workers are identified by their URL. - They are usually created and configured using - ProxyPass or - ProxyPassMatch when used - for a reverse proxy:

    +

    Examples

    + .com .example.org. +

    - 
    ProxyPass /example http://backend.example.com connectiontimeout=5 timeout=30
    +

    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.

    +
    -

    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:

    + +
    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:

    - 
    ProxySet http://backend.example.com connectiontimeout=5 timeout=30
    +
    +
    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.

    -

    or alternatively using Proxy - and ProxySet:

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

    - 
    <Proxy http://backend.example.com>
-  ProxySet connectiontimeout=5 timeout=30
-</Proxy>
    +

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

    -

    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.

    +

    Examples

    + prep.ai.example.edu
    + www.example.org +

    -

    The URL identifying a direct worker is the URL of its - origin server including any path components given:

    +

    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.

    +
    +
    - 
    ProxyPass /examples http://backend.example.com/examples
-ProxyPass /docs http://backend.example.com/docs
    +

    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.

    +

    For example, the following will allow only hosts in + yournetwork.example.com to access content via your proxy + server:

    -

    This example defines two different workers, each using a separate - connection pool and configuration.

    + 
    <Proxy *>
+  Require host yournetwork.example.com
+</Proxy>
    -

    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

    - 
    ProxyPass /apps http://backend.example.com/ timeout=60
-ProxyPass /examples http://backend.example.com/examples timeout=10
    +

    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:

    + 
    <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!

    -

    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.

    +

    The next example will allow web clients from the specified IP + addresses to issue CONNECT requests to access the + https://www.example.com/ SSL server, if + mod_proxy_connect is enabled. +

    -
    + 
    <Proxy www.example.com:443>
+  Require ip 192.168.0.0/16
+</Proxy>
    -

    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.

    -

    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.

    +

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

    +
    -

    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.

    -

    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.

    +

    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.

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

    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:

    - 
    <Proxy *>
-  Require ip 192.168.0
-</Proxy>
    +
    +
    IsError
    +
    Abort the request and end up with a 502 (Bad Gateway) response. This is + the default behaviour.
    +
    Ignore
    +
    Treat bad header lines as if they weren't sent.
    -

    For more information on access control directives, see - mod_authz_host.

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

    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.

    +
    +
    top
    +

    ProxyBlock Directive

    + + + + + + +
    Description:Disallow proxy requests to certain hosts
    Syntax:ProxyBlock *|hostname|partial-hostname [hostname|partial-hostname]...
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    +

    The ProxyBlock directive can be used to + block FTP or HTTP access to certain hosts via the proxy, based on + a full or partial hostname match, or, if applicable, an IP address + comparison.

    -

    See Also the Proxy-Chain-Auth environment variable.

    +

    Each of the arguments to the ProxyBlock + directive can be either * or a alphanumeric string. + At startup, the module will attempt to resolve every alphanumeric + string from a DNS name to a set of IP addresses, but any DNS errors + are ignored.

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

    +

    If an asterisk "*" argument is specified, + mod_proxy will deny access to all FTP or HTTP + sites.

    -

    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.

    +

    Otherwise, for any request for an HTTP or FTP resource via the + proxy, mod_proxy will check the hostname of the + request URI against each specified string. If a partial string + match is found, access is denied. If no matches against hostnames + are found, and a remote (forward) proxy is configured using + ProxyRemote or + ProxyRemoteMatch, access is allowed. If no + remote (forward) proxy is configured, the IP address of the + hostname from the URI is compared against all resolved IP + addresses determined at startup. Access is denied if any match is + found.

    -

    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.

    +

    Note that the DNS lookups may slow down the startup time of the + server.

    -

    LimitRequestBody only applies to - request bodies that the server will spool to disk

    +

    Example

    ProxyBlock news.example.com auctions.example.com friends.example.com
    +
    -
    top
    -
    -

    Reverse Proxy Request Headers

    +

    Note that example would also be sufficient to match any + of these sites.

    -

    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:

    +

    Hosts would also be matched if referenced by IP address.

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

    Note also that

    -

    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.

    + 
    ProxyBlock *
    -

    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 proxy Balancers/Workers defined 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" - Balancers and Workers 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 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
    -

    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
    -

    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:

    +

    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.

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

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

    -

    Examples

    - .com .example.org. -

    +
    Note: This directive cannot be used within a + <Directory> context.
    -

    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.

    +
    The ProxyRequests directive should + usually be set off when using + ProxyPass.
    -

    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.

    -
    +

    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/. Since + the socket is local, the hostname used (in this case localhost) + is moot, but it is passed as the Host: header value of the request.

    - -
    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:

    +
    Note: The path associated with the unix: + URL is DefaultRuntimeDir aware.
    -
    -
    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)
    -
    +
    Note: RewriteRule requires + the [P,NE] option to prevent the '|' character + from being escaped.
    -

    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.

    +

    Suppose the local server has address http://example.com/; + then

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

    + 
    <Location /mirror/foo/>
+    ProxyPass http://backend.example.com/
+</Location>
    -

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

    +

    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.

    -

    Examples

    - prep.ai.example.edu
    - www.example.org -

    +

    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:

    -

    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.

    -
    - + 
    ProxyPass /mirror/foo/ http://backend.example.com/
    -

    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.

    -

    For example, the following will allow only hosts in - yournetwork.example.com to access content via your proxy - server:

    +
    +

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

    +
    - 
    <Proxy *>
-  Require host yournetwork.example.com
-</Proxy>
    +

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

    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:

    - 
    <Proxy http://example.com/foo/*>
-  SetOutputFilter INCLUDES
-</Proxy>
    + 
    ProxyPass /mirror/foo/i !
+ProxyPass /mirror/foo http://backend.example.com
    -

    The next example will allow web clients from the specified IP - addresses to issue CONNECT requests to access the - https://www.example.com/ SSL server, if - mod_proxy_connect is enabled. -

    +

    will proxy all requests to /mirror/foo to + backend.example.com except requests made to + /mirror/foo/i.

    - 
    <Proxy www.example.com:443>
-  Require ip 192.168.0.0/16
-</Proxy>
    +

    Ordering ProxyPass Directives

    +

    The configured ProxyPass + and ProxyPassMatch + rules are checked in the order of configuration. The first rule that + matches wins. So usually you should sort conflicting + ProxyPass rules starting with the + longest URLs first. Otherwise later rules for longer URLS will be hidden + by any earlier rule which uses a leading substring of the URL. Note that + there is some relation with worker sharing. In contrast, only one + ProxyPass directive can be placed + in a Location block, and the most + specific location will take precedence.

    +

    For the same reasons exclusions must come before the + general ProxyPass directives.

    -

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

    -
    +
    +

    In Apache HTTP Server 2.1 and later, mod_proxy supports pooled + connections to a backend server. Connections created on demand + can be retained in a pool for future use. Limits on the pool size + and other settings can be coded on + the ProxyPass directive + using key=value parameters, described in the table + below.

    -

    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.

    -
    +

    By default, mod_proxy will allow and retain the maximum number of + connections that could be used simultaneously by that web server child + process. Use the max parameter to reduce the number from + the default. Use the ttl parameter to set an optional + time to live; connections which have been unused for at least + ttl seconds will be closed. ttl can be used + to avoid using a connection which is subject to closing because of the + backend server's keep-alive timeout.

    + +

    The pool of connections is maintained per web server child + process, and max and other settings are not coordinated + among all child processes, except when only one child process is allowed + by configuration or MPM design.

    +

    Example

    ProxyPass /example http://backend.example.com max=20 ttl=120 retry=300
    -
    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.
    - -
    Ignore
    -
    Treat bad header lines as if they weren't sent.
    - -
    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
    -

    ProxyBlock Directive

    - - - - - - -
    Description:Disallow proxy requests to certain hosts
    Syntax:ProxyBlock *|hostname|partial-hostname [hostname|partial-hostname]...
    Context:server config, virtual host
    Status:Extension
    Module:mod_proxy
    -

    The ProxyBlock directive can be used to - block FTP or HTTP access to certain hosts via the proxy, based on - a full or partial hostname match, or, if applicable, an IP address - comparison.

    - -

    Each of the arguments to the ProxyBlock - directive can be either * or a alphanumeric string. - At startup, the module will attempt to resolve every alphanumeric - string from a DNS name to a set of IP addresses, but any DNS errors - are ignored.

    - -

    If an asterisk "*" argument is specified, - mod_proxy will deny access to all FTP or HTTP - sites.

    - -

    Otherwise, for any request for an HTTP or FTP resource via the - proxy, mod_proxy will check the hostname of the - request URI against each specified string. If a partial string - match is found, access is denied. If no matches against hostnames - are found, and a remote (forward) proxy is configured using - ProxyRemote or - ProxyRemoteMatch, access is allowed. If no - remote (forward) proxy is configured, the IP address of the - hostname from the URI is compared against all resolved IP - addresses determined at startup. Access is denied if any match is - found.

    -

    Note that the DNS lookups may slow down the startup time of the - server.

    +
    BalancerMember parameters
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -

    Example

    ProxyBlock news.example.com auctions.example.com friends.example.com
    -
    +
    ParameterDefaultDescription
    min0Minimum number of connection pool entries, unrelated to the + actual number of connections. This only needs to be modified from the + default for special circumstances where heap memory associated with the + backend connections should be preallocated or retained.
    max1...nMaximum number of connections that will be allowed to the + backend server. The default for this limit is the number of threads + per process in the active MPM. In the Prefork MPM, this is always 1, + while with other MPMs it is controlled by the + ThreadsPerChild directive.
    smaxmaxRetained connection pool entries above this limit are freed + during certain operations if they have been unused for longer than + the time to live, controlled by the ttl parameter. If + the connection pool entry has an associated connection, it will be + closed. This only needs to be modified from the default for special + circumstances where connection pool entries and any associated + connections which have exceeded the time to live need to be freed or + closed more aggressively.
    acquire-If set this will be the maximum time to wait for a free + connection in the connection pool, in milliseconds. If there are no free + connections in the pool the Apache httpd will return SERVER_BUSY + status to the client. +
    connectiontimeouttimeoutConnect timeout in seconds. + The number of seconds Apache httpd waits for the creation of a connection to + the backend to complete. By adding a postfix of ms the timeout can be + also set in milliseconds. +
    disablereuseOffThis parameter should be used when you want to force mod_proxy + to immediately close a connection to the backend after being used, and + thus, disable its persistent connection and pool for that backend. + This helps in various situations where a firewall between Apache + httpd and + the backend server (regardless of protocol) tends to silently + drop connections or when backends themselves may be under round- + robin DNS. To disable connection pooling reuse, + set this property value to On. +
    enablereuseOnThis is the inverse of 'disablereuse' above, provided as a + convenience for scheme handlers that require opt-in for connection + reuse (such as mod_proxy_fcgi). +
    flushpacketsoffDetermines whether the proxy module will auto-flush the output + brigade after each "chunk" of data. 'off' means that it will flush + only when needed, 'on' means after each chunk is sent and + 'auto' means poll/wait for a period of time and flush if + no input has been received for 'flushwait' milliseconds. + Currently this is in effect only for AJP. +
    flushwait10The time to wait for additional input, in milliseconds, before + flushing the output brigade if 'flushpackets' is 'auto'. +
    iobuffersize8192Adjusts the size of the internal scratchpad IO buffer. This allows you + to override the ProxyIOBufferSize for a specific worker. + This must be at least 512 or set to 0 for the system default of 8192. +
    keepaliveOff

    This parameter should be used when you have a firewall between your + Apache httpd and the backend server, who tend to drop inactive connections. + This flag will tell the Operating System to send KEEP_ALIVE + messages on inactive connections and thus prevent the firewall to drop the connection. + To enable keepalive set this property value to On.

    +

    The frequency of initial and subsequent TCP keepalive probes + depends on global OS settings, and may be as high as 2 hours. To be useful, + the frequency configured in the OS must be smaller than the threshold used + by the firewall.

    +
    lbset0Sets the load balancer cluster set that the worker is a member + of. The load balancer will try all members of a lower numbered + lbset before trying higher numbered ones. +
    ping0Ping property tells the webserver to "test" the connection to + the backend before forwarding the request. For negative values + the test is a simple socket check, for positive values it's + a more functional check, dependent upon the protocol. For AJP, it causes + mod_proxy_ajpto send a CPING + request on the ajp13 connection (implemented on Tomcat 3.3.2+, 4.1.28+ + and 5.0.13+). For HTTP, it causes mod_proxy_http + to send a 100-Continue to the backend (only valid for + HTTP/1.1 - for non HTTP/1.1 backends, this property has no + effect). In both cases the parameter is the delay in seconds to wait + for the reply. + This feature has been added to avoid problems with hung and + busy backends. + This will increase the network traffic during the normal operation + which could be an issue, but it will lower the + traffic in case some of the cluster nodes are down or busy. + By adding a postfix of ms the delay can be also set in + milliseconds. +
    receivebuffersize0Adjusts the size of the explicit (TCP/IP) network buffer size for + proxied connections. This allows you to override the + ProxyReceiveBufferSize for a specific worker. + This must be at least 512 or set to 0 for the system default. +
    redirect-Redirection Route of the worker. This value is usually + set dynamically to enable safe removal of the node from + the cluster. If set all requests without session id will be + redirected to the BalancerMember that has route parameter + equal as this value. +
    retry60Connection pool worker retry timeout in seconds. + If the connection pool worker to the backend server is in the error state, + Apache httpd will not forward any requests to that server until the timeout + expires. This enables to shut down the backend server for maintenance, + and bring it back online later. A value of 0 means always retry workers + in an error state with no timeout. +
    route-Route of the worker when used inside load balancer. + The route is a value appended to session id. +
    status-Single letter value defining the initial status of + this worker. + + + + + + + +
    D: Worker is disabled and will not accept any requests.
    S: Worker is administratively stopped.
    I: Worker is in ignore-errors mode, and will always be considered available.
    H: Worker is in hot-standby mode and will only be used if no other + viable workers are available.
    E: Worker is in an error state.
    N: Worker is in drain mode, and will only accept existing sticky sessions + destined for itself and ignore all other requests.
    Status + can be set (which is the default) by prepending with '+' or + cleared by prepending with '-'. + Thus, a setting of 'S-E' sets this worker to Stopped and + clears the in-error flag. +
    timeoutProxyTimeoutConnection timeout in seconds. + The number of seconds Apache httpd waits for data sent by / to the backend. +
    ttl-Time to live for inactive connections and associated connection + pool entries, in seconds. Once reaching this limit, a + connection will not be used again; it will be closed at some + later time. +
    -

    Note that example would also be sufficient to match any - of these sites.

    +

    If the Proxy directive scheme starts with the + balancer:// (eg: balancer://cluster, + any path information is ignored) then a virtual worker that does not really + communicate with the backend server will be created. Instead it is responsible + for the management of several "real" workers. In that case the special set of + parameters can be add to this virtual worker. See mod_proxy_balancer + for more information about how the balancer works. +

    +
    Balancer parameters
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -

    Hosts would also be matched if referenced by IP address.

    +
    ParameterDefaultDescription
    lbmethodbyrequestsBalancer load-balance method. Select the load-balancing scheduler + method to use. Either byrequests, to perform weighted + request counting, bytraffic, to perform weighted + traffic byte count balancing, or bybusyness, to perform + pending request balancing. Default is byrequests. +
    maxattemptsOne less than the number of workers, or 1 with a single worker.Maximum number of failover attempts before giving up. +
    nofailoverOffIf set to On the session will break if the worker is in + error state or disabled. Set this value to On if backend servers do not + support session replication. +
    stickysession-Balancer sticky session name. The value is usually set to something + like JSESSIONID or PHPSESSIONID, + and it depends on the backend application server that support sessions. + If the backend application server uses different name for cookies + and url encoded id (like servlet containers) use | to to separate them. + The first part is for the cookie the second for the path.
    + Available in Apache HTTP Server 2.4.4 and later. +
    stickysessionsep"."Sets the separation symbol in the session cookie. Some backend application servers + do not use the '.' as the symbol. For example the Oracle Weblogic server uses + '!'. The correct symbol can be set using this option. The setting of 'Off' + signifies that no symbol is used. +
    scolonpathdelimOffIf set to On the semi-colon character ';' will be + used as an additional sticky session path delimiter/separator. This + is mainly used to emulate mod_jk's behavior when dealing with paths such + as JSESSIONID=6736bcf34;foo=aabfa +
    timeout0Balancer timeout in seconds. If set this will be the maximum time + to wait for a free worker. Default is not to wait. +
    failonstatus-A single or comma-separated list of HTTP status codes. If set this will + force the worker into error state when the backend returns any status code + in the list. Worker recovery behaves the same as other worker errors. +
    failontimeoutOffIf set, an IO read timeout after a request is sent to the backend will + force the worker into error state. Worker recovery behaves the same as other + worker errors.
    + Available in Apache HTTP Server 2.4.5 and later. +
    nonce<auto>The protective nonce used in the balancer-manager application page. + The default is to use an automatically determined UUID-based + nonce, to provide for further protection for the page. If set, + then the nonce is set to that value. A setting of None + disables all nonce checking. +

    Note

    +

    In addition to the nonce, the balancer-manager page + should be protected via an ACL.

    +
    +
    growth0Number of additional BalancerMembers to allow to be added + to this balancer in addition to those defined at configuration. +
    forcerecoveryOnForce the immediate recovery of all workers without considering the + retry parameter of the workers if all workers of a balancer are + in error state. There might be cases where an already overloaded backend + can get into deeper trouble if the recovery of all workers is enforced + without considering the retry parameter of each worker. In this case + set to Off.
    + Available in Apache HTTP Server 2.4.2 and later. +
    +

    A sample balancer setup

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

    Note also that

    - 
    ProxyBlock *
    +

    Setting up a hot-standby, that will only be used if no other + members are available

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

    blocks connections to all sites.

    +

    Normally, mod_proxy will canonicalise ProxyPassed URLs. + But this may be incompatible with some backends, particularly those + that make use of PATH_INFO. The optional nocanon + keyword suppresses this, and passes the URL path "raw" to the + backend. Note that may affect the security of your backend, as it + removes the normal limited protection against URL-based attacks + provided by the proxy.

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

    +

    Normally, mod_proxy will include the query string when + generating the SCRIPT_FILENAME environment variable. + The optional noquery keyword (available in + httpd 2.4.1 and later) prevents this.

    -

    Example

          ProxyRemote  *  http://firewall.example.com:81
    
-      NoProxy         .example.com 192.168.112.0/21
    
-      ProxyDomain     .example.com
    -
    +

    When used inside a <Location> section, the first argument is omitted and the local + directory is obtained from the <Location>. The same will occur inside a + <LocationMatch> section, + however ProxyPass does not interpret the regexp as such, so it is necessary + to use ProxyPassMatch in this situation instead.

    -
    -
    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 is not supported in <Directory> or <Files> sections.

    -

    This directive does not affect the processing of informational (1xx), - normal success (2xx), or redirect (3xx) responses.

    +

    If you require a more flexible reverse-proxy configuration, see the + RewriteRule directive with the + [P] flag.

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

    +

    The optional interpolate keyword, in combination with + ProxyPassInterpolateEnv causes the ProxyPass + to interpolate environment variables, using the syntax + ${VARNAME}. Note that many of the standard CGI-derived + environment variables will not exist when this interpolation happens, + so you may still have to resort to mod_rewrite + for complex rules. Also note that interpolation is not supported + within the scheme portion of a URL. Dynamic determination of the + scheme can be accomplished with mod_rewrite as in the + following example.

    -

    In almost every case there's no reason to change that value.

    + 
    RewriteEngine On
 
-    
    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+
    
+RewriteCond %{HTTPS} =off
+RewriteRule . - [E=protocol:http]
+RewriteCond %{HTTPS} =on
+RewriteRule . - [E=protocol:https]
 
-    
    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.
    
+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
    -

    <ProxyMatch> Directive

    +

    ProxyPassInherit Directive

    - - + + + +
    Description:Container for directives applied to regular-expression-matched -proxied resources
    Syntax:<ProxyMatch regex> ...</ProxyMatch>
    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.
    -

    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

    - +

    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
    -

    ProxyMaxForwards Directive

    +

    ProxyPassInterpolateEnv Directive

    - - - - + + + +
    Description:Maximium number of proxies that a request can be forwarded -through
    Syntax:ProxyMaxForwards number
    Default:ProxyMaxForwards -1
    Context:server config, virtual host
    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
    -

    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.

    +

    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
    -

    ProxyPass Directive

    +

    ProxyPassMatch Directive

    - - + + -
    Description:Maps remote servers into the local server URL-space
    Syntax:ProxyPass [path] !|url [key=value - [key=value ...]] [nocanon] [interpolate] [noquery]
    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
    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.

    +

    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.
    - -
    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/. Since - the socket is local, the hostname used (in this case localhost) - is moot, but it is passed as the Host: header value of the request.

    - -
    Note: The path associated with the unix: - URL is DefaultRuntimeDir aware.
    - -
    Note: RewriteRule requires - the [P,NE] option to prevent the '|' character - from being escaped.
    - +

    Suppose the local server has address http://example.com/; then

    - 
    <Location /mirror/foo/>
-    ProxyPass http://backend.example.com/
-</Location>
    + 
    ProxyPassMatch ^/(.*\.gif)$ http://backend.example.com/$1

    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.

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

    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:

    +

    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
    - 
    ProxyPass /mirror/foo/ http://backend.example.com/
    +
    +

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

    +
    -

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

    +

    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.

    -

    The ! directive is useful in situations where you don't want - to reverse-proxy a subdirectory, e.g.

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

    - 
    <Location /mirror/foo/>
-    ProxyPass http://backend.example.com/
-</Location>
-<Location /mirror/foo/i>
-    ProxyPass !
-</Location>
    +

    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.

    - 
    ProxyPass /mirror/foo/i !
-ProxyPass /mirror/foo http://backend.example.com
    +

    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 proxy all requests to /mirror/foo to - backend.example.com except requests made to - /mirror/foo/i.

    -

    Ordering ProxyPass Directives

    -

    The configured ProxyPass - and ProxyPassMatch - rules are checked in the order of configuration. The first rule that - matches wins. So usually you should sort conflicting - ProxyPass rules starting with the - longest URLs first. Otherwise later rules for longer URLS will be hidden - by any earlier rule which uses a leading substring of the URL. Note that - there is some relation with worker sharing. In contrast, only one - ProxyPass directive can be placed - in a Location block, and the most - specific location will take precedence.

    +

    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.

    -

    For the same reasons exclusions must come before the - general ProxyPass directives.

    +

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

    -

    In Apache HTTP Server 2.1 and later, mod_proxy supports pooled - connections to a backend server. Connections created on demand - can be retained in a pool for future use. Limits on the pool size - and other settings can be coded on - the ProxyPass directive - using key=value parameters, described in the table - below.

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

    -

    By default, mod_proxy will allow and retain the maximum number of - connections that could be used simultaneously by that web server child - process. Use the max parameter to reduce the number from - the default. Use the ttl parameter to set an optional - time to live; connections which have been unused for at least - ttl seconds will be closed. ttl can be used - to avoid using a connection which is subject to closing because of the - backend server's keep-alive timeout.

    +

    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.

    -

    The pool of connections is maintained per web server child - process, and max and other settings are not coordinated - among all child processes, except when only one child process is allowed - by configuration or MPM design.

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

    ProxyPass /example http://backend.example.com max=20 ttl=120 retry=300
    +

    Example

    ProxyReceiveBufferSize 2048
    -
    BalancerMember parameters
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + +
    top
    +

    ProxyRemote Directive

    +
    ParameterDefaultDescription
    min0Minimum number of connection pool entries, unrelated to the - actual number of connections. This only needs to be modified from the - default for special circumstances where heap memory associated with the - backend connections should be preallocated or retained.
    max1...nMaximum number of connections that will be allowed to the - backend server. The default for this limit is the number of threads - per process in the active MPM. In the Prefork MPM, this is always 1, - while with other MPMs it is controlled by the - ThreadsPerChild directive.
    smaxmaxRetained connection pool entries above this limit are freed - during certain operations if they have been unused for longer than - the time to live, controlled by the ttl parameter. If - the connection pool entry has an associated connection, it will be - closed. This only needs to be modified from the default for special - circumstances where connection pool entries and any associated - connections which have exceeded the time to live need to be freed or - closed more aggressively.
    acquire-If set this will be the maximum time to wait for a free - connection in the connection pool, in milliseconds. If there are no free - connections in the pool the Apache httpd will return SERVER_BUSY - status to the client. -
    connectiontimeouttimeoutConnect timeout in seconds. - The number of seconds Apache httpd waits for the creation of a connection to - the backend to complete. By adding a postfix of ms the timeout can be - also set in milliseconds. -
    disablereuseOffThis parameter should be used when you want to force mod_proxy - to immediately close a connection to the backend after being used, and - thus, disable its persistent connection and pool for that backend. - This helps in various situations where a firewall between Apache - httpd and - the backend server (regardless of protocol) tends to silently - drop connections or when backends themselves may be under round- - robin DNS. To disable connection pooling reuse, - set this property value to On. -
    enablereuseOnThis is the inverse of 'disablereuse' above, provided as a - convenience for scheme handlers that require opt-in for connection - reuse (such as mod_proxy_fcgi). -
    flushpacketsoffDetermines whether the proxy module will auto-flush the output - brigade after each "chunk" of data. 'off' means that it will flush - only when needed, 'on' means after each chunk is sent and - 'auto' means poll/wait for a period of time and flush if - no input has been received for 'flushwait' milliseconds. - Currently this is in effect only for AJP. -
    flushwait10The time to wait for additional input, in milliseconds, before - flushing the output brigade if 'flushpackets' is 'auto'. -
    iobuffersize8192Adjusts the size of the internal scratchpad IO buffer. This allows you - to override the ProxyIOBufferSize for a specific worker. - This must be at least 512 or set to 0 for the system default of 8192. -
    keepaliveOff

    This parameter should be used when you have a firewall between your - Apache httpd and the backend server, who tend to drop inactive connections. - This flag will tell the Operating System to send KEEP_ALIVE - messages on inactive connections and thus prevent the firewall to drop the connection. - To enable keepalive set this property value to On.

    -

    The frequency of initial and subsequent TCP keepalive probes - depends on global OS settings, and may be as high as 2 hours. To be useful, - the frequency configured in the OS must be smaller than the threshold used - by the firewall.

    -
    lbset0Sets the load balancer cluster set that the worker is a member - of. The load balancer will try all members of a lower numbered - lbset before trying higher numbered ones. -
    ping0Ping property tells the webserver to "test" the connection to - the backend before forwarding the request. For negative values - the test is a simple socket check, for positive values it's - a more functional check, dependent upon the protocol. For AJP, it causes - mod_proxy_ajpto send a CPING - request on the ajp13 connection (implemented on Tomcat 3.3.2+, 4.1.28+ - and 5.0.13+). For HTTP, it causes mod_proxy_http - to send a 100-Continue to the backend (only valid for - HTTP/1.1 - for non HTTP/1.1 backends, this property has no - effect). In both cases the parameter is the delay in seconds to wait - for the reply. - This feature has been added to avoid problems with hung and - busy backends. - This will increase the network traffic during the normal operation - which could be an issue, but it will lower the - traffic in case some of the cluster nodes are down or busy. - By adding a postfix of ms the delay can be also set in - milliseconds. -
    receivebuffersize0Adjusts the size of the explicit (TCP/IP) network buffer size for - proxied connections. This allows you to override the - ProxyReceiveBufferSize for a specific worker. - This must be at least 512 or set to 0 for the system default. -
    redirect-Redirection Route of the worker. This value is usually - set dynamically to enable safe removal of the node from - the cluster. If set all requests without session id will be - redirected to the BalancerMember that has route parameter - equal as this value. -
    retry60Connection pool worker retry timeout in seconds. - If the connection pool worker to the backend server is in the error state, - Apache httpd will not forward any requests to that server until the timeout - expires. This enables to shut down the backend server for maintenance, - and bring it back online later. A value of 0 means always retry workers - in an error state with no timeout. -
    route-Route of the worker when used inside load balancer. - The route is a value appended to session id. -
    status-Single letter value defining the initial status of - this worker. - - - - - - - -
    D: Worker is disabled and will not accept any requests.
    S: Worker is administratively stopped.
    I: Worker is in ignore-errors mode, and will always be considered available.
    H: Worker is in hot-standby mode and will only be used if no other - viable workers are available.
    E: Worker is in an error state.
    N: Worker is in drain mode, and will only accept existing sticky sessions - destined for itself and ignore all other requests.
    Status - can be set (which is the default) by prepending with '+' or - cleared by prepending with '-'. - Thus, a setting of 'S-E' sets this worker to Stopped and - clears the in-error flag. -
    timeoutProxyTimeoutConnection timeout in seconds. - The number of seconds Apache httpd waits for data sent by / to the backend. -
    ttl-Time to live for inactive connections and associated connection - pool entries, in seconds. Once reaching this limit, a - connection will not be used again; it will be closed at some - later time. -
    + + + + + +
    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] +

    -

    If the Proxy directive scheme starts with the - balancer:// (eg: balancer://cluster, - any path information is ignored) then a virtual worker that does not really - communicate with the backend server will be created. Instead it is responsible - for the management of several "real" workers. In that case the special set of - parameters can be add to this virtual worker. See mod_proxy_balancer - for more information about how the balancer works. -

    -
    Balancer parameters
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

    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.

    -
    ParameterDefaultDescription
    lbmethodbyrequestsBalancer load-balance method. Select the load-balancing scheduler - method to use. Either byrequests, to perform weighted - request counting, bytraffic, to perform weighted - traffic byte count balancing, or bybusyness, to perform - pending request balancing. Default is byrequests. -
    maxattemptsOne less than the number of workers, or 1 with a single worker.Maximum number of failover attempts before giving up. -
    nofailoverOffIf set to On the session will break if the worker is in - error state or disabled. Set this value to On if backend servers do not - support session replication. -
    stickysession-Balancer sticky session name. The value is usually set to something - like JSESSIONID or PHPSESSIONID, - and it depends on the backend application server that support sessions. - If the backend application server uses different name for cookies - and url encoded id (like servlet containers) use | to to separate them. - The first part is for the cookie the second for the path.
    - Available in Apache HTTP Server 2.4.4 and later. -
    stickysessionsep"."Sets the separation symbol in the session cookie. Some backend application servers - do not use the '.' as the symbol. For example the Oracle Weblogic server uses - '!'. The correct symbol can be set using this option. The setting of 'Off' - signifies that no symbol is used. -
    scolonpathdelimOffIf set to On the semi-colon character ';' will be - used as an additional sticky session path delimiter/separator. This - is mainly used to emulate mod_jk's behavior when dealing with paths such - as JSESSIONID=6736bcf34;foo=aabfa -
    timeout0Balancer timeout in seconds. If set this will be the maximum time - to wait for a free worker. Default is not to wait. -
    failonstatus-A single or comma-separated list of HTTP status codes. If set this will - force the worker into error state when the backend returns any status code - in the list. Worker recovery behaves the same as other worker errors. -
    failontimeoutOffIf set, an IO read timeout after a request is sent to the backend will - force the worker into error state. Worker recovery behaves the same as other - worker errors.
    - Available in Apache HTTP Server 2.4.5 and later. -
    nonce<auto>The protective nonce used in the balancer-manager application page. - The default is to use an automatically determined UUID-based - nonce, to provide for further protection for the page. If set, - then the nonce is set to that value. A setting of None - disables all nonce checking. -

    Note

    -

    In addition to the nonce, the balancer-manager page - should be protected via an ACL.

    -
    -
    growth0Number of additional BalancerMembers to allow to be added - to this balancer in addition to those defined at configuration. -
    forcerecoveryOnForce the immediate recovery of all workers without considering the - retry parameter of the workers if all workers of a balancer are - in error state. There might be cases where an already overloaded backend - can get into deeper trouble if the recovery of all workers is enforced - without considering the retry parameter of each worker. In this case - set to Off.
    - Available in Apache HTTP Server 2.4.2 and later. -
    -

    A sample balancer setup

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

    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.

    -

    Setting up a hot-standby, that will only be used if no other - members are available

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

    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.

    -

    Normally, mod_proxy will canonicalise ProxyPassed URLs. - But this may be incompatible with some backends, particularly those - that make use of PATH_INFO. The optional nocanon - keyword suppresses this, and passes the URL path "raw" to the - backend. Note that may affect the security of your backend, as it - removes the normal limited protection against URL-based attacks - provided by the proxy.

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

    -

    Normally, mod_proxy will include the query string when - generating the SCRIPT_FILENAME environment variable. - The optional noquery keyword (available in - httpd 2.4.1 and later) prevents this.

    +

    In a typical reverse proxy or gateway configuration, this + option should be set to + Off.

    -

    When used inside a <Location> section, the first argument is omitted and the local - directory is obtained from the <Location>. The same will occur inside a - <LocationMatch> section, - however ProxyPass does not interpret the regexp as such, so it is necessary - to use ProxyPassMatch in this situation instead.

    +

    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.

    -

    This directive is not supported in <Directory> or <Files> sections.

    +

    In order to get the functionality of (forward) proxying HTTPS sites, you + need mod_proxy_connect enabled in the server.

    -

    If you require a more flexible reverse-proxy configuration, see the - RewriteRule directive with the - [P] flag.

    +

    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.

    +
    -

    The optional interpolate keyword, in combination with - ProxyPassInterpolateEnv causes the ProxyPass - to interpolate environment variables, using the syntax - ${VARNAME}. Note that many of the standard CGI-derived - environment variables will not exist when this interpolation happens, - so you may still have to resort to mod_rewrite - for complex rules. Also note that interpolation is not supported - within the scheme portion of a URL. Dynamic determination of the - scheme can be accomplished with mod_rewrite as in the - following example.

    +

    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
    +

    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>
    - 
    RewriteEngine On
 
-RewriteCond %{HTTPS} =off
-RewriteRule . - [E=protocol:http]
-RewriteCond %{HTTPS} =on
-RewriteRule . - [E=protocol:https]
+    
    ProxySet balancer://foo lbmethod=bytraffic 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/
    + + 
    ProxySet ajp://backend:7001 timeout=15
    + + +

    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.

    +
    top
    -

    ProxyPassInherit Directive

    +

    ProxySourceAddress Directive

    - - - + + - +
    Description:Inherit ProxyPass directives defined from the main server
    Syntax:ProxyPassInherit On|Off
    Default:ProxyPassInherit On
    Description:Set local IP address for outgoing proxy connections
    Syntax:ProxySourceAddress address
    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.3.9 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 allows to set a specific local address to bind to when connecting + to a backend server.

    +
    top
    -

    ProxyPassInterpolateEnv Directive

    +

    ProxyStatus Directive

    - - - - + + + +
    Description:Enable Environment Variable interpolation in Reverse Proxy configurations
    Syntax:ProxyPassInterpolateEnv On|Off
    Default:ProxyPassInterpolateEnv Off
    Context:server config, virtual host, directory
    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
    -

    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 determines whether or not proxy + loadbalancer status data is displayed via the mod_status + server-status page.

    +

    Note

    +

    Full is synonymous with On

    +
    +
    top
    -

    ProxyPassMatch Directive

    +

    ProxyTimeout 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:Network timeout for proxied requests
    Syntax:ProxyTimeout seconds
    Default:Value of Timeout
    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 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.

    -
    Note: This directive cannot be used within a - <Directory> context.
    - -

    Suppose the local server has address http://example.com/; - then

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

    - 
    ProxyPassMatch ^/(.*\.gif)$ http://backend.example.com/$1
    +
      +
    • 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.
      • +
    • If set to On, each request and reply will get a + Via: header line added for the current host.
      • -

      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 Full, each generated Via: header + line will additionally have the Apache httpd server version shown as a + Via: comment field.
      • -

      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
      +
    • If set to Block, every proxy request will have all its + Via: header lines removed. No new Via: header will + be generated.
      • +
    -
    -

    The ! directive is useful in situations where you don't want - to reverse-proxy a subdirectory.

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

    -

    When used inside a <LocationMatch> section, the first argument is omitted and the - regexp is obtained from the <LocationMatch>.

    +

    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.

    -

    If you require a more flexible reverse-proxy configuration, see the - RewriteRule directive with the - [P] flag.

    +

    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.

    -
    -

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

    -
    +

    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.

    -
    -

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

    +

    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

    + +

    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: +

    -

    For example, suppose the local server has address - http://example.com/; then

    +

    Reverse Proxy PHP scripts

    <FilesMatch \.php$>
+    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.

    +
    + +

    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 proxying HTTP or FTP sites, you - need also mod_proxy_http or mod_proxy_ftp - (or both) present 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.

    -

    In order to get the functionality of (forward) proxying HTTPS sites, you - need mod_proxy_connect enabled in the server.

    +

    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.

    -

    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.

    -
    +

    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.

    -

    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
    -

    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.

    +
    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 balancer://hotcluster>
-    BalancerMember http://www2.example.com:8080 loadfactor=1
-    BalancerMember http://www3.example.com:8080 loadfactor=2
-    ProxySet lbmethod=bytraffic
+      
    <Proxy *>
+  Require ip 192.168.0
 </Proxy>
    
-
    - 
    <Proxy http://backend>
-    ProxySet keepalive=On
-</Proxy>
    +

    For more information on access control directives, see + mod_authz_host.

    - 
    ProxySet balancer://foo lbmethod=bytraffic timeout=15
    +

    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.

    +

    See Also the Proxy-Chain-Auth environment variable.

    - 
    ProxySet ajp://backend:7001 timeout=15
    +
    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.

    -

    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.

    -
    +

    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
    -

    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
    -

    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
    -

    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

    +

    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
    -

    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.

    +

    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.

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

    +

    LimitRequestBody only applies to + request bodies that the server will spool to disk

    -
      -
    • 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.
      • +
    top
    +
    +

    Reverse Proxy Request Headers

    -
  • If set to On, each request and reply will get a - Via: header line added for the current host.
    • +

    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 Full, each generated Via: header - line will additionally have the Apache httpd server version shown as a - Via: comment field.
    • +
    +
    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.
    +
    -
  • If set to Block, every proxy request will have all its - Via: header lines removed. No new Via: header will - be generated.
    • - +

    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 32e106b0b7..d9a0793212 100644 --- a/docs/manual/mod/mod_proxy.html.fr +++ b/docs/manual/mod/mod_proxy.html.fr @@ -155,383 +155,6 @@

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

    - -

    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.

    - -

    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.

    - -

    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.

    - -

    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.

    - -

    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

    - -

    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.

    - -

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

    Mandataire direct

    ProxyRequests On
-ProxyVia On
-
-<Proxy *>
-  Require host internal.example.com
-</Proxy>
    -
    -
    top
    -
    -

    Accès via un gestionnaire

    - -

    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 : -

    - -

    Scripts PHP et mandataire inverse

    <FilesMatch \.php$>
-    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.

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

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

    ou encore via les directives Proxy et ProxySet :

    - - 
    <Proxy http://backend.example.com>
-  ProxySet connectiontimeout=5 timeout=30
-</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.

    - -

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

    Dans cet exemple, deux workers différents sont définis, chacun - d'eux utilisant des configurations et jeux de connexions - séparés.

    - -

    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,

    - - 
    ProxyPass /apps http://backend.example.com/ timeout=60
-ProxyPass /examples http://backend.example.com/examples timeout=10
    - - -

    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 !

    - -

    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.

    - -
    - -

    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.

    - -

    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.

    - -

    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.

    - -
    -
    top

    Directive BalancerGrowth

    - - - + + + + + + + + + +
    Description:Nombre de membres supplémentaires pouvant être ajoutés @@ -1548,679 +1171,1056 @@ ProxyPass /mirror/foo http://backend.example.com Disponible depuis la version 2.4.5 du serveur HTTP Apache.
    nonce<auto>Le nombre à usage unique de protection utilisé dans la page - de l'application balancer-manager. Par défaut, la - protection de la page est assurée par un nombre à usage unique - automatique à base d'UUID. Si une valeur est précisée, elle sera - utilisée comme nombre à usage unique. La valeur - None désactive la vérification du nombre à usage - unique. +
    nonce<auto>Le nombre à usage unique de protection utilisé dans la page + de l'application balancer-manager. Par défaut, la + protection de la page est assurée par un nombre à usage unique + automatique à base d'UUID. Si une valeur est précisée, elle sera + utilisée comme nombre à usage unique. La valeur + None désactive la vérification du nombre à usage + unique. +

    Note

    +

    En plus du nombre à usage unique, la page de l'application + balancer-manager peut être protégée par une ACL.

    +
    +
    growth0Nombre de membres supplémentaires que l'on peut ajouter à ce + répartiteur en plus de ceux définis au niveau de la + configuration. +
    forcerecoveryOnForce la relance immédiate de tous les membres sans tenir + compte de leur paramètre retry dans le cas où ils sont tous en + état d'erreur. Il peut cependant arriver qu'un membre déjà + surchargé entre dans une situation critique si la relance de + tous les membres est forcée sans tenir compte du paramètre retry + de chaque membre. Dans ce cas, définissez ce paramètre à + Off.
    + 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>
    + + +

    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
    +

    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

    -

    En plus du nombre à usage unique, la page de l'application - balancer-manager peut être protégée par une ACL.

    +

    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
    +
    - - growth - 0 - Nombre de membres supplémentaires que l'on peut ajouter à ce - répartiteur en plus de ceux définis au niveau de la - configuration. - - forcerecovery - On - Force la relance immédiate de tous les membres sans tenir - compte de leur paramètre retry dans le cas où ils sont tous en - état d'erreur. Il peut cependant arriver qu'un membre déjà - surchargé entre dans une situation critique si la relance de - tous les membres est forcée sans tenir compte du paramètre retry - de chaque membre. Dans ce cas, définissez ce paramètre à - Off.
    - 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>
    +

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

    -

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

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

    +
    -

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

    +
    -

    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.

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

    -

    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.

    +

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

    -

    Cette directive ne peut pas être placée dans une section - <Directory> ou - <Files>.

    +

    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.

    -

    Si vous avez besoin d'un configuration de mandataire inverse plus - souple, reportez-vous à la documentaion de la directive RewriteRule et son drapeau - [P].

    +

    Supposons par exemple que le serveur local a pour adresse + http://example.com/ ; alors

    -

    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 :

    + 
    ProxyPass         /mirror/foo/ http://backend.example.com/
+ProxyPassReverse  /mirror/foo/ http://backend.example.com/
+ProxyPassReverseCookieDomain  backend.example.com  public.example.com
+ProxyPassReverseCookiePath  /  /mirror/foo/
    - 
    RewriteEngine On
 
-RewriteCond %{HTTPS} =off
-RewriteRule . - [E=protocol:http]
-RewriteCond %{HTTPS} =on
-RewriteRule . - [E=protocol:https]
+    
    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.
    
 
-RewriteRule ^/mirror/foo/(.*) %{ENV:protocol}://backend.example.com/$1 [P]
-ProxyPassReverse  /mirror/foo/ http://backend.example.com/
-ProxyPassReverse  /mirror/foo/ https://backend.example.com/
    +

    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, + utilisé 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 ProxyPassInherit

    +

    Directive ProxyPreserveHost

    - - - - + + + + - +
    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
    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é:Disponible à partir de la version 2.4.5 du serveur -HTTP Apache.
    Compatibilité:Utilisable +dans un contexte de répertoire depuis la version 2.3.3.
    -

    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.

    - +

    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 ProxyPassInterpolateEnv

    +

    Directive ProxyReceiveBufferSize

    - - - - + + + +
    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: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
    -

    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.

    +

    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 ProxyPassMatch

    +

    Directive ProxyRemote

    - - - + + +
    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: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 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

    +

    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 :

    - 
    ProxyPassMatch ^(/.*\.gif)$ http://backend.example.com/$1
    +

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

    -

    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.

    +

    Exemple

    ProxyRemote http://goodguys.example.com/ http://mirrorguys.example.com:8000
+ProxyRemote * http://cleverproxy.localdomain
+ProxyRemote ftp http://ftpproxy.mydomain:8080
    +
    -

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

    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.

    -

    Le drapeau ! vous permet de ne pas mandater un - sous-répertoire donné.

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

    -

    Dans une section <LocationMatch>, le premier argument est - omis et l'expression rationnelle est obtenue à partir de la directive - <LocationMatch>.

    +

    Pour une configuration typique de mandataire inverse ou + passerelle, cette directive doit être définie à + Off.

    -

    Si vous avez besoin d'une configuration du mandataire inverse - plus flexible, voyez la directive RewriteRule avec le drapeau - [P].

    +

    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.

    -
    -

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

    -
    +

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

    +

    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.

    +

    Voir aussi

    +
    top
    -

    Directive ProxyPassReverse

    +

    Directive ProxySet

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

    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.

    +

    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.

    + + 
    <Proxy balancer://hotcluster>
+    BalancerMember http://www2.example.com:8080 loadfactor=1
+    BalancerMember http://www3.example.com:8080 loadfactor=2
+    ProxySet lbmethod=bytraffic
+</Proxy>
    +
    -

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

    + 
    <Proxy http://backend>
+    ProxySet keepalive=On
+</Proxy>
    -

    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

    + 
    ProxySet balancer://foo lbmethod=bytraffic timeout=15
    - 
    ProxyPass         /mirror/foo/ http://backend.example.com/
-ProxyPassReverse  /mirror/foo/ http://backend.example.com/
-ProxyPassReverseCookieDomain  backend.example.com  public.example.com
-ProxyPassReverseCookiePath  /  /mirror/foo/
    + 
    ProxySet ajp://backend:7001 timeout=15
    -

    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.

    +

    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.

    +
    -

    Le mot-clé optionnel interpolate, - utilisé 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.

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

    -

    Cette directive ne peut pas être placée dans une section - <Directory> ou - <Files>.

    top
    -

    Directive ProxyPassReverseCookieDomain

    +

    Directive ProxyStatus

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

    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.

    +

    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 ProxyPassReverseCookiePath

    +

    Directive ProxyTimeout

    - - - + + + +
    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
    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 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/
    +

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

    + +
      +
    • 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.
      • + +
    • 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.
      • + +
    • 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é.
      • +
    + +
    +
    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).

    + +

    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.

    + +

    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.

    + +

    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.

    + +

    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.

    + +

    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

    + +

    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.

    + +

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

    Mandataire direct

    ProxyRequests On
+ProxyVia On
+
+<Proxy *>
+  Require host internal.example.com
+</Proxy>
    +
    +
    top
    +
    +

    Accès via un gestionnaire

    -

    -va réécrire un cookie possédant un chemin d'arrière-plan / -(ou /example ou en fait tout chemin) -en /mirror/foo/.. -

    +

    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 : +

    +

    Scripts PHP et mandataire inverse

    <FilesMatch \.php$>
+    SetHandler  "proxy:unix:/path/to/app.sock|fcgi://localhost/"
+</FilesMatch>
    -
    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.

    +

    Cette fonctionnalité est disponible à partir de la version + 2.4.10 du serveur HTTP Apache.

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

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

    -

    Exemple

    ProxyReceiveBufferSize 2048
    +

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

    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 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] -

    +

    ou encore via les directives Proxy et ProxySet :

    -

    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.

    + 
    <Proxy http://backend.example.com>
+  ProxySet connectiontimeout=5 timeout=30
+</Proxy>
    -

    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.

    +

    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.

    -

    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.

    +

    L'URL qui identifie un worker correspond à l'URL de son serveur + original, y compris un éventuel chemin donné :

    -
    -
    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 /examples http://backend.example.com/examples
+ProxyPass /docs http://backend.example.com/docs
    -
    -
    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.

    +

    Dans cet exemple, deux workers différents sont définis, chacun + d'eux utilisant des configurations et jeux de connexions + séparés.

    -

    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.

    +

    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,

    -

    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.

    + 
    ProxyPass /apps http://backend.example.com/ timeout=60
+ProxyPass /examples http://backend.example.com/examples timeout=10
    -

    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.

    -
    -

    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
    -

    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 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 !

    + +

    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.

    + +
    + +

    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.

    + +

    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.

    - 
    <Proxy balancer://hotcluster>
-    BalancerMember http://www2.example.com:8080 loadfactor=1
-    BalancerMember http://www3.example.com:8080 loadfactor=2
-    ProxySet lbmethod=bytraffic
-</Proxy>
    -
    +

    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 http://backend>
-    ProxySet keepalive=On
+      
    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>
    - 
    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
    -

    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 64edc36708..a286172efc 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 ce2196eed4..5b27d78030 100644 --- a/docs/manual/mod/mod_proxy_connect.html.en +++ b/docs/manual/mod/mod_proxy_connect.html.en @@ -65,31 +65,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.
    -
    - -

    CONNECT method requests are controlled by the - Proxy block - as any other HTTP request going through. - SSL connections through a proxy may be filtered explicitely - by specifying the target host and port, for instance: -

    - - 
    <Proxy www.example.com:443>
-  Require ip 192.168.0.0/16
-</Proxy>
    - -
    -
    top

    AllowCONNECT Directive

    説明:Number of additional Balancers that can be added Post-configuration
    AllowCONNECT directive to override this default and 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.
    +
    + +

    CONNECT method requests are controlled by the + Proxy block + as any other HTTP request going through. + SSL connections through a proxy may be filtered explicitely + by specifying the target host and port, for instance: +

    + + 
    <Proxy www.example.com:443>
+  Require ip 192.168.0.0/16
+</Proxy>
    +
    diff --git a/docs/manual/mod/mod_proxy_connect.html.ja.utf8 b/docs/manual/mod/mod_proxy_connect.html.ja.utf8 index fd4eb79487..9253bcd376 100644 --- a/docs/manual/mod/mod_proxy_connect.html.ja.utf8 +++ b/docs/manual/mod/mod_proxy_connect.html.ja.utf8 @@ -61,7 +61,6 @@
    -
    top

    AllowCONNECT ディレクティブ

    Description:Ports that are allowed to CONNECT through the @@ -113,6 +88,31 @@ Port ranges available since Apache 2.3.7.
    @@ -88,6 +87,7 @@ AllowCONNECT ディレクティブを使用します。

    +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_proxy_express.html.en b/docs/manual/mod/mod_proxy_express.html.en index 61f4c99528..31d8c8180b 100644 --- a/docs/manual/mod/mod_proxy_express.html.en +++ b/docs/manual/mod/mod_proxy_express.html.en @@ -86,7 +86,6 @@

    -
    top

    ProxyExpressDBMFile Directive

    @@ -170,6 +169,7 @@ controls whether the module will be active.

    +

    Available Languages:  en 

    diff --git a/docs/manual/mod/mod_proxy_ftp.html.en b/docs/manual/mod/mod_proxy_ftp.html.en index 87a4bdf7c1..469271cb1e 100644 --- a/docs/manual/mod/mod_proxy_ftp.html.en +++ b/docs/manual/mod/mod_proxy_ftp.html.en @@ -71,6 +71,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: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?

    @@ -174,63 +231,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: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_html.html.en b/docs/manual/mod/mod_proxy_html.html.en index ec67a3fdaa..58de023d11 100644 --- a/docs/manual/mod/mod_proxy_html.html.en +++ b/docs/manual/mod/mod_proxy_html.html.en @@ -70,7 +70,6 @@ extensive documentation
  • ProxyHTMLURLMap
    • -
    top

    ProxyHTMLBufSize Directive

    @@ -428,6 +427,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_scgi.html.en b/docs/manual/mod/mod_proxy_scgi.html.en index 1f9606a498..908a66d510 100644 --- a/docs/manual/mod/mod_proxy_scgi.html.en +++ b/docs/manual/mod/mod_proxy_scgi.html.en @@ -61,48 +61,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

    Description:Enable or disable internal redirect responses from the @@ -169,6 +127,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_wstunnel.html.en b/docs/manual/mod/mod_proxy_wstunnel.html.en index dee214b41b..e7046becdb 100644 --- a/docs/manual/mod/mod_proxy_wstunnel.html.en +++ b/docs/manual/mod/mod_proxy_wstunnel.html.en @@ -58,7 +58,6 @@ ProxyPass /wss2/ wss://echo.websocket.org/
    -
    top

    ProxyWebsocketAsync Directive

    @@ -107,6 +106,7 @@ ProxyPass /wss2/ wss://echo.websocket.org/ left open while idle.

    +

    Available Languages:  en 

    diff --git a/docs/manual/mod/mod_reflector.html.en b/docs/manual/mod/mod_reflector.html.en index f78c6cf0f9..4f8afd501a 100644 --- a/docs/manual/mod/mod_reflector.html.en +++ b/docs/manual/mod/mod_reflector.html.en @@ -48,6 +48,22 @@
  • Examples
    • 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.

    + +
    +
    top

    Examples

    @@ -73,22 +89,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_remoteip.html.en b/docs/manual/mod/mod_remoteip.html.en index a574499c20..59452d7343 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 bb1195a47b..43733ea36f 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
    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 eaf2a4a7fa..175e930760 100644 --- a/docs/manual/mod/mod_reqtimeout.html.en +++ b/docs/manual/mod/mod_reqtimeout.html.en @@ -41,51 +41,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_request.html.en b/docs/manual/mod/mod_request.html.en index aefca066d3..f110f6ca30 100644 --- a/docs/manual/mod/mod_request.html.en +++ b/docs/manual/mod/mod_request.html.en @@ -38,7 +38,6 @@
  • KeptBodySize
    • -
    top

    KeptBodySize Directive

    Description:Set timeout values for receiving request headers and body from client. @@ -167,6 +122,51 @@ version 2.3.14 and earlier.
    @@ -95,6 +94,7 @@ mod_include.
  • mod_auth_form documentation
    • +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_request.html.tr.utf8 b/docs/manual/mod/mod_request.html.tr.utf8 index f2609c10c9..cf87798bbc 100644 --- a/docs/manual/mod/mod_request.html.tr.utf8 +++ b/docs/manual/mod/mod_request.html.tr.utf8 @@ -38,7 +38,6 @@

  • KeptBodySize
    • -
    top

    KeptBodySize Yönergesi

    @@ -95,6 +94,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 a4874c32ec..f2f5827c3b 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

    @@ -1464,6 +1428,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 3726acf1ba..070cda7066 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 @@ -1584,6 +1544,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 a71cf27b86..7c8862f07b 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 069dd60c88..56904913d2 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 3dc426c725..46fccc515c 100644 --- a/docs/manual/mod/mod_session.html.en +++ b/docs/manual/mod/mod_session.html.en @@ -87,6 +87,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 @@ -342,144 +480,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_cookie.html.en b/docs/manual/mod/mod_session_cookie.html.en index 9654c34982..6c034056f2 100644 --- a/docs/manual/mod/mod_session_cookie.html.en +++ b/docs/manual/mod/mod_session_cookie.html.en @@ -73,25 +73,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

    @@ -163,6 +144,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_crypto.html.en b/docs/manual/mod/mod_session_crypto.html.en index 04ea1897a0..7f3148f633 100644 --- a/docs/manual/mod/mod_session_crypto.html.en +++ b/docs/manual/mod/mod_session_crypto.html.en @@ -70,29 +70,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

    Description:Name and attributes for the RFC2109 cookie storing the session
    @@ -231,6 +208,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_dbd.html.en b/docs/manual/mod/mod_session_dbd.html.en index 8c2600b400..1414f28861 100644 --- a/docs/manual/mod/mod_session_dbd.html.en +++ b/docs/manual/mod/mod_session_dbd.html.en @@ -85,86 +85,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:The crypto cipher to be used to encrypt the session
    @@ -323,6 +243,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_setenvif.html.en b/docs/manual/mod/mod_setenvif.html.en index 4599961c42..dcf734470c 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

    Description:Name and attributes for the RFC2109 cookie storing the session ID
    @@ -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 eee87a30c8..a32d30e938 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 c6103ca8b8..42b4c82967 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 3d249bcf6f..502c563b34 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 3ab30031c1..be9c4c4dff 100644 --- a/docs/manual/mod/mod_setenvif.html.tr.utf8 +++ b/docs/manual/mod/mod_setenvif.html.tr.utf8 @@ -67,7 +67,6 @@

    -
    top

    BrowserMatch Yönergesi

    @@ -310,6 +309,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 fe3c846579..1fd937166e 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 459d32f6e4..746ace307f 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 ca5bb91adf..72e2d51193 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 55a1d87950..86af5ae659 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 5a1762a965..04f1c42ed0 100644 --- a/docs/manual/mod/mod_so.html.tr.utf8 +++ b/docs/manual/mod/mod_so.html.tr.utf8 @@ -65,6 +65,57 @@ yeniden başlatılması sırasında yüklenmesini sağlar.
  • Yüklenebilir Modüllerin Windows için Oluşturulması
    • top
    +

    LoadFile Yönergesi

    + + + + + + +
    Açıklama:Belirtilen nesne dosyasını veya kütüphaneyi sunucu ile ilintiler. +
    Sözdizimi:LoadFile dosya-ismi [dosya-ismi] ...
    Bağlam:sunucu geneli
    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
    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ı

    @@ -139,57 +190,6 @@ yeniden başlatılması sırasında yüklenmesini sağlar. sonra LoadModule yönergesi ile sunucunuza yükleyebilirsiniz.

    -
    -
    top
    -

    LoadFile Yönergesi

    - - - - - - -
    Açıklama:Belirtilen nesne dosyasını veya kütüphaneyi sunucu ile ilintiler. -
    Sözdizimi:LoadFile dosya-ismi [dosya-ismi] ...
    Bağlam:sunucu geneli
    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
    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 360e2c5848..85cb9f015b 100644 --- a/docs/manual/mod/mod_speling.html.en +++ b/docs/manual/mod/mod_speling.html.en @@ -72,7 +72,6 @@ misspellings.
  • CheckSpelling
    • -
    top

    CheckBasenameMatch Directive

    @@ -152,6 +151,7 @@ module

    +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_speling.html.ja.utf8 b/docs/manual/mod/mod_speling.html.ja.utf8 index 67d77e5496..75f344fdca 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

    CheckBasenameMatch ディレクティブ

    @@ -157,6 +156,7 @@ This can be particulary useful in conjunction with 期待とは違う挙動になるからです。

    +

    翻訳済み言語:  en  | diff --git a/docs/manual/mod/mod_speling.html.ko.euc-kr b/docs/manual/mod/mod_speling.html.ko.euc-kr index a2f0b58f2f..a8f4b39877 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

    CheckBasenameMatch Áö½Ã¾î

    @@ -140,6 +139,7 @@ This can be particulary useful in conjunction with

    +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_ssl.html.en b/docs/manual/mod/mod_ssl.html.en index c4e11e9611..5707363a6c 100644 --- a/docs/manual/mod/mod_ssl.html.en +++ b/docs/manual/mod/mod_ssl.html.en @@ -121,205 +121,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_SAN_Email_n string Client certificate's subjectAltName extension entries of type rfc822Name
    SSL_CLIENT_SAN_DNS_n string Client certificate's subjectAltName extension entries of type dNSName
    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_SAN_Email_n string Server certificate's subjectAltName extension entries of type rfc822Name
    SSL_SERVER_SAN_DNS_n string Server certificate's subjectAltName extension entries of type dNSName
    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 +2360,205 @@ 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_SAN_Email_n string Client certificate's subjectAltName extension entries of type rfc822Name
    SSL_CLIENT_SAN_DNS_n string Client certificate's subjectAltName extension entries of type dNSName
    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_SAN_Email_n string Server certificate's subjectAltName extension entries of type rfc822Name
    SSL_SERVER_SAN_DNS_n string Server certificate's subjectAltName extension entries of type dNSName
    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_ct.html.en b/docs/manual/mod/mod_ssl_ct.html.en index daacf53510..c14947dc04 100644 --- a/docs/manual/mod/mod_ssl_ct.html.en +++ b/docs/manual/mod/mod_ssl_ct.html.en @@ -115,186 +115,6 @@ testing.

  • Off-line audit for proxy
    • top
    -
    -

    Server processing overview

    - - -

    Servers need to send SCTs to their clients. SCTs in a certificate - extension or stapled OCSP response will be sent without any special program - logic. This module handles sending SCTs configured by the administrator or - received from configured logs.

    - -

    The number of SCTs sent in the ServerHello (i.e., not including those in a - certificate extension or stapled OCSP response) can be limited by the - CTServerHelloSCTLimit - directive.

    - -

    For each server certificate, a daemon process maintains an SCT list to be - sent in the ServerHello, created from statically configured SCTs as well as - those received from logs. Logs marked as untrusted or with a maximum valid - timestamp before the present time will be ignored. Periodically the daemon - will submit certificates to a log as necessary (due to changed log - configuration or age) and rebuild the concatenation of SCTs.

    - -

    The SCT list for a server certificate will be sent to any client that - indicates awareness in the ClientHello when that particular server certificate - is used.

    - -
    top
    -
    -

    Proxy processing overview

    - - -

    The proxy indicates Certificate Transparency awareness in the ClientHello - by including the signed_certificate_timestamp extension. It can - recognize SCTs received in the ServerHello, in an extension in the certificate - for an origin server, or in a stapled OCSP response.

    - -

    On-line verification is attempted for each received SCT:

    - -
      -
    • For any SCT, the timestamp can be checked to see if it is not yet valid - based on the current time as well as any configured valid time interval for - the log.
      • -
    • For an SCT from a log for which a public key is configured, the server - signature will be checked.
      • -
    - -

    If verification fails for at least one SCT and verification was not - successful for at least one SCT, the connection is aborted if - CTProxyAwareness is set to - require.

    - -

    Additionally, the server certificate chain and SCTs are stored for off-line - verification if the CTAuditStorage - directive is configured.

    - -

    As an optimization, on-line verification and storing of data from the - server is only performed the first time a web server child process receives - the data. This saves some processing time as well as disk space. For typical - reverse proxy setups, very little processing overhead will be required.

    - -
    top
    -
    -

    Log configuration

    - - -

    Servers and proxies use different information about logs for their processing. - This log configuration can be set in two ways:

    - -
      -
    • Create a log configuration database using ctlogconfig, - and configure the path to that database using the - CTLogConfig directive. This method of configuration supports - dynamic updates; mod_ssl_ct will re-read the database at - intervals. Additionally, the off-line audit program ctauditscts - can use this configuration to find the URL of logs.
      • - -
    • Configure information about logs statically using the CTStaticLogConfig directive. As with all other - directives, the server must be restarted in order to pick up changes to the - directives.
      • -
    - -

    The information that can be configured about a log using either mechanism is - described below:

    - -
    -
    log id
    -
    The log id is the SHA-256 hash of the log's public key, and is part of - every SCT. This is a convenient way to identify a particular log when - configuring valid timestamp ranges or certain other information.
    - -
    public key of the log
    -
    A proxy must have the public key of the log in order to check the - signature in SCTs it receives which were obtained from the log. -
    - A server must have the public key of the log in order to submit certificates - to it.
    - -
    general trust/distrust setting
    -
    This is a mechanism to distrust or restore trust in a particular log, - for whatever reason (including simply avoiding interaction with the - log in situations where it is off-line).
    - -
    minimum and/or maximum valid timestamps
    -
    When configured, the proxy will check that timestamps from SCTs - are within the valid range.
    - -
    log URL
    -
    The URL of the log (for its API) is required by a server in order to - submit server certificates to the log. The server will submit - each server certificate in order to obtain an SCT for each log with a - configured URL, except when the log is also marked as distrusted or the - current time is not within any configured valid timestamp range. -
    - The log URL is also needed by off-line auditing of SCTs received by a - proxy.
    -
    - -

    Generally, only a small subset of this information is configured for a - particular log. Refer to the documentation for the CTStaticLogConfig directive and the - ctlogconfig command for more specific information.

    - -
    top
    -
    -

    Storing SCTs in a form consumable by mod_ssl_ct

    - - -

    mod_ssl_ct allows you to configure SCTs statically - using the CTStaticSCTs directive. These must be - in binary form, ready to send to a client.

    - -

    Sample code in the form of a Python script to build an SCT in the correct - format from data received from a log can be found in - Tom Ritter's ct-tools - repository. Refer to write-sct.py

    -
    top
    -
    -

    Logging CT status in the access log

    - - -

    Proxy and server modes set the SSL_CT_PROXY_STATUS and - SSL_CT_CLIENT_STATUS variables, respectively, to indicate - if the corresponding peer is CT-aware.

    - -

    Proxy mode sets the SSL_CT_PROXY_SCT_SOURCES variable to - indicate whether and where SCTs were obtained (ServerHello, certificate - extension, etc.).

    - -

    These variables can be logged with the %{varname}e - format of mod_log_config.

    -
    top
    -
    -

    Off-line audit for proxy

    - - -

    Experimental support for this is implemented in the ctauditscts - command, which itself relies on the verify_single_proof.py tool in the - certificate-transparency open source project. ctauditscts - can parse data for off-line audit (enabled with the - CTAuditStorage directive) and invoke verify_single_proof.py. -

    - -

    Here are rough notes for using ctauditscts:

    - -
      -
    • Create a virtualenv using the requirements.txt file - from the certificate-transparency project and run the following steps - with that virtualenv activated.
      • -
    • Set PYTHONPATH to include the python - directory within the certificate-transparency tools.
      • -
    • Set PATH to include the python/ct/client/tools - directory.
      • -
    • Run ctauditscts, passing the value of the - CTAuditStorage directive and, optionally, the path to - the log configuration database. The latter will be used to look up log URLs - by log id.
      • -
    - -

    The data saved for audit can also be used by other programs; refer to the - ctauditscts source code for details on processing the data.

    -
    -
    top

    CTAuditStorage Directive

    @@ -559,6 +379,186 @@ about the fields which can be configured with this directive. file extension .sct

    +
    top
    +
    +

    Server processing overview

    + + +

    Servers need to send SCTs to their clients. SCTs in a certificate + extension or stapled OCSP response will be sent without any special program + logic. This module handles sending SCTs configured by the administrator or + received from configured logs.

    + +

    The number of SCTs sent in the ServerHello (i.e., not including those in a + certificate extension or stapled OCSP response) can be limited by the + CTServerHelloSCTLimit + directive.

    + +

    For each server certificate, a daemon process maintains an SCT list to be + sent in the ServerHello, created from statically configured SCTs as well as + those received from logs. Logs marked as untrusted or with a maximum valid + timestamp before the present time will be ignored. Periodically the daemon + will submit certificates to a log as necessary (due to changed log + configuration or age) and rebuild the concatenation of SCTs.

    + +

    The SCT list for a server certificate will be sent to any client that + indicates awareness in the ClientHello when that particular server certificate + is used.

    + +
    top
    +
    +

    Proxy processing overview

    + + +

    The proxy indicates Certificate Transparency awareness in the ClientHello + by including the signed_certificate_timestamp extension. It can + recognize SCTs received in the ServerHello, in an extension in the certificate + for an origin server, or in a stapled OCSP response.

    + +

    On-line verification is attempted for each received SCT:

    + +
      +
    • For any SCT, the timestamp can be checked to see if it is not yet valid + based on the current time as well as any configured valid time interval for + the log.
      • +
    • For an SCT from a log for which a public key is configured, the server + signature will be checked.
      • +
    + +

    If verification fails for at least one SCT and verification was not + successful for at least one SCT, the connection is aborted if + CTProxyAwareness is set to + require.

    + +

    Additionally, the server certificate chain and SCTs are stored for off-line + verification if the CTAuditStorage + directive is configured.

    + +

    As an optimization, on-line verification and storing of data from the + server is only performed the first time a web server child process receives + the data. This saves some processing time as well as disk space. For typical + reverse proxy setups, very little processing overhead will be required.

    + +
    top
    +
    +

    Log configuration

    + + +

    Servers and proxies use different information about logs for their processing. + This log configuration can be set in two ways:

    + +
      +
    • Create a log configuration database using ctlogconfig, + and configure the path to that database using the + CTLogConfig directive. This method of configuration supports + dynamic updates; mod_ssl_ct will re-read the database at + intervals. Additionally, the off-line audit program ctauditscts + can use this configuration to find the URL of logs.
      • + +
    • Configure information about logs statically using the CTStaticLogConfig directive. As with all other + directives, the server must be restarted in order to pick up changes to the + directives.
      • +
    + +

    The information that can be configured about a log using either mechanism is + described below:

    + +
    +
    log id
    +
    The log id is the SHA-256 hash of the log's public key, and is part of + every SCT. This is a convenient way to identify a particular log when + configuring valid timestamp ranges or certain other information.
    + +
    public key of the log
    +
    A proxy must have the public key of the log in order to check the + signature in SCTs it receives which were obtained from the log. +
    + A server must have the public key of the log in order to submit certificates + to it.
    + +
    general trust/distrust setting
    +
    This is a mechanism to distrust or restore trust in a particular log, + for whatever reason (including simply avoiding interaction with the + log in situations where it is off-line).
    + +
    minimum and/or maximum valid timestamps
    +
    When configured, the proxy will check that timestamps from SCTs + are within the valid range.
    + +
    log URL
    +
    The URL of the log (for its API) is required by a server in order to + submit server certificates to the log. The server will submit + each server certificate in order to obtain an SCT for each log with a + configured URL, except when the log is also marked as distrusted or the + current time is not within any configured valid timestamp range. +
    + The log URL is also needed by off-line auditing of SCTs received by a + proxy.
    +
    + +

    Generally, only a small subset of this information is configured for a + particular log. Refer to the documentation for the CTStaticLogConfig directive and the + ctlogconfig command for more specific information.

    + +
    top
    +
    +

    Storing SCTs in a form consumable by mod_ssl_ct

    + + +

    mod_ssl_ct allows you to configure SCTs statically + using the CTStaticSCTs directive. These must be + in binary form, ready to send to a client.

    + +

    Sample code in the form of a Python script to build an SCT in the correct + format from data received from a log can be found in + Tom Ritter's ct-tools + repository. Refer to write-sct.py

    +
    top
    +
    +

    Logging CT status in the access log

    + + +

    Proxy and server modes set the SSL_CT_PROXY_STATUS and + SSL_CT_CLIENT_STATUS variables, respectively, to indicate + if the corresponding peer is CT-aware.

    + +

    Proxy mode sets the SSL_CT_PROXY_SCT_SOURCES variable to + indicate whether and where SCTs were obtained (ServerHello, certificate + extension, etc.).

    + +

    These variables can be logged with the %{varname}e + format of mod_log_config.

    +
    top
    +
    +

    Off-line audit for proxy

    + + +

    Experimental support for this is implemented in the ctauditscts + command, which itself relies on the verify_single_proof.py tool in the + certificate-transparency open source project. ctauditscts + can parse data for off-line audit (enabled with the + CTAuditStorage directive) and invoke verify_single_proof.py. +

    + +

    Here are rough notes for using ctauditscts:

    + +
      +
    • Create a virtualenv using the requirements.txt file + from the certificate-transparency project and run the following steps + with that virtualenv activated.
      • +
    • Set PYTHONPATH to include the python + directory within the certificate-transparency tools.
      • +
    • Set PATH to include the python/ct/client/tools + directory.
      • +
    • Run ctauditscts, passing the value of the + CTAuditStorage directive and, optionally, the path to + the log configuration database. The latter will be used to look up log URLs + by log id.
      • +
    + +

    The data saved for audit can also be used by other programs; refer to the + ctauditscts source code for details on processing the data.

    +

    Available Languages:  en 

    diff --git a/docs/manual/mod/mod_substitute.html.en b/docs/manual/mod/mod_substitute.html.en index b27444190e..f013f4cba0 100644 --- a/docs/manual/mod/mod_substitute.html.en +++ b/docs/manual/mod/mod_substitute.html.en @@ -42,7 +42,6 @@
  • SubstituteMaxLineLength
    • -
    top

    Substitute Directive

    Description:Existing directory where data for off-line audit will be stored
    @@ -156,6 +155,7 @@ Substitute "s|http://internal.blog.example.com/|http://www.example.com/blog/|i"< +

    Available Languages:  en 

    diff --git a/docs/manual/mod/mod_suexec.html.en b/docs/manual/mod/mod_suexec.html.en index 403b895983..bf5fc495ad 100644 --- a/docs/manual/mod/mod_suexec.html.en +++ b/docs/manual/mod/mod_suexec.html.en @@ -47,7 +47,6 @@ and Group
    -
    top

    SuexecUserGroup Directive

    @@ -72,6 +71,7 @@ and Group
  • Suexec
    • +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_suexec.html.ja.utf8 b/docs/manual/mod/mod_suexec.html.ja.utf8 index bae6cbce18..f6189612ea 100644 --- a/docs/manual/mod/mod_suexec.html.ja.utf8 +++ b/docs/manual/mod/mod_suexec.html.ja.utf8 @@ -52,7 +52,6 @@

    -
    top

    SuexecUserGroup ディレクティブ

    @@ -76,6 +75,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 432a51b17d..a760f2b165 100644 --- a/docs/manual/mod/mod_suexec.html.ko.euc-kr +++ b/docs/manual/mod/mod_suexec.html.ko.euc-kr @@ -50,7 +50,6 @@

    -
    top

    SuexecUserGroup Áö½Ã¾î

    @@ -74,6 +73,7 @@ +

    °¡´ÉÇÑ ¾ð¾î:  en  | diff --git a/docs/manual/mod/mod_suexec.html.tr.utf8 b/docs/manual/mod/mod_suexec.html.tr.utf8 index 848ba4883a..f1b5f2e82f 100644 --- a/docs/manual/mod/mod_suexec.html.tr.utf8 +++ b/docs/manual/mod/mod_suexec.html.tr.utf8 @@ -50,7 +50,6 @@

    -
    top

    SuexecUserGroup Yönergesi

    @@ -81,6 +80,7 @@
  • Suexec
    • +

    Mevcut Diller:  en  | diff --git a/docs/manual/mod/mod_systemd.html.en b/docs/manual/mod/mod_systemd.html.en index 42221b5a7e..d686e1228d 100644 --- a/docs/manual/mod/mod_systemd.html.en +++ b/docs/manual/mod/mod_systemd.html.en @@ -44,7 +44,6 @@

  • IdleShutdown
    • -
    top

    IdleShutdown Directive

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

    +

    Available Languages:  en 

    diff --git a/docs/manual/mod/mod_unixd.html.en b/docs/manual/mod/mod_unixd.html.en index a30f927477..0cc4a63099 100644 --- a/docs/manual/mod/mod_unixd.html.en +++ b/docs/manual/mod/mod_unixd.html.en @@ -43,7 +43,6 @@
    -
    top

    ChrootDir Directive

    @@ -175,6 +174,7 @@ requests
  • SuexecUserGroup
    • +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_unixd.html.tr.utf8 b/docs/manual/mod/mod_unixd.html.tr.utf8 index 7cd29665f8..6381c46dbd 100644 --- a/docs/manual/mod/mod_unixd.html.tr.utf8 +++ b/docs/manual/mod/mod_unixd.html.tr.utf8 @@ -42,7 +42,6 @@

    -
    top

    ChrootDir Yönergesi

    @@ -184,6 +183,7 @@
  • SuexecUserGroup
    • +

    Mevcut Diller:  en  | diff --git a/docs/manual/mod/mod_userdir.html.en b/docs/manual/mod/mod_userdir.html.en index bf4b02c5c3..9d28b98df0 100644 --- a/docs/manual/mod/mod_userdir.html.en +++ b/docs/manual/mod/mod_userdir.html.en @@ -49,7 +49,6 @@ Filesystem

  • public_html tutorial
    • -
    top

    UserDir Directive

    @@ -178,6 +177,7 @@ UserDir enabled user1 user2 user3 +

    Available Languages:  en  | diff --git a/docs/manual/mod/mod_userdir.html.ja.utf8 b/docs/manual/mod/mod_userdir.html.ja.utf8 index 17253db08e..a38b887061 100644 --- a/docs/manual/mod/mod_userdir.html.ja.utf8 +++ b/docs/manual/mod/mod_userdir.html.ja.utf8 @@ -55,7 +55,6 @@

  • public_html チュートリアル
    • -
    top

    UserDir ディレクティブ

    @@ -182,6 +181,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 6dbd9d3046..9aaaeada67 100644 --- a/docs/manual/mod/mod_userdir.html.ko.euc-kr +++ b/docs/manual/mod/mod_userdir.html.ko.euc-kr @@ -50,7 +50,6 @@

  • public_html ÅõÅ丮¾ó
    • -
    top

    UserDir Áö½Ã¾î

    @@ -154,6 +153,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 a3f21daa77..a8496e35db 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

    @@ -179,6 +178,7 @@ +

    Mevcut Diller:  en  | diff --git a/docs/manual/mod/mod_usertrack.html.en b/docs/manual/mod/mod_usertrack.html.en index de51874b42..60f618730a 100644 --- a/docs/manual/mod/mod_usertrack.html.en +++ b/docs/manual/mod/mod_usertrack.html.en @@ -50,19 +50,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

    @@ -206,6 +193,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_version.html.en b/docs/manual/mod/mod_version.html.en index eb7321be8f..1c1c038a57 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:The domain to which the tracking cookie applies
    @@ -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 e2137c8114..a44d3cfe7f 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 374d566c81..6a8d94ef12 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 b0711735dd..d7247ed2df 100644 --- a/docs/manual/mod/mod_vhost_alias.html.en +++ b/docs/manual/mod/mod_vhost_alias.html.en @@ -71,6 +71,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

    @@ -235,96 +325,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.tr.utf8 b/docs/manual/mod/mod_vhost_alias.html.tr.utf8 index 7f30df4114..b10187fd35 100644 --- a/docs/manual/mod/mod_vhost_alias.html.tr.utf8 +++ b/docs/manual/mod/mod_vhost_alias.html.tr.utf8 @@ -72,6 +72,85 @@ 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.

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

    @@ -220,85 +299,6 @@ Sanal Barındırma

    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.

    - - -
    -
    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 87fb8178fe..8b778b8c45 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 e87fd0393e..9c51e9b52c 100644 --- a/docs/manual/mod/mod_xml2enc.html.en +++ b/docs/manual/mod/mod_xml2enc.html.en @@ -58,6 +58,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 @@ -131,58 +183,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/mpm_common.html.de b/docs/manual/mod/mpm_common.html.de index 40210cfe2e..ddd0cbb604 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

    @@ -740,6 +739,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 14ecbc54b8..2069c14ccd 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

    @@ -787,6 +786,7 @@ client connections causes crashes with some common modules. +

    Available Languages:  de  | diff --git a/docs/manual/mod/mpm_common.html.ja.utf8 b/docs/manual/mod/mpm_common.html.ja.utf8 index 39c7a3e1e6..ffb01a613c 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 ディレクティブ

    @@ -762,6 +761,7 @@ simultaneously +

    翻訳済み言語:  de  | diff --git a/docs/manual/mod/mpm_common.html.tr.utf8 b/docs/manual/mod/mpm_common.html.tr.utf8 index 3af7a6b282..f721bc614a 100644 --- a/docs/manual/mod/mpm_common.html.tr.utf8 +++ b/docs/manual/mod/mpm_common.html.tr.utf8 @@ -59,7 +59,6 @@

  • ThreadStackSize
    • -
    top

    CoreDumpDirectory Yönergesi

    @@ -799,6 +798,7 @@ in *BSDs. 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 5ee01b03b4..43a98b1812 100644 --- a/docs/manual/mod/mpm_netware.html.en +++ b/docs/manual/mod/mpm_netware.html.en @@ -83,7 +83,6 @@ ports Apache httpd uses

    -
    top

    MaxThreads Directive

    @@ -104,6 +103,7 @@

    +

    Available Languages:  en 

    diff --git a/docs/manual/mod/prefork.html.de b/docs/manual/mod/prefork.html.de index d260da3984..2aa212bbbe 100644 --- a/docs/manual/mod/prefork.html.de +++ b/docs/manual/mod/prefork.html.de @@ -84,48 +84,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 @@ -185,6 +143,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 6a79a0dc86..92447341a0 100644 --- a/docs/manual/mod/prefork.html.en +++ b/docs/manual/mod/prefork.html.en @@ -79,49 +79,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

    @@ -181,6 +138,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.ja.utf8 b/docs/manual/mod/prefork.html.ja.utf8 index 4b796f7af2..3aa14c4ea1 100644 --- a/docs/manual/mod/prefork.html.ja.utf8 +++ b/docs/manual/mod/prefork.html.ja.utf8 @@ -86,51 +86,6 @@ が使用するアドレスとポートの設定

    top
    -
    -

    動作方法

    -

    一つのコントロールプロセスが、 - コネクションに対して listen して、しかるべき時に応答する - 子プロセスを起動します。Apache は常に幾つかのスペア - かアイドルなサーバプロセスを維持していて、それらは入ってきた - リクエストに応答できるように待機しています。 - このようにしてクライアントは、リクエストが応答される前に、 - 新しい子プロセスが fork されるのを待たなくてもよいように - なっています。

    - -

    親プロセスがリクエストに応答するの子プロセスを - どのように生成するかは、 - StartServers, - MinSpareServers, - MaxSpareServers, - MaxClients - で調整します。一般的に、Apache は非常に自律的なので、 - 大抵のサイトではこれらのディレクティブをデフォルト値から調整する - 必要はないでしょう。 - 同時に 256 を超えるリクエストに応答しないといけないサイトでは、 - MaxClients - を増やす必要があるでしょう。 - 一方、メモリの限られているサイトでは、スラッシング - (メモリとディスク間で何度もスワップ) が起こるのを防ぐために - MaxClients - を減らす必要があるでしょう。プロセス生成のチューニングに関する - 詳しい情報は、性能に関するヒント - にあります。

    - -

    通常 Unix では親プロセスは 80 番ポートにバインドするために - root で起動されますが、子プロセスやスレッドは - もっと低い権限のユーザで Apache によって起動されます。 - User と - Group - ディレクティブは - Apache の子プロセスの権限を設定するのに用いられます。 - 子プロセスはクライアントに送るコンテンツ全てを読めないといけませんが、 - 可能な限り必要最小限の権限のみを持っているようにするべきです。

    - -

    MaxRequestsPerChild - は、古いプロセスを停止して新しいプロセスを起動することによって、 - どの程度の頻度でサーバがプロセスをリサイクルするかを制御します。

    -
    -
    top

    MaxSpareServers ディレクティブ

    Description:Maximum number of idle child server processes
    @@ -183,6 +138,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 f6649b64a8..266299f7a6 100644 --- a/docs/manual/mod/prefork.html.tr.utf8 +++ b/docs/manual/mod/prefork.html.tr.utf8 @@ -79,47 +79,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

    説明:アイドルな子サーバプロセスの最大個数
    @@ -180,6 +139,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ı