Resumo

  • Na RFC 2774, uma requisição com extensão obrigatória trocava GET por M-GET ou PUT por M-PUT, fazendo um servidor alheio ao mecanismo rejeitar o método em vez de ignorar uma condição essencial.
  • Um destinatário compatível respondia 510 quando não conseguia cumprir a política de extensão e usava Ext ou C-Ext ao confirmar o cumprimento; a experiência depois virou Historic e seus campos e código foram marcados como obsoletos.

Compatibilidade que apaga o contrato

Considere um cliente que envia um documento por PUT, mas exige que uma extensão aplique uma restrição adicional. O servidor novo entende a declaração, aplica a regra e grava o recurso. O servidor antigo reconhece apenas PUT, descarta os campos desconhecidos e grava os mesmos bytes. Ambos podem responder com sucesso.

O segundo resultado é compatível no nível sintático e incompatível no nível que importa. A operação aconteceu sem a condição que autorizava o emissor a realizá-la. A tolerância tradicional a novidades transformou “não entendi” em “concluído”.

Publicada como Experimental em fevereiro de 2000, a RFC 2774 quis tornar esse desacordo impossível de esconder. Uma requisição obrigatória precisava alterar o nome do método com o prefixo M-. Um servidor que não conhecesse o framework encontraria M-PUT, não PUT, e falharia antes de executar uma versão reduzida da intenção original.

Falhar cedo era parte do desenho

O destinatário que conhecia a proposta seguia uma sequência. Identificava todas as declarações obrigatórias, avaliava se suportava cada extensão naquele contexto e, se algo faltasse, retornava 510 Not Extended. Somente depois podia processar as extensões e a semântica do método básico.

A especificação proibia declarar a requisição satisfeita sem compreender e obedecer a todas as exigências. O prefixo não era uma decoração para descoberta de recursos. Era uma barreira contra o rebaixamento silencioso: a incompatibilidade deveria aparecer antes de qualquer efeito colateral.

Quatro maneiras de declarar uma extensão

O modelo separava força e alcance. Uma declaração podia ser obrigatória ou opcional, de ponta a ponta ou válida apenas no próximo salto. Os quatro campos eram Man, Opt, C-Man e C-Opt.

Essa matriz dizia quem tinha autoridade para agir. Um proxy não se tornava destinatário de uma declaração final só porque conseguia vê-la. Uma declaração de conexão, por outro lado, destinava-se ao próximo participante e precisava ser protegida por Connection no HTTP/1.1 para não seguir adiante como metadado final.

Cada extensão tinha um identificador globalmente único, normalmente um URI. A declaração podia reservar um prefixo numérico, como 16, vinculando campos 16-... àquela instância. Isso reduzia colisões e permitia múltiplas instâncias sem entregar todo o espaço de nomes de campos a uma única extensão.

O significado estreito do 510

O 510 não era uma mensagem genérica de pane. A seção 7 descrevia uma política de acesso ao recurso que ainda não havia sido atendida. A resposta deveria fornecer informações para o cliente formular uma requisição estendida aceitável.

Se pudesse oferecer as extensões ausentes, o cliente modificaria e repetiria a tentativa. Caso contrário, o corpo serviria como diagnóstico. Até um método M- sem qualquer declaração obrigatória recebia 510: não fazia sentido exigir tratamento obrigatório sem dizer qual obrigação existia.

O status distinguia a disponibilidade do servidor da validade semântica da operação. O recurso podia existir e o método básico ser conhecido; ainda assim, aquele pedido específico não tinha cumprido seu contrato.

Cumprimento precisava de confirmação própria

Uma resposta positiva também precisava ser diferenciada. Ext indicava que todas as declarações obrigatórias de ponta a ponta tinham sido compreendidas e obedecidas. C-Ext fazia a mesma afirmação para as declarações por salto. Os campos não carregavam conteúdo da aplicação, apenas o reconhecimento do contrato de extensão.

Eles não provavam que a extensão era segura nem que o resultado estava correto. Seu valor era mais limitado: impedir que um sucesso do método básico fosse confundido com cumprimento da semântica adicional.

A semântica podia se perder em cada intermediário

Declarações finais tinham de atravessar proxies que talvez não as entendessem. Declarações por salto precisavam terminar na conexão certa. Um cache não podia reutilizar uma resposta dependente de extensão para uma requisição que não carregasse a mesma condição.

Por isso a RFC usava Cache-Control: no-cache="Ext" em respostas que cumpriam requisições obrigatórias de ponta a ponta. Para proxies HTTP/1.0, também prescrevia um Expires já vencido. Quando uma resposta variava conforme um campo de prefixo numérico, Vary precisava mencionar esse campo e a declaração que lhe dava sentido.

Cada detalhe fechava uma rota de remoção, deslocamento ou repetição da semântica. O conjunto também mostrava o custo da ambição: coordenar clientes, origens, proxies, caches e versões antigas por meio de um framework único.

A mudança de estado da experiência

A nota original do IESG já registrava cautela. O documento buscara Proposed Standard, mas avaliações divergentes e falta de consenso sobre a evolução do HTTP levaram à publicação Experimental. A nota dizia que isso não demonstrava necessariamente falhas técnicas e advertia contra usar a proposta como modelo universal.

Em 2021, o IETF moveu a RFC 2774 e outras experiências HTTP para Historic. O registro afirma que as experiências haviam terminado e que não havia evidência de uso disseminado. Hoje a IANA lista 510 como Not Extended (OBSOLETED) e marca Man, Opt, C-Man, C-Opt, Ext e C-Ext como obsoleted.

As fontes não medem adoção nem apontam uma causa única. Elas estabelecem a conclusão de ciclo de vida: o mecanismo genérico deixou de ser atual.

O HTTP continuou extensível

A RFC 9110 ainda reconhece pontos persistentes de extensão: métodos, códigos de status, nomes de campo, esquemas de autenticação e diretivas de cache. Registros e políticas de revisão dão identidade e estado a essas novidades, sem recuperar a matriz da RFC 2774.

Permanece uma exigência de projeto. Toda extensão precisa dizer se é opcional ou indispensável, qual participante deve interpretá-la, como evita colisões, o que intermediários preservam e qual evidência separa execução de mera entrega.

O 510 saiu do uso corrente, mas sua pergunta continua relevante. Uma conexão bem-sucedida não prova entendimento compartilhado. O mal-entendido mais perigoso é aquele que se apresenta como sucesso.

Fontes