Resumo

  • A RFC 2295 tornou visíveis, por meio de uma lista legível por máquina, várias representações associadas a um único URI HTTP; uma resposta de lista, porém, não trazia os dados de nenhuma variante.
  • Escolha, busca e apresentação eram etapas separadas. Sob determinadas condições, o servidor podia devolver a representação selecionada; o cliente também podia escolher e buscar uma variante anunciada.

Um recurso podia ter mais de uma resposta

No fim dos anos 1990, a Web já lidava com uma incompatibilidade prática. Um recurso podia existir em HTML ou PostScript, em inglês ou francês, e atender melhor a diferentes agentes de usuário. O editor podia publicar URLs distintas ou negociar versões atrás de um único URI. O desafio não era apenas escolher uma versão: intermediários, especialmente caches, também precisavam distinguir a resposta correspondente a cada requisição.

A RFC 2295, “Transparent Content Negotiation in HTTP”, apresentou um mecanismo experimental para tornar as alternativas visíveis. O memorando, de março de 1998, chamava cada versão de variante e descrevia uma lista legível por máquina vinculada a um recurso negociável. O cabeçalho Alternates podia associar a cada opção seu URI e atributos como tipo de mídia, idioma, qualidade de origem ou recursos suportados. “Transparente” significava que as variantes existentes no servidor de origem ficavam visíveis para as partes externas. Não significava que todo navegador faria a negociação automaticamente nem que a escolha deixaria de ser observável.

O mecanismo definia quatro dimensões: tipo de mídia, conjunto de caracteres, idioma e recursos. A quarta dimensão permitia tratar propriedades que as três primeiras não cobriam, como extensões de HTML ou capacidades específicas de outros formatos. A codificação do conteúdo — por exemplo, compressão — era ortogonal, não uma quinta dimensão de variantes. A distinção é importante: o texto descrevia qual representação poderia ser adequada, não toda transformação que o servidor pudesse aplicar aos bytes.

Três comprovantes, não um só evento

A resposta de lista era um inventário. A RFC 2295 a define como uma resposta que retorna a lista de variantes, mas não seus dados. Um agente de usuário compatível podia avaliar as opções e buscar uma por meio de uma requisição HTTP comum ao URI da variante. O exemplo da RFC separa as operações: o servidor primeiro entrega a lista; depois o cliente solicita paper.1; só a segunda resposta contém o documento. Uma resposta 300 Multiple Choices também podia incluir um corpo legível, permitindo que um agente sem suporte à negociação ou o próprio leitor escolhesse manualmente. Mesmo assim, a lista não era a representação escolhida.

O servidor não era apenas um catálogo. Uma choice response devolvia a representação da melhor variante e podia incluir a lista. Mas o servidor precisava dispor de informação suficiente para escolher em nome do agente, e a variante precisava atender à regra de proximidade de URI definida pela RFC. A RFC 2296, memorando experimental complementar, especificou um algoritmo remoto de seleção e tornou a escolha condicional: sem evidência suficiente para determinar uma melhor variante positiva e definida, ou se a condição de proximidade falhasse, o algoritmo retornava uma lista. O cliente também podia aplicar seu próprio algoritmo e, se a lista permanecesse disponível, buscar outra opção.

Por isso, não é preciso dizer que “o cliente escolhia”. Às vezes, sim; em outras situações, o servidor podia escolher. O protocolo separava o inventário das opções, quem tinha autoridade para decidir, a resposta que levava os bytes e a apresentação posterior. Do ponto de vista do servidor, o cabeçalho Negotiate indicava que o agente declarava suporte à negociação transparente. Uma declaração de capacidade não comprova que uma requisição específica usou o mecanismo.

O cache fazia parte do projeto

A negociação pode fazer um único URI produzir representações diferentes. Se o cache as confundir, até um algoritmo de seleção correto entrega o resultado errado. Por isso, a RFC 2295 usou o mecanismo Vary do HTTP e etiquetas de entidade, além de criar validadores para listas de variantes. Também descreveu como um cache podia extrair uma resposta HTTP normal de uma resposta de escolha e como a localização do recurso selecionado se relacionava ao recurso negociável. A correção do cache não era um detalhe de implementação periférico; fazia parte do contrato que tornava plausível reutilizar um URI.

Esse desenho tinha um custo. Enviar todas as preferências em cada requisição poderia aumentar os cabeçalhos, então o agente muitas vezes precisava examinar a lista localmente. Mas as preferências Accept podem revelar características do software ou do ambiente de uma pessoa. O memorando abordou explicitamente vazamento de privacidade, falsificação de respostas de recursos variantes e brechas de segurança expostas pela negociação. São riscos reconhecidos no projeto, não prova de que um incidente específico ocorreu.

A RFC 2295 era explicitamente Experimental e dizia que não especificava um Internet Standard. Seu mecanismo transparente valia para GET e HEAD, não para todas as transações HTTP. A especificação permite reconstruir uma ambição: tornar as opções inspecionáveis e distribuir a seleção entre clientes, servidores e caches. As fontes consultadas aqui não demonstram um levantamento de suporte dos navegadores, uma taxa de implantação ou um resultado para usuários. Uma variante anunciada não necessariamente foi buscada; receber uma resposta não prova o que alguém viu.

Fontes