Landscape トップページ | < 前の日 2003-11-10 2003-11-11 次の日 2003-11-12 >

Landscape - エンジニアのメモ 2003-11-11

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


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

この記事の直リンクURL: Permlink | この記事が属するカテゴリ: [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 リクエストメソッド経由で処理するのに合ったフォームデータを転送するために特別に定義されている。


すべての記事の見出し (全1029件)
全カテゴリの一覧と記事の数
カテゴリごとに記事をまとめ読みできます。記事の表題だけを見たい場合は、すべての記事の見出し (カテゴリ別表示) へ。

直近30日分の記事
2007-04-23 (Mon)
2007-03-07 (Wed)
2007-02-27 (Tue)
2007-01-17 (Wed)
2007-01-15 (Mon)
2007-01-14 (Sun)
2007-01-08 (Mon)
2006-12-01 (Fri)
2006-11-22 (Wed)
2006-11-20 (Mon)
2006-11-19 (Sun)
2006-09-30 (Sat)
2006-08-29 (Tue)
2006-08-04 (Fri)
2006-07-27 (Thu)
2006-07-23 (Sun)
2006-07-17 (Mon)
2006-07-10 (Mon)
2006-07-06 (Thu)
2006-07-03 (Mon)
2006-06-29 (Thu)
2006-06-28 (Wed)
2006-06-27 (Tue)
2006-06-25 (Sun)
2006-06-19 (Mon)
2006-06-18 (Sun)
2006-06-15 (Thu)
2006-06-11 (Sun)
2006-06-01 (Thu)
2006-05-30 (Tue)
プロファイル
斎藤 宏明。エンジニアです。宇都宮市に住んでいます。
リンク
RSS
スポンサードリンク
Powered by
さくらインターネット

© 斎藤 宏明 Saito Hiroaki Gmail Address
Landscape - エンジニアのメモ http://sonic64.com/
Landscape はランドスケープと読みます。
ひらがなだと らんどすけーぷ です。