Return-Path:
mod_ext_filter
は使えます。
説明: | 外部フィルタを定義 |
---|---|
構文: | 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
intype=
が指定されていれば、フィルタは指定されていない
- ドキュメントには適用されなくなります。outtype=imt
PreservesContentLength
PreservesContentLength
キーワードはフィルタが
- content length (訳注: コンテントの長さ)
- を変更しないということを指定します。ほとんどのフィルタは
- content length を変更するため、これはデフォルトではありません。
- フィルタが長さを変えないときは、このキーワードを指定すると
- よいでしょう。ftype=filtertype
disableenv=env
enableenv=env
説明: | 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
からは
- デバッグメッセージは生成されません。
説明: | 外部フィルタを定義 |
---|---|
構文: | 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
intype=
が指定されていれば、フィルタは指定されていない
+ ドキュメントには適用されなくなります。outtype=imt
PreservesContentLength
PreservesContentLength
キーワードはフィルタが
+ content length (訳注: コンテントの長さ)
+ を変更しないということを指定します。ほとんどのフィルタは
+ content length を変更するため、これはデフォルトではありません。
+ フィルタが長さを変えないときは、このキーワードを指定すると
+ よいでしょう。ftype=filtertype
disableenv=env
enableenv=env
説明: | 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
からは
+ デバッグメッセージは生成されません。
翻訳済み言語: en | Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/mod_ext_filter.html.ko.euc-kr URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/mod_ext_filter.html.ko.euc-kr?rev=1674086&r1=1674085&r2=1674086&view=diff ============================================================================== --- httpd/httpd/branches/2.4.x/docs/manual/mod/mod_ext_filter.html.ko.euc-kr [euc-kr] (original) +++ httpd/httpd/branches/2.4.x/docs/manual/mod/mod_ext_filter.html.ko.euc-kr [euc-kr] Thu Apr 16 14:59:48 2015 @@ -60,149 +60,19 @@ 수 있다.
설명: | 외부 필터를 정의한다 |
---|---|
문법: | 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
intype=
을 지정하면
- 다른 type의 문서는 필터로 처리하지 않는다.outtype=imt
PreservesContentLength
PreservesContentLength
키워드는 필터가
- content length를 유지하도록 한다. 대부분의 필터가 content
- length를 변경하므로 이 키워드는 기본값이 아니다. 필터가
- 길이를 유지할때만 이 키워드를 사용해야 한다.ftype=filtertype
disableenv=env
enableenv=env
설명: | 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
는
- 자체 디버그문을 기록하지 않는다.
설명: | 외부 필터를 정의한다 |
---|---|
문법: | 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
intype=
을 지정하면
+ 다른 type의 문서는 필터로 처리하지 않는다.outtype=imt
PreservesContentLength
PreservesContentLength
키워드는 필터가
+ content length를 유지하도록 한다. 대부분의 필터가 content
+ length를 변경하므로 이 키워드는 기본값이 아니다. 필터가
+ 길이를 유지할때만 이 키워드를 사용해야 한다.ftype=filtertype
disableenv=env
enableenv=env
설명: | 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
는
+ 자체 디버그문을 기록하지 않는다.
가능한 언어: en |
Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/mod_file_cache.html.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/mod_file_cache.html.fr?rev=1674086&r1=1674085&r2=1674086&view=diff
==============================================================================
--- httpd/httpd/branches/2.4.x/docs/manual/mod/mod_file_cache.html.fr (original)
+++ httpd/httpd/branches/2.4.x/docs/manual/mod/mod_file_cache.html.fr Thu Apr 16 14:59:48 2015
@@ -68,81 +68,15 @@ fichiers
d'Apache 1.3 mod_mmap_static
et s'en inspire
fortement .
Description: | Met en cache une liste de gestionnaires de fichiers au -démarrage |
---|---|
Syntaxe: | CacheFile chemin fichier [chemin fichier] ... |
Contexte: | configuration du serveur |
Statut: | Expérimental |
Module: | mod_file_cache |
La directive CacheFile
permet d'associer
- des gestionnaires à un ou plusieurs fichiers (séparés par des
- espaces), et de placer ceux-ci dans le cache au démarrage du
- serveur. Les gestionnaires des fichiers mis en cache sont
- automatiquement fermés à l'arrêt du serveur. Lorsqu'un ou plusieurs
- fichiers ont été modifiés sur disque, le serveur doit être redémarré
- afin que les modifications soient prises en compte par le cache.
Soyez prudent avec les arguments chemin fichier : ils
- doivent correspondre exactement au chemin du système de fichier que
- créent les gestionnaires de traduction URL-vers-nom-fichier
- d'Apache. On ne peut pas comparer des inodes ou autres identifiants
- pour mettre en correspondance des chemins à l'aide de liens
- symboliques (etc...), car là encore, ceci nécessiterait un
- appel à stat()
supplémentaire, ce qui n'est pas acceptable.
- Il n'est pas garanti que ce module fonctionne avec des noms de
- fichiers réécrits par mod_alias
ou
- mod_rewrite
.
CacheFile /usr/local/apache/htdocs/index.html-
Description: | Charge au démarrage une liste de fichiers en mémoire |
---|---|
Syntaxe: | MMapFile chemin fichier [chemin fichier] ... |
Contexte: | configuration du serveur |
Statut: | Expérimental |
Module: | mod_file_cache |
La directive MMapFile
permet de charger un
- ou plusieurs fichiers (séparés par des espaces) en mémoire au
- démarrage du serveur. Ceux-ci sont automatiquement déchargés de la
- mémoire à l'arrêt du serveur. Lorsqu'un ou plusieurs fichiers ont
- été modifiés sur disque, on doit au minimum envoyer un signal
- HUP
ou USR1
au serveur afin de les
- remmap()
er.
Soyez prudent avec les arguments chemin fichier : ils
- doivent correspondre exactement au chemin du système de fichier que
- créent les gestionnaires de traduction URL-vers-nom-fichier
- d'Apache. On ne peut pas comparer des inodes ou autres identifiants
- pour mettre en correspondance des chemins à l'aide de liens
- symboliques (etc...), car là encore, ceci nécessiterait un
- appel à stat()
supplémentaire, ce qui n'est pas
- acceptable.
- Il n'est pas garanti que ce module fonctionne avec des noms de
- fichiers réécrits par mod_alias
ou
- mod_rewrite
.
MMapFile /usr/local/apache/htdocs/index.html-
Description: | Met en cache une liste de gestionnaires de fichiers au +démarrage |
---|---|
Syntaxe: | CacheFile chemin fichier [chemin fichier] ... |
Contexte: | configuration du serveur |
Statut: | Expérimental |
Module: | mod_file_cache |
La directive CacheFile
permet d'associer
+ des gestionnaires à un ou plusieurs fichiers (séparés par des
+ espaces), et de placer ceux-ci dans le cache au démarrage du
+ serveur. Les gestionnaires des fichiers mis en cache sont
+ automatiquement fermés à l'arrêt du serveur. Lorsqu'un ou plusieurs
+ fichiers ont été modifiés sur disque, le serveur doit être redémarré
+ afin que les modifications soient prises en compte par le cache.
Soyez prudent avec les arguments chemin fichier : ils
+ doivent correspondre exactement au chemin du système de fichier que
+ créent les gestionnaires de traduction URL-vers-nom-fichier
+ d'Apache. On ne peut pas comparer des inodes ou autres identifiants
+ pour mettre en correspondance des chemins à l'aide de liens
+ symboliques (etc...), car là encore, ceci nécessiterait un
+ appel à stat()
supplémentaire, ce qui n'est pas acceptable.
+ Il n'est pas garanti que ce module fonctionne avec des noms de
+ fichiers réécrits par mod_alias
ou
+ mod_rewrite
.
CacheFile /usr/local/apache/htdocs/index.html+
Description: | Charge au démarrage une liste de fichiers en mémoire |
---|---|
Syntaxe: | MMapFile chemin fichier [chemin fichier] ... |
Contexte: | configuration du serveur |
Statut: | Expérimental |
Module: | mod_file_cache |
La directive MMapFile
permet de charger un
+ ou plusieurs fichiers (séparés par des espaces) en mémoire au
+ démarrage du serveur. Ceux-ci sont automatiquement déchargés de la
+ mémoire à l'arrêt du serveur. Lorsqu'un ou plusieurs fichiers ont
+ été modifiés sur disque, on doit au minimum envoyer un signal
+ HUP
ou USR1
au serveur afin de les
+ remmap()
er.
Soyez prudent avec les arguments chemin fichier : ils
+ doivent correspondre exactement au chemin du système de fichier que
+ créent les gestionnaires de traduction URL-vers-nom-fichier
+ d'Apache. On ne peut pas comparer des inodes ou autres identifiants
+ pour mettre en correspondance des chemins à l'aide de liens
+ symboliques (etc...), car là encore, ceci nécessiterait un
+ appel à stat()
supplémentaire, ce qui n'est pas
+ acceptable.
+ Il n'est pas garanti que ce module fonctionne avec des noms de
+ fichiers réécrits par mod_alias
ou
+ mod_rewrite
.
MMapFile /usr/local/apache/htdocs/index.html+
Langues Disponibles: en | Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/mod_file_cache.html.ko.euc-kr URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/mod_file_cache.html.ko.euc-kr?rev=1674086&r1=1674085&r2=1674086&view=diff ============================================================================== --- httpd/httpd/branches/2.4.x/docs/manual/mod/mod_file_cache.html.ko.euc-kr [euc-kr] (original) +++ httpd/httpd/branches/2.4.x/docs/manual/mod/mod_file_cache.html.ko.euc-kr [euc-kr] Thu Apr 16 14:59:48 2015 @@ -61,72 +61,15 @@
이 모듈은 아파치 1.3에 있는 mod_mmap_static
모듈의 기능을 확장한 결과다.
설명: | 시작시 여러 파일 핸들을 캐쉬한다 |
---|---|
문법: | CacheFile file-path [file-path] ... |
사용장소: | 주서버설정 |
상태: | Experimental |
모듈: | mod_file_cache |
CacheFile
지시어는 서버가 시작할때
- 여러 파일을 열고(open) 파일들의 핸들을 캐쉬에 저장한다.
- 서버 종료시 자동으로 캐쉬한 파일의 핸들을 닫는다(close).
- 파일시스템에서 파일이 변경되면 파일을 다시 캐쉬하기위해
- 서버를 재시작해야 한다.
file-path 아규먼트를 조심해라. 아규먼트는
- 아파치의 URL-파일명 변환 핸들러가 만든 파일시스템 경로와
- 정확히 일치해야 한다. 한번 더 불필요한 stat()
- 시스템호출이 필요하기때문에 inode나 심볼링크 등을
- 경로를 지정할 수 없다. 이 모듈은 mod_alias
나
- mod_rewrite
로 재작성한 파일명을 다룰 수
- 있기도 없기도 하다.
- CacheFile /usr/local/apache/htdocs/index.html
-
설명: | 시작시 여러 파일을 메모리에 대응한다 |
---|---|
문법: | 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
-
설명: | 시작시 여러 파일 핸들을 캐쉬한다 |
---|---|
문법: | CacheFile file-path [file-path] ... |
사용장소: | 주서버설정 |
상태: | Experimental |
모듈: | mod_file_cache |
CacheFile
지시어는 서버가 시작할때
+ 여러 파일을 열고(open) 파일들의 핸들을 캐쉬에 저장한다.
+ 서버 종료시 자동으로 캐쉬한 파일의 핸들을 닫는다(close).
+ 파일시스템에서 파일이 변경되면 파일을 다시 캐쉬하기위해
+ 서버를 재시작해야 한다.
file-path 아규먼트를 조심해라. 아규먼트는
+ 아파치의 URL-파일명 변환 핸들러가 만든 파일시스템 경로와
+ 정확히 일치해야 한다. 한번 더 불필요한 stat()
+ 시스템호출이 필요하기때문에 inode나 심볼링크 등을
+ 경로를 지정할 수 없다. 이 모듈은 mod_alias
나
+ mod_rewrite
로 재작성한 파일명을 다룰 수
+ 있기도 없기도 하다.
+ CacheFile /usr/local/apache/htdocs/index.html
+
설명: | 시작시 여러 파일을 메모리에 대응한다 |
---|---|
문법: | 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 | Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/mod_filter.html.fr URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/mod_filter.html.fr?rev=1674086&r1=1674085&r2=1674086&view=diff ============================================================================== --- httpd/httpd/branches/2.4.x/docs/manual/mod/mod_filter.html.fr (original) +++ httpd/httpd/branches/2.4.x/docs/manual/mod/mod_filter.html.fr Thu Apr 16 14:59:48 2015 @@ -52,16 +52,7 @@ contexte modification des modules de filtrage existants n'est nécessaire (bien qu'il soit tout de même possible de les simplifier).
Dans le modèle de filtrage traditionnel, les filtres sont insérés
+ sans condition à l'aide de la directive AddOutputFilter
et des directives
+ apparentées. Chaque filtre doit ensuite déterminer s'il doit
+ s'exécuter ou non, et les administrateurs du serveur disposent de
+ peu de souplesse pour faire en sorte que la chaîne soit traitée de
+ manière dynamique.
mod_filter
, à l'opposé, fournit aux
+ administrateurs du serveur un grand degré de souplesse pour
+ configurer la chaîne de filtrage. Concrètement, la décision
+ d'insérer un filtre peut être prise en fonction d'une expression booléenne complexe. Ceci
+ généralise le fonctionnement relativement souple de la directive
+ AddOutputFilterByType
.
+
+ Figure 1: Le modèle de filtrage traditionnel
Dans le modèle traditionnel, les filtres en sortie constituent + une simple chaîne s'étendant depuis le générateur de contenu (ou + gestionnaire) jusqu'au client. Ce fonctionnement peut convenir s'il + permet d'atteindre le but recherché, mais pose + problème lorsque cette chaîne doit être configurée dynamiquement en + fonction de la sortie du gestionnaire.
+ +
+
+ Figure 2: Le modèle de fonctionnement de
+ mod_filter
Le fonctionnement de mod_filter
consiste à
+ introduire des branchements dans la chaîne de filtrage. Plutôt que
+ d'insérer directement des filtres dans la chaîne, on insère un
+ sélecteur de filtre qui va effectuer un branchement conditionnel
+ vers un fournisseur de filtre. mod_filter
peut
+ utiliser tout filtre de contenu comme fournisseur ; aucune
+ modification des modules de filtrage existants n'est nécessaire
+ (bien qu'il soit tout de même possible de les simplifier). Il peut y
+ avoir plusieurs fournisseurs pour un seul filtre, mais un seul
+ fournisseur sera choisi pour chaque requête.
Une chaîne de filtrage peut comporter autant d'instances du + sélecteur de filtre que l'on souhaite, chacune d'entre elles pouvant + disposer de plusieurs fournisseurs. Un sélecteur de filtre possédant + un seul fournisseur dont le choix est inconditionnel constitue un + cas particulier : cette situation est équivalente à l'insertion + directe du filtre dans la chaîne.
+Trois étapes sont nécessaires pour configurer une chaîne de
+ filtrage avec mod_filter
. Voir ci-dessous la
+ description détaillée des directives.
FilterDeclare
permet de déclarer un
+ filtre en lui assignant un nom et un type. Elle n'est obligatoire
+ que si le filtre n'est pas du type par défaut
+ AP_FTYPE_RESOURCE.FilterProvider
permet d'associer un
+ fournisseur à un filtre. Le filtre a été éventuellement déclaré à
+ l'aide de la directive FilterDeclare
; si ce n'est pas le cas, FilterProvider
+ va le déclarer implicitement avec le type par défaut
+ AP_FTYPE_RESOURCE. Le fournisseur doit avoir été enregistré à
+ l'aide de ap_register_output_filter
par un module
+ quelconque. Le dernier argument de la directive FilterProvider
est une expression :
+ le fournisseur s'exécutera pour une requête si et seulement si
+ l'expression est évaluée vraie. L'expression peut évaluer une
+ requête HTTP ou les en-têtes de la réponse, des variables
+ d'environnement, ou le gestionnaire utilisé par cette requête. À la
+ différence des version précédentes, mod_filter supporte désormais
+ les expressions complexes associant des critères multiples au moyen
+ d'une logique AND / OR (&& / ||) et de parenthèses. Pour les
+ détails sur la syntaxe de l'expression, voir la documentation sur ap_expr.FilterChain
élabore une chaîne de filtrage à
+ partir de filtres intelligents déclarés, permettant avec souplesse
+ d'insérer des filtres au début ou à la fin de la chaîne, de
+ supprimer un filtre ou même la chaîne complète.Normalement, mod_filter n'applique les filtres qu'aux réponses
+ possédant un statut HTTP 200 (OK). Pour pouvoir filtrer des
+ documents possédant un autre statut, vous devez définir la variable
+ d'environnement filter-errordocs, les réponses étant
+ alors filtrées sans se préoccuper de leur statut. Pour définir ce
+ comportement de manière plus fine, vous pouvez utiliser des
+ conditions dans la directive
+ FilterProvider
.
La directive FilterProvider
a été modifiée par
+ rapport à httpd 2.2 : les arguments match et
+ dispatch ont été remplacés par l'argument unique
+ expression plus polyvalent. En général, il est possible
+ de convertir une paire match/dispatch vers les deux côtés d'une
+ expression, de la manière suivante :
"dispatch = 'match'"
Les en-têtes de requête et de réponse et les variables + d'environnement sont maintenant interprétés selon les syntaxes + respectives %{req:foo}, %{resp:foo} et + %{env:foo}. Les variables %{HANDLER} et + %{CONTENT_TYPE} sont également supportées.
+Notez que l'évaluation de l'expression ne supporte plus les + comparaisons de sous-chaînes. Ces dernières peuvent + être remplacées par des comparaisons d'expressions rationnelles.
+AddOutputFilterByType
+ FilterDeclare SSI +FilterProvider SSI INCLUDES "%{CONTENT_TYPE} =~ m|^text/html|" +FilterChain SSI+ +
FilterProvider SSI INCLUDES "%{HANDLER} = 'server-parsed'" +FilterChain SSI+ +
FilterDeclare gzip CONTENT_SET +FilterProvider gzip inflate "%{req:Accept-Encoding} !~ /gzip/" +FilterChain gzip+ +
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>+ +
Historiquement, tout filtre doit s'assurer que toute modification + qu'il effectue est correctement représentée dans les en-têtes de la + réponse HTTP, et qu'il ne s'exécutera pas si cette exécution + résultait en une modification interdite. Ceci impose aux auteurs de + filtres la corvée de réimplémenter certaines fonctionnalités + communes dans chaque filtre :
+ +Cache-Control: no-transform
éventuel.mod_filter
a pour but de gérer de manière
+ générale ces détails de l'implémentation des filtres, réduisant par
+ là-même la complexité des modules de filtrage de contenu. Le
+ travail permettant d'atteindre ce but est cependant toujours en
+ cours ; la directive FilterProtocol
+ implémente certaines de ces fonctionnalités à des fins de
+ compatibilité ascendante avec les modules d'Apache 2.0. Pour les
+ versions 2.1 et supérieures de httpd, les API
+ ap_register_output_filter_protocol
et
+ ap_filter_protocol
permettent aux modules de filtrage
+ de définir leurs propres comportements.
Cependant, mod_filter
ne doit pas interférer
+ avec un filtre qui gère déjà tous les aspects du protocole. Par
+ défaut (c'est à dire en l'absence de toute directive FilterProtocol
),
+ mod_filter
ne modifiera donc pas les en-têtes.
Au moment où ces lignes sont écrites, cette fonctionnalité a été + très peu testée, car les modules d'usage courant ont été conçus pour + fonctionner avec httpd 2.0. Les modules qui l'utilisent devront donc + l'expérimenter avec précautions.
+