Individuare il limite raggiunto
HTTP 429 segnala troppe richieste e può includere Retry-After. Conteggio e ambito dipendono dal servizio. Una media bassa non impedisce il superamento di un limite breve.
| Concetto | Cosa limita | Azione utile |
|---|---|---|
| Quota | Volume nel periodo | Pianificare il budget condiviso. |
| Frequenza | Arrivi in una finestra breve | Distribuire gli avvii. |
| Concorrenza | Operazioni in corso | Limitare il lavoro simultaneo. |
| Retry-After: 120 | Attesa di 120 secondi | Verificare scadenza e sicurezza della ripetizione. |
Organizzare la domanda consentita
- Verificare la chiave di conteggio: account, progetto, utente o rotta. Controllare fuso del ripristino, costo delle operazioni e budget condiviso.
- Smussare i picchi con una coda limitata e limitare separatamente le operazioni in corso. Propagare annullamenti e scartare attività ormai inutili.
- Interpretare Retry-After come data HTTP o attesa in secondi. Rispettarlo entro il tempo complessivo e definire un’attesa limitata se assente.
Valutare senza aggirare la protezione
Un 429 non prova che ripetere sia sicuro. Controllare idempotenza, durata e tentativi. Misurare rifiuti e coda; se la domanda stabile supera il contratto, ridurre il fabbisogno o concordare capacità adeguata.
Fonti primarie
Rendere rilevabile l'abuso dei limiti di frequenza.
I limiti di richiesta funzionano meglio quando distinguono l'uso legittimo dal comportamento anomalo e producono un evento interpretabile. I soli codici di errore possono nascondere l'inizio, la durata e la portata di un modello di abuso.
- Registrare soglia, decisione, percorso e contesto minimo senza segreti.
- Correlare i rifiuti ripetuti con gli effetti sugli utenti legittimi.
- Verificare che gli avvisi portino a indagini o a una regolazione proporzionata.
Fonte primaria: ACSC and partners — Event logging and threat detection. Metodo correlato: consultare la guida pratica.