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

広告

コメントする »

まだコメントはありません。

RSS feed for comments on this post. TrackBack URI

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

WordPress.com Blog.

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