nginxのevalモジュールについての説明が下記URLにあるのですが、英語のためどなたか和訳できる方がおられましたらお願いします。

http://www.grid.net.ru/nginx/eval.en.html

「Configuration directives」の項目だけでも構いません。よろしくお願いします。

※exciteなどの機械翻訳はご遠慮下さい

回答の条件
  • 1人5回まで
  • 13歳以上
  • 登録:2012/01/15 20:38:51
  • 終了:2012/01/16 11:51:02

ベストアンサー

id:a-kuma3 No.1

a-kuma3回答回数4489ベストアンサー獲得回数18572012/01/16 00:25:13

ポイント300pt

特に英語が得意なわけではありませんが、こういう類のマニュアル英語には慣れているつもりです。
ざっくりと訳してみました。
# 橙色の文字は、対訳ではなく、ぼくの注釈です。

syntax: eval $<variable1_name> $<variable2_name> ] ... ] {<block>}

Specifies names of variables to evaluate and block with proxy_pass or memcached_pass directives. The maximal number of variables is 8. Eval block is executed before rewrite module, therefore all configuration of rewrite module must be specified inside eval block. Example:

評価する変数名と、proxy_pass ディレクティブや memcached_pass ディレクティブを持ったブロックを指定します。
変数は、最大で八つまで指定できます。
評価のブロックは rewrite モジュールの前に実行されます。
そのため、全ての rewrite モジュールは eval のブロックの中に書く必要があります。
例えば、

set $foo bar; の行が、eval $var {} の外にあるか、中にあるか、で $foo がどう設定されているかで、$foo がどのように解釈されるかの違いが例として挙げてあります。

For the same reason eval block is ineffective inside if and limit_except blocks, but instead if and limit_except blocks are effective inside eval block.

同じ理由で、if や limit_exception ブロックの中にある eval ブロックは有効になりません。
しかし、eval ブロックの中にある if や limit_exception ブロックは有効です。

Evaluation of response into variables is controlled by it's content type (the value of Content-Type header). The following content types are recognized:

レスポンス中の変数は、その content-type によって制御されます。
次の content-type が有効です。

application/octet-stream -- the response body is treated as stream of bytes and copied into first variable's value as is;

application/octet-stream -- response body は、バイトストリームとして扱われ、最初の変数の値に、そのまま代入されます。
「最初の変数に」とあるのは、eval ブロックに複数の変数を指定できるので、断りを入れているのだと思います。

text/plain -- the response body is treated as text and first line is copied into first variable's value after stripping trailing characters and spaces;

text/plain -- response body は、テキストとして扱われ、最初の行が変数の値として代入されます。
その際、行末の文字と空白が取り除かれます (多分、trim されるということ)

application/x-www-form-urlencoded -- the response body is treated as a set of name-value pairs and encoded as follows:

application/x-www-form-urlencoded -- response body は、以下のようにエンコードされた変数名と値のペアとして扱われます。

1. Values are escaped. Space characters are replaced by `+', and then reserved characters are escaped as described in RFC 1738, section 2.2: Non-alphanumeric characters are replaced by `%HH', a percent sign and two hexadecimal digits representing the ASCII code of the character. Line breaks are represented as "CR LF" pairs (i.e., `%0D%0A').

1.
値は URL エスケープされています。
空白は '+' になっています。
そして、予約語は RFC 1738, section 2.2 にしたがっています (";", "/", "?", ":", "@", "=", "&")。
アルファベット以外は、'%HH' という形式 ('%' と、文字コードを16進数二桁で表現したもの) です。
改行文字 は、CR LF のペア ('%0D%0A') で表現されます。

2. The name is separated from the value by `=' and name/value pairs are separated from each other by `&';

2.
変数名と値は '=' で区切られており、更に、変数名と値の固まりは、'&' で区切られています。

3. Variables in response may follow in arbitrary order, multiple occurances of single variable are possible, but only the last one is used.

3.
変数は、特定の順序で並べられているわけではありません。
同じ名前の変数は複数指定することは可能ですが、評価されるのは最後に現れたものだけです。

In order to override content type returned by the proxy or memcached, it is necessary to use eval_override_content_type directive.

プロクシやメモリキャッシュによって返される content-type を置き換えるためには、eval_override_content_type ディレクティブを使う必要があります。

syntax: eval_escalate <on/off>

Enables escalation of error in eval block to upper level of configuration. For example this configuration:
...
returns HTTP error 405, whereas this configuration:
...
returns HTTP error 403.

eval ブロック中のエラーを、上位に通知することができます。
例えば、この設定だと、
  (eval_escalate を off にする)
HTTP のステータスは 405 で返りますが、この設定では、
  (eval_escalate を on にする)
ステータスが 403 で返ります。
正直、挙動がよく分かりません。eval ブロック内で指定したエラーのステータスで、その外側のステータスを置き換える、ということかしら。

syntax: eval_override_content_type <mime type>

Specifies content type to use instead of content type provided by memcached or proxy.

ここで指定した content-type で、メモリキャッシュ、もしくは、プロクシから返された content-type を置き換えます。



念のため、RFC 1738 (Uniform Resource Locators (URL)) の日本語訳。
http://www5b.biglobe.ne.jp/~type-aya/rfc/rfc1738j.txt

他1件のコメントを見る
id:a-kuma3

ちなみにeval_escalateの設定は仰るとおりの挙動だと思います。

eval_escalate の辺りが、ちょっとモヤモヤしたので、rewrite モジュールのドキュメントを読んでみました。

http://wiki.nginx.org/HttpRewriteModule
↑によると、return ディレクティブは、

This directive concludes execution of the rules

「そのルールの実行を終わらせる」とあるので、通常のプログラム言語の return と同じような制御フローになるようです。

eval_escalate off の場合には、return で eval ブロックを抜けて、そのブロックの次にある
return 405 が評価されるのに対し、
eval_escalate on の場合は、eval ブロックを抜けた後に、そのブロック自体が、
return 403 と同等の評価をされ、return 405 に制御が移る前に location ディレクティブのブロックを抜ける、という動作になるんでしょうね。

さらに if とかが入って、三重以上のブロックになると、どうなんでしょう。
大域ジャンプで、一番外のブロックまで飛ぶのかな、という気もしますが、
そうだったら upper level じゃなくて、top level とか書きそうな気もします。

2012/01/16 13:38:38
id:xxmasaxx

実際に試してみましたが、evalブロックのif内でreturnを実行すると、evalブロックを抜けるようです。ちなみにnginx自体、ifの多重ネストには対応していない(はず)だったと思います。

2012/01/16 18:47:44

コメントはまだありません

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません