Rate-Limits
Rate-Limit-Presets pro Formular mit den genauen Zahlen, wie sie sich auffüllen und wie ein 429 aussieht.
Rate-Limits verhindern, dass ein Besucher oder ein Skript ein Formular flutet. Jedes Formular hat ein Preset, und jedes Limit wird exakt gezählt, bevor der Body gelesen wird. Ein abgelehnter Post verbraucht kein Kontingent.
Presets
| Preset | Pro Besucher und Formular | Geeignet für |
|---|---|---|
| Standard (voreingestellt) | 5 pro Minute, höchstens 3 in 10 Sekunden | Die meisten Formulare |
| Relaxed | 20 pro Minute | Formulare hinter einem Login, interne Tools, Events in geteiltem WLAN |
| Strict | 2 alle 10 Minuten | Kontakt- und Vertriebsformulare, bei denen eine Wiederholung ein Doppelklick oder ein Bot ist |
| Custom | 1 bis 1.000 alle 10 Sekunden, pro Minute, alle 10 Minuten, pro Stunde oder pro Tag | Ein Eintrag pro Person, Kiosks und andere Sonderfälle |
Die Presets im Vergleich
Standard 5 pro Minute, 3 in 10 Sekunden14 von 120 akzeptiert
Locker 20 pro Minute59 von 120 akzeptiert
Streng 2 alle 10 Minuten2 von 120 akzeptiert
Wie sich Limits auffüllen
Limits sind ein gleichmäßiges Kontingent, kein festes Zeitfenster. Ein ruhiger Besucher startet mit dem vollen Kontingent und kann es sofort nutzen. Danach ist alle Fenster geteilt durch Limit ein weiterer Post erlaubt: alle 12 Sekunden bei Standard, alle 3 Sekunden bei Relaxed und alle 5 Minuten bei Strict. Nach einem vollen ruhigen Fenster ist das Kontingent wieder voll.
Standard hat außerdem eine Burst-Regel von 3 Posts pro 10 Sekunden, daher ist der erste Burst 3, nicht 5. Relaxed, Strict und Custom haben keine separate Burst-Regel.
Limits, die immer gelten
| Regel | Limit | Gezählt pro |
|---|---|---|
| Flood-Schutz, bevor das Formular nachgeschlagen wird | 600 pro Minute | IP, über alle Formulare |
| Formularübergreifend | 30 pro Minute, oder die Custom-Rate pro Minute, wenn sie höher ist | IP, über alle Formulare |
| Formularweit | 300 pro Minute, oder ein Custom-Höchstwert von 1 bis 10.000 | Formular, über alle Besucher |
GET /f/<formId>/schema | 60 pro Minute | IP und Formular |
| Der Prüf-Frame von Ikiform | 60 pro Minute | IP und Formular |
| REST API | 100 pro Minute | API-Schlüssel |
Custom-Raten, die schneller als der Flood-Schutz sind, werden beim Speichern abgelehnt; ein 10-Sekunden-Fenster erlaubt zum Beispiel höchstens 100. Das Laden des Schemas eines Formulars oder der Menschlichkeitsprüfung verbraucht nie das Kontingent zum Absenden.
Custom
- Einsendungen pro Besucher: eine ganze Zahl von 1 bis 1.000 und ein Fenster von 10 Sekunden, einer Minute, 10 Minuten, einer Stunde oder einem Tag.
- Formularweiter Höchstwert pro Minute: optional, von 1 bis 10.000. Er ersetzt den Standardwert von 300 pro Minute für das ganze Formular.
- Ein Fenster von einer Stunde oder einem Tag passt zu Formularen mit einem Eintrag pro Person, etwa Gewinnspielen oder Zusagen zu Einladungen. Denk daran, dass sich viele Menschen eine IP teilen können, zum Beispiel im Büro oder auf einem Event.
Wenn ein Limit erreicht ist
Der Post wird mit 429 rate_limited und einem Retry-After-Header abgelehnt, der die ganzen Sekunden bis zum nächsten erlaubten Post angibt. Browser-Formular-Posts sehen eine gehostete Seite „Langsamer“. fetch-Code kann Retry-After lesen, weil Ikiform ihn über CORS freigibt.
HTTP/1.1 429 Too Many Requests
Retry-After: 12
X-Request-Id: req_01k7v2c9t3e8m5q4x6z0a1b2c3
Content-Type: application/json; charset=utf-8
{"ok":false,"error":{"code":"rate_limited","message":"Too many requests. Please slow down."},"request_id":"req_01k7v2c9t3e8m5q4x6z0a1b2c3"}- Warte
Retry-AfterSekunden, bevor du erneut sendest. - Wenn ehrliche Besucher an das Limit stoßen, stelle das Formular auf Relaxed oder Custom um.
- Wenn dein Server für Besucher sendet, teilen sich alle Posts die IP deines Servers. Siehe Von einem Server.