仕様と根拠

Retry-After の読み方

値が数字だけなら delay-seconds(待つ秒数)、HTTP-date の 3 形式(IMF-fixdate・rfc850-date・asctime-date)のどれかなら日時として読みます(RFC 9110 10.2.3 節・5.6.7 節)。秒数は基準の日時に足し、日時はそのまま日本時間(UTC+9)と UTC に直します。受け取る側はこの 3 形式すべてを受理する決まりのため、旧い形式も読めた上で警告にします。

2 桁の年

rfc850-date の年は 2 桁です。50 年を超えて未来になる年は、同じ下 2 桁の直近の過去の年と読む規則(RFC 9110 5.6.7 節)を、基準の日時を現在として適用します。基準の日時がないと世紀が決まらないため、2000 年代と仮定して警告します。

RateLimit 系ヘッダー(草案)

RateLimit-Policy は q(割り当て)・qu(単位)・w(期間の秒数)、RateLimit は r(残り)・t(回復までの秒数)を持ちます。これは IETF の草案(draft-ietf-httpapi-ratelimit-headers-11)の書式で、RFC ではありません。r が 0 のときは t を基準の日時に足して回復の目安にします。

根拠にした仕様・資料

指摘の段階

• エラー: 仕様に反していて、正しく読めない・処理できない入力です。
• 警告: 読めるものの、仕様の推奨に反する・矛盾する・意図と違う結果になりやすい入力です。
• 情報: 誤りではありませんが、知っておくとよい扱い(読み飛ばした部分や解釈)です。

入力の扱い(送信しない仕組み)

処理はすべてお使いのブラウザの中で行います。処理の本体はこのサイトから配信する小さなスクリプト(/app.js)で、外部のサービスやライブラリを読み込みません。ページはブラウザに通信を禁止させる設定(Content-Security-Policy の connect-src)つきで配信しており、入力した内容がサーバーや第三者へ送られることはありません。ファイルを選んだ場合も、端末の中で読み込むだけです。

このツールでできないこと(制約)

• 実際のサーバーへ接続してヘッダーを取得する機能はありません。貼り付けた文字だけを読みます。
• 現在の時刻は使いません。秒数を時刻にするには、応答を受け取った時刻(基準の日時か Date ヘッダー)が必要です。
• RateLimit・RateLimit-Policy は草案の書式だけを読みます。X-RateLimit-Limit など各サービス独自の書式は読み飛ばします。
• ステータスコードごとの再試行の可否(どの応答で Retry-After に従うべきか)や、429 の意味づけは判定しません。