要求データ

要求データ

[1] CGI要求データ (request data) は、HTTP 要求メッセージ本体からCGIスクリプトに伝達する手段です。

仕様書

処理モデル

[3] 要求データへのアクセス方法はシステム定義ですが、別途定義されていない場合、 「標準入力ファイル記述子/ファイル・ハンドルによって読み取れることになっています >>2

[4] 要求データは、 CONTENT_LENGTH の長さのメッセージ本体のデータと、 更にその後に続く余分なデータで構成されます。 >>2

[5] CONTENT_LENGTHNULLでない場合はメッセージ本体がその長さ分提供されます。 は最低でもその長さのデータをCGIスクリプトが読み取れるようにしなければなりません>>2

[6] はその後にEOFを続けても構いませんし、更に別のデータを続けても構いません。 CGIスクリプトはたとえそのような余分なデータがあったとしても、それを読もうとしてはなりません>>2

[7] なお、CGIスクリプトはまったくデータを読まなくても構いません>>2

[8] なぜ意味も無い余分なデータの存在を認めているのかは明記されていませんが、 データのやりとりに使うバッファの類の管理の都合上、その方が良い場合もあるでしょうから、 それが不適切な実装とならないような配慮でしょうか。ただ CGIスクリプトが正確に動作することに依存した実装は一般的には安全ではありませんね。

[9] NPHスクリプトに関しては、データはが変更せずにそのままにして渡すべきです>>2

[10] これは >>11 も適用されないということなのでしょうか。

[11] 転送符号化を除去して CONTENT_LENGTH はそれを反映したものとしなければなりません。 バッファ・サイズ等の理由でそれが不可能な場合は要求誤りとして拒絶するべきです>>2

[18] HTTP_TRANSFER_ENCODING の値をどうするべきかは不明瞭です。

[12] 内容符号化を除去しても構いません>>2 その場合も CONTENT_LENGTH にそれを反映させる必要があります。

[17] その場合 HTTP_CONTENT_ENCODING も変更する必要があると思われますが、明記されていません。

[13] NPHスクリプト以外では文字コードMIME型の変換を適宜行なってから CGIスクリプトに引き渡して構わないと考えられます。

[16] CGIスクリプト要求データを読み込む前に CONTENT_LENGTH をチェックしなければなりません。また CONTENT_TYPE もチェックするべきです>>15

[19] HTTP 仕様上はサーバークライアント要求の全体を送信し終える前に処理を開始しても構わないことになっていますが、 CGI (やその規定を流用するサーバー側 API の実装) を使う場合には、 CGIスクリプトが処理を開始できるのはサーバー要求の全体を受信し、 CONTENT_LENGTH が確定した後になります。
[20] Content-Length: ヘッダー要求に含まれる場合でも、 当該 HTTP接続要求の途中で切断された場合に CGIスクリプト標準入力を読めることを保証するため要求全体が到着するのを待って CGIスクリプトを起動するか、あるいはCGIスクリプトがすべて読ま(め)ずに標準入力が閉じられることを許容するかの選択を迫られることになります。 RFC 上はこの場合をどう扱うべきか不明です。

派生仕様における要求データ

[21] CGI から派生した仕様も、CGI の仕様を引きずっています。

[22] PSGI では、標準入力に相当するファイルハンドルオブジェクト$env に含まれており、PSGIアプリケーションはそこから CONTENT_LENGTH 分読み込むことが期待されています。

制約

[23] 要求データの長さを CONTENT_LENGTH メタ変数としてアプリケーションに引き渡さなければならないという制約のため、 サーバー要求データの長さが確定するまでアプリケーションを起動できません。