APACHE の AcceptPathInfo ディレクティブの使用の概要_PHP チュートリアル-PHPチュートリアル-php.cn

APACHE の AcceptPathInfo ディレクティブの使用の概要_PHP チュートリアル

WBOY

リリース： 2016-07-21 15:14:06

オリジナル

1000 人が閲覧しました

zfdemo を学習するときに、AcceptPathInfo コマンドの設定について言及しました。

仮想静化を行ったり、パスを美しく見せたりするときに、この URL に http://www.example.com/index.php/html1 が表示されることがあります。実際にアクセスされるのはルートディレクトリにあるindex.phpファイルで、/html1がPATH_INFO環境変数としてスクリプトに渡されます。 Apache の場合、上記のアドレスが正しく実行できるかどうかは、AcceptPathInfo ディレクティブの構成によって決まります

AcceptPathInfo ディレクティブ

冗長なパス名情報を持つリクエストを受け入れるかどうかを示します
構文 AcceptPathInfo On|Off|Default
デフォルト値 AcceptPathInfo Default
スコープサーバー構成、仮想ホスト、ディレクトリ、.htaccess
オーバーライド項目 FileInfo
ステータスコア (C)
モジュールコア
互換性は Apache 2.0.30 以降でのみ利用可能

このディレクティブは、実際のファイル A の名前のリクエストを受け入れるかどうかを決定します(または実際のディレクトリに存在しないファイル) の後に冗長なパス名情報が続きます。この追加のパス名情報は、PATH_INFO 環境変数としてスクリプトに渡すことができます。

たとえば、/test/ が指すディレクトリに here.html というファイルが 1 つだけ含まれていると仮定すると、/test/here.html/more および /test/nothere.html/more のリクエストにより PATH_INFO 環境変数が設定されます。多くのための"。

AcceptPathInfo ディレクティブの値の範囲:

Off
リクエストは、実際のパスにマップされている場合にのみ受け入れられます。したがって、上記の /test/here.html/more のような実際のファイル名の後にパス名が続くリクエストは、「404 NOT FOUND」エラーを返します。
オン
先頭のパスが実際の既存のファイルにマッピングできる限り、リクエストは受け入れられます。このように、上記の /test/here.html が有効なファイルにマッピングできる限り、/test/here.html/more のリクエストは受信されます。
デフォルト
冗長なパス名情報を持つリクエストを受け入れるかどうかは、対応するプロセッサによって決定されます。通常のテキストを処理するコアプロセッサは、デフォルトで PATH_INFO を拒否します。 cgi-script や isapi-isa などのサーバースクリプトに使用されるプロセッサは、デフォルトで PATH_INFO を受け入れます。
AcceptPathInfo ディレクティブの主な目的は、PATH_INFO を受け入れるかどうかのプロセッサのデフォルト設定をオーバーライドできるようにすることです。この保障は必要です。たとえば、INCLUDES のようなフィルターを使用して、PATH_INFO に基づいてコンテンツを生成する場合です。通常、コアプロセッサはそのようなリクエストを拒否するため、次の設定を使用してそのようなスクリプトを可能にすることができます:

Options +includes
SetOutputFilter INCLUDES
AcceptPathInfo On

Apache 2.0 以降のデフォルトでは、acceptpathinfo はありません

Acceptpathinfo は APACH2.0.30 以降のサーバーから削除されました。必要に応じて、http.conf に AcceptPathInfo On を追加する必要があります。つまり、元の

Options FollowSymLinks include
AllowOverride None
に変更されました
Options FollowSymLinks include
AllowOverride None
AcceptPathInfo On

このコマンドは、特定のファイル (または既存のディレクトリ) に含まれる存在しないファイルを受け入れるかどうかを決定します) がパス情報に付加されます。このパス情報は、スクリプト内に PATH_INFO 環境変数として表示されます。
たとえば、/test/ が指すディレクトリには、here.html というファイルが 1 つだけ含まれているとします。次に、/test/here.html/more および /test/nothere.html/more に対するリクエストは、/more のような PATH_INFO 変数を取得します。
AcceptPathInfo ディレクティブの 3 つのパラメーターは次のとおりです:
off
リクエストは、実際のパスにマップされている場合にのみ受け入れられます。したがって、実際のファイル名の後にパス名を指定した上記の /test/here.html/more のようなリクエストは、404 NOT FOUND エラーを返します。
on
前のパスが実際の既存のファイルにマップされている場合、このリクエストは受け入れられます。 /test/here.html が有効なファイルにマップされている場合、上記の例の /test/here.html/more のリクエストは受け入れられます。
デフォルト
追加のパス名を持つリクエストの処理方法は、対応するプロセッサによって決定されます。通常のテキストを処理するコアプロセッサは、デフォルトで PATH_INFO を拒否します。 cgi-script や isapi-isa などのサーバースクリプトに使用されるプロセッサは、デフォルトで PATH_INFO を受け入れます。

PHP のグローバル変数 $_SERVER['PATH_INFO'] は、多くの CMS システムが URL を美しくするときにこのパラメーターを使用します。

次の URL の場合:
http://www.test.com/index.php/foo/bar.html?c=index&m=search
$_SERVER['PATH_INFO'] = '/foo/bar を取得できます.html'、この時点では $_SERVER['QUERY_STRING'] = 'c=index&m=search';
通常、最初に PHP プログラムを書き始めるときは、次のようなものを使用します: http://www.test.com /index .php?c=search&m=main のような URL は非常に奇妙に見えるだけでなく、検索エンジンにとっても非常に不親切です。多くの検索エンジンはインデックス作成時にクエリ文字列以降のコンテンツを無視しますが、Google はクエリ文字列を無視しませんが、クエリ文字列を含まない他のページに比較的高い PR 値を与えます。

以下は PATH_INFO を解析するための非常に簡単なコードです:

コードをコピーしますコードは次のとおりです:

 
if( !isset( $_SERVER['PATH_INFO' ] ) ){ 
$pathinfo = 'デフォルト'; 
}else{ 
$pathinfo =explode('/', $_SERVER['PATH_INFO']); 
} 
if( is_array($pathinfo) AND !empty($) pathinfo) ){ 
$page = $pathinfo[1]; 
}else{ 
$page = 'a.php'; 

 

スラッシュを含むファイル名「/」行に正常にアクセスできず、見つからないエラーが報告されます

システムが壊れた後、システムを再インストールし、php環境を設定します。使用するソフトウェアは以前のバージョンと同じです。環境構築後は、作業プロジェクトはすべて単一エントリのファイルなので、index.phpファイルの後にスラッシュを付けて入力します。システムを変更する前にアクセスできるため、ソフトウェアのバージョンの問題を解決できます。

作業プロジェクトに入ろうとしたときに、理由がわかりませんが見つからないと報告されます。テストした結果、PHPファイル名にスラッシュ「/」が含まれていると正常にアクセスできないことが分かりました

色々な人に聞きましたがダメでした。 Google Du Niangは失敗しました

会社の上級PHPエンジニアを見つけました
Apacheには次のようなコマンドがあると言われました: AcceptPathInfo

Apache設定ファイルにAcceptPathInfoを追加すればOKです。

http://www.bkjia.com/PHPjc/326345.html