De Retry-After header: hoe lang moet worden gewacht voordat u het opnieuw probeert

Retry-After is een HTTP-antwoordheader die aangeeft hoe lang uw app moet wachten voordat uw app de volgende aanvraag verzendt. De waarde is een aantal seconden of een HTTP-datum. Wanneer een API deze verzendt, is het het meest betrouwbare antwoord op 'wanneer kan ik het opnieuw proberen?', omdat deze afkomstig is van de server die uw aanvraag heeft afgewezen. Zie RFC 9110, sectie 10.2.3 voor meer informatie.

Hoe ziet Retry-After eruit

De header heeft twee indelingen. Uw app moet beide afhandelen.

Format Example Wat betekent het?
Seconds Retry-After: 120 Wacht 120 seconden (2 minuten) vanaf het moment dat u het antwoord hebt ontvangen. De waarde is een niet-negatief geheel getal.
HTTP-datum Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Verzend de aanvraag niet opnieuw vóór dit tijdstip. De datum is altijd in GMT.

Servers verzenden Retry-After met deze statuscodes:

Status Wat Retry-After betekent bron
429 Too Many Requests Hoe lang moet u wachten voordat u een nieuwe aanvraag verzendt. De server kan deze bevatten. RFC 6585, sectie 4
503 Service Unavailable Hoe lang de service naar verwachting niet beschikbaar is. De server kan deze bevatten. RFC 9110, sectie 15.6.4
413 Content Too Large Als de voorwaarde tijdelijk is, moet de server aangeven na hoeveel tijd deze voorbij is. RFC 9110, sectie 15.5.14
Willekeurige 3xx omleiding De minimale tijd om te wachten voordat u de omleiding volgt. RFC 9110, sectie 10.2.3

De header is optioneel. Sommige API's gebruiken in plaats daarvan hun eigen headers. GitHub geeft bijvoorbeeld met x-ratelimit-reset aan wanneer uw limiet opnieuw wordt ingesteld. Zie GitHub API-frequentielimiet overschreden voor meer informatie.

Retry-After afhandelen

  1. Lees beide formaten. Als de waarde een getal is, zijn dit seconden. Anders interpreteert u het als een datum en trekt u de huidige tijd ervan af. Als de datum zich al in het verleden bevindt, kunt u het meteen opnieuw proberen.
  2. Wacht minstens zolang de koptekst zegt. Als u het eerder opnieuw probeert, krijgt u meestal een andere 429 of 503. Sommige API's blijven uw aanvragen tellen terwijl ze u beperken, zodat vroege nieuwe pogingen de wachttijd langer kunnen maken. Zie bijvoorbeeld Microsoft Graph-richtlijnen voor throttling.
  3. Terugvallen op backoff met jitter wanneer de header ontbreekt. Verdubbel de wachttijd na elke mislukte poging, voeg een willekeurige hoeveelheid toe, zodat veel clients het niet opnieuw op hetzelfde moment proberen en stel een maximum in voor de wachttijd.
  4. Beperk het aantal pogingen. Retourneer na enkele pogingen de fout aan de aanroeper.
  5. Controleer of een nieuwe poging kan helpen. Sommige API's retourneren 429 wanneer uw tegoeden of bestedingslimiet op zijn. Wachten lost deze niet op. Zie OpenAI insufficient_quota en credit_balance_exhausted voor een voorbeeld.
function retryDelayMs(response, attempt) {
  const value = response.headers.get('retry-after');
  if (value) {
    const seconds = Number(value);
    const ms = Number.isNaN(seconds) ? Date.parse(value) - Date.now() : seconds * 1000;
    if (!Number.isNaN(ms)) {
      return Math.max(ms, 0);
    }
  }
  // No usable header: exponential backoff with jitter, capped at 30 seconds
  return Math.random() * Math.min(30_000, 1_000 * 2 ** attempt);
}

Veel SDK's verwerken Retry-After voor u, maar alleen totdat hun retries op zijn. Vervolgens geeft uw code een fout.

SDK Wat het standaard doet
.NET standaardhandler voor veerkracht Probeert 408, 429 en 5xx reacties maximaal 3 keer opnieuw, met exponentieel toenemende wachttijd en jitter. Het gebruikt Retry-After voor de vertraging, omdat ShouldRetryAfterHeader standaard is ingesteld op true.
Microsoft Graph SDKs Gebruik Retry-After als die aanwezig is, en val terug op exponential backoff als die er niet is. Aanvragen in een JSON-batch worden niet automatisch opnieuw geprobeerd.
OpenAI Python SDK Probeert 2 keer opnieuw bij verbindingsfouten en 408, 409, 429 en 5xx-antwoorden met een korte exponentiële uitstel. Stel max_retries in om dit te wijzigen.

Controleer de documentatie van uw SDK voor het exacte beleid en test wat er gebeurt nadat de laatste herhalingspoging is mislukt.

Zo test u of uw app met Retry-After omgaat

U krijgt zelden een Retry-After tijdens het ontwikkelen en wanneer u dat doet, kunt u de waarde ervan niet beheren. De manier waarop u dit test, bepaalt dus of u de bugs vindt voordat uw gebruikers dat doen.

Approach Wat u vindt Wat u mist
Wacht op productie Echte storingen Alles, tot een gebruiker erop klikt
Mock de API in je tests, of laat je codeeragent de mock schrijven Of uw code de header kan parseren Of uw echte HTTP-client of SDK lang genoeg wacht en wat de API echt verzendt. Uw app heeft ook een schakelaar alleen voor testdoeleinden nodig om de mock te bereiken.
De echte API aanroepen totdat deze u rate-limiet oplegt Werkelijk gedrag U kunt niet naar wens een reactie met snelheidsbeperking activeren, en u verbruikt uw echte quotum
Het echte verkeer van uw app onderscheppen en vertraagde reacties op aanvraag retourneren Of uw echte SDK en retrybeleid net zo lang wachten als de header aangeeft Er verandert niets in uw app, dus uw code wordt niet geïsoleerd getest. Gebruik daar unittests voor.

Probeer het uit in je app

Dev Proxy onderschept de aanvragen van uw app naar de API's die u kiest en retourneert 429 antwoorden met een Retry-After header, terwijl uw app de echte URL's blijft aanroepen. De RetryAfterPlugin onthoudt wanneer elk beperkt verzoek opnieuw kan worden geprobeerd. Als uw app vóór die tijd dezelfde URL aanroept, rapporteert Dev Proxy deze en beperkt Dev Proxy de aanvraag opnieuw. De invoegtoepassing houdt alleen 429-antwoorden bij.

Stel in het foutenbestand voor GenericRandomErrorPlugin de Retry-After waarde in van een 429 reactie op @dynamic, en Dev Proxy vult het aantal seconden in en houdt het voor u bij.

Als u het wilt proberen, downloadt u een voorinstelling die beide invoegtoepassingen gebruikt en start u de Dev Proxy ermee:

devproxy config get openai-throttling
devproxy --config-file "~dataFolder/configs/openai-throttling/.devproxy/devproxyrc.json"

Voer vervolgens uw app zoals gebruikelijk uit en bekijk wat deze doet. Zie Dev Proxy instellen om Dev Proxy te installeren.

Volgende stappen 

Testen of mijn toepassing bandbreedtebeperking goed verwerkt

Zie ook

  • Laatst bijgewerkt om