Resumo

  • O 429 informa que o fluxo atribuído a um sujeito pelo servidor ultrapassou um orçamento local. Ele não declara que a mensagem está malformada, nem prova que uma pessoa cometeu abuso.
  • Retry-After pode orientar uma nova tentativa, mas não reserva lugar nem capacidade. O pedido futuro continuará sujeito à carga, à autorização, à política e ao estado então vigentes.
  • A norma compartilha o veredito e deixa a contabilidade com quem opera o serviço. Essa liberdade exige verificar identidade, escopo, consistência e dano colateral — e admite silêncio quando responder a cada excesso custaria demais.

Uma requisição válida depois da linha

Um serviço aceita cinquenta chamadas por hora de cada conta autenticada. A chamada seguinte tem a mesma estrutura, chega ao mesmo recurso e carrega credenciais igualmente válidas. Se for recusada, seus bytes não precisam conter defeito algum. O fato novo está fora dela: o servidor associou a chamada a uma história e essa história alcançou um limite.

Foi para dar nome comum a essa condição que o RFC 6585 definiu 429 Too Many Requests, em 2012. Um erro genérico de cliente poderia sugerir que o corpo precisava ser corrigido. Um 503 poderia sugerir incapacidade geral do serviço mesmo enquanto outros clientes continuavam sendo atendidos. O 429 separou a frequência atribuída do significado individual da operação.

O RFC recomenda que a resposta explique a condição e permite incluir Retry-After. Em seguida, recusa-se a definir como o servidor de origem identifica o usuário ou contabiliza as requisições. O HTTP padronizou a frase pública, não o método privado que chegou a ela.

O sujeito da cota é uma escolha

Antes de negar, o sistema precisa decidir quais mensagens pertencem ao mesmo conjunto. Pode usar conta, chave de API, cookie, locatário, endereço de origem ou uma composição desses sinais. Credenciais e cookie aparecem no RFC como exemplos, não como provas de uma pessoa única.

Contar por endereço IP é barato e pode ocorrer no primeiro ponto da rede. Também reúne desconhecidos. CGNAT, uma saída corporativa ou um serviço de privacidade podem mostrar um endereço para muitas pessoas. Uma rajada de um participante consome a margem de todos. O 429 resultante pode estar correto para o contador de endereço e, ao mesmo tempo, estar errado como descrição de consumo individual.

Uma conta autenticada se aproxima mais de um contrato, mas pode abrigar vários dispositivos, processos ou integrantes de uma equipe. Uma chave pode circular ou ser roubada. Um cookie conserva a continuidade de uma sessão, não a identidade civil. Cada sinal sustenta uma autoridade limitada.

O servidor pode dizer “este agrupamento atingiu a cota”. Não pode usar o status para afirmar que uma pessoa identificada abusou do serviço sem evidência adicional.

A mesma resposta cobre escopos diferentes

O RFC 6585 permite contar por recurso, por servidor inteiro ou por um conjunto de servidores. Proteger separadamente uma busca cara mantém outras funções acessíveis. Uma cota global protege capacidade comum, mas talvez trate uma leitura leve e uma análise custosa como uma unidade idêntica.

Uma cota por locatário pode refletir a alocação comercial, desde que cada chamada seja atribuída corretamente. Uma cota entre regiões preserva um saldo único e introduz decisões sobre atraso de replicação, partição e falha do armazenamento de contadores.

Até o evento contado requer escolha. A unidade nasce na chegada, depois da autenticação, na admissão ou na conclusão? Um redirecionamento custa outra unidade? Um fluxo HTTP/2 cancelado permanece no saldo? Se um proxy repete internamente, o cliente deve pagar duas vezes? O código não responde porque a contabilidade pertence ao sistema que executa o trabalho.

É possível emitir um 429 perfeitamente bem formado a partir de um contador inexato. Conformidade de protocolo não certifica a conta.

Retry-After informa tempo, não concede vaga

Pelo RFC 9110, o campo aceita uma data HTTP ou um número não negativo de segundos. O RFC 6585 permite usá-lo com 429. Em ambos os formatos, o agente recebe um limite inferior prático para voltar, não uma promessa de atendimento.

Uma data absoluta depende de referência de tempo adequada; segundos são contados a partir do recebimento. Nenhuma forma impede que milhares de clientes acordem juntos. No instante sugerido, a demanda pode continuar alta, a política pode ter mudado, a credencial pode ter perdido validade e o recurso pode estar diferente.

Por isso a retomada precisa de critério local: tentativas limitadas, horários dispersos, prazo de utilidade e cuidado com efeitos. Uma operação não idempotente não se torna segura quando o relógio termina. Se houve falha de transporte, o temporizador não prova se alguma tentativa anterior produziu efeito.

429 e 503 apontam para controles distintos

O RFC 9110 define 503 como incapacidade temporária do servidor causada por sobrecarga ou manutenção. O 429 descreve excesso de chamadas segundo o sujeito e a janela de uma política de taxa. Os dois podem carregar Retry-After; a semelhança do campo não iguala a causa.

Um locatário pode receber 429 enquanto os demais seguem ativos. O serviço pode devolver 503 a todos sem que uma conta tenha ultrapassado sua cota. Sistemas reais podem enfrentar as duas condições; devem nomear a que tomou a decisão.

Apresentar falta geral de capacidade como erro do cliente desloca responsabilidade. Apresentar uma cota localizada como queda total esconde os caminhos que continuam funcionando. O valor do status preciso é mostrar onde a recusa nasceu.

A resposta de defesa também consome defesa

Nas considerações de segurança, o RFC 6585 alerta que responder 429 a cada mensagem durante um ataque ou um volume enorme de uma parte consome recursos. O servidor não é obrigado a responder sempre; pode descartar conexões ou agir de outra forma.

Antes de dizer não, talvez tenha decifrado, analisado, autenticado, consultado estado distribuído, composto conteúdo e cifrado a saída. Se uma entrada barata força todo esse caminho, a explicação amplia o custo do ataque. Negar no limite da rede custa menos, mas costuma operar com identidade mais fraca e pode unir usuários atrás do mesmo endereço.

A autoridade de agir cedo deve ser proporcional à evidência disponível. A meta não é responder a qualquer preço, mas preservar o recurso com a menor intervenção que ainda possa ser justificada e revertida.

Um veredito que não pode virar conteúdo armazenado

O RFC 6585 proíbe o cache de guardar 429. A decisão depende de sujeito, janela, escopo e contador atuais. Reproduzi-la depois pode alongar uma recusa já expirada ou impor a um pedido a dívida de outro contexto.

Um intermediário que controla uma política própria pode gerar novo 429 a partir do seu estado. Não pode tratar um 429 antigo como representação reutilizável. A regra mantém o veredito perto de quem ainda enxerga o orçamento.

A afirmação estreita que permanece

O 429 não autentica, não prova malícia, não garante equidade, não descreve o algoritmo e não promete atendimento futuro. Também não exige que um servidor sob ataque gaste recursos explicando cada recusa.

Ele faz algo menor e decisivo: distingue excesso de frequência de conteúdo inválido e de indisponibilidade geral. O cliente aprende que repetição imediata tende a falhar; o servidor pode oferecer uma recuperação compreensível quando possui margem para isso.

O HTTP não inventou a cota. Deu voz comum ao resultado de uma alocação local e deixou exposto quem ainda precisa responder pela qualidade dessa alocação.

Fontes