HTTP レスポンスで複数ファイルを返す

CGI からファイルをダウンロードさせたい。これだけなら非常に単純で簡単なのだが、今回は一度に複数のファイルをレスポンスとして返したい。複数のファイルを tar などでまとめるという方法は使えない。

単数のファイルだったら適切な Content-Type ヘッダを出力して、CRLF を2つ出力した後、ボディ部分を出力してやればいい。実に簡単だ。でも、返すデータが複数の場合はどんな http response を返せばいいのか調べてみた。

- 複数ファイルを返すための Content-Type

結局 Content-Type 次第だと思う。適切な Content-Type とそれを理解する UserAgent であれば、複数ファイルだろうがなんだろうが返してあげられるはず。複数ファイルのまとめ送りに適した Content-Type がきっとあるはずだ。それを調べてみる。

すぐに思いついた先行事例は、フォームによるファイルのアップロードだ。フォームによるファイルのアップロードでは、複数ファイル同時送信なんて当たり前だ。たとえば、Yahoo Mail などで添付ファイルを付けるとき、一気に付けることができる。

そのときの Content-Type って何を使っているのかを調べればいい。Google で http ファイル アップロード content-type で検索。すると Content-type: multipart/form-data というものを使っていることが判明。なるほど、フォームから送るときはこうするんだな。

次に、思いついた先行事例はメールだ。メールで複数の添付ファイルを付けたときって、どんな Content-Type なのかを調べてみた。Netscape Messanger の sent ディレクトリから、過去に自分が送ったメールのうち、複数の添付ファイルをがあるものを探してヘッダを見てみた。

Content-Type: multipart/mixed; boundary="------------546DD04699AFAF892A7D6D3F"

と書いてある。なるほど、multipart/mixed でいいんだな。boundary はデリミタだな。

- 結論 HTTP レスポンスで複数ファイルを返すには multipart/form-data か multipart/mixed

サーバは Content-type: multipart/form-data か Content-Type: multipart/mixed で送信する。Content-Type: multipart/mixed が汎用的でいいだろう。で、それを理解するクライアントで受信させる。Internet Explorer や Mozilla などでは理解してくれないかもしれないが、今回は専用のクライアントを使用可能なので問題ない。

- 参考

連載：インターネット・プロトコル詳説（4）MIME（Multipurpose Internet Mail Extensions）〜後編
http://www.atmarkit.co.jp/fnetwork/rensai/netpro04/netpro01. ...

RFC 2616によると、以下のように定義されていた。multipart/mixed はかなりローレベルな型なんだな。
http://www.studyinghttp.net/rfc_ja/2616/sec3.html

3.7.2 マルチパートタイプ
MIME は、一つのメッセージボディの中に複数のエンティティをカプセル化する "multipart" タイプをいくつか供給する。すべてのマルチパートタイプは RFC 2046 [40] の section 5.1.1 で定義されているように、共通のシンタックスを共有し、メディアタイプ値の一部として境界パラメータ{boundary parameter} を含めなければならない。メッセージボディは、それ自身プロトコル要素の一部であり、それゆえに、body-parts 間の行末を表すためには CRLF のみを使用しなければならない。 RFC 2046 と異なり、どのマルチパートメッセージのエピローグ{epilogue} も空でなければならない。そのため、HTTP アプリケーションは (たとえ元のマルチパートがエピローグを含んでいても) エピローグを転送してはならない。これらの制限は、最後のマルチパートの境界線によってメッセージボディの "終端" を示せるように、マルチパートのメッセージボディに自己限界性質{the self-delimiting nature} を持たせるために存在する。

一般的に、HTTP はマルチパートメッセージボディを他のメディアタイプとは区別無く、すなわち単なる付加物{payload} として扱う。ただ一つ例外は、206 (Partial Content) レスポンス中に現れる時の "multipart/byteranges" タイプ (appendix 19.2) であり、その場合 section 13.5.4 や section 14.16 で表されるような、いくつかの HTTP キャッシュメカニズムによって解釈されるだろう。その他のすべての場合では、HTTP ユーザエージェントは、MIME ユーザエージェントがマルチパートタイプの受けとる時と同じ、または似たような振る舞いをすべきである。マルチパートメッセージボディの各々のボディ部分中の MIME ヘッダフィールドは、HTTP ではそれらの MIME セマンティクスによる定義以上にどんな意味も持たない。

一般的には、HTTP ユーザエージェントは、MIME ユーザエージェントがマルチパートタイプの受けとる時と同じ、または似たような振る舞いをすべきである。アプリケーションが認識できないマルチパートサブタイプを受け取った場合は、それを "multipart/mixed" に相当するものとして扱わなければならない。

注意: "multipart/form-data" タイプは、RFC 1867 [15] で表されるように、特に POST リクエストメソッド経由で処理するのに合ったフォームデータを転送するために特別に定義されている。