Resumo

  • Em outubro de 2000, o RFC 2965 desenhou uma negociação de versões. Um cliente capaz de entender cookies antigos e novos deveria continuar a enviar Cookie quando cabível e acrescentar Cookie2: $Version="1". Um servidor compatível com a novidade deveria responder com Set-Cookie2; um servidor antigo poderia ignorar o anúncio.
  • Set-Cookie2 permitia o atributo Port, que delimitava os destinos de retorno do cookie, e CommentURL, endereço para informações ao usuário. Anunciar capacidade, receber uma resposta nova e ver uma pessoa ler a explicação são etapas distintas.
  • Em abril de 2011, o RFC 6265 substituiu o RFC 2965, pediu sua classificação como histórico e abandonou Cookie2 e Set-Cookie2. Ele descreveu Cookie e Set-Cookie como usados na Internet e observou que cookies de um host são compartilhados entre portas.

O navegador apresenta seu cartão de capacidade

Uma loja quer reconhecer o carrinho na próxima requisição HTTP. O servidor entrega uma informação ao navegador, e o navegador devolve o valor quando se aplica. O RFC 2109 de fevereiro de 1997 já descrevia uma forma de administrar esse estado. Melhorá-la exigia lidar com a população de programas que continuava falando versões anteriores. Ninguém possuía uma chave para atualizar todos os servidores e navegadores na mesma tarde.

O RFC 2965 de outubro de 2000 sugeriu uma negociação em vez de uma troca brusca. Set-Cookie2 era o novo campo de resposta do servidor; Cookie2, a declaração de capacidade do cliente. Um navegador que entendesse ambas as gerações continuaria a devolver um Cookie no estilo antigo quando tivesse recebido o valor por Set-Cookie. Ao lado dele, enviaria Cookie2: $Version="1". Era um aviso de que havia outra maneira de conversar.

Um servidor que também entendesse a novidade deveria continuar a sessão com Set-Cookie2. Um servidor antigo não precisava compreender a mensagem extra: podia ignorá-la. O intercâmbio comum permanecia. O navegador atualizado anunciava uma capacidade sem exigir que cada servidor antigo fosse reescrito antes da próxima requisição.

Há três funções para acompanhar na rede. Cookie2 anuncia a versão compreendida; não leva o conjunto de valores de sessão em substituição a Cookie. Set-Cookie2 leva uma resposta nova do servidor ao navegador. O retorno posterior dos valores aplicáveis acontece no campo Cookie da requisição. Encontrar a primeira mensagem em uma captura mostra uma oferta; a resposta do servidor e o uso seguinte precisam ser examinados separadamente.

O RFC também deixava o servidor decidir o que fazer com o estado recebido. Uma resposta com Set-Cookie2 pode criar ou atualizar valores; a aplicação que os usa ainda tem suas próprias decisões. O protocolo organizava a troca entre máquinas. A capacidade anunciada não confirmava, por si, que a melhoria havia sido usada naquela sessão.

O que havia atrás da nova porta

O número 2 vinha acompanhado de recursos concretos. Com Port em Set-Cookie2, o servidor podia indicar onde o cookie voltaria. Sem o atributo, o valor podia ser enviado a qualquer porta pertinente do mesmo host. Port presente sem valor limitava o retorno à porta de origem. Uma lista autorizava apenas as portas enumeradas. Para serviços vizinhos na mesma máquina, a opção oferecia uma fronteira mais estreita que o compartilhamento amplo.

CommentURL servia a outra fronteira. O texto estimulava o servidor a explicar o uso de cookies e preferia um endereço de página, capaz de conter informações mais ricas e em diferentes idiomas. Uma pessoa poderia seguir o link para entender melhor o que foi armazenado. A existência do endereço, a visita à página e a escolha informada eram acontecimentos que precisavam de provas diferentes.

Assim, a atualização não era um exercício de renomear cabeçalhos. O novo caminho tinha escopo por porta, um canal de explicação e um anúncio de compatibilidade. Cada benefício dependia de clientes e servidores realmente capazes de seguir as novas regras. Um dispensador de cookies mais elaborado não ajuda a requisição que continua recebendo a ficha antiga.

O texto de 2000 especificava com cuidado a coexistência. Clientes velhos que não reconheciam Set-Cookie2 prosseguiam com as regras que conheciam. Clientes das duas gerações tinham de saber como cada cookie fora recebido e responder adequadamente. Quando uma resposta trazia campos antigo e novo para um cookie equivalente, o novo deveria prevalecer para o cliente compatível. A proteção da infraestrutura instalada exigia software novo que soubesse administrar dois trilhos.

Os documentos não contam quantos navegadores enviaram Cookie2, nem quantos servidores mudaram para Set-Cookie2. Versões datadas e registros de tráfego permitiriam medir a adoção. As duas especificações são suficientes para reconstituir o projeto e a decisão normativa posterior.

O padrão de 2011 escolhe a estrada ocupada

O RFC 6265, publicado em abril de 2011, começou pelas trocas efetivamente usadas na Internet. Definiu Cookie e Set-Cookie e afirmou que as descrições anteriores — do texto da Netscape, do RFC 2109 e do RFC 2965 — não representavam adequadamente aquele uso. Recomendou aos servidores um perfil disciplinado de emissão e exigiu dos clientes uma leitura mais permissiva para conviver com os servidores existentes. O padrão observou os veículos antes de redesenhar a placa.

Na introdução, ele pediu que RFC 2109 e RFC 2965 passassem à condição histórica, substituiu RFC 2965 e desaconselhou expressamente Cookie2 e Set-Cookie2. O registro de cabeçalhos marcou ambos os nomes como obsoletos. A credencial que anunciava a nova versão e a resposta que a seguia saíram do contrato principal. Permaneceram os campos em torno dos quais os sites de fato funcionavam.

O documento de 2011 não elogiou cegamente essa prática. Ele apontou que cookies de um mesmo host são compartilhados entre portas, apesar de a política de mesma origem dos navegadores normalmente separar conteúdo por porta. O atributo Port de 2000 havia oferecido uma forma de estreitar justamente esse limite. O padrão posterior registrou o comportamento disseminado e deixou a restrição versionada no ramo abandonado.

Essa história é maior que uma disputa entre nomes de cabeçalho. O servidor decide sua resposta, o navegador decide o que anuncia, e um participante antigo pode ignorar um campo desconhecido. Cada um controla uma parte da migração. Os editores de uma especificação podiam escrever a rota, mas não fazer as requisições reais passarem por ela. Em 2011, o texto se alinhou com a linguagem que a rede já falava.

O desfecho documental é claro: RFC 2965 foi substituído e os dois campos foram depreciados. Uma cronologia de implementação por navegador exigiria arquivos de versões específicos. Mesmo sem essa contagem, a virada entre as normas fica à vista: em 2000, o anúncio buscava abrir a estrada nova; em 2011, o contrato comum descrevia a estrada que continuava carregada de tráfego.

A rota de compatibilidade virou o endereço fixo

O plano de Cookie2 tinha uma qualidade genuína: respeitava os participantes antigos. O cliente podia declarar capacidade, o servidor preparado podia escolher o novo campo, e os outros seguiam funcionando. O custo dessa delicadeza era que as vantagens só apareciam quando os dois lados se moviam. Servidores podiam esperar pelos navegadores; navegadores, pelos servidores.

O resultado deixou marcas específicas. A limitação por porta e a URL de explicação continuaram no conjunto de regras que a norma de 2011 aposentou. O intercâmbio comum ainda carregava compartilhamento entre portas e outros limites que seu próprio texto reconhecia. Uma solução proposta no papel precisa de uma população real de programas para alterar o sistema.

Uma rota de escape pode ser tão boa para manter o serviço que ninguém tem pressa de sair dela. O Cookie2 pedia licença para começar a melhoria. Onze anos depois, o HTTP guardou o pedido no arquivo e publicou o mapa do caminho onde todos haviam continuado a andar.