Resumo

  • Um Internet-Draft ativo do HTTP propõe 419 Purpose Declined quando o servidor recusa uma requisição por causa do Sec-Purpose declarado. É um recibo daquela requisição, não bloqueio permanente, atestado de saúde ou novo poder. Em 29 de setembro de 2026, a IANA ainda mostrava 419–420 como não atribuídos.
  • A mudança exige uma cadeia probatória: finalidade, ponto autorizado, política, não armazenamento em cache, reação do cliente, população do SLO e demanda real posterior. Se a pilha reduzir 419 a “outro 4xx”, o fio ganha um número e a operação continua cega.

O plantão recebeu uma página de indisponibilidade, mas encontrou origem estável. A diferença estava no tipo de demanda. Não era uma pessoa esperando o conteúdo: eram requisições especulativas, enviadas porque o cliente achava que talvez precisasse dele em breve.

Prefetch distribui incentivos de modo assimétrico. O cliente captura parte do ganho de latência; origem e CDN pagam computação, consultas, transferência e telemetria. Se a previsão estiver errada, o trabalho não vira uso. Portanto, rejeitar algumas previsões pode ser uma decisão operacional saudável.

O problema aparece quando essa decisão retorna 503 Service Unavailable. Pela semântica do RFC 9110, 5xx indica que o servidor falhou ao atender uma requisição aparentemente válida. O alerta que interpreta alta de 503 como possível pane está fazendo seu trabalho. Quem misturou admissão especulativa com incapacidade foi a camada anterior.

O draft-ietf-httpbis-pre-denied-01, de 9 de setembro de 2026, propõe 419 Purpose Declined: o servidor rejeitou esta requisição por causa da finalidade declarada. É documento ativo do grupo HTTP com destino pretendido à trilha de padrões, não RFC. No congelamento das fontes, 419–420 permaneciam não atribuídos pela IANA.

O projeto não concede capacidade nova de negar. Ele torna legível uma decisão que já existe. A questão é saber se foi falta de capacidade ou escolha de não aceitar trabalho opcional.

A finalidade declarada é contexto, não prova

Fetch define Sec-Purpose para finalidades diferentes do uso imediato pela pessoa. O único token definido é prefetch: buscar algo previsto para uso em breve. O algoritmo coloca Sec-Purpose: prefetch quando esse é o iniciador.

O servidor pode mudar expiração de cache, negar a pré-busca ou contá-la separadamente de uma visita. Mas o cabeçalho não prova navegação futura, precisão, identidade nem benefício. Ele informa por que o cliente diz estar pedindo.

Essa fronteira preserva decisão local. O cliente declara; a origem, ou gateway mandatado, decide. Um intermediário não autorizado não ganha poder só porque transporta a mensagem. A especificação comum permanece mínima, enquanto custo, carga e contrato ficam com quem assume o resultado.

Um código errado desloca pessoas e dinheiro

Misturar recusa voluntária com 503 leva SRE a investigar capacidade, queima error budget e altera relatórios de cliente. Pode ainda induzir compra de infraestrutura para “corrigir” uma curva que refletia contenção deliberada. O indicador passa a premiar trabalho inútil.

403 Forbidden também extrapola. A mesma URL pode responder normalmente ao acesso imediato e aceitar o próximo prefetch. O 419 proposto enuncia apenas que esta requisição foi recusada por sua finalidade.

Essa precisão não diz que a regra era boa. Um 419 mal configurado pode prejudicar experiência. Classificar é identificar o tipo de decisão, não certificá-la.

A recusa termina com a requisição

O texto limita 419 à requisição associada; outra requisição com a mesma finalidade pode ter resultado diferente. A política, carga e situação de cache mudam. Sobretudo, uma requisição de uso imediato é outro fato.

Por isso 419 não é heuristicamente cacheável e não deveria ser cacheado. Reutilizar uma recusa remove a decisão da origem e do instante que a justificaram. Servir o 419 antigo à visita real transformaria otimização em pane.

A resposta não se destina a exibição. Deve ter corpo de comprimento zero, e eventual conteúdo deve ser descartado. Explicação operacional pertence ao trace e à versão de política, não a uma nova página de erro.

Testes precisam repetir prefetch sob condições distintas e, depois, fazer acesso imediato. Devem provar que não houve replay de cache, que o decisor correto foi consultado e que o usuário não viu a resposta vazia.

A autoridade de emitir também precisa de recibo

Origem e gateways que agem em seu nome, como CDN e proxy reverso, podem gerar 419. Proxies sem essa relação não deveriam. Essa é a fronteira que impede um intermediário qualquer de apagar a requisição e fingir que a origem escolheu recusá-la.

Registre onde o status nasceu, delegação, policy version, regra e entradas. Sec-Purpose não autentica o remetente. Servir objetos em nome da origem também não implica mandato ilimitado para redefinir admissão.

Há ainda risco de vazamento de estado interno. Se a frequência de 419 varia com carga ou inventário, observadores podem sondar limiares. A resposta é controlar granularidade e abuso, não esconder tudo num 503 semanticamente falso.

Cliente antigo entende 4xx, mas pode perder a razão

RFC 9110 manda tratar código 4xx desconhecido como equivalente genérico a 400. Assim, cliente antigo não confunde 419 com sucesso. Porém, SDK pode chamá-lo de bad request, logs podem agregá-lo em other_4xx, retry pode aplicar política errada e painel pode continuar vermelho.

Running-Code Primacy exige teste ponta a ponta: cliente, edge, origem, cache, tracing, métricas, alerta, SLO e relatório. Registro futuro na IANA não atualiza esses componentes por decreto.

Preserve três dimensões: finalidade especulativa, identidade do decisor e resultado do acesso real seguinte. Uma onda de 419 pode vir de novo comportamento do cliente sem falha. Mas falha imediata simultânea continua sendo incidente. “Todo 419 é inofensivo” seria uma nova simplificação errada.

Ligar a resposta ao que ocorreu depois

O recibo começa com ID, método, alvo, iniciador, Sec-Purpose, versão do cliente e cache. Soma decisor, delegação, regra, versão e horário. Guarda status, cache control, tamanho e posição no trace. Depois liga eventual demanda real, latência, bytes, trabalho de origem e efeito visível.

Sem essa junção, não há prova de economia nem de dano. Se ninguém usar o recurso, o trabalho talvez tenha sido evitado, mas precisa ser medido. Se a pessoa pedir e receber normalmente, a saúde está demonstrada e resta avaliar latência. Se também falhar, o 419 anterior não apaga a pane. Se receber 419 cacheado, o escopo foi violado.

Disponibilidade imediata e taxa de admissão especulativa merecem SLOs separados. A correlação entre ambos, custo e experiência é informativa; a fusão dos denominadores não é.

As fontes oficiais comprovam a proposta, o estado processual, a semântica Fetch, as regras HTTP e a não atribuição pela IANA. Não comprovam browser, CDN, implantação, interoperabilidade, economia ou adoção. Isso requer testes e observação.

A força do projeto está em ser pequeno: nomear uma recusa existente, limitá-la a uma requisição, mantê-la fora do cache, sem conteúdo ao usuário e com emissor delimitado. Só a cadeia em execução pode provar que o servidor estava saudável.

Fontes