IE php ssl
phpでDBからCSVファイルを生成、submit押したらダウンロードという単純なプログラムを作成したんだけど、なぜかIEでだけダウンロードできない。またIEかよと。
調べてみたところ、どうやらCache関係でいろいろあるらしい。
no-cache指定されていると発生するようです。
なんとなく意味がわかりました。IEだとページ閲覧もダウンロードもすべてtemporary Internet filesフォルダへいったん保存されます。保存されたデータは、no-cache指定されていると、即削除されるため、ダウンロードの場合の、
ダウンロード→temporary→指定フォルダ
この流れが実現できないためかと思われます。ダウンロード→temporaryこの時点で削除されてしまうため。
PHPで、これを回避するには、cacheするように設定することで対応可能です。
PHPでCSVファイルのダウンロード(SSL+IE)（Tips for Programing）
実際にheader情報を確認してみると、確かに
Cache-Control: no-cache
Pragma: no-cache
とあるのを発見。まぁ冷静に考えてみれば、SSLなんだからこのようなCache設定になってるのは当たり前か。
てことなんだけど、以下のような情報も発見。
IE6 の場合、アクセスしたページの HTML ファイル本体とそのファイルで指定してあった css ファイルが一時フォルダにキャッシュされることが確認できた。ブラウザを閉じても、これらのファイルは残されたままだった。サイトの設計によっては、このキャッシュファイルの中にクレジットカード情報などが入っていることになるかも知れない。ちょっと恐ろしい仕様だと思われた。サーバー側でがんばって no-cache ヘッダを出すとか、対策をする必要があるだろう。
ff3 の場合、アクセスしたページの HTML ファイル本体とそのファイルで指定してあった css ファイルがメモリにキャッシュされた。ブラウザを閉じたらこれらのキャッシュは消えてしまった。後から出たブラウザだからこうなっているのかも知れない。キャッシュもきいて、センシティブな一時ファイルも残らない、バランスの取れた実装だと思った。
SSL と キャッシュの微妙な関係 （民芸的プログラミング 〜ソフトウェア開発日記〜）
IE・・・orz
今度実験してみよう。
apache ssl VirtualHost
IP ベースのバーチャルホストでは、応答する バーチャルホストへのコネクションを決定するために IPアドレスを使用します。ですから、それぞれのホストに個々に IPアドレスが必要になります。これに対して名前ベースのバーチャルホストでは、クライアントが HTTP ヘッダの一部としてホスト名を告げる、 ということに依存します。この技術で同一 IP アドレスを異なる多数のホストで共有しています。
名前ベースのバーチャルホストは通常単純で、それぞれのホスト名とそれに対応する正確な IP アドレスを DNS で設定し、異なるホスト名を区別するように Apache HTTP サーバを設定するだけです。さらに、名前ベースのバーチャルホストは不足する IPアドレスの需要を緩和します。したがって、IP ベースのバーチャルホストを選択すべき特定の理由がなければ名前ベースのバーチャルホストを使うべきです。IP ベースのバーチャルホストを使用することを考慮する理由として、
- 名前ベースのバーチャルホストに対応していない古いクライアントがある名前ベースのバーチャルホストが働くためには、クライアントはHTTP ホストヘッダを送ってこなければなりません。 これは HTTP/1.1 の仕様で要求されていて、すべての現代的なHTTP/1.0 ブラウザでも拡張として実装されています。とても古いクライアントをサポートしつつ、名前ベースのバーチャルホストを行いたい場合は、この文書の最後の方に書かれている解決策になるかもしれない方法を見てください。
- 名前ベースのバーチャルホストは SSL プロトコルの特徴により、SSL セキュアサーバには使えません。
- オペレーティングシステムやネットワーク装置のなかには、別の IP アドレス上でない場合、複数のホストを別扱いできないような帯域管理の方法を実装しているものがあります。
名前ベースのバーチャルホスト
できないらしい。見事にはまってしまったではないかorz
ちなみにバーチャルホストに https で接続要求を行うと、httpd.conf のServerNameで指定したサーバー自身のドキュメントルートを返すため、フルアクセス、つまりhttpをhttpsと置き換えて利用できるhttpsサーバーとしては使う事は出来ないということであり、バーチャルドメインでのSSL運用が出来無いと言う訳ではありません。言葉足らずだったのでこの辺を補足します。
特定のディレクトリに存在する掲示板など、通常のドキュメントルート下に設置できるのであれば、特定ディレクトリでのSSL暗号化保護においてバーチャルドメインによる運用は可能です。例えば、以下の様になります。
httpsでバーチャルドメインに接続した場合、ServerNameで指定した通常のドキュメントルートを返します。つまり、/aaa/というディレクトリを同一ディレクトリです。
https://VirtualDomain.com/aaa/ = https://ServerName.com/aaa/
ディレクトリ/aaa/をバーチャルドメイン、VirtualDomain.com の専用掲示板としてServerName.comのドキュメントルートに設置できるのであれば、SSLの保護に関してはバーチャルドメインによる運用は可能です。
ただし、クライアント認証などは、ServerName.comのサーバー証明書との兼ね合いで制限が出てくると思います。試してません。SSLによる保護は行えますので第三者から通信の盗聴を防ぐ目的は達成されます。
名前ベースのバーチャルホストの欠点
あれ？できるのか？じゃあapacheの設定が悪かったのか…。
