要約

  • 2015年のRFC 7578は、同じフィールド名のパートをまとめることと、中継側が結果を並べ替えることを禁じた。通信の成功だけでは、アプリケーションが情報を保ったとはいえない。
  • Larry Masinterが関わった仕様の変遷は、表現の忠実さ、業務上の解釈、ファイルを使う許可を別々の判断として捉える手掛かりになる。

同じ名前が付いているからといって、同じ一つの値とは限らない。一つの添付欄で二つの証明書を受け付けるフォームを考えてみる。それぞれのファイルは、同じフィールド名を持つ別々のパートとして届く。補助処理が名前ごとに一つの値だけを持つ辞書へ変換し、最後のファイルしか残さなければ、通信に欠落がなくても業務記録は欠ける。これは特定の製品で確認した事故ではなく、仕組みを説明する例である。Larry Masinterのmultipart仕様を読む際には、この「届く」と「残る」の違いが重要になる。

アップロードの提案から、互換性を保つ仕事へ

1995年11月のRFC 1867は、E. NebelとL. Masinterの共著だった。当時の通常のHTMLフォームには、ローカルファイルの提出を一様に求める仕組みがなかった。提案は、ファイル選択の拡張とMIMEに適合する送信表現を組み合わせ、古いブラウザー向けの移行策も扱った。ただし分類はExperimentalであり、インターネット標準ではないと明記されている。提案の存在を、そのまま広い普及の証拠にはできない。

L. Masinterが著者として記される1998年8月のRFC 2388はStandards Trackの文書となった。2015年7月のRFC 7578がそれを置き換える。後者も同じ著者名を掲げるが、公開レビューを経たIETFコミュニティーの合意であることを記している。継続的な貢献を評価することと、MIMEやブラウザーの振る舞いを一人の発明に帰すことは違う。本人の旧ホームページには2014年という時点が示され、当時の仕事や公開写真の文脈を確認できる。現在の勤務先を証明する資料ではない。

multipartのボディーは、境界で区切られたパートの列である。各パートのContent-Dispositionはform-dataを指定し、nameパラメーターで元のフィールド名を示す。テキストとファイルを一緒に運びながら、別々の要素として扱える。2015年仕様はHTMLやHTTPだけに用途を限定せず、人が画面のフォームに記入しないアプリケーションも視野に入れている。添付ボタンは、この表現を利用する一つの入口にすぎない。

あいまいだった二つの点

1998年仕様の5.5節は、フォームの順序と返却値の順序の関係、同名フィールドの扱いを定義していなかった。2015年仕様の5.2節はここを明確にする。順序が定まっているフォームの処理側は、その順に結果を返すべきである。中継側は結果を並べ替えてはならず、同名のパートを一つにまとめてはならない。最初の規則はSHOULDであり、自然な順序のないフォームにまで順序を作らせる絶対要件ではない。

複数の同名パートは、むしろ正しい送信方法でもある。4.3節は、一つのフィールドで複数のファイルを送る場合、同じnameを持つ別々のパートにすることを求める。旧仕様が提案したmultipart/mixedの入れ子は非推奨となり、広く使われていた方式に合わせた。同時に、幅広い用途を想定する受信側には旧方式も扱うよう推奨している。すべての受信側への無条件の互換義務ではないが、仕様改訂だけで昔のクライアントが消えるわけではないと認めた形だ。

一つの値への変換が常に誤りなのではない。アプリケーションが個数を確認し、自分の規則として一つを選んだ後なら、単一値の表現は意図的な判断になり得る。先に変換してしまうと、その判断に必要な証拠がなくなる。列や複数値を保てる構造は観察可能性を残すが、それ自体が二つの業務操作を許すわけでもない。受け取った構造への忠実さと、値の受理方針は別問題である。

ファイル名に渡してはいけない権限

フィールドのnameと、ファイルのfilenameは異なる情報だ。RFC 7578はファイル内容に名前を付けることを推奨する一方、名前が得られない、意味を持たない、私的な情報である場合には省略を認める。受信側は提供された名前を無条件に使ったり、そこに含まれるディレクトリー情報を保存先の指示として扱ったりしてはならない。機器から直接送られるストリームに、架空のデスクトップファイル名を付ける必要はない。

文字コードにも移行の履歴がある。仕様は相互運用性のためASCIIのフィールド名を勧め、非ASCIIが避けられない場合にはUTF-8を一貫して使うよう勧める。既定の文字集合に関する慣行を記し、過去の生成側がさまざまな符号化を用いたことにも注意を促す。この形式でfilename*は禁止されるため、別のヘッダーの文脈で得た知識をそのまま当てはめることはできない。

さらに、ボディーを元のフォームへ結び付ける固有の仕組みはない。処理先やアプリケーションが持たせる情報で文脈を定める責任は、形式の外側にある。multipartは機密性や完全性も保証しない。1995年の提案は、本人が明示的に送るよう求めていないローカルファイルの送信を警戒した。2015年の文書も、意図しない開示、ファイルの上書き、実行可能な内容を扱う。構文を読めたというだけで、これらの信頼判断を済ませたことにはならない。

資料と限界

本稿は上記の三つのRFCと、時点の明らかな本人のページを比較した。現在のライブラリーの実態調査、事故率の測定、攻撃試験は行っていない。運用上の含意は編集上の分析である。公開の顔写真はAI編集肖像の本人性を裏付ける参照に使い、背景の作業空間は実在の職場ではなく創作とした。