[8] CGI のメタ変数 PATH_INFO は、Script-URI の path
のうち、CGIスクリプトによって解釈されるべき部分をパーセント復号したものです。
PATH_INFO = "" | ( "/" path )
path = lsegment *( "/" lsegment )
lsegment = *lchar
lchar = <any TEXT or CTL except "/">[12] PATH_INFO は元の URL の path
のうちCGIスクリプトを識別する部分の後に続く部分から決まる値です。
path-segment に引数は認められていません。 >>6
[14] 大文字と小文字は区別され、元の状態を保存しなければなりません >>6。
[15] 鯖は PATH_INFO の値に更に制限を課し、それに反するものを誤りとしても構いません
>>6。
[17] 非ASCII文字の扱いはシステム定義です。 >>6
[21] NULL (空文字列) の意味は明記されていませんが、 path 全体が CGIスクリプトを識別する場合、
PATH_INFO は必然的に空になります。
[27] RFC は、値はパーセント符号化されていない >>6 としています。
[1] [NCSA] ではこの変数はサーバーが (URI符号化を) 復号した値にするべき (should) と述べていましたが、 [COAR 03] は何も述べていません。しかしながら、 CGI メタ変数から URI を作る節で PATH_INFO を URI 符号化した値を使うことになっていますから、暗黙のうちに復号を要求しています。
[2] 実際には Apache はじめどの実装も復号するはずです。たぶん。
[19] パーセント復号するという仕様は CGIスクリプトの手間や実装漏れの発生を鯖側で吸収しようとしたものでしょう。 手軽にCGIスクリプトを書くためにはそれも良かったのでしょうが、正確なRequest-URI をCGIスクリプト側で決定できないことによる URL 設計の制約などから、 現在では不便な仕様と考えられることが多いようです。
[28] HTTP::Request::AsCGI は、ソースコードのコメントで、
パーセント復号する仕様は問題があるとしつつも、
Apache や lighttpd がそうしているとして、RFC 通りすべてのパーセント符号化を復号しています。
[24] CGIスクリプトは PATH_INFO を処理するつもりがないときは
404 応答により拒絶するべきです。 >>23
[405] PATH_INFO や PATH_TRANSLATED や
SCRIPT_NAME を扱うときは、空の path segment (//)
や特別な path segment (. や ..)
の扱いに注意するべきです。 OS に渡す必要があるときは削除する、あるいは誤りとして
404 を返すなどの処置を行うべきです。 >>23
CON など DOS で特別な意味を持つファイル名が含まれるとき、
非ASCII文字などファイル・システムやロケールによって正しく扱えない可能性がある文字が含まれるときなども同様に注意が必要です。
[26] 古い CGIスクリプトを中心に、 PATH_INFO を気にしていないことがよくあります。
URL に基づくアクセス制御などとの関係で、意図せぬ URL で CGIスクリプトにアクセスできてしまうことは、
セキュリティー上の問題につながるかもしれません。 (そのため >>24 の通り、
利用するつもりがなければ拒むべきです。)
The PATH_INFO metavariable specifies a path to be interpreted
by the CGI script. It identifies the resource or sub-resource to be returned by the CGI script, and it is derived from the portion of the URI path following the script name but preceding any query data. The syntax and semantics are similar to a decoded HTTP URL 'path' token (defined in RFC 2396 [4]), with the exception that a PATH_INFO of "/" represents a single void path segment.
PATH_INFO (経路情報) メタ変数には、 CGI スクリプトにより解釈される 経路を指定します。これは CGI スクリプトが返す資源または副資源を 識別するものであり、 URI 経路のうちスクリプト名に続く、 問合せ (query) データの前の部分から得たものです。 構文と意味は復号した HTTP URL 「path」(経路)字句 (RFC 2396 で定義) と同様ですが、例外として 「/」という PATH_INFO は 単一空経路部分を表します。
PATH_INFO = "" | ( "/" path )
path = segment *( "/" segment )
segment = *pchar
pchar = <any CHAR except "/">The PATH_INFO string is the trailing part of the <path> component of the Script-URI (see section 3.2) that follows the SCRIPT_NAME portion of the path.
PATH_INFO 文字列は Script-URI (第3.2節参照) の <path> (経路) 部品の、 SCRIPT_NAME 部分の後の部分です。
Servers MAY impose their own restrictions and limitations on what values they will accept for PATH_INFO, and MAY reject or edit any values they consider objectionable before passing them to the script.
サーバーは PATH_INFO にいかなる値を受け付けるかという自身の制限を 課しても構いませんし、スクリプトに渡す前に宜しくないと思う 値を却下したり編集したりしても構いません。
Servers MUST make this URI component available to CGI scripts. The PATH_INFO value is case-sensitive, and the server MUST preserve the case of the PATH_INFO element of the URI when making it available to scripts.
サーバーはこの URI 部品を CGI スクリプトから利用可能にし なければなりません。 PATH_INFO 値は大文字・小文字を区別し、 サーバーはスクリプトから利用可能とする時に、 URI の PATH_INFO 要素の大文字・小文字を保存しなければなりません。
[406] HTTP::Request::AsCGI は与えられた URL の path 全体を PATH_INFO
に含めます。 (SCRIPT_NAME は / で固定です。)
[20] PATH_INFO をファイル・システム上の path
に写像した PATH_TRANSLATED も存在します。
[18] 当初 CGIスクリプトへの引数は QUERY_STRING から受け取るのが一般的でしたが、
2000年代の初め頃からそのような URL は汚いものとみなされるようになり、
しばしば PATH_INFO が使われるようになっていきました。
その場合であっても本来は path の一部として資源を識別するとみなせるものは PATH_INFO
に、それ以外は引き続き QUERY_STRING に含めるのが意味的には正しいのでしょうが、
QUERY_STRING を過度に忌避して PATH_INFO に無理に詰め込むような使い方をする人も出てきました。
[3] IIS は正しい PATH_INFO をくれないことがあるそうです。
[5] Apache2 + mod_perl2 の仕様と正しく mod_perl2 を使うための方法 - 冬通りに消え行く制服ガールは、夢物語にリアルを求めない。 - subtech ( 版) <http://subtech.g.hatena.ne.jp/cho45/20101221/1292941055>
[25] Twiggy は要求URLとして絶対URLが指定されると、それをすべて
PATH_INFO とするようです。 (SCRIPT_NAME
は空文字列になります。)
/からはじまる任意の文字列が認められています。