Non-Parsed Header

NPH

[1] いわゆる nph-cgi は、HTTP CGIスクリプトの用意した応答メッセージを (ほぼ) そのまま編集せずに HTTP 応答メッセージとして返すような CGI の仕組み、あるいはそれを利用した CGIスクリプト、あるいは CGIスクリプトがそのように実行されるよう設定されたディレクトリーのことです。

[2] 通常、HTTP CGIスクリプト応答 (標準出力に出力されたバイト列) をそのまま HTTP 応答としてクライアントに返すのではなく、 状態行を付与したり、CGI頭欄を処理したり、 Date:Server: のような追加の HTTP頭欄を補ったりしてから HTTP 応答メッセージとしてクライアントに返します。 nph-cgi はこれらの処理をできるだけ省きます。

[3] もともとは「できるだけ」ではなく本当にそのまま返すのが想定された実装だったようですが、 HTTP/1.1chunked符号化が導入されるなど、クライアントからの要求に応じて HTTP が行うべき処理が増え、それらすべてを CGIスクリプト側で処理させることは現実的でないために、 今では nph-cgi であってもある程度の後処理を HTTP が行うのが一般的です。 要出典

HTTP/2NPH を両方実装するには HTTP鯖側で NPH応答から HTTP/2 応答への変換を実装せざるを得ないはずです。

仕様書

処理

[5] NPH (Non-Parsed Header) スクリプトに対応しても構いません >>4

[6] 必須ではありません。

識別

[7] NPHスクリプトか通常のCGIスクリプトかは、実装定義の方法によって決まります。 >>4

[8] 伝統的にはCGIスクリプトの名前が nph- ではじまればNPH、 のような名前によって区別する方法が採られてきました。

[17] WebSTARIIS は最初の行によって決定するそうです。

[18] RFC 3875スクリプトの出力によって決めることはできないと言っていますが、 実際には CGI応答には表れない状態行HTTP応答には存在するので区別できるはずです。

NPH 応答

[11] NPHスクリプトにかわって適切な応答を構築する責任を持ちます。 スクリプトに (ひいてはクライアントに) 応答を返す方法はシステム定義です。 特段の定めがない限り、これは通常の CGIスクリプトの場合と同じ方法となります。 >>4

[12] NPHスクリプトHTTP に関してのみ定義されており、完全な HTTP 応答メッセージを返さなければなりませんSERVER_PROTOCOL メタ変数に応じて適当な形式とする必要がありますし、 その他各種のメタ変数もプロトコル仕様に従い適宜考慮する必要があります。 >>4

[13] スクリプトの出力が修正なしにクライアントに送られるようにしなければなりませんはこれをできるだけ少ない内部のバッファリング、およびトランスポート層から見えるバッファリング無しでクライアントへと送信するべきです>>4

[14] スクリプトは、別途実装定義が無い限り、クライアントが同じ接続で更に次の要求を送っても良いと応答で示してはなりません>>4

[15] つまり持続接続Keep-Alive を使ってはいけません。
[16] chunked など転送符号化を勝手に行って良いとは読めませんが、実際にはどうなっているのでしょうか。

歴史

[9] 元々は CGI応答HTTP鯖による後処理オーバーヘッドを削減することが狙いだったと思われますが、 現在となってはその必要性もほとんど無いだろうこと、 CGI 自体が使われなくなって来ていること、 本当に応答の性能が問題となるなら FastCGImod_*、 独自のアプリケーション鯖などその後 CGI にかわって使われるようになった技術を使う方がより良いだろうことなどより、 NPH もほとんど使われなくなって来ているものと思われます。