web-dev-qa-db-ja.com

HTTP応答ヘッダーの再試行-何に影響しますか？

一時的な過負荷が原因でWebサイトのサービスを丁寧に拒否したい場合、HTTP応答 503 Service Unavailable が適切と思われます。仕様には、503で Retry-after ヘッダーを送信することが記載されています。

ポイントはありますか？再試行後は何かに影響しますか？ブラウザはそれに注意を払っていますか？

httphttp-headers
56
user213154

私の知る限り、ブラウザはRetry-afterヘッダー。プロキシとキャッシュは可能性がありますが、

どうやら、一部のブラウザにはRetry-After（サポートはまだ最高の状態です）。私はブラウザでそうすることの利点を完全に確信しているわけではありません。一般的に、障害をキャッシュすることは悪い考えと考えられています。ただし、いつリクエストを受け入れるかがわかれば、クライアントに害を及ぼすことはありません。 （ただし、予想よりも早く復帰した場合、実際にヘッダーを尊重するプログラムは、サイトがまだダウンしていると想定し、報告する必要があります。）

最も明らかな利点は、Googlebot（および場合によっては他のスパイダー）がヘッダーがある場合に注意を払うように見えるためです。

それだけで...追加するのが簡単で、サービスがいつ利用可能になるかについて合理的に正確な推定値を思い付くことができるなら、それを選んでください。しかし、あなたがそれをするためにあなたの邪魔をすることはお勧めしません。とにかく単なる助言であり、そこに間違った時間を入力すると、ヘッダーをまったく含めないよりも多くの問題が発生する可能性があります。

21
cHao

Retry-Afterヘッダーの現在の状態

クライアントとサーバーでのRetry-Afterヘッダーの実装は、この質問の最初の投稿以来、近年少し変更されています。だから私は更新された答えを提供すると思った。

最初に、RFC 2616、 セクション14.37再試行後 状態：

Retry-After response-headerフィールドを503（Service Unavailable）応答とともに使用して、要求元のクライアントがサービスを利用できないと予想される期間を示すことができます。

...

その使用法の2つの例は次のとおりです。

  Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
  Retry-After: 120

後者の例では、遅延は2分です。

クライアントおよびサーバーソフトウェアでのサポート

以下は、さまざまなソフトウェアのRetry-Afterヘッダーに関するコードリポジトリコミットメッセージ、アナウンス、およびドキュメントです。

クロム/クロム

ログメッセージで2012年11月22日にコミットされたコード： 検出タイムアウトとRetry-After HTTPヘッダーの使用法 。

Mozilla/Firefox

ログメッセージを使用した2012年3月27日のコードコミット： 5xxの処理、X-Weave-Backoff、Retry-After 。さらに、Mercurialリポジトリには Retry-Afterヘッダーに関する他の3つの言及 があります。

バグは、2004年1月6日にタイトル HTTP 503応答で送信された再試行後は無視されます で最初に送信されました。

Googlebot

サイトのダウンタイムへの対処に関するGoogleウェブマスターセントラルブログの記事には、 Retry-Afterヘッダーを使用してURLを再クロールするタイミングを決定できる が記載されています。

Bingbot/Msnbot

公式のRetry-Afterサポートドキュメントが見つかりませんでした。ただし、Microsoftのボットを抑制するために503応答でこのヘッダーを使用することについて、ランダムフォーラムでいくつか言及されていました。

Nginx

add_headerディレクティブ 状態：

応答コードが200、201、204、206、301、302、303、304、または307に等しい場合、指定されたフィールドを応答ヘッダーに追加します。

したがって、バージョンを使用して503応答のRetry-Afterヘッダーを追加するには、次のようにします。

  • 1.7.4以前では、 Headers More などのサードパーティモジュールを使用します。

  • 1.7.5以降では、alwaysパラメーターをadd_headerディレクティブに追加します。

アパッチ

Nginxとは異なり、Apache header documentation は、503応答でRetry-Afterヘッダーを送信できないことを示しません。ただし、2xx以外の応答については、ドキュメントには次のように記載されています。

リダイレクトなど、ローカルで生成された成功以外（2xx以外）の応答にヘッダーを追加します。この場合、常に対応するテーブルのみが最終的な応答で使用されます。

これは SO回答 であり、503応答に対してalways条件でRetry-Afterヘッダーを設定します。

AskApacheの記事には、 検索エンジンに戻るように指示する Retry-Afterヘッダーで503応答を使用する方法の他の構成例が記載されています。

クライアントテスト

私は、Rubyサーバーを作成しました。このサーバーは、10秒に設定されたRetry-Afterヘッダーと乱数を含む本文で503応答を返すだけです。

require 'sinatra'

get '/' do
  headers 'Content-Type' => 'text/plain', 'Retry-After' => '10'
  status 503
  body Rand(1000).to_s
end

私はそれにアクセスしました：

  • Chromium 44、Firefox-ESR 38、およびSeamonkey 2.33を使用したOpenBSD 5.8、
  • Chrome 47およびSafari 6.1を使用するMac OSX 10.7.5、
  • Chrome 48、Firefox 41、およびEdge 25を使用するWindows 10。

これらのブラウザは、10秒後にURLを自動的に更新し、新しい乱数を表示することを期待していました。ただし、数分たってもすべてのブラウザーが再試行しませんでした。 Retry-After期間を短くしたり長くしたりしても同じ結果が得られました。サーバーアクセスログは、これらのブラウザーのいずれからも再試行が行われなかったことを確認しました。

また、再試行後の期間がURLをすぐに再取得する前の「ソフト」リフレッシュ。そのため、Retry-Afterヘッダーを使用して、 "refresh-happy"ユーザーを調整することはできません。いくつかのフォーラムで、このヘッダーを使用して、せっかちなユーザーがサイトを攻撃するのを抑えることができると見たので、これについて言及します。

サイドノートとして、タイムアウト期間の前に「ソフト」リフレッシュがアクションを持たないことは論理的に思えますが、「ハード」またはキャッシュバイパスリフレッシュはタイムアウトを無視し、すぐにURLを再フェッチします。

結論

Retry-Afterヘッダーのサポートは、クライアントとサーバーの両方でまだ少し大ざっぱなようです。それでも、設定が難しくない場合は、503応答の再試行タイムアウトを設定することをお勧めします。

Googlebotがヘッダーをサポートし、タイムアウト期間後に実際に再試行する唯一のクライアントであっても、404、500、502、または504応答とは対照的に、ページのインデックスが解除されないようにすることができます。

77
Clint Pachl

これはニワトリと卵の問題だと思っています。ウェブサイトに煩わされることはないので、ブラウザは現在、再試行を実装していません。私の意見では、先に行き、ユーザーにサービスとして送信します。 Webブラウザーの選択がそれを実装しない場合、それはブラウザーが単に有用な情報を提供しないことです。やった！

複数の競合する実装を持つ標準を実装しようとするとき、私は常に標準に準拠し、異なる実装に注意を払わないようにします（cURLingなどの実装をエミュレートしようとしているが、ヘッダーをウェブブラウザ）。そうでなければ、事実上の標準になります。IEの支配的な時代を覚えているなら、それは望まないでしょう。

8
dotancohen

X時間後に自動的に更新を送信する場合は、

Refresh: 120; url=http://your_url.com

pHPの場合：

header("Refresh: "    .$retry_time."; url=". $url);

現在のページを更新するには、$_SERVER["REQUEST_URI"]の$ url。

Opera、Firefox、Internet Explorerの異なるバージョンでこのヘッダーをテストしました。

このヘッダーは、画像などのバイナリコンテンツを更新するためにも機能します（ただし、直接またはフレームにロードされた場所でのみ-IMG-Tagは再ロードされません）。

1
Radon8472