Resumo

  • O HTTPbis publicou em 9 de setembro de 2026 a revisão 01 de draft-ietf-httpbis-pre-denied. É uma draft ativa do grupo de trabalho, não um RFC nem uma atribuição aprovada pela IANA.
  • A versão troca “Preliminary Request Denied” por Purpose Declined, propõe o número 419 e abrange recusas baseadas no Sec-Purpose declarado. Hoje, o Fetch define apenas o token prefetch.
  • A origem e um gateway agindo em nome dela podem gerar a resposta. Um proxy independente não deveria. A fronteira diz quem pode representar a política do serviço, não quem consegue montar um pacote HTTP.
  • O status não identifica a regra aplicada. Proponho um registro mínimo ligando finalidade, ator, delegação, versão da política, horário, cache e resultado. É uma proposta editorial de Daniel Kade, não um requisito da draft.

A frase “em nome da origem” carrega o peso da revisão

Às 08h56 UTC de 9 de setembro, o Datatracker disponibilizou The Purpose Declined HTTP Status Code na revisão 01. A versão anterior usava 4xx como espaço reservado e falava em pedidos preliminares recusados, com prefetch e preload como casos centrais. Agora o texto escolhe 419 e trata de qualquer requisição recusada por causa da finalidade declarada.

O estágio do documento impõe cautela. Trata-se de trabalho ativo do HTTPbis no stream IETF, com intenção de Proposed Standard e Tommy Pauly como document shepherd. Ao mesmo tempo, o estado no IESG ainda é I-D Exists; não há Area Director responsável, processamento no IESG nem telechat. No registro corrente da IANA, 419-420 continuam como Unassigned. A revisão fixa uma proposta de trabalho, não o resultado final.

O ponto institucional está na lista de quem pode responder. A origem pode produzir o código. Um CDN ou reverse proxy também pode, desde que atue por conta da origem. Um proxy independente não deveria. Não é uma limitação física: o intermediário tem meios de devolver um 4xx. É uma limitação de autoridade para apresentar a própria recusa como se fosse a política da aplicação.

Um gateway não recebe esse mandato por estar perto da origem na topologia. Ele o recebe de uma relação administrativa verificável. Sem essa distinção, uma intervenção do trânsito e uma decisão do dono do serviço ficam visualmente idênticas.

Finalidade declarada não é intenção comprovada

O Sec-Purpose tem uma função específica no Fetch Standard. Ele indica que a requisição atende a uma finalidade diferente do uso imediato. É um cabeçalho estruturado e, no corte desta reportagem, seu único token definido é prefetch. Um servidor pode usar essa informação para mudar a validade do cache, impedir a busca antecipada ou contabilizar a visita de outra maneira.

O nome mais amplo abre espaço para valores futuros, sem criá-los. Também não dá ao servidor uma faculdade nova. Recusar tráfego sempre foi possível. A própria draft diz que a contribuição é tornar o comportamento existente mais legível para clientes e operadores.

Essa legibilidade não autentica a motivação. Sec-Purpose: prefetch registra o que o cliente declarou, não o desejo subjetivo do usuário, o consentimento para atividade em segundo plano ou o módulo que iniciou a chamada. A declaração pode estar errada. Do outro lado, 419 não informa se a regra era absoluta, dependia de carga, custo, região, abuso, conteúdo ou uma exceção local.

O diálogo de protocolo suporta duas conclusões estreitas: houve uma declaração de finalidade e um ator autorizado recusou com base nela. Não transforma a finalidade em julgamento geral sobre legitimidade, segurança ou vontade da pessoa.

O mandato do gateway precisa sobreviver ao incidente

Serviços distribuídos costumam separar a propriedade da política do ponto de execução. O CDN encerra a conexão antes da aplicação. O reverse proxy roda regras para vários serviços. Isso poupa recursos, mas cria uma dívida de explicação quando a resposta surpreende o cliente.

O operador precisa saber se a decisão veio da aplicação, de uma regra delegada ou de um intermediário fora do controle administrativo da origem. Precisa identificar o tenant que autorizou a regra, a versão vigente e a avaliação de exceções. Nada disso cabe no número 419.

Também não seria prudente expor toda a política no fio. A seção de segurança da draft reconhece que uma recusa específica por finalidade pode revelar estado interno. A solução é manter um comprovante operacional controlado: token exato de Sec-Purpose; componente decisor e função; origem ou tenant representado; identificador estável e versão da política; instante da decisão; resultado; tratamento de cache enviado; e, quando seguro, uma classe de motivo.

O registro não precisa criar um perfil do usuário nem conservar o conteúdo da navegação. Seu escopo é provar a delegação e reproduzir uma decisão contestada. Proximidade de rede nunca deve substituir a evidência do mandato.

Não armazenar a resposta limita a duração do poder

A revisão 01 pede conteúdo com tamanho zero e orienta descartar qualquer corpo recebido. Também declara que 419 não é heuristicamente cacheable e não deveria ser armazenado. Assim, uma recusa local não vira política persistente por acidente.

O RFC 9110 preserva compatibilidade: quem não conhece 419 deve tratá-lo como o x00 da classe, portanto como um erro 4xx genérico. O RFC 9111 estabelece as condições gerais de armazenamento. A instrução específica da draft evita que uma decisão tomada sob certa carga ou versão seja repetida depois que o contexto mudou.

Em gateways compartilhados, uma resposta em cache pode atravessar tenant, sobreviver a uma correção ou atingir outro contexto de finalidade. Ela aparenta transmitir uma nova decisão da origem, embora a origem não tenha avaliado a nova requisição. Por isso, cache faz parte da prova de autoridade, não só da otimização técnica.

Há uma divisão de trabalho saudável: o protocolo público informa uma semântica mínima; o registro interno preserva a responsabilização; a política local decide quanto do motivo pode ser mostrado sem aumentar a exposição.

Fontes