詳細な方法nginxの変数（6）

なぜ、コードの80％は農業建築家を行うことはできませんか？>>>

nginxのは、組み込みの場合はその行動の「サブリクエスト」の文脈で使用される変数やや微妙になります。（3）の前では、我々はすでに、彼らは一般的に登録「アクセス処理プログラム」を通じて、異なる動作する組み込み変数の多くは、「貯蔵容器値は」単純ではないことを知っていて、彼らも価値の店を持っていますコンテナ、キャッシュのみ「アクセス処理プログラム」を使用して計算します。我々は以前の$ argsを変数はそのを通じて現在の要求のURLを返すためにパラメータ文字列で説明した「取るハンドラ。」この要求はまた、「サブリクエスト」である可能性があるので、それが自然にパラメータ文字列「サブリクエスト」に戻ります「ハンドラを取得する」とは、$ argsを「サブリクエスト」を読み出します。のは、この例を見てみましょう：

location /main {
        echo "main args: $args";
        echo_location /sub "a=1&b=2";
    }

    location /sub {
        echo "sub args: $args";
    }

ここで/メインインターフェイスでは、変数$ argsをの最初の出力電流値が命令で要求をエコーして、命令が、その後開始されecho_locationサブリクエスト/サブ。それは、離れステートメントecho_locationの最初のパラメータで指定されていることは注目に値しますURIで「サブ要求」外、第二のパラメータはまた、URLパラメータ文字列（すなわち、= 1＆B = 2）の「サブ要求」を指定するために設けられています。最後に、我々は、出力におけるビット/サブインターフェース、値$引数を定義します。次のように要求/メイン結果インタフェースは、次のとおり$カール 'のhttp：// localhostを:? 8080 /主C = 3' メイン引数：C = 3サブ引数：明らかに、A = 1及びB = 2、ときに "マスタ要求" で使用される$引数URLパラメータストリング/時間、単に「マスタ要求」メイン出力、C = 3;及び「サブ要求」/時間サブパラメータ列「サブ要求」の出力は、A = 1＆B =で使用2。この動作は、私たちの直感に沿ったものです。組み込み変数$ URI「子要求」で使用される$ Argsのと同様の、その「取得ハンドラは、」正しく、現在の「サブリクエスト」を返しますURIを解析されました。

location /main {
        echo "main uri: $uri";
        echo_location /sub;
    }

    location /sub {
        echo "sub uri: $uri";
    }

結果要求/メインです

$ curl 'http://localhost:8080/main'
    main uri: /main
    sub uri: /sub

これは、我々が期待するものはまだです。残念ながら、ない組み込み変数の現在のすべての要求に適用されます。唯一の組み込み変数「マスタ要求」数に関する法律組み込み変数モジュールngx_http_core $ REQUEST_METHOD標準で提供されるような。REQUEST_METHOD変数$とき、読み取り、常にそのようなのPOST、GETなど「マスタ要求」要求メソッドを取得クラス。テストをしてみましょう：

location /main {
        echo "main method: $request_method";
        echo_location /sub;
    }

    location /sub {
        echo "sub method: $request_method";
    }

$ REQUEST_METHODの各出力値に、この例では、/メイン及び/サブインターフェース。同時に、我々は内部のecho_location /主なインタフェースの使用中に/サブGETインターフェース「サブリクエスト」命令を開始しました。私たちは今/ POSTリクエストメインインターフェイスを開始するために、curlコマンドラインツールを使用します。

$ curl --data hello 'http://localhost:8080/main'
    main method: POST
    sub method: POST

ここでは、--dataオプションは自動的にPOSTリクエストメソッドを使用して送信された要求を行う一方で、ボリュームデータとして、当社の要求に挨拶を指定するカールプログラム--dataオプションを使用します。テスト結果は、我々の以前の予測は、$ REQUEST_METHOD変数でもGETで「サブリクエスト」使用/サブは、結果の値は、まだPOST「メインリクエスト」/メインのリクエストメソッドであることを証明しました。一部の読者は、私たちがここにいると感じることがありケースが読んで、「メインの要求」（および出力）の$ REQUEST_METHOD変数、それからだけ作られた「サブリクエスト」で初めてですので、いくつかの性急な結論は、これらの読者は、これはサブの$ REQUEST_METHODを入力するための要求を排除しないと思うかもしれ最初の前にこのように、後続のサブ出力要求に影響を与え、バッファライブ値に読み込まれています。フロント（V）において、我々はまた、特に言及されているようしかし、この問題は、不要であり、キャッシュの値は、コンテナ変数がngx_echoモジュール「サブ要求」によって開始される、現在の要求と結合され、依存します内蔵実際バッファ容器として使用される変数$ REQUEST_METHOD値（実際にはない）、それは/サブサブ要求に影響を与えることができない場合であっても、実施の形態におけるように、変数は、無効要求サンズ間で共有されます。わずかにその例を変更し、読者の関心のこの部分を除去するために、我々としても、「サブリクエスト」に延期時間/メインインタフェース出力の$ REQUEST_METHOD変数が後に終了することがあります。

location /main {
        echo_location /sub;
        echo "main method: $request_method";
    }

    location /sub {
        echo "sub method: $request_method";
    }

私たちに再テストをしてみましょう：

$ curl --data hello 'http://localhost:8080/main'
    sub method: POST
    main method: POST

つまりことを除いて、元の一例をインタフェースと、それはPOSTメソッド要求を再び見ることができる/メイン結果が一致している逆親子要求の出力順序（我々は/主な構成インターフェイスを交換するので、本実施形態における2つの出力命令オーダー）。したがって、我々は、標準の変数$ REQUEST_METHOD要求メソッド「サブリクエスト」を取得することができません。当初の目標を達成するために、我々は、ビルトインngx_echo $ echo_request_methodを提供変数サードパーティのモジュールに頼る必要があります。

location /main {
        echo "main method: $echo_request_method";
        echo_location /sub;
    }

    location /sub {
        echo "sub method: $echo_request_method";
    }

このとき、出力は最終的に我々はしたいです：

$ curl --data hello 'http://localhost:8080/main'
    main method: POST
    sub method: GET

私たちは、「サブリクエスト」の後に、その父と息子は内蔵の一般URL「メイン要求」を解析されていない返された変数$ REQUEST_URI、同様に$ REQUEST_METHOD。それらの異なる要求メソッド、POSTの出力を要求してGETしてご覧くださいnginxのは、内部に開始され、元の形式でない「未解決」いわゆるありません。、など、以前の一部の読者は、父と息子の間に可変バッファの組み込みの値が変数リクエストが役割を果たして共有することを恐れていた場合、これは悲惨です。私たち（5）の前でngx_auth_requestモジュールは、「サブリクエスト」その「親リクエスト」変数のセットを共有しているの打ち上げ見られています。ここではそのようなひどい例は次のとおりです。

map $uri $tag {
        default     0;
        /main       1;
        /sub        2;
    }

    server {
        listen 8080;

        location /main {
            auth_request /sub;
            echo "main tag: $tag";
        }

        location /sub {
            echo "sub tag: $tag";
        }
    }

ここでは、タグへの組み込み変数$ユーザー変数$ URIをマッピングするためのマップコマンドに戻って使用します。$メインURI /の値は、$タグ値1は、第ngx_auth_requestとそうでない場合オード0次に、我々/メインインターフェイス、$ URI / SUBの値は、2 $タグ値を与えられたとき、与えられたときコマンドモジュールが開始/サブインターフェースサブ要求にauth_request、次いで変数$タグの値を出力します。/サブインターフェースでは、出力変数$タグを指示します。何を推測我々はメインインターフェイス/にアクセスした場合、出力のどのようなことでしょうか？

$ curl 'http://localhost:8080/main'
    main tag: 2

えっ？我々はそれにマッピングされた1の/メイン値に明らかにされていませんか？なぜ、実際の出力/結果マッピングは、サブ2が行うのですか？私たちの変数$タグが最初の「サブリクエスト」で/サブに読み、その値2を算出しているため実際には、その理由は、非常に簡単です（$のURI値/サブ、マップやマッピングルールに従って、$以来、バッファ値が住んでいたにもタグ値2）、コンテナから$タグでした。結果auth_requestは、「サブリクエストは、」共有変数のセットと、「親の要求」で開始した出力変数の「親リクエスト」$のタグ値が行われたときにnginxのは、バックに流れる、それは単にライブキャッシュされたNginxは2を返します。 A。この結果は本当に予想外です。この例から、我々は、再び見父と息子の間で共有変数を要求し、それは良いアイデアではありません。

ます。https：//my.oschina.net/766/blog/211405で再現

詳細な方法nginxの変数（6）

おすすめ