ファイルのダウンロードにはContent-Type：application/octet-streamが必要ですか。
HTTP標準 は言う：
このヘッダ[Content-Disposition：attachment]がapplication/octet-stream content-typeの応答で使用される場合、暗黙の示唆は、ユーザエージェントが応答を表示するのではなく、 `save response as ..を直接入力することです。ダイアログ。
私はそれを読む
Content-Type: application/octet-stream
Content-Disposition: attachment
しかし、私はContent-Typeはapplication/pdf、image/pngなどになると思いました。
ブラウザにファイルをダウンロードさせる場合はContent-Type: application/octet-streamが必要ですか？
いいえ.
あなたがそれを知っていれば、content-typeはそれがあることが知られているものであるべきです。 application/octet-streamはRFC 2046で「任意のバイナリデータ」として定義されています、そしてここでそれが唯一の意図された目的がディスクに保存されることである実体に適切であることの明確な重複があります。それとも別の方向から見てみましょう。 application/octet-streamを使って安全にできる唯一のことは、それをファイルに保存し、それが何のためのものであるかを他の人に知ってもらうことです。
Content-Dispositionの使用をimage/pngまたはtext/htmlなどの他のコンテンツタイプと組み合わせて、表示ではなく保存したいことを示すことができます。 text/htmlのケースでは、これを無視してしまうブラウザもありましたが、これはこの時点ではかなり前のことだと思います（そしてすぐに寝るので、全体のテストを開始するつもりはありません）。今ブラウザの;おそらく後で）。
RFC 2616は拡張トークンの可能性にも言及しており、最近のほとんどのブラウザは可能であればエンティティを表示したいという意味でinlineを認識しています（つまり、ブラウザが表示方法を知っているタイプであれば問題ありません）。 ）もちろんこれはデフォルトの振る舞いですが、ブラウザが使用するヘッダのfilename部分を含めることができることを意味します（おそらくファイル拡張子が問題のcontent-typeのローカルシステム標準に一致するように、多分調整しないで）ユーザーが保存しようとした場合の提案として）。
それゆえ：
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="picture.png"
「これが何なのかわからない。できればpicture.pngという名前のファイルとして保存してください」という意味です。
Content-Type: image/png
Content-Disposition: attachment; filename="picture.png"
「これはPNG画像です。ファイルとして保存してください。好ましくはpicture.pngという名前です」。
Content-Type: image/png
Content-Disposition: inline; filename="picture.png"
「これはPNG画像です。PNG画像の表示方法がわからない場合は表示してください。それ以外の場合、またはユーザーが保存することを選択した場合は、保存するファイルにpicture.pngという名前をお勧めします」.
inlineを認識するブラウザの中には常にそれを使うものもあれば、表示中にユーザが「save link as」を選択した場合（または少なくともIEを選ばない場合はそれを使うものもあります）以前はそのようになっていましたが、数年前に変更されている可能性があります。