IE

IE では特定の URL を任意のセキュリティゾーンに指定できるが、その際の https 限定オプションは入力チェックとしてしかか機能せず、実際のサイト接続時にはチェックされない。

- 任意のサイトをイントラネットゾーンや信頼済みサイトゾーンに設定可能

Internet Explorer は、ウェブサイトをいくつかの「ゾーン」に分類し、それぞれ異なるセキュリティ設定を適用することができる。インターネットゾーンのサイトは厳格なセキュリティを適用し、イントラネット内のサイトは身内なのでゆるいセキュリティで利便性を優先する、といったことができる。

この設定はインターネットオプションの「セキュリティ」タブで設定できる。たとえば、イントラネットゾーンとして扱いたいサイトがある場合は「イントラネット」を選び、「サイト」ボタンを押し、「詳細設定」ボタンを押すことで URL を設定する画面に入れる。ちなみに設定画面には以下のように書いてある。

このゾーンに Web サイトを追加/削除できます。このゾーンのすべての Web サイトには、このゾーンのセキュリティの設定が適用されます。

- 「このゾーンのサイトにはすべてサーバーの確認 (https:) を必要とする」オプションは入力時のチェックでしかない

私の所属するチームでこの機能を実際に試していたところ、以下のオプションが有効にならないんだけど、という相談を受けた。

このゾーンのサイトにはすべてサーバーの確認 (https:) を必要とする(&S)

このオプションを有効にしても、http しかサポートしていないサイトに接続できてしまったとのこと。私の環境でも同じ現象が出た。

テスト環境は、OS が WindowsXP Professional With Service Pack2、IE が IE 6.0.2900.2180.xpsp_sp2_gdr.050301-1519 だ。

いろいろ試しているうちにわかったことが、このオプションは入力時にしか機能せず、接続時には機能しないということだ。さも接続時に https かどうかをチェックして、そうでなければイントラネット扱いしないという動きをしてくれそうな文言だが、そうではない。サイトの URL を入力する時にしか効かない入力チェックでしかない。

確かに、「このゾーンのサイトにはすべてサーバーの確認 (https:) を必要とする」チェックボックスをオンにしている場合、https: で始まらない URL をゾーン設定の URL として入力すると以下のメッセージが出る。

イントラネット

このゾーンに追加したサイトには、https:// prefix を使用する必要があります。この prefix は、セキュリティで保護された接続を保証します。

ここまではいい。しかし、ここの URL にはドメインだけを入力することもできる。オプションの挙動を把握していない人は以下のようなことをしてしまうだろう。

チェックを外した状態で http://sonic64.com や https://sonic64.com を設定。オプションをオンにすれば https の接続のみイントラネット扱いとしてくれることを期待し、チェックボックスをオンにして http://sonic64.com にアクセスする。この例では、ユーザーの期待に反してすべてのサイトが見事にイントラネットゾーンとして扱われてしまう。

また、チェックボックスをオンにする前に入力した http や ドメイン指定のサイトも入力チェックの対象外。この挙動は理解できなくもないが、設定済みのサイトに https: 以外で始まるものがあるという警告くらいは欲しい。

非常にわかりにくい。なぜこんな不完全な機能なんだろう? また、この不完全な機能でも、オプションの文言を工夫して入力時にしかチェックしないことを明示すればユーザーを適切に誘導できるはず。なぜそうしないんだろう?

IE で ローカル HTML ファイルを使用するとセッション Cookie が失われるという問題。問題になるのはブラウザを閉じると消える「セッション Cookie」だけで、有効期限の設定された Cookie なら問題は発生しない。

[IE55][IE6] ローカル HTML ファイルを使用するとセッション Cookie が失われる
http://support.microsoft.com/default.aspx?scid=kb;ja;315713

以下の条件をすべて満たす場合、Internet Explorer で保持するべきはずのセッション cookie が失われます。

・ Internet Explorer 5.5 以降を使用している
・ セッション cookie を使用している(cookie に有効期限が設定されていない)
・ ローカルファイルを使用している (ホームページを c:\homepage.html や \\server\share\homepage.html にしている、file:// で始まる URL を使用している、など)
・ 新しいウィンドウを開く(ウィンドウの数を増やす)ような操作を行っている (window.open や window.showModalDialog で子ウィンドウを開く、リンクを [新しいウィンドウで開く] など)
・ ウィンドウを閉じる(ウィンドウの数を減らす)操作を行った後、残りウィンドウの数が 1 つ(または 0)になった

この IE のバグを回避するため、いろんなプロジェクトでそれぞれ対策を取っていた。UI をデザインする段階で window.open などを使わないようにしたり、Cookie に必ず有効期限をセットするようにして回避したり。ASP.NET で、かつ要件が許すときは、web.config で IsCookieless を True にし、ASP.NET の Session ID をクエリストリングに入れて Cookie を使わないようにして回避したこともあった。

IE6 SP1 で修正済みとのこと。パッチが出てたとは。気づかなかった。

Internet Explorer 6 Service Pack で修正される問題の一覧
http://support.microsoft.com/default.aspx?scid=kb;ja;JP32648 ...

315713 (http://support.microsoft.com/kb/315713) [IE55][IE6] ローカル HTML ファイルを使用するとセッション Cookie が失われる

たまに Internet Explorer や IE 互換のタブブラウザで印刷することがある。後で見返したときに便利なように、印刷するときにページのヘッダかフッタに時刻を入れておきたい。

- Internet Explorer の印刷時ヘッダとフッタのカスタマイズ

IE の上部メニューの ファイル(F) の 「ページ設定」の「ヘッダーとフッター」に書式指定文字列を記述することでヘッダやフッタをカスタマイズできる。

24時間表記で時刻を入れるには、&T を使えばいい。これはデフォルトでは入っていない。

ヘッダの書式指定文字列。
私の設定ではデフォルトのまま。左上にページタイトル、右上に 現在ページ数/総ページ数 を配置。

&w&b&p/&P Page

フッタの書式指定文字列。
私のフッタには &T を追加した。左下に URL、右下に印刷した年月日時分秒を配置。

&u&b&d &T

上記設定だと以下のように印刷される。

Landscape - エンジニアのメモ                  1 / 64 Page



                    本文



http://sonic64.com/                            2005/12/20 10:10:43

中央に文字を配置することもできる。ロゴを入れたりできると楽しいんだけど、残念ながらできないみたい。

共有のプリンタだったら、印刷物が混ざらないように印刷者名を固定的な文字列として入れておくといいかも。あ、でもそれって IE の設定でやらなくても、プリンタドライバの設定でできるかな。

InernetExplorer ヘルプ 印刷時に Web ページの外観を変更するには

印刷する内容 文字

ウィンドウ タイトル &w
ページのアドレス (URL) &u
短い形式の日付 (コントロール パネルの [地域と言語のオプション] での指定と同じ) &d
長い形式の日付 (コントロール パネルの [地域と言語のオプション] での指定と同じ) &D
コントロール パネルの [地域と言語のオプション] で指定する形式の時刻 &t
24 時間制の時刻 &T
現在のページ番号 &p
総ページ数 &P
右揃えの文字列 (&b に続けて文字列を入力) &b
中央揃えの文字列 (&b と &b の間に文字列を入力) &b&b
アンパサンド (&) &&

Internet Explorer 6 では、インターネットオプションで設定を行うことで meta refresh によるページ移動が無効になる。

ここで言う meta refresh というのは、以下の meta 要素によるページの自動遷移のこと。発動までの時間を指定できるので、0秒にしてリダイレクトとして使ったり、数秒だけコンテンツを見せた後自動ジャンプにするようにしたり、url を指定しないようにしてページを一定時間ごとに自動的に再読込させたい時などに使う。

<meta http-equiv="refresh" content="0; url=http://sonic64.com/">
<meta http-equiv="refresh" content="0"> <!-- url 省略時は自分自身に遷移する -->

- IE6 で meta refresh によるページの自動読み込みを無効にする

IE のメニューバーの「ツール (T)」 の「インターネットオプション (O)を開く。
「セキュリティ」タブを開く。
「インターネット」のアイコンを選択する。
「レベルのカスタマイズ (C)」ボタンを押す。
「その他」カテゴリにある「ページの自動読み込み」を「無効にする」を選択。

ちなみに、IE6 ではセキュリティレベルが「中」のとき、「ページの自動読み込み」は「有効にする」になっている。

XML ファイルが置いてあるドメインと XSL ファイルが置いてあるドメインが異なっている場合、Internet Explorer のセキュリティ設定によってはエラーが出て XSLT が有効にならないことがある。インターネットオプションで設定することで対処可能。

- アクセスが拒否されました。リソース ' http://sonic64.com/rss.xsl ' の実行エラーです。

当サイト Landscape の RSS http://sonic64.com/cl.xml は、2005-03-16 の「RSS を XSLT で html に変換して見栄え良く表示する」で作成した XSLT http://sonic64.com/rss.xsl を使い、ブラウザで見たときに見やすくなるようにしてある。

しかし、RSS にアクセスすると、以下のようなエラーが表示されるようになってしまった。

XML ページを表示できません
XSL スタイル シートを使用した XML 入力は表示できません。エラーを訂正してください。 [更新] ボタンをクリックするか、または後でやり直してください。

アクセスが拒否されました。リソース ' http://sonic64.com/rss.xsl ' の実行エラーです。

- XSTL 実行時にエラーになる原因を探る

何でエラーになるんだろう? 2005-10-12 の「RSS広告社の広告プログラム Trend Match に参加」したことが原因だろうか? http://sonic64.com/cl.xml にアクセスされたら http://rss.rssad.jp/rss/qArzgZHGLg5Z/rss_0003 に HTTP 302 Moved Temporarily でリダイレクトしているのだが、それが悪いってこと? まさかそんなことはないはず。

Google で アクセスが拒否されました リソース の実行エラーです を検索しても、有力な情報は得られなかった。

おかしいなあ、httpd のアクセスログには XSL ファイルへのアクセスは HTTP Status 200 OK で記録されてる。つまり、XSL ファイルには HTTP 的にアクセスできている。XSLT ってクライアント側で行うものだし、rssad.jp のサーバ設定も関係ない。何だろう?

いろいろ切り分けて考える必要があるな。試しに Mozilla でやってみると、やっぱり XSLT が実行されない。あと、私のサイト sonic64.com 内に別の RSS を置き、同じ XSL を参照すると正常に XSLT が実行される。ということは、RSS や XSL ファイル自体の問題ではないってことだ。クライアント側の問題のような気がする。

IE のオプションで何かあるんじゃないか? 探してみる。あった。

- 「ドメイン間でのデータソースのアクセス」を「有効にする」で IE の XSLT が有効になった

IE だと以下の設定を行うことで、ドメインをまたいだ XML と XSTL による XSLT が有効になる。

IE のメニューバーの「ツール (T)」 の「インターネットオプション (O)を開く。
「セキュリティ」タブを開く。
「インターネット」のアイコンを選択する。
「レベルのカスタマイズ (C)」ボタンを押す。
「その他」カテゴリにある「ドメイン間でのデータソースのアクセス」を「有効にする」を選択。

ちなみに、セキュリティレベルが「中」のとき、「ドメイン間でのデータソースのアクセス」は「無効にする」になっている。

つまり、ドメインをまたがって XSL ファイルにアクセスすることは、セキュリティ的に良くないのでデフォルトで無効にしてあるということか。それもそうか。参照先の XSL ファイルが差し替えられた場合、出力する HTML も差し替えられるということだもんね。

そういえば、amazon は 2004-04-15 の「amazon ウェブサービスでリアルタイムに価格を表示」などのサービスにおいて、XSLT をブラウザ任せにせずにわざわざ HTTP GET している。高度な XSLT プロセッサを提供するというのが第一の理由だろうが、このセキュリティ制限に引っかからないようにするというのも、理由の一つなんだろうな。

Yahoo Search http://search.yahoo.co.jp/ やその検索結果画面 http://search.yahoo.co.jp/search?p=sonic64.com&ei=UTF-8& ... で、日本語が表示されなかったり文字化けするときは、ブラウザの UserAgent と Accept-Charset の設定を見直すと文字化けを解消できるかもしれない。

- UserAgent によって返されるデータが異なる?

IE コンポーネント型タブブラウザの Sleipnir Version 1.66 で Yahoo Search を見ると、アルファベットと数字以外が全く表示されない。文字化けというより、文字が欠落しているという感じ。Sleipnir がおかしいのかな? と思って Internet Explorer でブラウズすると、問題なく表示される。Firefox でも問題なく表示される。Firefox は Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.12) Gecko/20050919 Firefox/1.0.7 を使っている。

文字化けしたときの html ソースを見ると、charset が ISO-8859-1 になっている。日本語文字列が入っているのに ISO-8859-1 を指定されていれば文字化けして当然。というか、そもそも htmlの データ自体がおかしいようだ。meta だけじゃなくて、データそのものが変。

<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"><title>Yahoo!  </title>

いろいろ試した結果、UserAgent が Sleipnir Version 1.66 だと文字化けするようだ。Firefox でも同じ現象。ただ、Accept-Charset があると化けない。たとえば、Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7 を送出している場合は utf-8 で返してくれる。

文字化けしたときの HTTP トランザクション。わざと Accept-Encoding を送らないようにた Firefox でリクエストしてみた。Content-Type レスポンスヘッダにも text/html; charset=ISO-8859-1 が入ってる。

GET / HTTP/1.1
Host: search.yahoo.co.jp
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.12) Gecko/20050919 Firefox/1.0.7
Accept: text/xml,application/xml,application/xhtml+xml,text/html; q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Keep-Alive: 300
Connection: keep-alive

HTTP/1.x 200 OK
Date: Tue, 04 Oct 2005 10:18:06 GMT
P3P: policyref="http://privacy.yahoo.co.jp/w3c/p3p.xml", CP="CAO DSP COR CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV"
Cache-Control: private
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=ISO-8859-1
Content-Encoding: gzip
Set-Cookie: **************************

- UserAgent を IE に偽装したら文字化けしなくなった

Sleipnir に Accept-Encoding を送出させるようにすることは大変そうなので、UserAgent をIE に偽装してやれば対処できそうだ。試しに Sleipnir の UserAgent をMozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) に偽装したら文字化けしなくなった。

- 何が文字化けの原因?

これって何が原因? Apache2 で Default Charset が ASCII になっちゃうという問題があると聞いたことがあるけど、まさか Yahoo がそんな初歩的な問題につまづくとは思えない。そもそも Yahoo って Apache 使ってるのかな?

HTTP サーバー以外の部分も原因として挙げられそう。Yahoo ともなるとクライアントとサーバの間にデータの圧縮やロードバランシングを担当する機器がいろいろ入ってるだろうから、それのどこかがおかしいとか?

ieHTTPHeaders は HTTP リクエストとレスポンスを表示してくれる IE 用プラグイン。

2005-04-16 に書いた「Live Http headers - HTTP ヘッダ表示ツール」は Mozilla / Firefox 用だったが、こちらは IE 用。Firefox を使えない環境で役立つ。

- ieHTTPHeaders のダウンロードとインストール

オフィシャルサイトから setup.exe をダウンロードして実行するだけ。最新版は Version 1.6。インストールする際は IE をすべて閉じておいた方が無難。

blunck.info
http://www.blunck.info/iehttpheaders.html

Download ieHTTPHeaders - Just download and execute the installer
http://www.blunck.se/iehttpheaders/ieHTTPHeadersSetup.exe

- ieHTTPHeaders の使い方

IE の上部メニューから、表示 (V) -> エクスプローラーバー (E) -> ieHTTPHeaders を選択する。
すると IE のウインドウ下部に HTTP リクエストとレスポンスを表示するウインドウが出現する。
あとはブラウズすればリクエストとレスポンスが随時表示される。

HTTP リクエスト/レスポンス表示ウインドウから文字列をコピーすることもできる。CTRL + C を押すだけ。メニューには無いけどね。

表示サンプル。

GET http: //sonic64.hp.infoseek.co.jp/ HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/x-shockwave-flash, */*
Accept-Language: ja
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Host: sonic64.hp.infoseek.co.jp
Proxy-Connection: Keep-Alive
Cookie: ******=**********************; ***=************

HTTP/1.1 200 OK
Date: Wed, 27 Apr 2005 00:37:17 GMT
Server: Apache
Content-Length: 70461
Content-Type: text/html
X-Cache: MISS from ****************
Age: 0
Proxy-Connection: close
Via: HTTP/1.0 ********** (**********************)

- ieHTTPHeaders のオプション設定

HTTP リクエスト/レスポンス表示ウインドウで右クリックして Settings を選択すると設定画面に入れる。

Misc の Scroll during Capture にはチェックを入れておこう。チェックを入れておくと、スクロールバーを自動で一番下まで移動してくれる。unix の tail コマンドのように、常に最新の情報を表示し続けることができる。

ieHTTPHeaders は Live Http headers に比べると機能が少ない。正規表現でキャプチャ対象 URL を絞り込んだりできないし、別ウインドウで表示させることもできない。一度発行したリクエストを修正して再度リクエストし直すこともできない。あくまで簡易なキャプチャ用ツールと割り切って使うのが良いだろう。

HTTP で xls や doc ファイルをダウンロードさせたとき、対応するアプリケーションがインストールされたマシンではブラウザ内で開いてしまう。そうさせたくない場合は、サーバで HTTP レスポンスヘッダ Content-disposition: を送出してやればよい。

既知の MIME タイプに対し [ファイルのダウンロード] ダイアログ ボックスを開く JP260519
http://support.microsoft.com/default.aspx?scid=kb;JA;260519

Web サーバーからドキュメントを提供する際、ユーザーが、そのドキュメントをブラウザで開かずに直接ディスクに保存できるよう、即座にプロンプトを表示したい場合があります。しかし Microsoft Word ("application/ms-word") などの MIME (Multipurpose Internet Mail Extensions) タイプに対する既定の動作は、Internet Explorer でドキュメントを開くようになっています。

content-disposition ヘッダを使って、この既定の動作を無効にすることができます。そのフォーマットは次のとおりです。
Content-disposition: attachment; filename=fname.ext

Content-disposition: はよく使うけど、IE に対してこんな効果があるとは知らなかった。

- クライアント側では Shift 押しながらリンククリック ・・・してもできません

クライアント側では Shift キーを押しながら該当ファイルへのリンクをクリックすれば良い。

・・・と思ったけど、できない。html や png へのリンクを Shift を押しながらクリックしてもブラウザで普通に開いてしまう。昔 Shift キー押しながら大量のリンクを一気にクリックしてファイルを保存した記憶があるんだけどなあ。

- Netscape Navigator なら Shift + クリックが有効

しかし、Shift キーを押しながらクリックって、どのブラウザなら有効なんだろう? 大量のリンクをブラウザでクリックしまくって保存するなんて、右も左もわからなかった頃の所業だ。普通 wget なり Iria や Irvine 使って遊んでる間にダウンロードさせるよね。となると、20世紀の Netscape 全盛だった頃かな?

普段メールクライアントとしてしか使っていない Netscape Communicator 4.8 を立ち上げて、Navigator で http://www.google.co.jp/ を Shift + クリックすると・・・ Save as ダイアログが出たー! これと勘違いしてたんだ。ちなみに Mozilla Firefox 0.8 ではできなかった。

- IE のクライアント側での対処

以下の方法ならクライアント側、というか IE 側で対処可能。でも、私の扱う要件ではそれができるクライアントや環境だけじゃないから、やっぱりサーバ側での対処が必要。

なお、サーバー側から Content-Disposition ヘッダーを送信せずに、クライアント側の設定によりダイアログを表示させる場合には、以下の手順を実行します。

クライアント側のフォルダオプションで設定する方法:1. [マイ コンピュータ] をダブルクリックします。
2. [ツール] メニューの [フォルダ オプション] をクリックします。
3. [ファイル タイプ] タブをクリックします。
4. [登録されているファイル タイプ] の下から、ダイアログを表示させたいファイルの種類を選択して、[詳細設定] ボタンをクリックします。
5. [ダウンロード後に開く確認をする] (または [ダウンロード後に常に開くように設定する]) のチェックボックスをオフにし、[OK] をクリックします。
6. [登録されているファイル タイプ] の下からファイルの種類を選択して、[詳細設定] ボタンをクリックします。
※ ただし、ファイルの種類によっては上記の手順で設定できないものもあります。

LAN 内のベーシック認証つきサイトへのリンクはこの形式で記述していたので、削除されると困るなあ。

834489 - Microsoft plans to release a software update that modifies the default behavior of Internet Explorer for handling user information in HTTP and HTTPS URLs

Microsoft plans to release a software update that removes support for handling user names and passwords in HTTP and HTTP with Secure Sockets Layer (SSL) or HTTPS URLs in Microsoft Internet Explorer.

ユーザ名とパスワード付き URL の例。

http(s)://username:password@server/resource.ext

- 追記

日本語の説明ページができたのでメモ。説明ページの URL は上記のものと変わらない。
Internet Explorer で HTTP URL と HTTPS URL のユーザー情報を処理する際のデフォルトの動作を変更するソフトウェア アップデートのリリースについて

マイクロソフトは HTTP URL および HTTPS URL (SSL を使用する HTTP URL) に含まれるユーザー名とパスワードを Internet Explorer によって処理しないようにする修正プログラムをリリースしました。MS04-004: Internet Explorer 用の累積的なセキュリティ修正プログラム (832894)をインストールすると、Internet Explorer またはエクスプローラで次の URL 構文がサポートされなくなります。
http(s)://username:password@server/resource.ext

ツール(T) -> インターネットオプション(O) -> 「セキュリティ」タブ ->
「レベルのカスタマイズ」ボタン -> 「スクリプト」 の
「アクティブスクリプト」で「有効にする」を選択。