PDFファイルの特定のアドレスに行くと、Chromeは内蔵のPDFビューアを使って開くのではなく、PDFをダウンロードしてしまいます。すると、ページが真っ白になります
私のChromeの設定に問題はありません。他の PDF ファイルのアドレスを試すと、Chrome は期待通りに動作します (Chrome に内蔵された PDF ビューアを使用するように設定しています)。しかし、同じ問題のあるアドレスを試すたびに、ChromeはPDFをダウンロードして、空白のページを表示します
Windows10とChrome Version 63.0.3239.84 (Official Build) (64-bit)を使っています
今回私が問題にしている具体的なURLは、こちら（Google検索結果）
131 Rgrthat 2017-12-17
基本的に、これはウェブサイトがブラウザにそうするように指示したために起こります。時には、ウェブサイトの開発者が、ファイル共有サイトなどでよく見られるように、このような動作をしてほしいと判断したために発生します。他には、使用しているソフトウェア（フォーラムやブログソフトなど）のデフォルトオプションとして設定されているために発生することもあります。時には、サイト開発者が何をしているのかわからないからです
Content-Disposition
これは通常、サイトがレスポンスに Content-Disposition ヘッダを送信しているからです。具体的には、inline または attachment のどちらかを送ることができます
inlineは、特に指定がなければデフォルトで、ブラウザがブラウザウィンドウ内でファイルを開くことができる場合には、ブラウザがファイルを開くことを意味します
attachmentは、常にファイルをダウンロードすることを意味し、決してブラウザ内で開こうとしないことを意味します
ブラウザの開発者ツールを開くと、特定のリンクが以下のレスポンスヘッダを送信していることがわかります
Content-Disposition: attachment; filename="Schubert-Sonata-21-B-flat.pdf"
Content-Type: application/pdf
これは、ブラウザにファイルを常にダウンロード (attachment) し、URL から推測するのではなく Schubert-Sonata-21-B-flat.pdf というデフォルトのファイル名を与えるように指示します。さらに、ブラウザに(正しく) application/pdf ファイルであることを伝えます – しかし、それは attachment であるため、ブラウザはまだダウンロードすることをデフォルトにします
インラインでの取り扱いの詳細
Content-Dispositionがインライン(または指定されていない)の場合、ブラウザはそのファイルをデフォルトの埋め込みビューアで開こうとします。これは、ブラウザがそのファイルの種類を知っていて、ブラウザがその種類のファイルを開く方法を知っている場合にのみ機能します
Type detection
ファイルの種類は、Content-Typeヘッダでサーバ側で指定することができます。例えば、最も一般的なインライン型は text/html, application/javascript, text/css で、現代のウェブサイトの三大部分を構成しています。また、application/pdfのような難解なタイプを持つこともできます
もう一つの可能性としては、サーバが application/octet-stream の Content-Type を指定していることが考えられます。これは最も一般的な型で、ブラウザにファイルが任意のデータであることを伝えます
Content-Typeがサーバによって指定されていない場合(指定されている場合もあります)、ブラウザはファイルを読み込んでパターンを探すことで型を推測しようとする、スニッフィングとして知られていることを実行することができます
Type handling
inline または指定されていないファイルを受け取った場合、ブラウザは可能であればブラウザ内でそれを開こうとする必要があります。これを行うには、ファイルの種類を見て、その種類を認識していれば、それを開こうとします
型 application/octet-stream は特別に扱われました。これは、任意のバイト列を表す最も汎用的な型であることになっているので、この「型」のすべてのファイルに適用できるハンドラは存在しないことになっています。例えば、Firefox では、これは application/octet-stream のデフォルトハンドラ を設定できないことを示しています
いくつかのウェブサイトでは、非標準の型が使われています。application/force-downloadが使われているのを見たことがありますが、これはブラウザが型を認識していないか、型を使って他に何をすべきかを知らないからですが、application/octet-streamのような特別な処理ができないからです
ちょっとした歴史の授業
PDFがどのように扱われているかを見るために、ウェブの歴史を少し掘り下げてみましょう。ほら、過去には、ブラウザはPDFが何であるかを知りませんでした。そのため、PDFを開くことができませんでした。しかし、PDFビューアが内蔵されるようになるずっと前から、PDFがブラウザで開かれていたのを見てきましたが、それはどのように機能していたのでしょうか？
かつては、最近では限られた拡張機能やアドオンでできることよりもはるかに多くのコントロールでブラウザの機能を拡張することが可能でした。それらは プラグイン として最も一般的に知られていました。Internet Explorer では ActiveX コントロールでしたが、Mozilla Firefox や後の Google Chrome では NPAPI プラグインでした。これらのプラグインは、他のプログラムができることをすべて行うことができ、さらに、ブラウザが認識しないかもしれない特定のファイルタイプのハンドラとして自分自身を登録することができました。(ちなみに、これは後に大きなセキュリティリスクであることが判明し、これらの強力なプラグインのサポートは徐々に削除されていきました…)
プラグインの時代には、Adobe Acrobat Reader をインストールし、ActiveX または NPAPI プラグインをインストールして application/pdf MIME タイプを登録し、プラグインを使ってインラインでこれらのタイプを開くようにブラウザに指示していました
もちろん、これらのプラグインによるセキュリティやパフォーマンスの問題が多発した後、主要なブラウザベンダーは、ほとんどのプラグインのサポートを段階的に終了する一方で、独自のPDFビューアを組み込むことにしました。今でも見かけるのは、application/x-shockwave-flashを扱うAdobe Shockwave Flashだけです
実際には、Firefox の Preview in Firefox オプションなど、このためのコントロールがまだ残っています
これまでは、そのタイプを登録しているプラグインを複数選択できるようになっていました。例えば、Flashに登録されているタイプの一覧
当時は、HTML5 に付属する多くのメディア サポートの前の時代でもありました。それは PDF だけではありませんでした – ブラウザは MP4 コンテナや H.264 ビデオの扱い方を知らなかったり、MP3 ファイルの再生方法を知らなかったり、などなど。VLC や Windows Media Player のようなメディア プレーヤーによって提供されるプラグインを見たり、ウェブサイトに Flash に組み込まれたメディア プレーヤーが埋め込まれたりすることもありました
167 Bob 2017-12-17
説明を見つけました。見つけた回答によると、MIMEコンテントタイプがapplication/pdfではなく、application/octet-streamの「不正なMIMEタイプまたは一般的なMIMEタイプ」に設定されている場合、ChromeはPDFをダウンロードしてしまうようです
さらに詳しく, “ほとんどのウェブサーバは、デフォルトのapplication/octet-stream MIMEタイプを使用して未知のタイプのリソースを送信します。セキュリティ上の理由から、ほとんどのブラウザはそのようなリソースに対してカスタムのデフォルトアクションを設定することを許可しておらず、ユーザーはそれを使用するためにディスクに保存することを余儀なくされています。”
23 Rgrthat 2017-12-17
これは、HTTP Content-Disposition ヘッダーがファイルが添付ファイルであることを指定しているためです。これは、ファイルを直接開くのではなく、ファイルをダウンロードするようにブラウザに指示しています
この動作をオーバーライドできるChromeアドオンがあります
22 bwDraco 2017-12-17
