Hebikuzure's Tech Memo

2011年11月28日

Windows のカレンダーに元号を追加する

Filed under: Windows Tips — hebikuzure @ 11:00 PM

Extending the Windows Japanese Calendar Era information.
http://blogs.msdn.com/b/shawnste/archive/2011/11/15/extending-the-windows-japanese-calendar-era-information.aspx


Windows では日付と時刻のフォーマットがロケールによって変更されるようになっていますが、ロケールが日本語(日本)であると、カレンダーの形式として「和暦」が利用できるようになり、元号を使用した日付の表示が可能になります。この形式は例えば Excel の日付の表示形式など、Windows 上のアプリケーションでも利用されています。

「平成」がいつまで続くのかという事はさておき、この和暦のカレンダーには既定では「明治」「大正」「昭和」「平成」の元号が設定されています。例えば歴史に関する文書や資料を作成する場合、明治以前の元号をカレンダーで利用したい事もあるでしょう。こうした場合、上記のブログ記事によればレジストリ値で元号を追加する事ができます。
追加するレジストリ値は以下の通りです。

  • キー : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras
  • 名前 : (元号の開始日)
  • 種類 : REG_SZ
  • データ : (表示する元号)

元号の開始日は、昭和であれば “1926 12 25”、平成であれば “1989 01 08” のように年・月・日を半角スペースで区切って入力します。
表示する元号は、漢字の綴り・漢字の頭文字・アルファベットの綴り・アルファベットの頭文字をアンダースコア (“_”) で区切って入力します。例えば昭和なら “昭和_昭_Showa_S”、平成なら “平成_平_Heisei_H” となります。
一例として、「慶応」を追加するのであれば、”1865 05 01” という名前の REG_SZ 値を作成し、データに “慶応_慶_Keiou_K” と入力します。

「平成」の次の元号が決まれば Microsoft からそれを追加する更新プログラムが Windows Update などで配布されるでしょうが、もし早急に新元号に対応させたいという事であれば、この方法で追加できるはずです。

この話とは直接関係ないのですが、昭和への改元の際は大正15年12月25日に即日改元しているので、この日は途中まで大正15年、改元後昭和元年というややこしい事になっていました。これは明治->大正の改元の際も同様だったようです。そのため平成への改元の際は、昭和64年1月7日に翌日(1月8日)から改元を施行する政令を施行しています。したがってこの場合には同日に異なる元号という事態は避けられています。

2011年11月27日

セキュリティ設定を既定の設定に戻す方法 – 全面改訂 –

Filed under: Windows Tips — hebikuzure @ 6:20 PM

How do I restore security settings to a known working state?
http://support.microsoft.com/kb/313222/en-us


以前に「セキュリティ設定をデフォルトに戻す方法」および「セキュリティ設定をデフォルトに戻す方法 – 改定版 」で Windows のセキュリティ設定(ビルトイン アカウントやグループ (Administrator や Administrators、Usersなど) に対する権限や、既定のフォルダやレジストリ キーに対するアクセス権の設定、ローカル セキュリティ ポリシーの構成)を “secedit /configure” コマンドを利用してインストール当初の初期値に戻す方法を紹介していました。

その際に紹介していたサポート技術情報 文書番号313222「セキュリティ設定を既定の設定に戻す方法」について、日本語版の内容は改定されていないのですが、本家の英語版の内容が 2011年9月23日付で全面改訂され、以前に紹介していた方法がサポートされなくなっています。英語版「How do I restore security settings to a known working state?」では、以前の “secedit /configure” コマンドを利用して既定の設定を復元する方法について

  • Windows 7 / Windows Vista / Windows Server 2008 R2 /Windows Server 2008 では既定のセキュリティー構成を復元するのに有効ではなくサポートもされない (このコマンドの利用はオペレーティング システムを不安定にする可能性もある)
  • Windows 2000 / Windows XP / Windows Server 2003 ではこのコマンドはごく限られた特定の場合には有効でありサポートされるが、この方法ですべてのセキュリティー設定が復元される訳ではないので互換性の問題を引き起こす可能性がある

と記載されています。そのため以前のバージョンの技術情報や日本語版に付属している Fixit も取り下げられています。
(カスタム テンプレートをインポートする方法としての “secedit /configure” コマンドの利用は完全にサポートされています)

それではこれまでの方法に替えてどのような方法が利用できるのかについてもこの技術情報では紹介しています。
具体的には以下の方法が挙げられています。

  • Windows Backup (バックアップからの復元)
  • System Restore (システムの復元)
  • Security Configuration Wizard (セキュリティの構成ウィザード)
  • ICACLS /Restore
  • Troubleshooting methods (個別のトラブルシュートの実行)

ただし最後の個別のトラブルシュートの実行以外は、事前に正常時の設定の保存・バックアップを行っておく必要があり、問題が発生してから初期化を行えるという方法ではありません。また個別のトラブルシュートの実行というのは要するにセキュリティー設定のどの部分に問題が生じているのか特定して修正するという方法なので、「初期化する」という事ではありません。

つまり結論として言えば、インストール後に運用を開始した Windows では、インストール時に設定されるのと同様のセキュリティー設定を完全に復元する安全な方法は事実上存在しないという事です。セキュリティー設定の含む範囲の広範さ・複雑さを考えれば実運用状態にある Windwos 環境について、セキュリティー設定だけ「えいやっ」と初期化して問題が起きないようにするという事は困難なのでしょう。

またこれまで技術情報で紹介していた手順がサポートされなくなる(だけでなく問題を生じる可能性がある)という変更が加わっているだけに、日本語版の技術情報も早期に改定してほしいものです。

2011年11月26日

Windows 8 へのアップグレード(補足)

Filed under: Windows Info — hebikuzure @ 3:57 PM

昨日の記事について少し追加の説明をします。

Windows 7 までの場合、いわゆるインプレース アップグレード インストールの場合にはWindows の設定やインストール済みアプリケーション、ユーザー アカウントやユーザーのファイルははべて新しい環境に引き継がれますが、インプレース アップグレードができない場合は何も引き継がれず、必要に応じて「Windows 転送ツール」や USMT を利用して移行する必要がありました。

Blog 記事によると、Windows 8 ではこの動作が改善され、Windows 7 Upgrade AdvisorWindows 転送ツールが Windows 8 のインストーラーに統合されます。古い Windows 上で Windows 8 のインストーラーを起動すると、自動的にアップグレード チェックが行われ問題が確認されていたり対処が必要だったりするデバイスやソフトウェアがリストアップされます。これらについてクリアできるとインストールが開始されますが、その途中で Windows 8 に移行したい内容を選択する画面が表示されます。


互換性の確認画面


Windows 8 に移行する内容の選択

古い Windows のバージョンによっては、昨日の記事で書いたように移行できない物もありますが、ここで移行したい物を選択できます。

この後で再起動が求められ、インストールのためのWindows PE 環境が起動します。Windows 転送ツールでは古い Windows が稼働している状態で移行する情報やファイルを収集していましたが、Windows 8 ではこの Windows PE 環境で古い Windows 環境は Winodows.old フォルダーに移動され、Windows 8 のインストール後に上の画面での設定に応じて Windows.old フォルダーから移行すべき情報・ファイルが取り出され適用されます。この動作により、移行したい情報の収集がオフラインで行われるので、より安全に移行する事が可能になるようです。(また Windows.old フォルダーは既定ではインストール後4週間で自動的に削除されるようにするとの事です。)

オンライン インストール

もう一つ Windows 8 のインストールでの変更点として大きいのは、オンライン インストールが行えるようになる点でしょう。現在でも Windows 製品のダウンロード販売はありますが、これを進化させ、小サイズのインストーラーを起動すると自動的にインターネットからインストール パッケージのダウンロードとインストールが行われるようにするとの事です。またこの場合はダウンロードされるイメージに予めプロダクト キーを埋め込んで、ユーザーがプロダクト キーを入力しなくとも良いようにすると書かれています。具体的な販売方法や価格、再インストールやライセンスの別コンピュータへの移管方法など不明な点もありますが、インストール手段も大きく変わる事は間違いないようです。


インストール イメージのダウンロード

なおこの方法でダウンロードしたイメージも、DVD / USB メディアに書き込み、そこからインストールを行う事も可能と説明されています。

2011年11月25日

Windows 8 へのアップグレード

Filed under: Windows Info — hebikuzure @ 8:10 PM

Improving the setup experience
http://blogs.msdn.com/b/b8/archive/2011/11/21/improving-the-setup-experience.aspx


Building Windows 8 ブログに Windows 8 のインストール、特に以前のバージョンの Windows からのアップグレード インストールについての記事が掲載されています。かなり長文で内容も多義に渡りますが、多くの人の興味のあるだろう Windows 8 へのアップグレード パスについて記事から簡単に紹介します。

Windows 8 へのアップグレードがサポートされるのは(現在の予定では)Windows XP、Windows Vista、Windows 7 からで、Windows 7 のへのアップグレードと同様に Windows XP からのアップグレードが(三世代前のシステムであるにもかかわらず)サポートされるのが注目です。Windows 8 のリリース予定時点でも Windows XP のサポートが終了していないと考えられるためでしょうし、また現実問題として依然として多数利用されている Windows XP からのアップグレードをサポートしない訳にもいかないのでしょう。

ただしアップグレードが可能と言っても、いわゆる「インプレース アップグレード」、つまりアプリケーションや Windows の各種設定・構成を維持したままでのアップグレードが可能なのは Windows 7 からのアップグレードの場合だけで、Windows XP からのアップグレードではユーザー アカウントとファイルだけが移行の対象になります。

ブログでも書かれていますが、既存のコンピュータへの Windows 8 のインストールでは、以前のバージョンのシステムやユーザーファイル(Windows・Program files・Program files (x86)・Users・Program data)はオフラインの状態で(Windows PE で起動されている状態で) Windows.old フォルダーに移動され、Windows 8 のインストール中に必要な内容(設定や構成、ファイル)だけが Windows.old フォルダー内のデータから取り出され、新しい Windows 8 に適用される動作になるようです。また移行されるファイルは「移動(move)」されるのではなく、ハードリンクの作成が行われるとのことです。これらの動作により、アップグレード インストールの所要時間が(特に移行する情報が多い場合)劇的に低減されるとブログでは書かれています。


Windows 8 でのアップグレード インストール所要時間の高速化

こうした動作により Windows XP からのアップグレードも可能ですが、前述のようにアップグレード元の Windows に応じて移行できる内容は下表の通りとなります。アプリケーションを含む元の環境のすべてを移行できるのは Windows 7 からのアップグレードだけになる点に注意してください。

 

元の Windows

移行される内容 Windows 7 Windows Vista Windows XP
アプリケーション

×

×

Windows の設定

×

ユーザー アカウントと
ファイル

このブログ記事の内容は確定ではなく、製品としてリリースされる際には変更があるかもしれませんが、新しい PC であっても現時点ではダウングレード権などを利用して Windows XP を使い、リリース後に Windows 8 にアップグレードするというシナリオは可能と考えられます。もし今導入する PC の Windows をどうするか検討している方がいらっしゃれば、参考にしてください。

2011年11月13日

Internet Explorer 9 でアドオンを無効にする

Filed under: Internet Explorer — hebikuzure @ 12:45 PM

Internet Explorer 9 では起動時に読み込まれるアドオンを確認し、パフォーマンスに影響を与えるアドオンが検知されると通知バーに「アドオンを無効にすることで、閲覧の速度を上げます」というメッセージを表示します。このバーには [アドオンの選択] と [後で確認する] というボタンがあり、ここから問題のあるアドオンを無効にする事ができます。この動作についてはさくしまたかえさんのブログ「世の中は不思議なことだらけ」のこの記事に詳しいので参照してください。

以下はこのさくしまさんの記事への補足です。

この通知は IE が各アドオンの読み込みに時間を計測していて、特定の閾値を越えたアドオンがあると表示されます。また閾値は通知バーで [アドオンの選択] をクリックした時に表示される [アドオンの選択] ダイアログで変更できるようになっています。この通知バーから確認する以外にアドオンの読み込み時間を確認したい場合は、[アドオンの管理] (“ツール” ボタン – [アドオンの管理]) を表示します。ここで [アドオンの種類] を [ツールバーと拡張機能] に、[表示] を [すべてのアドオン] に変更し、[読み込み時間] カラムの数字を見ればわかります。

image

通知バーが表示されない場合や、一度表示された通知バーで [後で確認する] ボタンのドロップダウンから [無効にしない] を選択してしまった場合、あるいは閾値を大きな数字に変更したため通知バーが表示されなくなった場合は、以下の手順で [アドオンの選択] を表示させることができます。

  1. Interenet Explorer のウィンドウの右上の方にあるボタン(家の形の “ホーム”, 星印の “お気に入り”, 歯車の “ツール”) の部分を右クリックします
  2. 表示されるメニューから [コマンド バー] をクリックします
  3. コマンド バーが表示されます。その中の [ツール] ボタン (歯車の形) をクリックし、[ツールバー] をポイントします
  4. サブ メニューから [アドオンを無効にする] をクリックします

これで次のような [アドオンの選択] ダイアログが表示されます。

image

通知バーから開いたダイアログと同様に、特定のアドオンを無効にしたり、通知の閾値を変更する事ができます (上記の例では閾値を 1.0秒に変更しています)。

2011年11月7日

HTTP メソッドとリダイレクト ステータス コード

Filed under: Internet Explorer — hebikuzure @ 10:37 PM

HTTP Methods and Redirect Status Codes 
http://blogs.msdn.com/b/ieinternals/archive/2011/08/19/understanding-the-impact-of-redirect-response-status-codes-on-http-methods-like-head-get-post-and-delete.aspx


更新間隔が開いてしまいましたが、今回も EricLaw’s IEInternals の記事をを私訳しました。 HTTP レスポンスでクライアントがリダイレクトされる際の挙動について、RFC の記述とブラウザーの実装の微妙な違い、またブラウザー間の挙動の相違について興味深い情報が示されています。

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


HTTP メソッドとリダイレクト ステータス コード

EricLaw [MSFT]

2011年8月19日 午前11時14分

今朝早く、このつぶやきが私の Twitter のタイムラインに現れました:

Internet Explorer が適切に動作している事をお知らせする公開サービスが必要なのかちょっと分かりませんが、そうしたからと言って害はないでしょう。とは言え情報提供が不足しているとその結果は驚くような事になります。私はこのつぶやきの元の投稿者は実際には他の事を言おうとしているのではないかと考えました。

それではちょっと解説していきましょう。HTTP/1.0 の仕様 RFC1945 では HTTP/301 は以下のように記述されています:

301 Moved Permanently
要求されたリソースは別の永続的な URL に割り当てられており、今後のすべてのこのリソースへの参照は新しいURL を使用すべきである。
// …
注意: 301 ステータスコードを受信した後の POST リクエストの自動リダイレクトの際、既存のいくつかのユーザー エージェントは誤って GET リクエストに変更する。

下線を付けた注意点は HTTP302 についての記述にも含まれています。この注意書きで言及されているこうした “ユーザー エージェント” には、当時の人気のあるブラウザー、Netscape Navigator や Internet Explorer が含まれていました。間違いなく、この挙動は正に多くの Web サイトが — 正しく処理された POST の後で何か別の物を表示するようにユーザーを異なる URL に送るために — 必要としていたものでした。とは言え POST の GET への変換の挙動は、HTTP 仕様の策定者が意図したものではありません。

RFC2616 の策定者は曖昧さをなくす事を狙って、HTTP/1.1 仕様に新しい二つのリダイレクション レスポンス コードを追加しました。

HTTP/302 の更新された定義では以下のように注記されています:

注記: RFC 1945 と RFC 2068 ではリダイレクトされたリクエストでクライアントがメソッドを変更する事を許さないと規定している。しかしながら、多くの既存のユーザー エージェントの実装では 302 を 303 レスポンスであるかのように取扱い、元のリクエスト メソッドを無視して Location フィールド値への GET を実行します。ステータス コード 303 と 307 は、クライアントがどのように反応するのを期待しているのか明確したいサーバーのために追加されています。

当時の実装者のために弁解すれば、RFC1945 と REF2068 が真にクライアントのユーザー エージェントが “メソッドを変更する事を許さない” と規定していたのであれば、彼らは明確にその通りにしたでしょう。この期待はレスポンス コードの定義において言及されていたのではなく、リダイレクトに関する助言で言及されていたのです。残念ながら現行の HTTPBIS ドラフトにも同じ制限による問題が表れていますが、この欠点は作業課題として監視されていると信じています。

RFC2616 において、新しい HTTP/303 リダイレクト コードは以下のように定義されています:

リクエストに対するレスポンスは異なる URI の下で発見でき、かつリソースへの GET メソッドで取得しなければならない。このメソッドは主に、POST により起動されたスクリプトが選択したリソースにユーザー エージェントをリダイレクトできるようにするために存在している。

つまり 303 は、リダイレクトされたリクエストのメソッドは GET に変更される事を明確に意味しています。

残念ながら、新しく導入された HTTP/307 の定義は、HTTP/302 1の元々の定義に含まれていたのと同様の問題として、最初のメソッドが利用されるべきであると明瞭に示す事に失敗しています。とは言え、(前記の文書に基づけば) HTTP/307 レスポンス コードの意図するものはクライアントがリダイレクトされたリクエストの本来のメソッドを保存すべきであるとはっきり示している事は明白です。

従って HTTP/303 と HTTP/307 の双方により、Web 開発者はメソッドに対して何が起きてほしいのか (303->GET への変換; 307->元のメソッドの維持) を示す事ができるようになったのです。

それではこれがどの位うまく成し遂げられているか、見てみましょう…

リダイレクト時のメソッドを維持する

この節では、さまざまなシナリオによるクロス ブラウザーのテストの結果を示したいと思います。この結果は XmlHttpRequest オブジェクトと Meddler Script ファイルを使って生成されています。

使用した MeddlerScript は以下の通りです:

import Meddler;
import System;
import System.Net.Sockets;
import System.Windows.Forms;
 
class Handlers
{ 
    static function OnConnection(oSession: Session)
    {
        if (oSession.ReadRequest()){        
            var oHeaders: ResponseHeaders = new ResponseHeaders();
            oHeaders.Status = "200 OK";
            oHeaders["Connection"] = "close";
            
            var sRequestAsString = oSession.requestHeaders.ToString(true, true, true) + System.Text.Encoding.UTF8.GetString(oSession.requestBodyBytes);
                        
            if (oSession.urlContains('redir'))
            {
                MessageBox.Show(sRequestAsString, "Redirect Request");
                oHeaders["Content-Type"] = "text/plain";    
                var s = oSession.GetQueryParams()["code"];
                oHeaders.Status = s + " redirect";
                oHeaders["Location"] = 'http://'+ oSession.requestHeaders["Host"] + '/final.cgi';
                oHeaders["Cache-Control"] = "max-age=0";
                oSession.WriteString(oHeaders.ToString());
                oSession.WriteString("redirecting...\r\n");
            }
            else
            if (oSession.urlContains('final'))
            {
                MessageBox.Show(sRequestAsString, "Final Request");
                oHeaders["Content-Type"] = "text/plain";    
                oHeaders["Cache-Control"] = "max-age=0";
                oSession.WriteString(oHeaders.ToString());
                oSession.WriteString("Final Request was:<br />\r\n");
                oSession.WriteString(sRequestAsString);
            }            
            else
            {
                oHeaders["Content-Type"] = "text/html";
                oSession.WriteString(oHeaders);
                oSession.WriteString("<html><head><title>XMLHTTPRequest-based Redirect Test Harness</title>\n");
                oSession.WriteString("<!doctype html>\r\n<html><head><script type='text/javascript'>\r\n");
                oSession.WriteString("var xmlHttp; var i=0;");
                oSession.WriteString("function doXHR(sMethod, sURI, sBody, iResponseCode){\r\n");
                oSession.WriteString("i++; xmlHttp = new XMLHttpRequest();\r\n");
                oSession.WriteString("\toutputdiv.innerHTML = '<pre>Beginning request #' + i + '...</pre><br />';\n");
                oSession.WriteString("\txmlHttp.onreadystatechange = stateChanged;\n");
                oSession.WriteString("\txmlHttp.open(sMethod,sURI+'?code='+iResponseCode,true);\n");
                oSession.WriteString("\txmlHttp.setRequestHeader('CustomHeader', 'CustomValue');\n");
                oSession.WriteString("\txmlHttp.send(sBody);}\n");
                oSession.WriteString("function stateChanged(){\n\t\nif (xmlHttp.readyState==4){\n data = xmlHttp.responseText; ResponseHeaders.innerHTML = '[#' + i + ']Script-accessible response headers were:<br/><PRE>' + xmlHttp.getAllResponseHeaders() + data+ '</pre>';}\n}\n");
                
                oSession.WriteString("function BuildRequest(){ doXHR(document.getElementById('txtMethod').value, document.getElementById('txtURI').value,document.getElementById('txtBody').value, document.getElementById('txtCode').value);\n}\n");
                
                
                oSession.WriteString("</script></head><body><br></p><hr>Output: <div id='outputdiv'></div><br>Response: <span id='ResponseHeaders'></div><br></span>");
                
                oSession.WriteString("<br /><input type=text id='txtMethod' value='GET' /><br />\n");
                oSession.WriteString("<input type=text id='txtURI' value='/redir.cgi' /><br />\n");
                oSession.WriteString("<input type=text id='txtBody' placeholder='Request body text...' value = '' /><br />\n");
                oSession.WriteString("<input type=text id='txtCode' value='302' />\n<br />");
                
                oSession.WriteString("<button onClick='BuildRequest();'>Send Request</button>");
                oSession.WriteString("</body></html>\n");
                
            }
            
        }
            
        oSession.CloseSocket();
    }
}

まず HTTP/303 リダイレクトを試してみました:

IE 6-10 DELETE が GET に変換される
Chrome 13 DELETE が GET に変換される
Firefox 6 DELETE が GET に変換される
Safari 5.1 DELETE が GET に変換される
Opera 11.5 DELETE が GET に変換される

すべてのブラウザーが HTTP/303 リダイレクト コードを受信した際に適切に動作しています。具体的には、クライアントは DELETE メソッドを GET に変換してリクエストを再発行しています。


次のテストとして、HTTP/307 リダイレクトを示しました:

IE 6-10 DELETE メソッドが維持される
Chrome 13 DELETE メソッドが維持される
Firefox 6 DELETE メソッドが維持される (確認後)
Safari 5.1 DELETE メソッドが維持される
Opera 11.5 リダイレクトに失敗する (確認後)

(バグがあるのではないかと思われる Opera 11.5 を除く) すべてのブラウザーが、HTTP/307 を受信した後に正しくリクエスト メソッドを維持しています。


以前からの HTTP/301 と HTTP/302 メソッドを利用した際に、開発者の皆さんもブラウザー間の相違に直面するでしょう。

IE 6-10 DELETE メソッドが維持される
Chrome 13 GET に変換される
Firefox 6 GET に変換される
Safari 5.1 GET に変換される
Opera 11.5 GET に変換される

ハイライトした結果が、Twitter での発言者が驚いた部分なのは間違いないでしょう。Internet Explorer だけが HTTP/302 リダイレクトの後でも DELETE メソッドを維持しており、RFC2616 で “誤った” としている動作を行っていません。他のブラウザーはメソッドを GET に変換しており、HTTP/301 または HTTP/302 に対して HTTP/303 と同様の応答をしています。

しかしまだびっくりする事があります…


前節で示したこの動作ですが、Internet Explorer も他のブラウザーと同様に HTTP/301HTTP/302 に対して POSTGET変換するのですから、なおさら驚くべき事でしょう:

IE 6-10 GET に変換される
Chrome 13 GET に変換される
Firefox 6 GET に変換される
Safari 5.1 GET に変換される
Opera 11.5 GET に変換される

前に示唆したように、IE が HTTP/301 と HTTP/302 に対して POST->GET 変換をするのは、1990年代に追加された、当時のより一般的だった Web ブラウザーとの互換性のための歴史的な所産です。XMLHttpRequest オブジェクトが採用される以前は、Web ページが他の HTTP メソッドを利用する事は現実的にできず、そのため POST メソッドに限って変換が行われたのです。


ブラウザー間の挙動の相違は、HEAD リクエストに対する 302 レスポンスへの対処でも顕著です:

IE 6-10 HEAD メソッドが維持される
Chrome 13 HEAD が GET に変換される
Firefox 6 HEAD が GET に変換される
Safari 5.1 HEAD が GET に変換される
Opera 11.5 リダイレクトが発生しない

HEAD が GET に予期せず変換されてしまう事により、パフォーマンス上の問題や機能上の欠陥が生じるのではないかと思われます。

リダイレクトを確認する

さて、RFC2616 ではリダイレクトは一般的に冪等/ “安全” であるメソッドを除き”自動的” に行われるべきではないと注記しています; この考え方は、同じアクションが異なる URL に対して行われる際、ユーザーがそれを確認しなければならないという事です。現実的には、ユーザーがそうしたプロンプトを理解できそうにはないので、多くのブラウザーはリダイレクトに対するユーザーの確認を求めるこの要請を無視しています。

POST -> 307 リダイレクトでの警告に関する各ブラウザーの挙動

IE 6-10 サイレントに再度 POST する
Chrome 13 サイレントに再度 POST する
Firefox 6 再 POST の前にプロンプト (ターゲット URL なし) を表示
Safari 5.1 サイレントに再度 POST する
Opera 11.5 プロンプト (ターゲット情報あり) を表示。

ただしYes でも No でも同じ結果。バグか?

Firefox のリダイレクト時の確認プロンプト:

Opera のリダイレクト時の確認プロンプト (: 三つのボタンのどれをクリックすれば良いのかという問題には見えません)

この記事が、状況を明確にするのに役立てばと願っています。一般的に言えば、もし GET 以外のメソッドを使っている際にリダイレクトをさせようと思ったら、どのような動作が望ましいのか明らかにするため HTTP303/ と HTTP/307 を使いましょう。

-Eric

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

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