[2] [DFN[[CODE[[[429]]]]]] ([DFN[[[Too Many Requests]]]])
は、[[要求]]数の上限 ([[rate limit]]) に達したことを表します。

* 仕様書

[REFS[
- [1] '''[CITE@en[RFC 6585 - Additional HTTP Status Codes]] ([TIME[2012-05-03 01:56:08 +09:00]] 版) <https://tools.ietf.org/html/rfc6585#section-4>'''
- [15] [CITE@en[RFC 6585 - Additional HTTP Status Codes]] ([TIME[2015-11-02 08:48:01 +09:00]] 版) <http://tools.ietf.org/html/rfc6585#section-7.2>
]REFS]

* 意味

[9] [CODE[[[429]]]] は、
[[利用者]]がある[[時間]]内に送信した[[要求]]が多すぎることを示します
[SRC[>>1]]。

[13] [[利用者]]の特定や[[要求]]の数の数え方は、[[仕様]]では規定されていません
[SRC[>>1]]。[[応用]]依存の方法で計測・制限できます。

;; [16] [CODE[[[429]]]] を使うのは義務ではありませんから、
単に[[HTTP接続]]を閉じたりしても構いません [SRC[>>15]]。

* 構文

[10] [[応答]]の[[表現]]は、条件の詳細を含める[['''べきです''']] [SRC[>>1]]。

[EG[
[12] 例えば [[HTML]] で[[英語]]で記述できます [SRC[>>1]]。
]EG]

[11] [[応答]]には [CODE(HTTP)@en[[[Retry-After:]]]] [[ヘッダー]]を含めることができます
[SRC[>>1]]。

* 処理

[14] [[キャッシュ可能]]ではありません [SRC[>>1]]。

* 文脈

[18] [[Web API]] [[サーバー]]で、 [[API]] の利用頻度制限に達した時に処理を拒むことを示すために使われることがあります。

[19] 契約や設計に基づく上限ではなく、意図しない[[サーバー]]側の資源不足によって処理できない状況にあるときは、
[CODE(HTTP)[[[503]]]] を使うのがより適切と思われます。

* 関連

[8] [CODE[X-Rate-Limit-[VAR[*]]:]] [[ヘッダー]]とよく併用されます。

* 歴史

[FIG(quote)[
[FIGCAPTION[
[3] [CITE@en[Platform API Reference | Heroku Dev Center]]
([TIME[2015-03-06 08:11:26 +09:00]] 版)
<https://devcenter.heroku.com/articles/platform-api-reference#error-response>
]FIGCAPTION]

> HTTP/1.1 429 Too Many Requests
> {
>   "id":       "rate_limit",
>   "message":  "Your account reached the API rate limit\nPlease wait a few minutes before making new requests",
>   "url":      "https://devcenter.heroku.com/articles/platform-api-reference#rate-limits"
> }

]FIG]


[FIG(quote)[
[FIGCAPTION[
[4] [CITE@en[Dropbox - Core API - endpoint reference]]
([TIME[2015-03-06 09:06:28 +09:00]] 版)
<https://www.dropbox.com/developers/core/docs>
]FIGCAPTION]

> 429	Your app is making too many requests and is being rate limited. 429s can trigger on a per-app or per-user basis.

]FIG]


[FIG(quote)[
[FIGCAPTION[
[5] [CITE[HTTP API - Guide - SoundCloud Developers]]
([TIME[2015-03-29 18:46:42 +09:00]] 版)
<https://developers.soundcloud.com/docs/api/guide#errors>
]FIGCAPTION]

> 429 Too Many Requests	To keep the amount of spam on SoundCloud as low as possible, our API limits the rate at which you can perform certain actions.

]FIG]


[FIG(quote)[
[FIGCAPTION[
[6] [CITE[Gnip Support]]
([TIME[2015-03-25 07:16:06 +09:00]] 版)
<http://support.gnip.com/apis/powertrack/api_reference.html>
]FIGCAPTION]

> 429	Rate Limited	Your app has exceeded the limit on connection requests.

]FIG]


[FIG(quote)[
[FIGCAPTION[
[7] [CITE@en[Uber API Reference Guide]]
([TIME[2015-09-25 03:53:01 +09:00]] 版)
<https://developer.uber.com/v1/api-reference/>
]FIGCAPTION]

> 429	Too Many Requests. Rate limited.

]FIG]


[FIG(quote)[
[FIGCAPTION[
[17] [CITE@ja[IIJmioクーポンスイッチAPI | クーポンについて | IIJmio]]
([TIME[2016-01-23 10:47:50 +09:00]] 版)
<https://www.iijmio.jp/hdd/coupon/mioponapi.jsp>
]FIGCAPTION]

> 429	Your application sends too many requests	X-IIJmio-Developer ヘッダに指定されたデベロッパIDを持つアプリケーション全体からのリクエスト数が上限を超過した
> 429	You send too many requests	X-IIJmio-Authorization ヘッダに指定されたユーザからのリクエスト数が上限を超過した

]FIG]





[21] [CITE@en[HTTP 429: Too Many Concurrent Connections · Bonsai]]
([TIME[2018-01-06 01:15:33 +09:00]])
<https://docs.bonsai.io/docs/troubleshooting-http-error-codes>

[FIG(quote)[
[FIGCAPTION[
[22] [CITE[python3 - HTTP Error 429: Too Many Requests - youtube-dl stopped working - Ask Ubuntu]]
([TIME[2020-03-11 22:05:26 +09:00]])
<https://askubuntu.com/questions/1181500/http-error-429-too-many-requests-youtube-dl-stopped-working>
]FIGCAPTION]

> For me the problem solved when I upgraded to kernel 4.14.150 ...
> (both 4.14.148 and 4.14.149 had the same problem)

]FIG]

[23] 
>>22 は [CODE[youtube-dl]] での報告ですが、
それだけの問題ではなくて、
[CDOE[[[curl]] --dump-header - https://www.youtube.com/watch]]
でも再現するようです。
[CODE[[[curl]] --dump-header - https://www.youtube.com/]]
では発生しません ([CODE[200]])。
そして同じ [[LAN]] に接続された別の環境で同時に実行したらそちらは
[CODE[200]]。
なので[[ネットワーク]]の問題や、サーバー側の規制ではないということです。
駄目な環境だと、
[[Python]]
でも
[[curl]] ([[HTTP/2]])
でも、他の言語で [[socket]] を読み書きするプログラムを書いても
([[HTTP/1.1]])
再現します。
駄目な環境といっても、つい先日まで普通に動いていた環境でした。

こうなると [[TCP]] か [[TLS]] のレベルで問題があると考えざるを得ません。
[[Google]] のサーバーなら変なことをしている可能性は十分あり得ます。
システムの [[OpenSSL]] と別にコンパイルした [[LibreSSL]]
を使っても同じだったので、 [[TLS]] でなく [[TCP]]
かもしれません。
[[Linux]] カーネル依存という報告とも整合します。
長時間使い続けるとか、 [[TCP]] セッション数が一定数を超えるとかで、
相性問題が起こるのかもしれません。
[TIME[2020-03-11T13:29:05.000Z]]

[25] 
TCP [[fingerprinting]]
で [[IPアドレス]]以外の要素も使って規制しているのかも?