Resumo

  • O HTTP 431 separa campos de requisição grandes demais de conteúdo grande demais, mas o HTTP não impõe um limite idêntico a todas as implementações e rotas.
  • A recusa pode apontar o conjunto ou um único campo; reduzir e reenviar é possível, porém apagar contexto sem critério pode mudar autorização, condições ou destino.

A recusa anterior ao conteúdo

Uma operação pequena chega a um gateway. O corpo é mínimo ou nem existe, mas a requisição acumulou cookie, credencial, preferências, rastreamento e contexto de encaminhamento. Cada campo parece razoável; a soma ultrapassa o orçamento escolhido pelo receptor.

Em 2012, o RFC 6585 nomeou essa situação como 431 Request Header Fields Too Large. O servidor não quer processar a requisição porque seus campos são grandes demais. O cliente pode reduzi-los e submetê-la novamente.

Não é o conteúdo associado ao 413 pelo RFC 9110. Os campos são o envelope de controle que informa interpretação, autoridade, condições e rota. Uma requisição pode, portanto, exceder o limite antes de o corpo começar.

Uma resposta comum sem um teto comum

O RFC 9110 não define máximo prévio para linha, valor ou seção completa de campos. Memória e tempo de análise continuam finitos, então cada implementação decide o que aceita.

Uma cadeia possui vários orçamentos. A biblioteca cliente constrói, um proxy local admite, o gateway de borda recusa; outro caminho talvez alcance uma origem com limite diferente. Os mesmos bytes podem funcionar numa rota e falhar em outra, pois não existe um número HTTP universal violado.

O 431 dá linguagem comum a decisões privadas. Sozinho, não identifica qual salto impôs o menor orçamento nem demonstra que elevá-lo é seguro.

Um campo culpado não é o mesmo que excesso total

O RFC 6585 admite duas situações: o conjunto inteiro é grande demais ou um campo específico é responsável. Neste segundo caso, a representação deveria dizer qual campo foi.

Um campo isolado pode ser encurtado ou renovado quando sua semântica permite. O excesso agregado pode resultar de dezenas de adições independentes. Retirar a maior não garante passagem pelo próximo salto. O nome do campo é uma pista, não prova de compatibilidade de ponta a ponta.

A responsabilidade também pode estar distribuída. Cookies acumulam estado, intermediários ampliam campos de encaminhamento, credenciais mudam com a rotação e plataformas de rastreamento adicionam contexto fora da visão da aplicação.

Ignorar silenciosamente muda a operação

O RFC 9110 exige um 4xx apropriado quando campos ultrapassam o que o servidor quer processar. Ignorá-los aumenta o risco de interpretações divergentes e request smuggling.

Campos carregam credenciais, precondições, destino e regras de interpretação. Se um salto ignora o que outro aplica, eles deixam de agir sobre a mesma requisição. Um corte conveniente pode transformar atualização condicional em incondicional, remover autorização ou dividir a compreensão dos limites da mensagem.

O servidor precisa receber toda a seção antes de aplicar o método, pois campos tardios podem conter condições, credenciais ou duplicatas enganosas. A saída segura é a recusa explícita e a reconstrução por quem conhece o significado.

Reenviar é permitido, não prometido

Reduzir permite uma nova tentativa, mas não garante sucesso. Um intermediário posterior pode ter limite menor; o campo retirado pode ser obrigatório; a ação pode perder validade. Se houve incerteza de transporte, o cliente talvez nem saiba se a tentativa anterior produziu efeito.

A nova tentativa deve partir do estado autorizado, preservar credenciais e condições necessárias, usar idempotência quando disponível e confirmar que a ação continua útil. Repetir mais rápido uma requisição danificada não recupera seu sentido.

Cache não pode prolongar um orçamento local

O RFC 6585 proíbe armazenar respostas 431. A decisão pertence a uma seção, uma rota e um orçamento atuais. Reproduzi-la depois pode negar uma requisição reduzida ou transformar a configuração antiga de um salto em regra de outro.

Um receptor pode gerar novo 431 a partir do estado presente. O cache não pode tratar a recusa como conteúdo reutilizável.

Sob ataque, explicar também consome recursos

Servidores não são obrigados a emitir 431. O RFC 6585 admite que, sob ataque, derrubar conexões ou tomar outras medidas seja melhor. Ler e analisar o suficiente para explicar usa a memória e o processamento que o limite protege; revelar números exatos pode ajudar o reconhecimento ofensivo.

Com folga, um diagnóstico limitado ajuda o cliente legítimo. Sob pressão hostil, conter cedo pode prevalecer. Uma conexão fechada, contudo, não prova publicamente que os campos eram a causa; a observabilidade interna deve guardar essa diferença.

A verdade estreita do 431

O código não diz que o corpo é grande, que um teto da Internet foi cruzado ou que o cliente é malicioso. Diz apenas que um receptor recusou um envelope de controle além do que queria processar.

Essa precisão tornou um limite oculto reparável sem padronizar o orçamento. A disciplina duradoura é manter contexto limitado, com dono e reconstruível — e nunca retirar a condição que tornava a ação segura apenas para fazê-la caber.

Fontes