[505] CGI の応答responseは、 HTTP の応答の元となるデータをCGIスクリプトから鯖へと伝達するものです。 構文的にも意味的にもほとんどHTTP応答と同じですが、 若干の違いもあります。

仕様書

構文

[11] CGI応答は、

... の3つの部分により構成されます。あるいは CGI応答は次の3種類に分類できます。 >>6

CGI の頭欄

[304] CGI応答における頭欄は、

... の2種類に分けられます。詳しくはCGI欄の項をご覧ください。

構文

[308] 頭欄の構文は次のように定義されています >>6。

      generic-field   = field-name ":" [ field-value ] NL
      field-name      = token
      field-value     = *( field-content | LWSP )
      field-content   = *( token | separator | quoted-string )

[309] field-name は大文字・小文字不区別です。 >>6

[310] NULL (空文字列) とその頭欄を指定しないことは等価です。 >>6

[311] HTTP では空文字列であっても存在する場合と存在しない場合で意味が異なる頭欄があります。 仕様上 CGI ではそれが等価とみなされてしまいます。

[312] CGI では折り畳みを使うことはできず、頭欄はそれぞれ一行で表さなければなりません >>6。

[313] 構文上、 LWSP に改行が含まれるので、それよりも強い制約があることになります。 (というか NL を LWSP として使ってしまうと解釈が一意でなくなってしまいますが・・・。)

[314] : の後や、 field-value 内の字句の間には空白を挿入できます。 >>6

[315] この空白は LWSP のことを指しているのでしょうか。またこのような字句化は Location: 欄の構文と矛盾しているようですが、良いのでしょうか・・・。 と思いましたが CGI RFC で規定される3つの CGI欄にはこの一般構文は適用されないようです・・・。 しかし HTTP のいろいろな頭欄がこの字句化とは矛盾しますね。 (結果として構文的に表現可能ではあるのでしょうが・・・。)

[321] CGI欄はそれ以外よりも先に出力するべきです。その方が鯖のメモリー管理上都合がいいことがあります。 >>322

プロトコル依存の頭欄

[316] CGIスクリプトは適宜プロトコル依存の頭欄 (HTTP頭欄など) を返すことができます。 鯖はクライアントとのプロトコルの規定その他に応じて適宜それを変形しなければなりません >>6。

文書応答

[12] 文書応答document responseは、クライアントに対して文書を返すものです。 >>6

[17] 鯖はCGI応答を適宜変形してクライアントとのプロトコルに適合するようにしなければなりません。 >>6

[18] そうできないときにどうしなければならないかは明記されていません。通常は適合といっても完璧に適合するかどうか鯖が検査するのではなく、 実用上十分な程度の要件を満たすよう整形や転送符号化等を適用するくらいです。

[324] Apache2 では Content-Type: は省略可能なようです。

局所リダイレクト応答

[19] 局所リダイレクト応答local redirect responseは、CGIスクリプトが指定した path に対するアクセスであったものとして再度鯖によって処理しなおすことを指示するものです。 >>6

[22] 鯖は

      scheme "://" server-name ":" server-port local-pathquery

... という URL (local-pathquery が Location: 欄で指定された値) に要求があったものとして処理しなおさなければなりません。 >>6

[23] リダイレクト・ループに対する処理をどうするべきか明確にされていません。[24] >>21 が守られていない場合にどうなるのかも明確にされていません。

[501] Apache2 では HTTP の頭欄が指定されていると、それがリダイレクト先の HTTP 応答頭欄に加えて応答に含まれます。複数段リダイレクトされているとそれらがすべて順に (後のものほど後に) 付加されていきます。

[328] Apache2 では >>23 は 500 エラーとなります。 >>501 はこのエラーの場合も含めて適用されます。

クライアント・リダイレクト応答

[25] クライアント・リダイレクト応答client redirect responseはクライアントに対してリダイレクトを指示するものです。文書付きと文書無しの2種類があります。 それぞれの要件は次の通りです >>6。

[35] 鯖は文書無しの場合 302 応答を返さなければなりません。 >>6

[303] 鯖は文書付きの場合CGI応答を適宜変形してクライアントとのプロトコルに適合するようにしなければなりません。 >>6

[327] Apache2 では Status: が無く絶対pathであれば >>19 により、それ以外ならこちらにより処理するようです。

[325] Apache2 では (現実の Webブラウザーの実装がそうであるように) Location: の値が相対URLであっても構いません。

[326] Apache2 では Status: が無ければ >>27、あれば >>31 と解釈されるようです。 >>27 の場合 Content-Type: や応答本体があっても無視されます。

処理モデル

[7] CGIスクリプトは常に空でない応答を鯖に送り返さなければなりません。 >>6

[8] CGIスクリプトから鯖にデータを送る方法はシステム定義です。 別途定義がない場合、「標準出力」ファイル記述子によってデータを送ることになります。 >>6

[9] CGIスクリプトは応答を準備するに当たり REQUEST_METHOD をチェックしなければなりません。 >>6

[10] 鯖はタイムアウトを設定して構いません。その場合、タイムアウトになるとスクリプトを終了させて構いません。 >>6

[320] 応答本体response-bodyは、零個以上の OCTET の列です。これはクライアントへと返されることになります。鯖は CGIスクリプトが提供したデータをすべて、 EOF に到達するまで読まなければなりません。 それをそのまま無変更で送信するべきです。 ただし、 HEAD の場合、転送符号化、内容符号化、 charset の変換が必要な場合を除きます。 >>6

[323] 実装によっては標準誤り出力が標準出力と共にCGI応答に使われてしまうことがあります。

[504] 標準出力を閉じると HTTP応答も終了したものとして扱う実装が一般的ですが、 特にそう規定されているわけではなく、そうなっていない実装もあります。また、 標準出力が閉じられると CGIスクリプトを終了させる実装もあるようです。

HEAD の場合

[1] HEAD メソッドの場合、 CGIスクリプトは応答本体を指定してはなりません。 鯖は指定されても捨てなければなりません。 >>2

[3] 多くのCGIスクリプトは HEAD メソッドに対応しておらず、 GET と同じものを返し、結果として >>1 の要件に違反しています。

NPH スクリプトの場合

[4] NPHスクリプトは完全な HTTP 応答メッセージを返すことが求められています。 詳しくはNPH応答の項を参照してください。

メモ

[502] CGIの動作について ( ( 版)) http://chaichan.web.infoseek.co.jp/qa3000/qa3198.htm

[503] close(STDOUT)するとCGIが終了する。 | OKWave ( ( 版)) http://okwave.jp/qa/q6476437.html