Internet Explorer(IE)を使ってSSL接続を経由したサーバーからのファイルダウンロードに失敗する場合の対処法

最初にお断りしておきます。
この記事は自分のために書く記事です。何年後かの自分が同じ問題にぶち当たった時、この記事にたどり着けば問題が解決するということを意図しています。
特に後半に書くことは私の推測というか妄想です。妄想が始まるところは明記しますので、もし検索などでこの記事を読みに来た場合にはご承知起き下さい。
あと、このネタをここに書くことによって「お前ＸＸだろ？」とか「このサイトの中の人はＸＸの人なのでは無かろうか？」などと想像がついてしまう読者もいるかもしれませんが、それは心の中にしまっておいてくれると助かります……。

めんどうな前置きも済んだところで本題に入ります。

できないんですよ。本当にできない。はまりまくりです。この問題を解決するためにいろいろなキーワードを駆使して検索すると、個人サイトやプロバイダやWeb上でサービスを提供している企業のサイトがヒットしまくります。
それらをいちいち挙げるのは忍びないのですが、この記事が上がっている「はてな」にもこの問題に関連すると思われる記載がありました。リンクは貼りません。はてなだけを特別扱いするわけにもいかないので。興味がある人は探してみてください。
ちなみに、自分の環境ではないですが、検証してもらった結果、この問題は少なくともIE6 SP2、IE7、IE8で共通して発生しています。

さて、IEの問題ならMSに聞けばいいだろう？とお思いになる方もいらっしゃるでしょう。ところが、この問題はどうにもならないんですよ。

MSの説明その１ SSL 経由で Active ドキュメントをダウンロードするときにキャッシュしないようにします。
MSの説明その２(翻訳) ［IE］ HTTPS URL から Office ドキュメントまたは PDF ファイルを開こうとすると "ダウンロードできません" エラーが発生

でたよ。怪文書。とりあえず解読します。
まずその１。
ダウンロードできるようにする手順として

２．[ 詳細設定 ] タブで、セキュリティ ] までスクロールし、クリックして、暗号化されたページをディスクに保存しない ] チェックボックスを選択します。

というものが挙げられています。ふむふむ。なるほどねぇと。
そして、その２。
ダウンロードが失敗する理由として

[暗号化されたページをディスクに保存しない] が有効の場合

…………
はぁ？？？？？

矛盾している！矛盾しているんだよ。わけわかんないんだよ。ちなみにはてなは「その２派」でした。その２は翻訳だから翻訳に問題があるのかと思って原文にまであたっちまったよ。読めない英語読んじゃったよ。少なくとも俺のつたない英語力では日本語訳が間違えているとは思えないんだよねぇ。
その１とその２ではそもそも違う問題じゃないかと今現在問題を抱えていない人は思うかも知れませんが、SSL通信でダウンロードできないっていうのが本質的な問題なのでおそらくは同じ問題だと思われます。

開発者としてはユーザーにブラウザの設定変更をお願いするのは忍びないのですが、アプリ側ではどうにもこうにも対応ができなくてねぇ。
結局当方の場合は、チェックボックスをオンにすることによって解決する方向になりました。

さて、以下妄想です。検証していません。以上の事実から推測したデバッグ方針みたいな物だと思ってください。以下の推測が正しいとは限りませんよ。もちろん。くどいですね。すいません。

まずは、サーバー側のHTTP Headerだな。そこがね今回自由にはいじれなかった。SSL通信するテストサーバーの管理はなかなか厳しくて結局 no-cache 設定は外してもらえなかったんですよね。当然と言えば当然ですが。アプリ側で無理矢理ヘッダーに no-cache 以外のを突っ込んでみたりしたけれど結局うまく行かなかった。

もし、ヘッダーの設定さくっと変えられたら以下の結果が出るんじゃないかなぁと推測しているんですよ。

サーバー側でno-cacheを設定している時は、「暗号化されたページをディスクに保存しない」を有効にする
サーバー側でno-cache以外を設定している時には「暗号化されたページをディスクに保存しない」を無効にする。

つまりだ。この問題の根幹は、サーバーのキャッシュ設定とIE側の設定が一致していないとダウンロードできないと言う障害なんじゃないかなと推測したんです。
もしそうだとしたらサーバー側の設定をいくら修正しても絶対にダウンロードできないクライアント設定ってのが存在することになります。だからこのテストさえすれば「ユーザーにIEの設定を修正してもらうという対応が最善」と言い切れると俺は思うんだな。
俺はテストしてないけど(笑)。

さてさて、上にも書いたように、この問題は息が長いです。少なくともIE6、IE7、IE8のすべてで起こっています。MSへのリンクを見ればわかるようにずいぶん前に問題自体は把握しているはずなんです。パッチまで提供しているように見える(レジストリ修正が必要とか書いてあるからユーザーにはお願いできない対応ですけどね)。
なのに、なぜ未だに治ってないのか？

ここからさらに深い妄想……。
サーバー側のキャッシュ設定とIE側のキャッシュ設定を比較している1文が、上記IEのバージョンすべてから呼び出されている共通モジュールに入っているとしか思えないです。その共通モジュールはもしかするとIEの中にあるんじゃないのかも知れない。Windows のコアの部分にあるのかもしれない。もし仮にWindows OS内のモジュールだとすると、この問題はFirefoxやらChromeやらで起こらなかったので、MSがAPIを公開していない関数の中で問題の処理が行われているのでは無かろうか？そう推測しているんですよね。
IEの中だろうとWindowsの中だろうとわかれば簡単に治せると思うんですよ。ところが治っていない。その理由も２つ思い付きます。もちろん妄想ですよ。勘違いしないでくださいね。
一つは簡単な話。問題は認識しているけれどクリティカルではないと判断しているケース。ありがちありがち。でもその割にこの問題に対するいろいろなサイトのエクスキューズを見ているような気がします。でも良いか悪いかはともかく優先順位を決めるのはMicrosoft様なのでユーザーである我々にはどうにもならない話です。それがいやなら自分でソースが追えるようなブラウザ使えってことですねわかります。でもサービス提供側はそんなこと言ってられません！！！
まぁいいや。

もう一つ、こっちの方がより信憑性の高い妄想なのですが、問題のモジュールが至るところから呼び出されていて、しかもセキュリティを担保するために必須であり安易に変更をするとこの問題が発生しているところ以外でも予期せぬ問題が起こることが想定されるケースです。
わかりますよね。SSL通信の時に使うモジュールですよ。そこに穴があったらいろんなことが起こると思います。だからさわれない。問題があることはわかっていて、その１文(は言い過ぎ？)を修正すれば直ることがわかっているのに直せない、それこそ御法度の逆アセンブルかけたら一般ユーザーでも直せちゃうかもしれない程度の問題だけれど直せない、そんな状況であるのかなぁと推測しています。

いずれにしろ、この問題、根が深そうです。同じトラブルへの対処法で２つの相反する指示がほぼ拮抗して案内されているなんていうのは初めて見たかも。

と、ここまで書いて気づいた。もしかしてこのネタつい先日途中経過を書いたかも知れません。妄想部分以外は２重カキコかも。
まぁいいや。いろいろなキーワードを意図的に混ぜ込んだから検索するとこっちの記事がヒットするだろうな。

2009/07/02追記

本件、仕事として検証してもらえるかもしれません。大人の事情で私自身がやるわけにはいかないのですが……。今日もらった情報によると俺の妄想はどうやら前提条件からして間違えているっぽいです。ただ、まだ設定ができているか確認撮れてないので結論はだせません。テストで立てたサーバーでサーバーエラーが出たりするらしい。できれば自分でも検証したいんだけれど大人の事情で、ね。
一人でやるのなら時間をかければなんとかなるけれど、仕事だから何人もがそれぞれの役割をこなさなきゃならんので大変なのですよ……。