Summary

  • O RFC 6265 descreve o percurso: o servidor envia Set-Cookie; o navegador devolve pares aplicáveis em Cookie. O documento pede aos servidores poucos cookies, de tamanho reduzido.
  • O RFC 6585 introduziu, em abril de 2012, o 431 para o conjunto de cabeçalhos excessivo ou um campo grande demais. A resposta 431 não pode ficar em cache, e a requisição pode ser repetida depois de encolher os campos.
  • Os padrões HTTP/2 e HTTP/3 mantêm a possibilidade de rejeitar um bloco ou seção de cabeçalhos acima do limite que o servidor aceita processar.

A encomenda volta para quem a preparou

Imagine alguém voltando a uma loja online. O navegador pede a página inicial e leva junto o campo Cookie: identificador da sessão, preferência de idioma, marcas de experiências. A loja pediu que essas informações fossem guardadas em visitas anteriores. Na entrada, um gateway ou servidor mede os cabeçalhos e encontra um volume acima do que aceita. O resultado é 431. A empresa lotou a mala e barrou quem a trouxe de volta.

O mecanismo aparece no RFC 6265, publicado em abril de 2011. Set-Cookie leva do servidor ao navegador um par de nome e valor. Em requisições futuras, o navegador avalia domínio, caminho e outras condições antes de devolver o par em Cookie. Os atributos que determinam escopo e validade não voltam como pares; os nomes e valores voltam. Uma instrução emitida uma vez vira carga recorrente para toda rota alcançada por aquele escopo.

O capítulo sobre limites mostra por que capacidade de armazenamento e capacidade de recepção são contas diferentes. Navegadores de uso geral devem suportar pelo menos 4096 bytes por cookie e pelo menos 50 cookies por domínio. O mesmo texto pede que os servidores usem poucos cookies e os mantenham pequenos, porque Cookie acompanha toda requisição aplicável. Os 4096 bytes dizem quanto um navegador precisa conseguir guardar em um cookie. Não estabelecem o teto do cabeçalho completo que cada aplicação e cada intermediário aceitará ler.

O diagnóstico veio com um número

Em abril de 2012, o RFC 6585 acrescentou quatro códigos de status ao HTTP. O 431, Request Header Fields Too Large, serve tanto para a soma de campos quanto para um campo isolado acima do limite. Quando um único campo provoca o problema, a representação da resposta deveria identificá-lo. O cliente pode tentar novamente com campos menores. O cache não pode guardar a resposta 431 e reaplicá-la a outra requisição.

O código nomeia o obstáculo; a especificação não escolhe qual cookie apagar nem fixa um número único de bytes para a Internet inteira. Também não garante que a pessoa verá a mensagem: sob ataque, o servidor pode encerrar a conexão sem produzir 431. Uma tela que falha ao carregar não revela se a rejeição ocorreu no gateway, no proxy ou na aplicação. Essa identidade exige o registro da primeira peça que recusou a requisição.

Apagar todos os cookies pode diminuir o pedido, mas também elimina sessões e preferências. Se a aplicação continuar emitindo os mesmos valores, o problema reaparece. A página de ajuda deve ser alcançável com uma requisição pequena; caso contrário, o socorro fica atrás da mesma porta. O operador tem acesso às decisões que criaram a carga: nomes e valores, prazo, domínio, caminho e limites dos componentes que recebem o tráfego.

Uma viagem comprimida continua chegando inteira

O RFC 9113, de 2022, afirma que um servidor HTTP/2 pode enviar 431 quando recebe um bloco de campos maior do que quer tratar. O RFC 9114 prevê o mesmo para a seção de cabeçalhos em HTTP/3. A compressão economiza bytes em trânsito. O destinatário ainda precisa processar a coleção de campos e ainda decide quanto aceita.

Isso cria uma armadilha para quem investiga a falha. Um gráfico de rede pode mostrar uma transferência pequena; o gateway mede um conjunto de campos expandido e o rejeita. É preciso separar um Cookie enorme do acúmulo de muitos campos modestos. Campos de autorização também ocupam espaço. Os quatro RFCs não trazem estatística de incidentes reais de 431 causados por cookies. Para um caso determinado, a prova está na requisição capturada e no log do primeiro ponto de rejeição.

O interesse histórico do 431 está no desencontro de controle. O navegador cumpre a ordem de devolver estado. A infraestrutura protege o orçamento de entrada. A aplicação pode nem receber o pedido. O cliente vê uma única loja, embora a recusa tenha sido produzida por decisões tomadas em lugares diferentes dentro dela. O número no protocolo descreve a encomenda recusada; reduzir seu conteúdo depende de quem a enviou.