Refresh: ヘッダー (HTTP)

[1] Refresh: は、指定した秒数が経過した後に navigate を開始するべきことを示す HTTPヘッダーです。 <meta http-equiv=Refresh> は、同じく HTML プラグマ指令です。

仕様書

[85] HTML Standard (2015-05-06 10:42:35 +09:00 版) https://html.spec.whatwg.org/#attr-meta-http-equiv-refresh

構文

[10] Refresh = "Refresh" [FWS] ":" [FWS] refresh-content

[2] HTML 4.0 には例示 (>>8) がある (4.01 にはない) けど、一般に使われているパラメーター型 (>>12; 例: >>3) ではなくて読点区切型 (>>13; 例: >>5) になってる。

[11] refresh-content = refresh-param-content / refresh-comma-content
[12] refresh-param-content = refresh-second FWS] ";" [FWS] "URL=" value]
[13] refresh-comma-content = refresh-second [FWS] "," [FWS] refresh-uri

[9] >>12 のようにパラメーターの属性名は URL になっていて、実際中身が URL でない URI である例は見たことが無いけど、 URL でない URI に対応している実装は、あえて URL に限定することなく、どんな URI でも受け付けるのが良いと考えられる。

[14] refresh-second = 1*DIGIT
[15] refresh-uri = absoluteURI / relativeURI

[17] refresh-second (>>14) 秒後に (一度だけ) 指定 URL または自 URI を読む (そしてそれに移動する)。 (refresh-second 秒毎に URI を読むわけではない。)

[18] refresh-second が "0" の場合、実質的に (標準的な) HTTP の redirect と同じになる。でも Netscape の説明文 (>>9) はこんなことも言ってるぞ。

a "Refresh" header can be returned as part of any HTTP response, including a redirection. So a single HTTP response can say "go get this URL now, and then go get this other URL in 10 seconds".
("Refresh" 頭は redirect を含む任意の HTTP 応答の一部として返すことが出来ます。ですから単一の HTTP 応答で「この URL に今行き、それからこの別の URL に10秒後に行くように。」と言うことが出来ます。)

This means you can have a continuous random URL generator! Have a normal random URL generator (such as URouLette http://kuhttp.cc.ukans.edu/cwis/organizations/kucia/uroulette/uroulette.html) that returns as part of its redirection response a "Refresh" directive that causes the browser to go get another random URL from the random URL generator in 18 seconds.
(これは継続無作為 URL 生成器を作れることを意味します! 普通の無作為 URL (例えば URouLette (ルーレット] ]) は "Refresh" 指示を redirect 応答の一部として返し、ブラウザーは他の無作為な URL を18秒後に無作為 URL 生成器から得ることになります。))

[19] WAI とか HTML4 はアクセス性の観点から使用しないように薦めている。 (確かに、 >>18 の Netscape の言ってる例は面白いけど、遊び以外でやられたらたまらんわな。)

[16] value = http-token / quoted-string / non-token

[20] value (>>16) の部分は、他の頭欄の作法からすると http-token 以外の文字は quoted-string にしないといけないはず。

[21] この頭欄は HTML の META要素で使われる (例: >>6) 事が多い。 HTTP で見かけることはあまりない。 (皆無ではない。) HTTP 頭欄なのに HTTP で使ってもらえないなんて不憫だね。

[22] META 要素の属性値で既に「"」で囲まれているので、その中で更に (「"」で) 囲もうとする意識は無い。みっともないし。そもそもその必要性に気付かないのだろうかね? ってことで、主に CGI 出力 (Web chat の CGI script とか。) で、 http-token 以外が生で出てきたりする (>>24)。

[23] ○ <meta http-equiv="refresh" content="0;URL="foo.cgi?hoge=foo&bar=aa"">
[24] × <meta http-equiv="refresh" content="0;URL=foo.cgi?hoge=foo&bar=aa">

※ (>>24) 「=」が URL に含まれるので quoted-string にするべき。それから「&」は「&」でないと HTML として異常。

[25] そもそも URI は(絶対だと)「:」を含むので http-token にはならないことも多いじゃないか。

[26] non-token = absoluteURI / relativeURI ;; 救済措置

[27] Netscape 社の説明文によると絶対 URL のみで相対 URL は使ってはいけない。けど、現実には結構使われている。

[28] fragment は要らないでしょう。多分。あってもそこに飛ぶのはあんまり好ましくないような... (それを言うなら Refresh: 欄自体あっても飛ぶのは宜しくないなあ。)

[29] >>28 なんで? 利用者にとってはちょっとあれだけど、一定時間後に下のほうに飛ぶとかあってもよさそう。

[30] 属性名が「URL」だから、URN とかは駄目なのかなあ...

[31] >>30 See >>9

[32] non-token /= 1*octet ;; 人にやさしく・・にも程がある。

[33] CGI の出力で、例えば Web chat CGI script で名前とかが URI符号化されてなかったりすることもままある。それだと URI としてすら正しくない。そんなのまで救済 (>>32) してあげる必要があるのかどうか。

[56] 値を URL=foo.html のように (秒なしで) 指定している文書があるようです。 MacIE 4.5 にはこの時 URL 指定を無視して当該文書を即座に読み込み直す不具合があるそうです。 (Internet Explorer 4.5(Mac版) http://members.jcom.home.ne.jp/pctips/ua/IE45Mac.html)
[66] >>2 HTML 4.01 では不適切だとして削除されたそうです。変更履歴参照。

UA の実装

[40] Opera (6.05 で実験) は、 " で囲まれていると、 " も URI の一部 (すなわち、 URI 符号化されていない不適切な相対 URI) とみなして、そこに飛ぼうとしますから、 (ふつう) 404 となります。

[41] (>>40) ですから " をはずせばよいのですが、この時 URI に ; が含まれていると、そこを url] パラメーター (>>12) の終わりとみなしてしまいます。対処法はその URI の性質に応じて & に置き換えるなり URI 符号化するなりするしかありません。

[42] NetscapeNavigator 2.01 は、 >>41 と同様に ; があると問題が起こります。 (>>40 の " は問題ありません。)

[43] WinIE 3.02, WinIE 5.5, Mozilla などでは今のところ問題は確認されていません。

[44] HTML の meta 要素と HTTP の頭欄の一方だけにしか対応していない UA はまだ見つかっていません。

[45] NN2.01 は、タイミング? により Refresh: 欄を指定しても飛んでくれないことがありました。 HTML に meta 要素でも同じ内容を指定すればちゃんと飛んでくれましたが、必ずこれで直るかはわかりません。
[46] >>27 NN2.01 では相対 URI でも動きました。
[47] >>28 <somewhere#fragment> に飛ばすのは NN2.01 を含めていろんなブラウザは対応していますね。
[48] >>42 NC4 PR4 でも同様の問題が確認できました。
[49] Amaya 7.0: 未対応。Wish list には載ってましたが・・・
[50] Mozilla/1.22 (compatible; MSIE 2.0; Windows 95): 対応。>>40 問題がありました。 >>41 問題はありません。
[51] WinIE 6.0: 対応。WinIE5 もそうですが、 0 にしても表示されてから飛び始めるまでにちょっと間があります。 (Moz ならすぐに飛び始めるのに。) IE はレンダリングその他全て完了した後に処理を始めるんでしょうか? (Moz もそうだと思うんだけどなあ。) (単に IE がのろいだけとか?)
[52] WinIE6: 対応。「セキュリティゾーン」の設定で無効に出来ます。
[55] MacIE 4.5: 対応。変な不具合あり (>>56)
[67] NC 4.01: 対応。url='foo' (' quote) でも動いてしまいました。っていうかいままでうっかり間違って ' で quote してました。 (ってことは最新の Mozilla でも動くのか?)
[68] WinIE 3.01: 対応。>>67 のように書くと、単引用符で始まる相対 URI として扱います。 (正しい動作)
[70] emacs-w3m: 対応。>>40 emacs-w3m にもその問題がありました [emacs-w3m:06562] が、修正されました [emacs-w3m:06656]。修正のついでに ' で引用してもよいことにされたらしいですが、気持ち悪いなあ。 (value として解釈するなら、 ' は token の一部と解釈するのが正しい。)
[72] Lynx: 対応。1996年8月2日の版で URI をレンダリングするようになったそうです。

`url` 引数の引用符

[405] テスト (HTML): Index of /~wakaba/-temp/test/html/meta/http-equiv/refresh (2009-01-05 22:29:25 +09:00 版) http://suika.fam.cx/~wakaba/-temp/test/html/meta/http-equiv/refresh/ の squote、dquote

[406] (HTML) Firefox 3.0.5、Opera 9.61、Chrome 1.0.154.36、 WinIE7 のいずれも、 url="double-quoted" と url='single-quoted' の両方に対応していました。

[408] テスト (HTTP): Index of /~wakaba/-temp/test/http/refresh (2009-01-05 22:54:49 +09:00 版) http://suika.fam.cx/~wakaba/-temp/test/http/refresh/

[409] (HTTP) Firefox 3.0.5、Safari 3.2.1、 WinIE7 のいずれも、 url="double-quoted" と url='single-quoted' の両方に対応していました。 Opera 9.61 は url="double-quoted" に対応していましたが、 url='single-quoted' には対応していません ('single-quoted' という URL とみなします)。

[410] Bug 6464 – Support meta refresh with quotes (2009-01-26 10:42:13 +09:00 版) http://www.w3.org/Bugs/Public/show_bug.cgi?id=6464

文脈

[97] しばしば、サーバー側での HTTPリダイレクトを設定するのが困難な場合の代替として使われます。

[98] 何らかの Webページの表示とダウンロードを同時に実行したいときに使われることもあります。

飛び先のプロトコルに関して

[34] Web chat の CGI script などで、飛び先が HTTP の 304 Not Modified 応答を返すように仕向けることがあるみたいです。

これを受け取ったら refresh 元のの表示を続けるのはいいとして、また指定秒数待って飛ぶのが適切かどうかはわかりません。

[35] 205 No Content も考慮する必要がありますね。

処理

[86] 構文解析器または DOM 操作により Refresh の meta 要素が文書に挿入された場合、 content 属性値の構文解析を行います。

[108] 要素が文書に挿入された時、次のようにしなければなりません >>85。

[153] 入力を、要素の content 属性値に設定します。
[154] 入力が null または空文字列の場合、
1. [155] ここで停止します。
[152] 共有宣言的更新手順群を実行します。
文書
要素の節点文書
入力
入力
メタ要素
真

[151] 共有宣言的更新手順群 (shared declarative refresh steps) は、 文書、入力、メタ要素について、次のようにします >>85。

[116] 文書のこれから宣言的に更新するフラグが真の場合、
1. [110] ここで停止します。
[124] 時間と URL を、 文書と入力を処理 (>>125) した結果に設定します。
[123] URL が失敗なら、
1. [126] ここで停止します。
[111] 文書のこれから宣言的に更新するフラグを、真に設定します。
[127] 次のいずれか1つ以上を実行します。
- 自動 navigate (>>92)
- 手動 navigate の利用者インターフェイスを提示 (>>93)
- 何もしない (>>94)

[156] この処理は、 meta 要素が文書に挿入された場合の他に、 navigate において Refresh: ヘッダーが指定されていた場合にも、実行されます。

[112] 文書は、これから宣言的に更新する (will declaratively refresh) フラグを持ちます。初期値は偽です。 HTML Standard

[125] 文書と入力の処理は、次のようにしなければなりません >>85。

[117] 入力の先頭から、間隔文字を除去します。
[118] 数字列を、入力の先頭の ASCII数字列とし、それを入力から除去します。
[120] 数字列が空文字列なら、
1. [121] ここで停止します。
[119] 時間を、数字列に非負整数を構文解析する規則を適用した結果に設定します。
[122] 入力の先頭から、 . と ASCII数字をすべて除去します。

[92] 利用者エージェントは、指定時間経過後に navigate することができます。

[130] これが最も一般的で、著者が想定する実装方法です。

[136] 次のようにしなければなりません。

[131] 利用者による停止フラグを、偽に設定します。
[137] 更新の期限が到来 (refresh has come due) を、時間秒 (利用者および利用者エージェントの都合により調整可能。) 待つタイマーに設定します。 >>85
[138] 文書の completely loaded が真なら、
1. [139] 更新の期限が到来の計測を開始します。
[140] それ以外なら、
1. [141] 文書の completely loaded から起算するタイマー群に、 更新の期限が到来を追加します。

[113] つまり、meta の挿入とcompletely loadedの遅い方から起算して時間秒待ちます。 Refresh: ヘッダーの場合には、completely loadedから起算します。

[88] 待つ時間は利用者や利用者エージェントによる調整が認められています。仕様書にはその意図は明記されていませんが、利用者が視認できない速さで navigate が実行されることを利用者が望まない時にこれを緩和したり、高頻度で navigate を繰り返す悪意ある Webページに利用者が惑わされることを防いだり、裏側で動作するWebページの navigate を遅延させて電力消費を抑えたりできるようにすることを企図していると思われます。

[87] 更新の期限が到来したら、次のようにしなければなりません >>85。

[132]
- [134] 利用者による停止が偽
- [109] メタ要素が真の場合、
  - [135] 文書の活性砂箱化フラグ集合の sandboxed automatic features browsing context flag が設定されていない
... をすべて満たす場合、
1. [133] navigate します。
  navigate する閲覧文脈
  文書の閲覧文脈
  新しい資源
  URL記録
  置換有効
  真
  始点閲覧文脈
  文書の閲覧文脈

[104] 利用者エージェントは、利用者が利用者による停止フラグを真に設定する手段を提供することが認められています >>85。一般的な Webブラウザーでは、中止ボタンがこの機能を持っています。

[95] 利用者エージェントは、タイマーの状態やリダイレクト先などを随時表示して構いません >>85。一般的な Webブラウザーではそのような表示は見られませんが、便利そうではあります。

[93] 利用者エージェントは、手動で navigate することを選択できる利用者インターフェイスを提供することができます。

[91] その場合、利用者の指示により、次のようにしなければなりません >>85。

[128] navigate します。
navigate する閲覧文脈
文書の閲覧文脈
新しい資源
URL記録
始点閲覧文脈
文書の閲覧文脈

[129] 現在の Webブラウザーではそのような利用者インターフェイスの提示は一般的ではありませんが、かつてはテキストブラウザーなどで Refresh を通常のハイパーリンクのような形で表示するものがありました。

[94] 利用者エージェントは、何もしないことも認められています。

[96] 全く何もしないのは、 Web互換では無いかもしれません。しかし mailto: や telnet: への navigate などは無効にできた方が嬉しいかもしれません。

利用者インターフェイス

[105] アドレスバーも参照。

歴史

[416] リンク型 redirect は、 XHTML2 の第4次案で検討対象として挙げられていました。

「http-equiv の機能で XHTML2 に欠けているもの」とされているので、 <meta http-equiv=refresh> の代替として検討されていたものと推測されます。

[417] - Module Definition Conventions (2003-02-01 00:24:54 +09:00 版) http://www.w3.org/TR/2003/WD-xhtml2-20030131/abstraction.html#s_abstraction_issue_2

例

[3] Refresh: 20; URL="http://suika.fam.cx/"
[4] Refresh: 30
[5] Refresh: 0,refreshed.html (使用するべきではない。)
[6] <meta http-equiv="refresh" content="0;URL=hoge.html">

メモ

[36] 飛び先が自分自身だと無限 loop になる危険性がありますが、 Web chat のように意図的にそうしている場合もありますからどうしようもないですね。 Refresh: 0 が数回続いたら中断、とかがいいんでしょうか。
[37] WinIE は Refresh: 0 で飛んだら履歴 (「戻る」ボタンのメニュー) から飛び元の頁を消しますね。 (WinIE 5.0 くらいからだったっけ?)
[38] WinIE 3.0 が HTTP 頭の Refresh: 欄に対応しているんを確認しました
[53] Another HTML-lint : Explanation http://openlab.ring.gr.jp/k16/htmllint/explain.html#refresh-link
[54] Refresh: に対応していない UA や設定で切られている場合を考慮して、本体 (HTML など) でもハイパーリンク (a 要素など) を用意しておくのが望ましいでしょう。
[57] >>1 応答頭欄よりも実体頭欄かと思ったけど、 Netscape は応答頭欄だとしていますね。どっちがいいかわからなくなってきた...
[58] >>57 実際の使い方を考えれば、「移転しますた」とかは、頁の内容の一部に近いメタ情報ということで、実体頭欄に分類できると思われ。一方 Netscape の目論見では server push もどきなんだから、プロトコル要素 (→応答頭欄) のような気もするな。
[59] w3m や Lynx では、 a 要素のようなハイパーリンクとして文書の最初に表示します。 w3m の場合は更に自動で飛ぶことも出来ます。
[60] >>59 0 秒後とかならともかく、10秒後とかに、予告無く移動が始まると驚かされますから、他の UA であっても、画面に表示する内容に Refresh: の情報を加えて欲しいですよねえ。
[61] ダウンロードの頁で、リンク先がダウンロードする資源そのものではなく、 HTML でその Refresh が当該資源になっていることが、特に海外のサイトでしばしばあります。何を狙っているのか知りませんが、何か異様な気がしてすきになれません。
[62] >>61 の「ダウンロード画面が出る」例だけではなくて、例えば大抵メイル作成画面が出るように設定されている mailto: URI などが指定されていると利用者は面食らうでしょう。
[63] >>62 特に秒数が大きいと忘れたころ (本文読んでる途中とか。) に突然変化が起こったり。一般に秒数には制限があったほうがいいかも。
[64] >>61 加えて、 URI を使って致命的な動作が可能な場合 (独自拡張とか。例: X-Becky-*: (>>2)) は非常に危険です。そのような機能は実行されないように制限する必要があるでしょう。
[65] >>63 現在の多くの実装では Refresh: 指定の存在を即座に示す UI が無いのももんだいでしょう。 w3m などだと Refresh: を頁の上のほうにリンクとしてレンダリングします。
[69] 無料サービス系 Web サイトとかで、 404 などのエラー時の出力に Refresh で、エラー報告を数秒した後にそのサービスのトップ頁に飛ばすようなのがよくあります。これは bad practice だと思います。 URI を手入力して typo してしまって、直そうと思ったら次の URI に飛んでしまうとか。 (ブラウザの界面の実装の問題ではありますが。)