Come scegliere il limite di richieste dell'API del tuo sito

La domanda è per chi progetta l'API del sito, prima che un client veda un errore: quale finestra, quale quota, e se una richiesta entra nel conteggio. Il 3 novembre 2026 ho letto la pagina già online sul 429, una bozza IETF, la pagina italiana di Stripe, la pagina di GitHub e la scheda OWASP del 2023. Nessuna dà un numero solo, valido per ogni API. Non ho misurato un sito. Non assegno a un sito i numeri di queste pagine.

La pagina già online

La pagina sul 429 ha risposto 200 il 3 novembre 2026 alle 07:54:22 GMT. Non ha un last-modified. Titolo visibile: Errore 429 Too Many Requests: cause e soluzioni. Indirizzo: Errore 429 Too Many Requests: cause e soluzioni. Non la riscrivo.

Nel testo, la parola soglia non c'è. La parola finestra non c'è. Non nomina un controllo di salute, un lavoro interno, né che cosa lasciare fuori dal conteggio. L'unica frase sulla quota è questa: se il servizio è vostro, usate 429 quando un client ha superato la quota e 503 quando il servizio non è in grado di rispondere. Aggiungete Retry-After solo se il tempo è una stima vera. Un'altra frase della stessa pagina dice che molti client ignorano Retry-After. L'header chiede un'attesa. Non la impone. Queste frasi spiegano lo stato e l'attesa. Non scelgono la finestra né la quota di un'API. Non le allungo qui.

La bozza è un lavoro in corso

La pagina HTML della bozza draft-ietf-httpapi-ratelimit-headers-11 ha risposto 200 il 3 novembre 2026 alle 07:54:48 GMT. Non ha un last-modified. L'indirizzo è https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-ratelimit-headers-11. Non è una RFC.

In testa il documento scrive Published 23 May 2026 e Expires 24 November 2026. Lo stato della memoria dice che le bozze Internet sono documenti validi al massimo sei mesi e possono essere aggiornati, sostituiti o resi obsoleti in qualunque momento, e che non è appropriato citarli se non come lavoro in corso. La stessa memoria dice che questa bozza scade il 24 novembre 2026. Il 23 maggio, il massimo di sei mesi, e la data di scadenza del 24 novembre, restano tre scritti. Non li concilio in un solo giorno.

L'intestazione del documento scrive Intended Status: Standards Track. Il riquadro della pagina, alla riga Intended RFC status, scrive (None). Due frasi. Non le unisco. Gli autori in pagina sono R. Polli, A. Martinez e D. Miller. Le affiliazioni scritte sono Team Digitale, Italian Government, Red Hat e Microsoft. Non le uso come misura di un sito.

L'abstract dice che il documento definisce i campi RateLimit-Policy e RateLimit, così i server possono annunciare le politiche di quota e i limiti di servizio correnti, e i client possono evitare di essere limitati. È lo scopo dei campi. Non è un numero per ogni API.

I tre scopi del documento restano distinti. Interoperabilità: standardizzare nomi e semantica delle intestazioni. Resilienza: dare ai client informazioni utili per frenare le richieste ed evitare risposte 4xx o 5xx. Documentazione: semplificare la documentazione dell'API, togliendo il bisogno di ripetere lì i limiti di quota e i campi collegati. Sono scopi dei campi. Non sono la scelta della quota di un sito.

Fuori scopo, quattro frasi separate. Autorizzazione: i campi non servono all'autorizzazione né ad altri controlli di accesso. Codice di stato: la specifica non copre se le risposte non riuscite contano sulla quota, e non impone una correlazione fra i valori RateLimit e lo stato restituito. Algoritmo: non impone un algoritmo, e i valori pubblicati, finestra compresa, possono essere calcolati in modo statico o dinamico. Accordo di servizio: i suggerimenti di quota non implicano una garanzia, e il server è libero di limitare un client che è rimasto dentro i limiti consigliati. Quattro esclusioni. Non le unisco in una regola sola.

L'introduzione fa un esempio, 10 richieste al secondo. Dice che è tipico, con la formula e.g. Non è uno standard. L'appendice ripete un meccanismo di base con lo stesso esempio, 10 richieste al secondo, e poi un esempio diverso: un utente può avere 10 richieste al secondo, limitate a 60 al minuto, limitate a 1000 all'ora. Due esempi. Non li unisco in un solo numero, e non sono il numero di un sito.

Unità, finestra e partizione

La quota, nel glossario della bozza, è un'allocazione di capacità che il server usa per limitare le richieste del client. La capacità si misura in unità di quota che il client può consumare dentro una finestra di tempo. L'unità di quota è l'unità di misura dell'attività del client. La partizione è una divisione della capacità del server fra client, utenti e risorse di cui sono proprietari. La finestra è un periodo associato alla quota allocata. La politica regola l'attività dentro una partizione, in unità di quota, su una finestra, fino a un limite predefinito che la bozza chiama quota. Le politiche possono essere annunciate, ma non è obbligatorio annunciarle, e più di una politica può toccare una stessa richiesta. Sono definizioni. Non sono un numero.

L'unità predefinita è requests, le richieste. Se una richiesta precisa consuma un'unità è una scelta dell'implementazione. La bozza non nomina un controllo di salute, né un lavoro interno, né un visitatore da lasciare fuori. Non invento quell'elenco. Le altre due unità hanno un altro nome: content-bytes, i byte di contenuto, e concurrent-requests, le richieste contemporanee. Tre unità. Non sono la stessa quota.

Il parametro della finestra, chiamato w, deve essere un intero non negativo e diverso da zero, in secondi. La precisione sotto il secondo non è prevista. È il tipo del parametro. Non è l'orologio di un secondo di Stripe, e non è l'ora di GitHub.

La chiave di partizione divide la capacità. Le strategie che la bozza elenca sono per utente, per applicazione, per metodo, per risorsa, o una combinazione. Il server dovrebbe documentare come genera la chiave, così il client può prevederla. Dovrebbe usare solo informazioni presenti nella richiesta. Dovrebbe evitare chiavi che contengono informazioni sensibili. Le quote sono allocate per chiave di partizione. Dico per metodo senza scrivere i nomi dei metodi. La frase non è un elenco di richieste da escludere dal conteggio.

L'appendice scrive tre scopi delle quote, uniti da oppure: evitare il sovraccarico dei sistemi, assicurare una distribuzione equa delle risorse di calcolo, oppure far rispettare altre politiche, e l'esempio è la monetizzazione. Quando la quota è superata, i server di solito non servono la richiesta e rispondono con un 4xx, e gli esempi nominati sono 429 o 403, oppure adottano politiche più aggressive, e la bozza nomina l'interruzione dei collegamenti. Non descrivo quell'interruzione. Il 429 o 403 di questa appendice non è la frase della pagina Roxxo, che distingue il 429 di quota dal 503 di servizio incapace di rispondere. Non le unisco.

Il suggerimento non è una garanzia

La sezione 8.1 dice che la specifica non impedisce ai client di fare richieste. I server dovrebbero sempre avere meccanismi per evitare l'esaurimento delle risorse. È un nome e un impatto. Non descrivo un meccanismo.

La sezione 8.3 dice che i campi portano suggerimenti, per aiutare i client a non essere limitati. Il client non deve trattare la quota disponibile come un accordo di servizio. In caso di saturazione, il server può abbassare i valori restituiti, oppure non servire la richiesta, anche se le quote annunciate direbbero altro. È la stessa famiglia della frase fuori scopo sull'accordo di servizio, scritta in un altro punto. Non le fondo in una sola.

La sezione 6 dice che un servizio che usa questi campi non deve comunicare valori che espongono un volume di richieste indesiderato, e dovrebbe limitare il rapporto fra quota disponibile e finestra effettiva, soprattutto se la finestra è larga. Se nella stessa risposta ci sono Retry-After e RateLimit, Retry-After non dovrebbe indicare un momento precedente alla fine della finestra effettiva. È la bozza. La lettura di Retry-After resta sulla pagina del 429. Non la riscrivo. In certi casi il server può abbassare i valori fra una richiesta e la successiva, per esempio per rispondere a una negazione del servizio o a una saturazione. Non descrivo la procedura.

La sezione 8.5 dice che molti client limitati possono tornare nello stesso momento indicato dalla finestra effettiva. La stessa cosa vale per Retry-After. La bozza nomina un po' di jitter come mitigazione. Non copio un algoritmo. L'esempio della bozza è un azzeramento ogni giorno alle 18:00:00, con un'alta probabilità che tutti i client si presentino a quell'ora. È l'esempio. Non è un orario per un sito.

La stessa sezione dice che una finestra larga permette a un client, per caso o di proposito, di consumare la maggior parte delle unità in un intervallo molto più corto. L'esempio, non una raccomandazione: una politica non consumata di 10000 unità ogni 1000 secondi, con finestra effettiva residua di 10 secondi. Un rapporto semplice legge 1000 unità al secondo, mentre la media della politica è 10 unità al secondo. Se il servizio non regge quel carico, la bozza dice di restituire una quota disponibile più bassa oppure una finestra effettiva più alta. Affiancare una finestra corta a una lunga mitiga il rischio. Non incollo le righe dell'intestazione.

La sezione 8.5.1 dice che un valore può essere inatteso per caso o di proposito. Tre casi, tenuti separati: un intermediario malevolo, un server configurato male, e una finestra effettiva larga che può inibire i client. Non spiego come un intermediario aumenterebbe le richieste. L'esempio del client, introdotto da for example, è mettere un tetto alle richieste al secondo, oppure ritentare quando la finestra effettiva supera i dieci minuti. Dieci minuti è quell'esempio. Non è una regola per ogni API, e non è il tetto di 100 al secondo di Stripe. La bozza dice che la stessa cautela vale per Retry-After. Resto su quella frase, senza riscrivere la pagina del 429.

Stripe ha un altro orologio

La pagina https://docs.stripe.com/rate-limits ha risposto 200 il 3 novembre 2026 alle 07:54:49 GMT, un secondo dopo la bozza. Non ha un last-modified. L'intestazione x-content-age vale 0, e x-content-timestamp è 2026-11-03T07:54:49Z. Non trasformo lo zero in una data di revisione, e non unisco quel secondo alle 07:54:48 della bozza. La pagina arrivata è in italiano. Non ho aperto una seconda lingua.

Stripe scrive di usare i limiti di frequenza per massimizzare la stabilità dell'API ed evitare gli abusi, di trattare i limiti come massimali e di evitare carichi superflui. Superare i limiti restituisce lo stato 429. In generale i limiti si misurano in richieste al secondo per account Stripe. Il limite globale è l'uso totale dell'API per account. Alcuni endpoint hanno limiti aggiuntivi propri. Sono i tetti di Stripe. Non sono lo standard della bozza, e non sono l'esempio dei 10 al secondo.

In generale, scrive la pagina, i limiti di frequenza si azzerano dopo un secondo. Quell'orologio non è la frase della bozza, che ammette qualunque intero di secondi diverso da zero e non ammette frazioni di secondo. Un secondo ci sta nel tipo della bozza. Stripe non dice di implementare la bozza. Non li unisco.

Stripe considera ogni operazione con un nome un endpoint distinto. Creare un intento di pagamento e leggere un intento di pagamento sono endpoint distinti. Le letture di oggetti distinti contano sullo stesso limite di endpoint. Non copio i percorsi.

I numeri, tutti di questa pagina, restano righe separate. Globale, modalità live: 100 richieste al secondo. Sandbox: 25 al secondo. Singoli endpoint, salvo diversa indicazione: 25 al secondo. Aggiornamenti di Payment Intent: 1000 per oggetto all'ora, e la pagina italiana scrive 1.000. Abbonamenti, tre limiti: 10 nuove fatture per abbonamento al minuto, 20 nuove fatture per abbonamento al giorno, 200 aggiornamenti di quantità per abbonamento all'ora. File: 20 letture al secondo e 20 scritture al secondo. Pagamenti in uscita: 15 richieste di creazione al secondo e 30 richieste simultanee per attività. Creazione di account Connect, e la riga include sia Accounts v2 sia Accounts v1: 30 al secondo in live, 5 al secondo in sandbox. Le carte Issuing: i limiti di creazione dipendono dal Paese e dal settore. La pagina non dà un numero. Non ne invento uno.

La riga Search mostra un 1 e poi 20 richieste di lettura al secondo. Non so se l'1 sia una nota. Non dichiaro un numero di Search.

La simultaneità è separata dalla frequenza. A differenza della frequenza, che in generale si azzera dopo un secondo, la simultaneità conta quante richieste sono in corso. Il limite di concorrenza globale predefinito, per il traffico standard in live, è di 50 richieste in corso. I limiti possono differire per endpoint e per account. L'esempio della pagina: gli eventi contatore consentono una chiamata simultanea per cliente per contatore. 50, e una chiamata per cliente per contatore, sono due frasi. Non le unisco.

Un 429 con l'intestazione Stripe-Rate-Limited-Reason è il limite. I valori scritti sono cinque, non uno: global-rate, endpoint-rate, global-concurrency, endpoint-concurrency, resource-specific. Un 429 senza quell'intestazione non è il limite di frequenza. La pagina dice che potrebbe essere un timeout di blocco. Due cause. Non copio l'identificativo del codice. Gli SDK di Stripe ritentano i 429 da timeout di blocco. Non copio l'esempio del linguaggio, né un parametro di quell'esempio.

Sui client legittimi la pagina scrive due frasi. Cerca di impostare limiti abbastanza alti perché il traffico di pagamenti legittimo non li superi mai. Una vendita lampo potrebbe comunque superarli, e in quel caso dice di contattare l'assistenza. Non è una misura di un sito.

Le cause frequenti che nomina restano tre. Molte richieste ravvicinate, e spesso si tratta di un'analisi o di una migrazione. Un aumento improvviso degli addebiti. Molte richieste di lunga durata: elenchi ed espansioni usano di più. L'analisi o la migrazione è la frase più vicina a un lavoro interno. La pagina non scrive job interno. Non le cambio il nome. Per la mitigazione nomina un backoff esponenziale con jitter, il token bucket come tecnica lato client, e l'effetto thundering herd. Non copio un'implementazione né dei parametri.

Un'altra frase sconsiglia i test di carico in sandbox: i limiti più bassi possono far raggiungere soglie che in produzione non si raggiungerebbero, e la sandbox non replica le chiamate reali. Il 25 al secondo della sandbox e il 100 al secondo della live restano due tetti di Stripe. Non li scambio.

GitHub conta all'ora, e poi ha altri orologi

La pagina https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api ha risposto 200 il 3 novembre 2026 alle 07:54:48 GMT, lo stesso secondo della bozza e un secondo prima di Stripe. Age 54. Non ha un last-modified. Non sottraggo 54 secondi per fabbricare una revisione, e non unisco i tre orari. Il riquadro scrive API Version: 2026-03-10 (latest). Non è un last-modified e non è la data della risposta. Non ho aperto la pagina degli endpoint di ricerca, né la pagina del limite primario di GraphQL.

Lo scopo, una frase con due fini: evitare abusi e attacchi di negazione del servizio, e tenere l'API disponibile per tutti. Non descrivo l'attacco. Alcuni endpoint, come quelli di ricerca, hanno limiti più restrittivi. Non ho aperto quella pagina. GraphQL ha un limite primario separato. Non ho aperto nemmeno quella.

Senza autenticazione: 60 richieste all'ora, associate all'indirizzo IP di origine, non all'utente e non all'applicazione. Con un token personale, oppure con un'app GitHub o un'app OAuth che agisce per conto dell'utente: 5000 all'ora. La pagina inglese raggruppa le migliaia con una virgola e scrive 5,000. Il numero è 5000. Un'app GitHub di proprietà di un'organizzazione GitHub Enterprise Cloud: 15000 all'ora. La pagina scrive 15,000. Un'app OAuth di proprietà o approvata da un'organizzazione di quel tipo, se l'utente ne è membro: ancora 15000 all'ora. Sono tetti di GitHub. Non sono i 100 al secondo di Stripe, né i 10 al secondo dell'esempio della bozza.

Le richieste dell'app con il tetto più alto riducono il budget rimasto ai metodi di autenticazione con il tetto più basso. L'esempio della pagina, non una misura di un sito: se l'app da 15000 fa 10000 richieste per conto dell'utente, il budget di 5000 del token personale è esaurito, anche se all'app ne restano 5000. È la conseguenza per un client legittimo che divide un budget. Non è la frase di Stripe sull'analisi o sulla migrazione.

Git LFS è un contenitore a parte: 300 richieste al minuto senza autenticazione, 3000 al minuto con autenticazione. La pagina dice che l'API batch elabora 100 oggetti per richiesta, in modo predefinito, e quindi scrive 30000 oggetti al minuto senza autenticazione e 300000 con autenticazione. È la moltiplicazione della pagina. Non è un consiglio per un sito.

Il token di installazione di un'app GitHub ha un minimo di 5000 all'ora. Se l'installazione è su un'organizzazione GitHub Enterprise Cloud, il tetto è 15000 all'ora. Se non lo è, la pagina aggiunge 50 all'ora per ogni repository oltre 20, e 50 all'ora per ogni utente oltre 20, e il tetto non sale sopra 12500. La pagina scrive 12,500. I token di accesso utente seguono il limite dell'utente autenticato e lo dividono con le altre app e con i token personali. È un'altra frase sulla condivisione. Non è l'esempio dei 10000 e dei 5000, anche se sta vicino.

Le app OAuth che usano l'identificativo e il segreto del client per dati pubblici hanno 5000 all'ora per app, oppure 15000 se l'app è di un'organizzazione GitHub Enterprise Cloud. Non copio l'esempio di chiamata, né l'avviso sul segreto. Il token delle Actions, scritto GITHUB_TOKEN, ha 1000 all'ora per repository, oppure 15000 all'ora per repository se le risorse appartengono a un account GitHub Enterprise Cloud. La pagina scrive 1,000.

I limiti secondari si aggiungono ai primari, con lo stesso scopo: evitare abusi e tenere l'API disponibile. Non sono lo stesso orologio. Il primario di cui sopra è all'ora. Il secondario che segue è al minuto, e la concorrenza è un terzo limite. Non più di 100 richieste contemporanee, condivise da REST e GraphQL. Non più di 900 punti al minuto per gli endpoint REST, e non più di 2000 punti al minuto per l'endpoint GraphQL. Sul tempo di calcolo: non più di 90 secondi di CPU ogni 60 secondi di tempo reale, di cui non più di 60 per GraphQL. Due frasi senza un numero in più: troppe richieste che consumano calcolo in eccesso, e creare troppo contenuto. Sul contenuto, a parte: in generale non più di 80 richieste che generano contenuto al minuto e 500 all'ora. Alcuni endpoint stanno più in basso. Conta anche l'interfaccia web, oltre a REST e GraphQL. Sulle richieste di token OAuth: non più di 2000 all'ora per le app GitHub e le app OAuth. La pagina dice che i limiti secondari possono cambiare senza preavviso, e che si può incontrare un limite secondario per ragioni non disclose. Non presento questi numeri come eterni.

La tabella dei punti, per il limite secondario, assegna 1 alle richieste GraphQL senza mutazioni e 5 a quelle con mutazioni. Per la maggior parte delle letture REST assegna 1, e per la maggior parte delle richieste REST che modificano assegna 5. Alcuni endpoint REST hanno un costo diverso, non pubblicato. La pagina scrive most, la maggior parte. Non è tutti. Non elenco i nomi dei metodi. I punti GraphQL di questa tabella sono separati dal calcolo dei punti del limite primario di GraphQL. Quel limite primario non l'ho aperto.

OWASP elenca il limite fra altri limiti

La scheda API4:2023 Unrestricted Resource Consumption ha risposto 200 il 3 novembre 2026 alle 07:57:22 GMT, dopo tre reindirizzamenti alle 07:57:21 GMT: 308 verso il percorso senza sbarra finale, 308 verso l'host api-security.owasp.org, 301 di nuovo con la sbarra finale. Last-modified: 22 settembre 2026 alle 14:25:40 GMT. Non unisco il 22 settembre con le 07:57 del 3 novembre. Un primo corpo di 15 byte, fermo sul 308, non è la scheda. Non l'ho letto come testo. Indirizzo finale: https://api-security.owasp.org/editions/2023/en/0xa4-unrestricted-resource-consumption/.

In cima la pagina nomina due impatti: esaurimento delle risorse, e un costo operativo più alto, con gli esempi di CPU e di spazio su cloud. È il nome dell'impatto. Non copio il paragrafo sui vettori, né uno scenario, né un prezzo, né un numero di telefono.

L'API è vulnerabile se manca almeno uno dei limiti elencati, oppure se è impostato in modo inappropriato. L'esempio di inappropriato è una sola parentesi, too low/high, troppo basso o troppo alto. Non ne faccio due raccomandazioni. L'elenco, oltre al limite di frequenza, nomina i timeout di esecuzione, la memoria allocabile, i descrittori di file, i processi, la dimensione di un file caricato, il numero di operazioni in una sola richiesta del client, e la pagina fa l'esempio del raggruppamento GraphQL, il numero di record per pagina, e il tetto di spesa dei fornitori terzi. Il limite di frequenza è una voce. Non è tutta la lista.

Nella prevenzione, le frasi che uso sono queste. Mettere un limite a quanto spesso un client può interagire con l'API dentro un intervallo definito, e la pagina lo chiama rate limiting. Il limite va regolato sulle esigenze del lavoro. Alcuni endpoint possono richiedere politiche più strette. Limitare quanto spesso un solo client, o un solo utente, esegue una sola operazione. Non copio l'esempio di quell'operazione. A parte, e non sono un numero di richieste per finestra: una dimensione massima dei dati, e tetti di spesa, oppure avvisi di fattura quando il tetto di spesa non si può impostare. La pagina nomina anche memoria, CPU, numero di riavvii, descrittori di file e processi, con l'esempio dei container o del codice serverless. È l'esempio della pagina. Non è una quota di richieste.

La navigazione della stessa risposta elenca il nome del 2019, API4:2019 Lack of Resources & Rate Limiting. Il titolo del 2023 è Unrestricted Resource Consumption. La pagina del 2019 non l'ho aperta. Due nomi. Non li unisco.

Tre conseguenze, non una regola

Sui client legittimi le pagine non dicono la stessa cosa. La bozza dice che un suggerimento non è una garanzia, e che un client rimasto dentro il limite pubblicato può comunque essere limitato. Stripe dice di cercare tetti alti abbastanza per il proprio traffico di pagamenti legittimo, e che una vendita lampo può comunque superarli. OWASP, nella parentesi too low/high, è l'unica frase per cui un limite messo male può essere troppo basso oppure troppo alto. Non le chiudo in una regola sola.

Sui lavori interni, nessuna delle quattro pagine scrive job interno. Stripe nomina un'analisi o una migrazione come causa frequente del proprio limite. GitHub dice che un'app con il tetto più alto può esaurire il budget personale di 5000. Due frasi. Non le unisco, e non le rinomino.

Sui controlli di salute, nessuna delle quattro pagine ne nomina uno. Non aggiungo un'esclusione. L'unica frase disponibile è della bozza: se una richiesta precisa consuma un'unità è una scelta dell'implementazione, e le risposte non riuscite non sono coperte dalla specifica. Un'altra frase, nella sezione 8.2, non decide se le risposte non riuscite consumano quota: se le risposte di errore contano, e la bozza fa gli esempi 401 e 403, un client malevolo potrebbe ricavare informazioni sul traffico di un altro utente. È il condizionale della bozza. Non descrivo il modo, e non ne ricavo un elenco di richieste da escludere.

Esempio ipotetico

bottega.example è un nome di scuola. Non l'ho aperto. Non so quale finestra usi, né quale quota, né se una richiesta del visitatore consumi un'unità. prova.bottega.example è l'altro nome. Non l'ho aperto. Non gli assegno 100 al secondo, né 5000 all'ora, né 10 al secondo.

Se il visitatore, una migrazione e un controllo condividessero una finestra, la bozza non dice quale di queste richieste consuma un'unità. Il tetto live di Stripe e il budget orario di GitHub restano i numeri di quei servizi. Il 25 al secondo della sandbox di Stripe resta di Stripe. Non li assegno a questi nomi, e non dico che un controllo di salute vada lasciato fuori. Nessuna pagina letta lo scrive.

Che cosa questa pagina lascia stare

Non ho misurato un'API. Non ho aperto la pagina del limite primario di GraphQL, né la pagina degli endpoint di ricerca di GitHub, né la scheda OWASP del 2019. Non ho copiato la sintassi dei campi, né uno scenario, né un percorso. La copertina è nuova, perché la pagina è nuova. Nessuna delle pagine lette dà una soglia unica per ogni API. Non la invento.

Non ho riscritto la pagina sul 429. Non ho rifatto la pagina sugli indici, la pagina sulla mappa del codice, la pagina sul file caricato, la pagina sulla rotazione della chiave, la pagina sul timer, la pagina sul disco, la pagina sul primo byte, la pagina sugli spostamenti, la pagina sulle misure, la pagina su Server-Timing, la mappa di DNS, hosting e CDN, la pagina sulla connessione lunga, la pagina sul lavoro lungo, la pagina sulla copia di prova, la pagina sulla chiave, la pagina sulla compressione, la pagina sulla cartella e la pagina sul lucchetto.

Fonti lette il 3 novembre 2026, non unite. Pagina sul 429, risposta delle 07:54:22 GMT, senza last-modified, https://www.roxxoitalia.com/blog/operativita/http-429-retry-after. Bozza IETF, risposta delle 07:54:48 GMT, senza last-modified, pubblicata il 23 maggio 2026, scadenza scritta 24 novembre 2026, stato previsto Standards Track e, nel riquadro, (None), https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-ratelimit-headers-11. Stripe, risposta delle 07:54:49 GMT, senza last-modified, x-content-age 0, pagina italiana, https://docs.stripe.com/rate-limits. GitHub, risposta delle 07:54:48 GMT, Age 54, senza last-modified, versione d'API in riquadro 2026-03-10, https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api. OWASP API4:2023, reindirizzamenti alle 07:57:21 GMT, risposta 200 alle 07:57:22 GMT, last-modified 22 settembre 2026 alle 14:25:40 GMT, https://api-security.owasp.org/editions/2023/en/0xa4-unrestricted-resource-consumption/.