要約

  • HTMLのdownload属性は保存を求め、ファイル名を提案できる。HTTP応答のContent-Dispositionも名前を伝えられる。
  • 2013年のMozillaの報告と2017年のWHATWGの議論には、別サイトのファイルを保存するときの判断の揺れが残っている。

「資料をダウンロード」と書かれたリンクを押す。保存先には当然、資料らしい名前のファイルが来ると思う。ところがブラウザーの窓口には、リンクを置いたページと、実際に中身を送るサーバーから、それぞれ別の札が届くことがある。宅配便なら差出人に電話をかけたいところだが、ウェブのクリックは一瞬で終わる。窓口がその場で判断する仕組みが必要だった。

サーバーの札については、2011年6月のRFC 6266が詳しい。HTTPのContent-Dispositionにattachmentがあれば保存を促し、filenameまたは国際文字を扱えるfilename*が名前の候補を示す。規格はその候補を助言として扱う。ディレクトリーを指す文字列、危険な拡張子、紛らわしい制御文字をそのまま採用すれば、ファイルは思わぬ場所や姿で現れる。ブラウザーには荷札を読むだけでなく、受け取り場所を守る仕事がある。

ページ側にも道具が増えた。Chromiumの機能記録はa[download]をM14で利用可能になった項目として載せている。HTMLのリンクにこの属性を置けば、ページは「移動ではなく保存」と希望を伝えられ、属性値で名前も提案できる。ページ内で作ったデータをファイルにする場合など、便利さは分かりやすい。しかしリンク先が別サイトの画像なら、ボタンの作者とファイルの提供者は別人だ。

Mozillaに2013年に寄せられた報告は、その違いを一枚の画像で示した。外部サイトの画像へdownload="filename.png"を付けたリンクを押すと、Firefoxは画像を開き、Chromeは保存した。報告者はFirefoxの不具合だと考えたが、Mozilla側は必要な安全措置だと説明し、報告を無効として閉じた。同じ画面の同じクリックでも、誰が中身を提供するかが結果に入ってくる。

2017年4月のWHATWGの議論では、差がさらに細かく整理された。当時のFirefoxとSafariは、この条件ではdownloadを無視した。一方のChromeは保存を始めるが、ページが書いたファイル名を採用しなかった。規格の編集者は、当時の手順がどちらの挙動も許していると述べ、足並みをそろえる余地を示した。「保存するか」と「何という名前で保存するか」は、同じ判断ではなかった。折しもWebKitはSafari 10.1での属性対応を発表し、Blobからファイルを作る用途も紹介している。便利な機能ほど、札の扱いを決める必要があった。

現在のHTML標準では、ページのdownloadは保存の意図と推奨名を示し、サーバーのContent-Dispositionが名前を上書きする場合がある。別オリジンの内容では、サーバーのattachmentが重要な合図になる。最後にブラウザーがローカルの保存先と安全な名前を決める。

ダウンロードボタンは小さい。そこを通る権限の話は小さくない。ページは欲しい動作を示し、サーバーは送る物について語り、ブラウザーは利用者のコンピューターに置く責任を引き受ける。荷札が三枚届いても、受領印は一つだ。