Analisi degli header di limite e calcolo del ripristino
Un limite di 100 con 42 richieste rimaste e un ripristino di 60 alle 12:00 UTC significa che si può riprendere alle 12:01, tra 60 secondi. Incolli i tre valori e l’ora di ricezione per pianificare un nuovo tentativo sicuro. Gratis nel suo browser.
- Gratis
- Funziona nel suo browser
- Senza registrazione
- I suoi dati restano sul dispositivo
Esegui gratis nel browser
Esempio risolto
- Limite
- 100
- Rimanente
- 42
- Reimpostazione
- 60
- Ora attuale
- 2026-07-25T12:00:00Z
- Limite
- 100
- Rimanente
- 42
- Tipo di reimpostazione
- seconds_offset
- Reimpostazione in tempo Unix
- 1.784.980.860
Gli header di limite sembrano semplici finché servizi diversi non esprimono il ripristino in modi differenti. Questo analizzatore riceve limite, quota residua, valore di ripristino e ora corrente esplicita, quindi restituisce numeri normalizzati e i secondi interi prima che le richieste tornino disponibili. Riconosce timestamp Unix in secondi o millisecondi, date UTC ISO 8601 rigorose e brevi differimenti numerici. Poiché è Lei a fornire l’ora corrente, lo stesso input produce sempre lo stesso risultato.
Come viene letto il valore di ripristino
Gli header di limite riportano di solito tre numeri: il massimo consentito, quante richieste restano e quando la quota torna disponibile. Ogni servizio però scrive quest’ultimo valore a modo suo. I numeri piccoli, come 30 o 900, vengono trattati come secondi da aggiungere all’ora indicata. Da un miliardo in su il valore è letto come secondi Unix; da cento miliardi in su come millisecondi Unix, convertiti in secondi. È accettata anche una data e ora UTC che termina con Z. Con limite 100, 42 richieste rimaste e ripristino 60 alle 12:00 UTC, la quota torna alle 12:01, tra 60 secondi.
Errori comuni e come usare il risultato
L’errore più costoso è trattare un valore illeggibile come zero: il programma riprova subito, aggrava il blocco e prolunga il disservizio. Qui un valore che non si può leggere produce un errore chiaro. Vengono respinti anche numeri negativi, date impossibili e un numero di richieste rimaste superiore al limite. L’attesa è arrotondata per eccesso al secondo intero, così non si riprova nell’ultima frazione di secondo, e un ripristino già passato dà zero. Poi spetta al suo programma decidere se attendere, mettere il lavoro in coda, ridurre la concorrenza o mostrare un avviso.
Distingua timestamp e differimenti
I valori numerici di reset seguono convenzioni comuni. Da un miliardo in su sono secondi Unix; da cento miliardi sono millisecondi Unix convertiti in secondi. Pertanto 30 o 900 sono attese, mentre i timestamp moderni restano assoluti. reset accetta anche una data UTC ISO 8601 rigorosa come 2026-07-25T12:01:00Z, con millisecondi facoltativi.
La convalida rileva date impossibili, ore errate, valori assenti, numeri negativi e testo estraneo. Un reset illeggibile genera un errore di input anziché diventare silenziosamente zero, perché un tentativo immediato accidentale può aggravare la limitazione e prolungare un disservizio.
Casi d'uso
Pianificare un nuovo tentativo sicuro
Converta le stringhe degli header in un ritardo intero prima di rimettere il lavoro in coda.
Diagnosticare i limiti del fornitore
Normalizzi gli header acquisiti e confronti il ripristino con l’istante esatto della risposta.
Creare test deterministici
Fornisca un’ora fissa e verifichi calcoli stabili senza simulare l’orologio di sistema.
Domande frequenti
Quali formati di ripristino sono accettati?
Usi differimenti non negativi in secondi, timestamp Unix in secondi o millisecondi oppure date UTC ISO 8601 rigorose che terminano in Z.
Lo strumento esegue una richiesta o attende?
No. Convalida e normalizza soltanto i valori; l’applicazione resta responsabile dei tentativi e del backoff.
Che cosa succede se il momento del ripristino è già passato?
L’attesa è zero, mai negativa. È utile quando si rileggono registri archiviati o notifiche arrivate in ritardo, perché il risultato indica che si può già riprovare senza inventare un tempo di attesa.
Perché devo indicare l’ora attuale?
Così nessun orologio di sistema cambia la risposta: gli stessi dati danno sempre lo stesso risultato. Indichi l’istante in cui ha ricevuto la risposta, in secondi o millisecondi Unix o come data UTC; non viene mai trattato come uno scarto.
E se le richieste rimaste superano il limite?
L’inserimento viene respinto. Limite e richieste rimaste devono essere numeri interi non negativi, e le rimaste non possono superare il limite. Anche un ripristino illeggibile dà errore invece di zero, per evitare nuovi tentativi immediati.
Strumenti correlati
Per sviluppatori — accesso via API
Tutto quello che vedi in questa pagina è disponibile anche via API. Questa sezione è per i team che vogliono integrarlo nei propri sistemi; chi non ne ha bisogno può semplicemente usare lo strumento qui sopra.
Endpoint
Autenticazione con Bearer token: un POST mette in coda l'attività e il risultato arriva via webhook o link firmato.
Chiamala dal tuo stack
curl -X POST https://api.kit.forhosting.com/security/rate-limit-header-parse \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"limit":"100","remaining":"42","reset":"60","current_time":"2026-07-25T12:00:00Z"}'const res = await fetch("https://api.kit.forhosting.com/security/rate-limit-header-parse", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"limit": "100",
"remaining": "42",
"reset": "60",
"current_time": "2026-07-25T12:00:00Z"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/security/rate-limit-header-parse",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"limit": "100",
"remaining": "42",
"reset": "60",
"current_time": "2026-07-25T12:00:00Z"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/security/rate-limit-header-parse", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"limit":"100","remaining":"42","reset":"60","current_time":"2026-07-25T12:00:00Z"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"limit":"100","remaining":"42","reset":"60","current_time":"2026-07-25T12:00:00Z"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/security/rate-limit-header-parse", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Esempio di richiesta
{
"limit": "100",
"remaining": "42",
"reset": "60",
"current_time": "2026-07-25T12:00:00Z"
}Esempio di risposta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "security.rate_limit_header_parse",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L'API è asincrona: ricevi subito un task_id e puoi fare polling fino a 1 richiesta al secondo.
Prezzi
Prezzo pubblicato, senza token né crediti. Se l'attività fallisce, non paghi.
Errori
| HTTP | Codice | Significato |
|---|---|---|
401 | unauthorized | Chiave API mancante o non valida: controlla l'header Authorization. |
402 | insufficient_balance | Credito esaurito: ricarica per continuare a eseguire attività. |
404 | unknown_type | Tipo di attività sconosciuto: controlla il campo type della richiesta. |
429 | rate_limited | Troppe richieste in poco tempo: rallenta e riprova tra qualche secondo. |
Note tecniche
Normalizzi gli header prima di pianificare nuovi tentativi
Se il ripristino è già passato, il risultato è zero e mai negativo. L’output è adatto a log, middleware, ritardi di coda e test senza replicare le stesse regole in ogni integrazione. Le API comunicano spesso un numero massimo di richieste, una quota residua e un valore di ripristino, ma il client deve ancora trasformare queste stringhe in una decisione sicura. Invii i valori come limit, remaining e reset e specifichi in current_time l’istante di ricezione. L’analizzatore verifica che limit e remaining siano interi non negativi e rifiuta una quota residua superiore al limite. Conserva il testo reset, indica se è stato letto come timestamp assoluto o differimento in secondi e produce un’ora Unix normalizzata. seconds_until_reset viene arrotondato verso l’alto, impedendo un nuovo tentativo nell’ultima frazione dell’attesa.
Distingua timestamp e differimenti
I numeri più piccoli non negativi vengono aggiunti a current_time. Il suffisso UTC evita ipotesi sul fuso orario. current_time accetta gli stessi formati assoluti, ma non è mai un differimento.
Usi risultati deterministici nei client e nei test
Una politica di ripetizione deve separare l’analisi dalla decisione. Un differimento di 60 a mezzogiorno genera sempre un timestamp un minuto dopo e sessanta secondi residui. Lo strumento non deduce header specifici né sceglie il backoff esponenziale; tratta i valori già estratti. Usi questa capacità per stabilire i dati della quota, poi lasci all’applicazione la scelta di attendere, accodare, ridurre la concorrenza o mostrare un messaggio. current_time è esplicito: orologio di sistema, rete, impostazioni locali e casualità non possono cambiare la risposta. Il calcolo nel browser coincide così con quello dell’API e i test restano stabili nel tempo. I ripristini precedenti producono zero, utile per webhook in ritardo o log archiviati. Il browser è gratuito, mentre le chiamate automatizzate applicano il prezzo base mostrato di $0.002 per elemento.
Domande tecniche
Quanto costa una chiamata API?
Ogni elemento usa il prezzo base indicato di $0.002; lo strumento nel browser esegue localmente lo stesso calcolo.
Perché devo fornire current_time?
Un’ora esplicita mantiene deterministico il calcolo e rende i risultati riproducibili nei client e nei test.
Cosa accade se il ripristino è già passato?
seconds_until_reset viene limitato a zero, mentre reset_at_unix conserva l’istante assoluto analizzato.