Resumo

  • Retry-After informa quando um agente de usuário deve repetir a solicitação, não quando a recuperação está garantida.
  • O valor pode ser uma data HTTP ou um atraso em segundos, portanto relógio e interpretação fazem parte da evidência.
  • Um 503 ou 429 descreve a resposta observada, não a capacidade futura nem todas as dependências.
  • Um registro da decisão de nova tentativa deve unir a instrução a dados recentes do serviço e ao resultado real.

Imagine um controlador que recebe 503 Service Unavailable com Retry-After: 120. Ele segura todas as solicitações, marca de verde o ponto dois minutos à frente e libera toda a fila no mesmo segundo. O incidente é encerrado antes de qualquer nova solicitação ter êxito. Ao fim do prazo, o servidor de origem segue sobrecarregado, uma dependência continua indisponível e a onda sincronizada prolonga a sobrecarga.

O cabeçalho era válido. A conclusão de recuperação foi inventada.

RFC 9110 define Retry-After de forma estreita: indica quanto tempo seria recomendável o agente aguardar antes de uma solicitação subsequente. Com 503, o servidor pode sugerir um momento adequado; em uma resposta de redirecionamento, o campo pode indicar quanto seria prudente esperar antes de seguir o novo endereço. Nenhum uso transforma o horário em previsão de saúde.

O campo aceita uma data HTTP ou um número não negativo de segundos após a recepção. A data depende dos relógios; o atraso depende do instante de chegada e de como intermediários, filas e temporizadores tratam o tempo. Guardar apenas o prazo calculado elimina a instrução original.

A RFC 9110 descreve 503 como incapacidade temporária por sobrecarga ou manutenção. O servidor pode sugerir quando tentar, mas não garante que a restrição acabará naquele instante e tampouco exige que todo servidor sobrecarregado use 503. A recuperação pode ser parcial, regional, dependente do contexto de acesso ou bloqueada em outro componente.

RFC 6585 define 429 Too Many Requests. A resposta pode incluir Retry-After, mas a identificação do usuário e a contagem ficam a cargo do servidor. Token, conta, rota, tenant ou edge podem ter limites diferentes. Um temporizador sem esse escopo não prova admissão futura.

O registro da decisão preserva solicitação, resposta, ponto de observação, código, valor bruto, forma, horário de chegada, instante calculado, fonte do relógio e idade introduzida por intermediários. Associa a instrução ao escopo aplicável sem armazenar segredos.

Depois registra a estratégia de espaçamento entre tentativas, a variação aleatória aplicada ao intervalo, o orçamento de tentativas, o limite de solicitações simultâneas, o cancelamento e o horário real de envio. Antes de liberar a nova tentativa, acrescenta dados atuais sobre o funcionamento do serviço, a capacidade disponível, as dependências e a autorização. Por fim registra a resposta obtida e o resultado da transação. “Espera concluída”, “estado verificado”, “nova tentativa liberada” e “transação concluída” não são o mesmo evento.

Fontes

RFC 9110 — HTTP Semantics; RFC 6585 — Additional HTTP Status Codes.