Hebikuzure's Tech Memo

2012年3月30日

HTTP/308 で Web を前進させよう

Filed under: Internet Explorer — hebikuzure @ 7:28 PM

Pushing the Web Forward with HTTP/308 
http://blogs.msdn.com/b/ieinternals/archive/2012/03/29/http-308-permanent-redirect-pushing-the-web-forward-by-breaking-unwanted-forward-compatibility.aspx


以前に紹介した IEInternals の記事「HTTP Methods and Redirect Status Codes」(私訳) で検討されていた HTTP リダイレクト ストータス コードについての新しい話題です。本文中にもあるように、Internet-Draft となった HTTP/308 ステータス コードが取り上げられています。

以下の文章は EricLaw’s IEInternals の 2012/3/29 の記事 Pushing the Web Forward with HTTP/308 を hebikuzure が私的に試訳したものです。翻訳については Microsoft Corporation および日本マイクロソフト株式会社とは無関係に hebikuzure が公開情報に基づき独自に行ったものであり、この文書の内容についての文責は公開者である hebikuzure にあります。翻訳の内容および技術的内容については正確を期すよう十分な注意を払っておりますが、誤りや不正確な部分が含まれている可能性がありますので、本文書を利用される際には原文も併せてご確認ください。


HTTP/308 で Web を前進させよう

EricLaw [MSFT]

2012年3月29日 午前8時43分

最近、ネットワーク作業グループは HTTP/308 ステータス コードを定義する新しいインターネット ドラフト(意図されたステータス: 実験的)を公開しました。このステータス コードは既存の HTTP/307 ステータス コードの “永続的” 版として定義されています。1999年に立ち返って HTTP/307 が HTTP/301 と HTTP/302 のリダイレクト コードの曖昧さを回避するために策定された事を思い出してください。多くのユーザー エージェントがリダイレクト後のリクエスト メソッドを POST から GET に変更していましたね。HTTP/303 はユーザー エージェントがメソッドをGET に必ず変更すべきだという事を明確に示すよう定義されており、HTTP/307 はユーザー エージェントは現在のメソッドを維持すべきだという事を明瞭に示すよう定義されています。

HTTP/308 は HTTP/307 とほぼ同じですが、次の二つが異なっています:

  1. このステータスは “永続的なリダイレクト” であると定義する。
  2. “リンク編集” 機能を持つクライアントはリダイレクト先の URL に自動的に再リンク ”すべき” である。

こうした基本的な性格は HTTP/301 から継承していますが、見逃してはならない微妙な違いもあります。第一に、永続的であると定義されているにも関わらず、キャッシュはリダイレクションの有効期限の判定に明示的にヒューリスティックな方法を利用するでしょう("永続性” はいささか損なわれます)。しかしこれはそう悪い話ではありません。多くの実際のサイトでは HTTP/301 を適切に利用していないので、キャッシュが本当にリダイレクトを永続的なものとして扱うと、そうしたサイトは無限のリダイレクト ループに陥ります。第二に、私は未だかつて 301 コードに基づいてURI を自動的に更新するような “リンク編集” 機能を持つクライアントを見た事がありません。これはそのような動作は、301 コードが一時的リダイレクトのために誤利用されているという事実の下では、セキュリティ的な影響があるからでしょう。同様に HTTP/308 レスポンスに基づいて自動的な “リンク編集” をする動作も目にする事はないでしょう。

実用的には HTTP/307, HTTP/308 と同等であるにも関わらず、HTTP/308 には自身を非常に興味深いものにしている、ユニークな属性があります:

完全に新規のステータス コードであるため、21年にわたる HTTP の歴史の中で HTTP/308 をサポートするクライアントの実装は存在しません。

この特徴は、非常に最先端を行くブラウザー(例えば最新の Firefox ナイトリー ビルド)でのみ HTTP/308 ステータスは機能するという事を意味している点で、興味深いものです。既存の数十億の Web クライアントの何れであれ、HTTP/308 に遭遇してもインターネット ドラフトに書かれたような方法と同じようにはリダイレクトを実行しないでしょう。

サーバーは User-Agent スニッフィングにより、クライアントが極端な最先端の標準サポートをしていない場合、308 に代えて 307 を返信できます。HTTP ヘッダーにはクライアントがどのようなレスポンス コードをサポートしているかを示す物が何もないため、こうしたスニッフィングが必要です。もちろん、もちろん、サーバーがクライアントの HTTP/308 サポートを自明の事として知っているような状況もあるでしょう。例えばクローズな環境で、ユーザーは特定のクライアントの利用を強制されているような場合、HTTP/308 はその機能を確実に果たすでしょう。

これとは別に、多くの場合、クライアントは HTTP/308 レスポンスのボディ部分を Web ページとして単純に表示します。これは未知の 3xx レスポンス コードに対する “フォールバック” 動作です。残念な事に、308 が POST をリダイレクトするために利用された場合、ボディ部分のフォールバック スクリプトやマークアップは、一般的には新たなターゲット URL への POST を実行できません。何故なら POST のボディは、… 308 のボディに元の送信された POST のボディをエコーバックするようなフォームが含まれない限り、ページから利用できないからです。

そのため、HTTP/308 レスポンスのボディは代わりにユーザーに利用しているブラウザーが最先端のインターネット標準対応では無い事を知らせる良い方法になるでしょう。そうしたページではユーザーに HTTP/308 をサポートしているナイトリー ビルドのブラウザーを教える事ができます。ブラウザーを簡単にアップデートできないようなレガシー デバイス(携帯電話、ゲーム機、サポート期間の切れたタブレットなど)には、ユーザーが最新の標準をサポートするデバイスが購入できるような Web ストアへのリンクを示せます。

Fiddler のユーザーであれば、最新でないクライアントでも HTTP/308 の動作をシミュレートできます。Rules > Customize Rules とクリックし、OnPeekAtResponseHeaders メソッドの中に以下のブロックを追加します:

if (oSession.responseCode == 308) {
    oSession.responseCode = 307;
    oSession["ui-backcolor"] = "teal";
}

ブラウザーが HTTP/308 をサポートしているか、こちらのテストページで試せます: http://webdbg.com/test/308/

-Eric

広告

2012年3月24日

Internet Explorer 10 の quirks モードは今までの quirks モードではない

Filed under: Internet Explorer — hebikuzure @ 7:07 PM

Internet Explorer 10 Compatibility Cookbook
http://msdn.microsoft.com/library/hh801219.aspx


Internet Explorer 10 では Web 標準への準拠や他のブラウザーとの相互運用性の向上が Internet Explorer 9 以上に強化されています。これは Web 全体の進化と将来的なユーザー利益には問題なく大きな前進ですが、その反面、古いバージョンの Internet Explorer の挙動に依存していた Web サイトや Web アプリケーションでは、深刻な互換性の問題が生じる可能性もあるという事です。

その中でも注意すべきだと考えているのが、Quirks モードの動作の変更です。

Internet Explorer における quirks モードは、Internet Explorer 6 で導入された後方互換性のための機能で、ほぼ IE5 以前と同等の方法で HTML の解釈とレンダリングを行うモードです。詳しくは「ドキュメント互換性の定義」(MSDN) や「IE8互換モードについて」(Japan IE Support Team Blog) を参照してください。

Internet Explorer 9 までの Quirks モードは上記の通り、ほぼ IE5 と同等の動作を行っていましたが、Internet Explorer 10 では HTML5 の仕様内に Quirks モードでの挙動が定められる事になるのを踏まえ、それに準拠するよう動作が変更されます。この辺りの話は以前にこのブログでも IE Blog の私訳「IE10 の相互運用性のある Quirks モード」で紹介しています。
しかし重要な変更点はそれだけではありません。MSDN の Internet Explorer 10 Compatibility Cookbook を確認すると、Internet Explorer 10 の quirks モードでは次のような機能の変更 (廃止) も行われます。

こうした IE の独自機能の廃止も Quirks モードにおける他のブラウザーとの相互運用性の向上が目的です。IE9 までの Quirks モードでは HTML5 の要素は未知の要素として無視されていましたが、IE10 では Quirks モードでも HTML5 が有効になります (VML は SGV で代替されます)。そのため HTML5 で利用可能になる機能と重複する IE の独自機能が廃止されるのです。
レガシーな Web サイト / Web アプリケーションで、IE9 までのバージョンでは Quirks モードを利用する事で動作していた物は、これらの廃止される機能が利用されている場合、IE10 ではそのままでは動作しません。廃止される機能についてそれぞれの詳細はリンク先を確認していただくのが良いのですが、こうした機能の利用について心当たりのあるサイト管理者の方は、早急にテストと確認をされると良いでしょう。

多くの場合、サイトを Quirks モード以外の互換モードで動作させる事で機能が廃止される問題は回避できるでしょう。実はこれらの機能が廃止されるのは Quirks モードとIE10 標準モードだけで、それ以外の、例えば IE9 モードなどの互換モードではこれらの機能は維持されています。そのため X-UA-Compatible META タグなどを利用して、サイト / ページを互換表示すれば、以前と同様に機能が利用できます。ただし、その場合ページのレンダリングは Quirks モード ではなく指定した IE のバージョンのモードになりますから、レンダリング面で IE7 以降のバージョンと互換性が無いサイト/ ページの場合、今度はこちらの問題が生じる事になります。

まとめると、IE10 で動作せず根本的な改修が必要になるパターンは、「IE6 以前のレンダリング モードでないと意図通りに表示できない」かつ「(上記の) IE10 で廃止される機能を利用している」サイト / ページという事になります。これらのサイト / ページは、

  • IE7 以降のバージョンでも意図通りレンダリングされるよう改修し、互換表示を利用する
  • 廃止される機能を HTML5 や SVG などで置き換える

のいずれかの対処を行わないと、IE10 では適切に利用できないサイトになってしまいます。ご注意ください。(もちろん IE10 や他のブラウザーでも利用可能なように、HTML/CSS 共にモダナイズする事が最良の選択です)

2012年3月5日

保護モードの昇格ダイアログを理解する

Filed under: Internet Explorer — hebikuzure @ 7:36 PM

Understanding the Protected Mode Elevation Dialog
http://blogs.msdn.com/b/ieinternals/archive/2009/12/01/understanding-internet-explorer-security-protected-mode-elevation-dialog.aspx


ずいぶん古い記事になりますが、今まで Windows XP 環境のユーザーが Windows 7 / Windows 8 の環境に更新するケースは今年多そうなので、改めて確認する意味でも意外と知られていない保護モードの動作についての話題を一つ訳してみました。特に「許可しない」をクリックしている限りはこのダイアログが永遠に出続ける、という話は興味深いですね。

以下の文章は EricLaw’s IEInternals の 2009/12/01 の記事 Understanding the Protected Mode Elevation Dialog を hebikuzure が私的に試訳したものです。翻訳については Microsoft Corporation および日本マイクロソフト株式会社とは無関係に hebikuzure が公開情報に基づき独自に行ったものであり、この文書の内容についての文責は公開者である hebikuzure にあります。翻訳の内容および技術的内容については正確を期すよう十分な注意を払っておりますが、誤りや不正確な部分が含まれている可能性がありますので、本文書を利用される際には原文も併せてご確認ください。


保護モードの昇格ダイアログを理解する

EricLaw [MSFT]

2009年11月30日 午後6時56分

Internet Explorer 7 では、ブラウザーとそのアドオンが最小限の権限のセットで実行される事を確実にする機能として、保護モードが導入されました。“権限低”のプロセスで実行されているコードには、皆さんのユーザー プロファイルやレジストリ キーに書き込む権限が無いため、悪意のある人がブラウザーやそのアドオンの脆弱性を見つけようと企んでも、被害が限定されるようになっています。

互換性を確実にするため、保護モード内のコードがその権限が制約された場合でも動作し続けるよう、システムの仮想化が保護モードで利用されています。

場合によっては、仮想化は予期しない結果をもたらします。Mark Russinovich が彼のブログ記事「The Case of the Phantom Desktop Files」で解説しているのはその一例です。そうしたびっくりはさておき、特定の機能は適切に仮想化する事ができません—例えば現在のユーザーのデスクトップの壁紙を変更する機能を提供したいとしたら、そのコードではどうしてもユーザー プロファイルに書き込む必要があります。

IE はこのセキュリティーと機能性のトレードオフをどのように解決しているのでしょうか? 答えは”ブローカーを使うこと”です。このアイデアでは、Internet Explorer (と Flash や Java のような一部のアドオン) は”権限中”のブローカー プロセスを起動し、コンテンツが保護モードのサンドボックス内で表示されている場合には通常禁じられている、現在のユーザー権限の利用が可能になります。ブローカー プロセスは (呼び出しコードに悪意がありサンドボックスを回避しようとする場合もあるので) 信頼できない呼び出しを受け付けないよう慎重に設計し、データをサニタイズし、セキュリティー センシティブな動作は変更を行う前に確認を行うようにする必要があります。

保護モード内で動作しているアドオンがブローカー プロセス (やその他の全てのプログラム) を起動する場合には、プロセスをどのように起動するべきかを確認するために ElevationPolicy レジストリ キー ({HKLM/HKCU}\Software\Microsoft\Internet Explorer\Low Rights\ElevationPolicy) がチェックされます。四つのポリシー値のいずれかが指定されています:

ポリシー

結果

0

保護モードはプロセスを起動しない。

1

保護モードはブローカーを整合性レベル「低」でサイレントに起動する。

2

保護モードはユーザーにプロセスを起動する許可を求める。許可が得られれば、プロセスは整合性レベル「中」で起動される。

3

保護モードはブローカーを整合性レベル「中」でサイレントに起動する

ブローカー プロセスが昇格ポリシーを適切に登録していない場合、問題が生じます。ElevationPolicy が検知されなかった場合の既定のポリシーは #2 で、ユーザーにプロセスを起動する許可を求めるプロンプトが表示されます。ブローカー プロセスのこの動作は、ユーザー エクスペリエンスに混乱をもたらす場合があります。例えば、Flash のブローカーの昇格ポリシーがレジストリから欠落すると、Flash を使っているどのページでも以下のような表示が出てきます:

一般的なユーザー (と熟練ユーザーの大半) はブローカーが何であるか、またどうしてこのダイアログが表示されるのか分からないだろう事を忘れないでください。そうした人たちは、これをどうにかするためには “許可する” か “許可しない” のいずれかをクリックすればよい事は理解できるでしょう。しかしアドオンが次にブローカー プロセスを起動しようとした際、ユーザーにはこれと同じプロンプトがまた表示されます。簡単に想像できるでしょうが、これにはすぐにうんざりするでしょう。

“許可しない” ボタンのクリックに飽き飽きしたユーザー (実際にはブローカー プロセスが何であり、なぜ存在しているのか理解してはいないのですが) は、”許可しない”ボタンをクリックする前に”このプログラムについての警告を表示しない”チェックボックスをチェックするでしょう。

残念ながら、この行為は役に立ちません— “このプログラムについての警告を表示しない”チェックボックスは、”許可する”ボタンを押す場合にのみ有効です—このプロセスについて自動的にアクセスを拒否する事はできません。

どうしてでしょうか? これは意図に反していろいろと問題を生じさせ、その場合普通の人では何が問題であるかを確認し、それを修正する方法が無いからです。アドオンのブローカーを起動しようとする試みは常に失敗しますが、その試みは繰り返し行われる (そしてブラウザーをハングさせる) でしょう。しかもなお悪い事に、ユーザーが元に戻って考え方を変える方法が無いのです— HKCU ElevationPolicy レジストリ キーが更新された後で、それを反転できるようなユーザー インターフェイスを作成する、合理的で実現可能な方法はないのです。

アドオンの開発者は、アドオンのインストール時にそのブローカー プロセスに対する ElevationPolicy が適切に設定されるように確実を期してください (そしてブローカー プロセスがいつもアクセス拒否エラーで失敗する場合はそのプロパティを確認し、ユーザーにしかるべく通知する事を望みます)。

保護モードの昇格プロンプトが予期せず表示されるエンド ユーザーは、プロンプトの原因となったアドオン (多くの場合明確にわかります) を再インストールするか、不明であったり不必要であったりするアドオンを無効にする事を検討すべきです。攻撃の対象側面とプロンプトを減らすだけでなく、不要なアドオンの無効化は多くの場合ブラウザーのパフォーマンスを向上させます。

-Eric

2012年3月3日

Internet Explorer 10 Consumer Preview のマイナーな変更点リスト

Filed under: Internet Explorer — hebikuzure @ 11:15 PM

Internet Explorer 10 Consumer Preview Minor Changes List
http://blogs.msdn.com/b/ieinternals/archive/2012/03/01/ie10-beta-consumer-preview-minor-changes-changelist.aspx


Windows 8 Consumer Preview が公開されました。それに含まれる IE も Internet Explorer 10 Consumer Preview に更新されています。このバージョンでの変更点について解説している、EricLaw’s IEInternals の記事を私訳しました。記事中にも書かれていますが、ここに示されているのは他で取り上げられていないマイナーな(しかし開発者や管理者にとっては結構重要な) 変更点のみです。メジャーな変更点については IEBlog の記事や開発者ガイドIE10 Compatibility Cookbook も確認してください。

以下の文章は EricLaw’s IEInternals の 2012/3/1 の記事 Internet Explorer 10 Consumer Preview Minor Changes List を hebikuzure が私的に試訳したものです。翻訳については Microsoft Corporation および日本マイクロソフト株式会社とは無関係に hebikuzure が公開情報に基づき独自に行ったものであり、この文書の内容についての文責は公開者である hebikuzure にあります。翻訳の内容および技術的内容については正確を期すよう十分な注意を払っておりますが、誤りや不正確な部分が含まれている可能性がありますので、本文書を利用される際には原文も併せてご確認ください。


Internet Explorer 10 Consumer Preview のマイナーな変更点リスト

EricLaw [MSFT]

2012年3月1日 午前10時32分

昨年公開した IE9 マイナーな変更点リスト (@hasegawayosuke さんによる日本語訳)に引き続き、この記事では Windows 8 Consumer Preview に含まれる Internet Explorer 10 で確認できるマイナーな変更点について説明しています。

ここではカバーしきれないほど多数の変更がありますので、これが完全なリストであると誤解しないでください。また既に IEBlog で説明されている大幅な機能向上については意図的に省いている事にも地優位してください。このブログで解説してきた、結果や機能に影響を与えるような改善点については BetterInIE10 タグで検索して見つける事ができます。

難しい話はこれまでにして、IE10 のマイナーな変更点を紹介します:

  • Firefox や Chrome、そして最新の標準と合致するよう、サイト間のリダイレクトの際にフラグメントは維持されます。
  • 他のブラウザーの動作や RFC2616 で許されているように、Internet Explorer も 進む/戻る のナビゲーションで no-cacheを無視するようになります。
    • 同じく、RFC2616 では条件付き GET は no-cache リソースの再評価も許されています。
    • 進む/戻る のナビゲーションでリソースの再利用を阻むには、no-store を利用します。
  • サーバーから HTTP/204 が返されても、XMLHttpRequest が “1223” エラーで失敗しないようになりました。
  • ページをリロードするため CTRL+F5 を利用した際、XMLHttpRequest はキャッシュ破棄フラグに従った動作をします
  • XMLHttpRequest の getResponseHeader メソッドは、同名の複数のヘッダーが存在するイベントの、全ての値が結合された文字列を返すようになりました。
  • XMLHttpRequest は CORSCOMET-streaming、さらにその他色々を新たにサポートします。
    • 注: Consumer Preview にはバグがあり、HTTP->HTTPS および FTP->HTTPS リクエストを生成できません。このバグは今後の IE10 の更新で修正されます。
  • IE10 は LINK REL=dns-prefetch をサポートするようになりました。IE9 では dns- prefetch のトークンがまだ定義されていなかったため、LINK REL=prefetch にだけ DNS の先読みを行っていました。
  • HTTPS の混在したコンテンツについての警告は、数秒で自動的に消えるようになりました。
  • IE10 標準モードでは、host とパス名の DOM プロパティーが予期しない結果を返さにないようになりました。
  • Internet Explorer は VPN またはモデム接続がアクティブな場合でも、ホストごとの接続数 (Connections-Per-Host) の制限を 2 に低減しません。制限は 6 のままです。
  • 他のブラウザーと同様になるよう、CTRL;U のキーボード コンビネーションでソースの表示が開きます。
  • CTRL+SHIFT+B でお気に入りバーの表示が切り替えできます。
  • PNG gAMA が Windows 8 でサポートされます。
  • ダウンロードマネージャーは、サーバーが Content-Length ヘッダーを返していない場合でも、正しいダウンロード スピードを正しく表示します。
    • IE9 ではそのような場合、ダウンロードが一定のレートで進行している場合でも、ダウンロード スピードが次第に低速になるように表示されていました。
  • SCRIPT DEFER の動作が修正され仕様に準拠するようになりました。(async もサポートされます)
  • スタイルシートの制限は劇的に改善されました。
  • 相互運用性のため、BASE 要素が相対パスをサポートするようになりました。
    • それでもやはり、皆さんは BASE 要素内で相対 URL を利用しないよう、また可能であれば BASE 要素の利用を避けるようお願いします。
  • IE10 以前のバージョンでは、フォームの name/id がウィンドウのビルトイン プロパティーと競合していた場合、スクリプトからの参照はフォーム要素に解決されていました。この現象は発生しなくなりました。
  • Windows 7 およびそれ以前の Windows では、カスタム プロトコル スキームを ShellExecute しようとした場合、ShellExecute は最初にプロトコル スキームが登録された Application Protocol であるか確認します。登録されていない場合、次にスキームが IE に登録された Asynchronous Pluggable Protocol であるか確認します。そうであれば IE が起動され、URL が渡されます。Windows 8 では、asynchronous pluggable protocol のチェックへフォールバックは発生しません。そのためターゲットのプロトコルが登録された application protocol でなければブラウザーは起動しません。こうした事の結果、RES:// プロトコルが application protocol として登録されています。
  • Mailto リンクで UTF-8 を使う オプションは INETCPL (インターネット オプション) から削除されました。IE は ShellExecute API に常に Unicode を渡します。
  • Application Protocols の可用性を、msProtocols コレクションを使ってJavaScript から検知できるようになりました。
  • IE10 がプレリリース バージョンである事を検知できるよう、window.navigator.appMinorVersion 文字列に “BETA” が設定されています。

プレビュー版については IEBlog開発者ガイドをご覧いただき、TestDrive のデモをお試しください。また IE10 で変更されたり廃止されたりする機能については IE10 Compatibility Cookbook もご確認ください。最後に、Web プラットフォーム API の詳細な情報について IE10 Web Platform Features の記事をご覧ください。

-Eric

注: 2012/3/5 コメントでいただいたご指摘を元に、一部訂正しています。

Windows 8 Consumer Preview のインストール

Filed under: Windows Info — hebikuzure @ 2:35 PM


Windows 8 Consumer Preview
http://windows.microsoft.com/ja-JP/windows-8/consumer-preview


以前の記事で Windows 8 Developer Preview のインストールを試した事を書きましたが、Windows 8 Consumer Preview が公開されたので同じマシンにインストールしてみました。操作などは Developer Preview を使って慣れてきていたのですが、細かな部分がよりチューニングされて使いやすくなっています。また全体的な動作速度も Developer Preview に比べると早くなっていて、さらに最適化が進む製品版には期待ができそうです。各機能や使い方の解説は多くの方が記事やブログで書かれていますので、そちらに譲ります。

ちなみに Windows 8 Consumer Preview のインストールに使ったマシンは以前の記事にも書いたように HP Business Desktop dx5150 SF という、元々は Windows XP SP2 がプリインストールされていたマシンです。これでエクスペリエンス インデックスが「2.2」で最低の項目が「Aero のグラフィック」 (Developer Preview の時より 0.2 向上) という事なので、日常的な Web ブラウジングやメール、SNS、Office アプリケーションの利用では普通に使えるレベルなのですから、恐れ入ります。(Windows 7 や Developer Preview の時と同様、ディスプレイ ドライバーはベンダーのサイトから Windows Vista 用ドライバをダウンロードして適用しています)

一つになるのは、Metro スタイルのアプリケーションとして提供されているメール アプリケーションで、一般的な POP/SMTP や IMAP のアカウントが作れない事です。このアプリでアカウントとして設定できるのは Hotmail と Gmail、Exchange のアカウントに限られています。そのためプロバイダーのメールや Exchange ではない企業内メールなどはそのままでは利用できません。Hotmail、Gmail、Exchange のいずれも外部の POP/SMTP アカウントを接続して送受信する事ができますから、そちらの設定で回避する事は可能ですが、ちょっと面倒ですね。いずれは Store POP/SMTP にも対応したメール クライアントを公開するベンダーも出てきそうですが、ちょっと注意が必要です。

WordPress.com で無料サイトやブログを作成.

%d人のブロガーが「いいね」をつけました。