[504] HTTP の Retry-After: ヘッダーは、 次に要求を送信するまでに待つべき時間を指定するものです。

[529] Webブラウザーでは実装されていませんが、特別な用途の利用者エージェントや Googlebot は 503 応答後の再試行の時期の決定のために参照しているようです。

仕様書

意味

[510] Retry-After: ヘッダーは、 利用者エージェントが続きの要求を行う前に待つべきought to長さを示します。 >>509

[512] 3xx 応答では、リダイレクト先の要求を発行する前に利用者エージェントが待つべきought to最低時間を示します。 >>509

[5] 503 応答では、サービスが利用不能であると思われる時間を示します。 >>509

[516] それ以外の状態符号では意味は定義されていませんが、 なぜか特に禁止もされていません。

[7] OData では 202 でも Location: と Retry-After: を使うことを認めており、 Retry-After: は Location: の URL にアクセスする前に待つべき時間を表します >>6。

構文

[506] Retry-After: ヘッダーの値は、 その時刻以降に再試行を開始するべき絶対時刻をHTTPの日付形式として指定するか、 または待つべき相対的な時間をデルタ秒として整数で指定するかのいずれかです >>509。

  1. |
    1. HTTP-date
    2. delay-seconds

文脈

[415] 鯖は、 413 応答において、 その状態が一時的なものである場合、クライアントが再試行してもよい時刻を表す Retry-After: ヘッダーを生成するべきです >>507。

[508] 鯖は、 503 応答において、 要求を再試行するまでクライアントが待つべき時間を提案する Retry-After: ヘッダーを送っても構いません >>505。

[12] 429 応答で Retry-After: ヘッダーを使うことができます >>11。

3xx での用法

>>512

[1] 実際 redirect で2分とか待たされたら嫌かも。 その間 UA は、利用者は、何をしてればいいんやねん? みたいな。

応答で送られてきた実体を利用者に見せつつ、 何秒後に移動します。。。というメッセージを出すといいのかな。 非対話 UA だったら・・・どうするのだろう?

[2] よく、移転しますた。っていうメッセージを 200 で出して、 Refresh で数秒後に飛ばすというのをやってますけど、 それの標準化された代替として使えるかな??

[515] 実装がこれに対応しているという話は聞いたことがありませんし、 鯖で使われているという話も聞いたことがありません。

歴史

[505] RFC 1945 (HTTP/1.0) D.2.8; RFC 2068 (HTTP/1.1) 14.38; RFC 2616 (HTTP/1.1) 14.37 Retry-After

The Retry-After response-header field can be used with a 503 ({1945} service unavailable Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client. {2616} This field MAY also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked wait before issuing the redirected request. The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.

Retry-After 応答頭欄は、 どれだけの間サービスが利用不能と思われるかを要求してきたクライアントに示すために 503 (サービス利用不能) 応答と共に使うことができます。 この欄は、再指向要求を発行する前に利用者エージェントに待機して欲しい最低時間を示すために 3xx (再指向) 応答でも使って構いません。 この欄の値は、 HTTP-date か、応答の時刻の後の秒数 (十進整数) のいずれかです。

{2968,2616}

  • Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )

Two examples of its use are

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

In the latter example, the delay is 2 minutes.

後者の例では、間隔は2分です。

実装

[517] Retry-After: ヘッダーは Webブラウザー本体では実装されていません。

[523] Firefox の Bugzilla には2004年から登録されています >>522 が、 10年経っても実装の見込みはありません。

[520] Chrome の captive portal 検出機能では、 503 からの再試行時に Retry-After: の値を尊重するようです >>518, >>519。

[524] Mozilla Project の Android 関連機能では 503 からの再試行時に Retry-After: の値を尊重するようです >>521。

[526] Android で用いられる GCM では 503 で Retry-After: を尊重することが求められています >>525。

[528] Googlebot は 503 時の Retry-After: の値をスケジューリングの参考にしているようです >>527。

例

[513] 絶対時刻を指定した例 >>509
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
[514] 相対時刻を指定した例 >>509
Retry-After: 120

メモ

[3] 423 (固定済) あたりにも Retry-After が使えてもいい気がするのだけどどうよ?

[4] >>3 Lock は他の処理との相互作用だから、予測がつかない、ってことかもしれませんけど、経験的に予想できることもありますから、使ってもいいかもしれませんね。

[8] Help Desk API for Developers | Freshdesk (humans.txt 著, 版) http://freshdesk.com/api#ratelimit

The number of API calls per hour is restricted to 1000. If your API request is received after the limit has been reached, Freshdesk will give you an error response. The "retry-after" value in the response header will tell you how long you need to wait before you send another API request.

Response

HTTP STATUS: HTTP 403 Forbidden

Headers:

"Retry-After": <seconds>

[9] Rate Limiting | Content API ( 版) https://box-content.readme.io/reference#rate-limiting

HTTP/1.1 429 Too Many Requests

Retry-After: {retry time in seconds}

[10] Rate Limiting - Riot Games API ( 版) https://developer.riotgames.com/docs/rate-limiting

If a call exceeds the user or service rate limit for a given period of time, then subsequent calls made to limited endpoints will return a 429 "Rate limit exceeded" HTTP response until the rate limit expires.

In addition to the response code, some additional headers will be included in the response that provide more information.

Retry-After - The remaining number of seconds before the rate limit resets.

X-Rate-Limit-Type - The rate limit type, either "user" or "service".

If the above headers are not included in the response, then the rate limit was not enforced by the API infrastructure, but rather by the underlying service to which the request was proxied.

[13] RFC 7030 - Enrollment over Secure Transport () https://tools.ietf.org/html/rfc7030#section-4.2.3

If the server responds with an HTTP [RFC2616] 202, this indicates

that the request has been accepted for processing but that a response

is not yet available. The server MUST include a Retry-After header

as defined for HTTP 503 responses. The server also MAY include

informative human-readable content. The client MUST wait at least

the specified "retry-after" time before repeating the same request.

The client repeats the initial enrollment request after the

appropriate "retry-after" interval has expired.

[14] Backoff indicators — Kinto 8.1.5 documentation () https://kinto.readthedocs.io/en/latest/api/1.x/backoff.html

A Retry-After header will be added if response is an error (>=500). See more details about error responses.

[15] Firebase Cloud Messaging の HTTP プロトコル () https://firebase.google.com/docs/cloud-messaging/http-server-ref?hl=ja

500~599 の範囲に含まれるエラー(500 や 503 など)は、リクエストの処理中に FCM 接続サーバーで内部エラーが発生したか、サーバーが(タイムアウトなどの理由で)一時的に利用できないことを示します。送信者はレスポンスに含まれている Retry-After ヘッダーを適用し、後で再試行する必要があります。アプリサーバーでは指数バックオフを実装する必要があります。