5

私はnginxを使用してかなり標準的なWebサーバーを構成しています。サーバーは期待どおりに動作していますが、理解したい小さな構成の詳細があります。

私の現在の構成は次のとおりです。

index index.html index.htm index.php;

location / {
    try_files $uri $uri/ /index.php?q=$uri;
}

location ~ \.php$ {
    try_files $uri =404;
    fastcgi_index index.php;
    fastcgi_pass unix:/var/run/php5-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include /etc/nginx/fastcgi_params;
}

この構成で、http：//myweb.com/wp-content/uploads/2012/10/cropped-bitmap11.png/lol.phpにアクセスすると、期待どおりに404が得られます。

ただし、この構成では次のようになります。

try_files $uri =404;

location ~ \.php$ {
    fastcgi_index index.php;
    fastcgi_pass unix:/var/run/php5-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include /etc/nginx/fastcgi_params;
}

「アクセスが拒否されました」という空白のページが表示されます。

結果が異なるのはなぜですか？

ありがとうございました

4

2 に答える 2

15

おそらく、try_filesサーバーレベルではすべてのリクエストに対して機能する必要があるという印象を受けています。全くない。まったく逆に、locationブロックに一致しないリクエストに対してのみ機能します。

于 2013-02-21T01:47:27.267 に答える
3

短い回答：security.limit_extensions php5.3.9の時点で、php-fpmは、のデフォルト値と既存の.pngファイルに対するリクエストのため、.phpと.php5以外の拡張子を許可していません。

長い答え：これは、try_filesがロケーションブロックの内側または外側にあることとは関係ありません。休憩して説明しましょう：

リクエストは次のとおりです：http：//myweb.com/wp-content/uploads/2012/10/cropped-bitmap11.png/lol.php

最初の構成で

  • location ~ .php$ { ... }リクエストは。で終わるため、ブロックと一致し.phpます。
  • $ uriという名前のファイルがないため、場所内の try_files $uri =404;ディレクティブ.php$によりnginxは404を返します（= /wp-content/uploads/2012/10/cropped-bitmap11.png/lol.php）
  • location / { ... }ブロックが一致することはありません。他のロケーションブロックが一致しない場合にのみ一致します。（http://wiki.nginx.org/HttpCoreModule#locationを参照してください）

2番目の構成で

  • この場合も、リクエストはで終了するため、ロケーションブロック.phpと一致します。.php$
  • ロケーションブロック内にファイルが存在するかどうかのチェックはありません。要求はfastcgiプロセスに直接渡されます。
  • fastcgiプロセスは/wp-content/uploads/2012/10/cropped-bitmap11.png（明らかに存在します）を検出し、拡張子が.pngであるため、要求の実行を拒否します。（短い答えを参照してください）

それがバグなのか「設計による」ものなのかはわかりませんが、「root」ディレクティブとは異なり、ロケーションブロック外のtry_filesディレクティブはロケーションブロック内に継承されません。（間違っている場合は誰かがこれを修正する可能性があります）

于 2013-02-21T01:31:45.310 に答える