Resumo

  • Em 1994, o marketplaceMCI precisava preservar dados de pedido, cobrança e entrega entre requisições Web. A MCI rejeitou a proposta inicial da Netscape de guardar o estado no servidor e exigiu que ele ficasse no cliente.
  • A Netscape ampliou essa exigência para criar uma função genérica do navegador. O servidor podia enviar um valor de estado para que o navegador o devolvesse em futuras requisições dentro de certo escopo; esse valor, por si só, não identificava quem estava usando o navegador.
  • O RFC 2109 tentou formalizar um mecanismo que já havia sido moldado pelo código e pela compatibilidade. Suas regras reconheciam os limites do controle do usuário, a possibilidade de ler os valores e a falta de proteção durante o transporte.

Um carrinho transformou a falta de memória do protocolo em problema de produto

O modelo comum de requisição e resposta da Web tinha uma lacuna prática. Uma requisição HTTP pedia um recurso e recebia uma resposta, mas a próxima não carregava automaticamente o histórico da aplicação. Um comerciante podia guardar esse histórico no servidor, mas teria de administrar o estado e os registros que sobravam quando o navegador desaparecia.

A MCI planejava o marketplaceMCI, um ambiente de compras on-line que reuniria um navegador com a marca da empresa, um servidor Web, servidores de lojistas para receber e atender pedidos e sistemas de apoio e de contas comerciais. A tarefa era concreta: manter informações de pedidos, cobranças e entregas ao longo de uma sequência de requisições.

A escolha de projeto aparece em um registro judicial posterior, e não em uma história mítica sobre um inventor solitário. Em uma reunião de 10 de agosto de 1994, a MCI rejeitou a proposta inicial da Netscape de guardar o estado no servidor. A empresa exigiu que a informação fosse armazenada no computador cliente. A decisão descreve esse requisito geral como incontroverso, embora registre divergências sobre alguns detalhes técnicos.

Essa exigência mudou o lugar da memória de curto prazo da aplicação. O navegador manteria um pequeno objeto de estado entre as interações com o servidor. Lou Montulli, programador da Netscape, recebeu a tarefa. Mais tarde, ele se lembrou de um pedido feito naquele verão para criar um método de carrinho que lidasse com a natureza sem sessão do HTTP, mas não se recordava de que a cliente específica fosse a MCI. Marc Andreessen declarou que o projeto da MCI acabou levando aos cookies e que a Netscape ampliou o recurso para uso geral. Os relatos ligam a necessidade comercial à decisão de produto sem transformar cada detalhe do projeto em certeza.

O navegador passou a carregar o estado da aplicação

A cópia preservada da especificação da Netscape descreve o mecanismo de forma direta. Um servidor podia enviar um objeto de estado junto com uma resposta HTTP. O navegador o armazenava e o incluía em requisições posteriores cujas URLs estivessem dentro do escopo do cookie. A aplicação no servidor escolhia o valor e o interpretava; o navegador o retinha e devolvia.

Assim, uma referência ao carrinho, um dado de cadastro ou uma preferência podia atravessar várias requisições. O HTTP não se tornou um protocolo de conexão contínua. A página tampouco precisava conter o carrinho individual de cada visitante, o que favorecia o cache da Web. E o servidor não deixava de trabalhar: podia usar o valor devolvido como chave para consultar registros mantidos em outro lugar.

O documento da Netscape se identificava como especificação preliminar e recomendava cautela. As primeiras regras delimitavam host ou domínio, caminho, validade e transmissão segura. Esses limites indicavam quando o navegador devolveria o estado. Não provavam o nome da pessoa, seu consentimento ou sua presença contínua.

A decisão localiza código preliminar de cookies no repositório da Netscape em 3 ou 4 de outubro de 1994, com alterações posteriores nos dias 6 e 13. As partes do processo divergiam sobre a data exata em que a invenção teria sido colocada em prática. A cronologia segura é: uma exigência de cliente e um desenho durante o verão; código no início de outubro, segundo o registro judicial; e a ampliação da função para o navegador da Netscape. Não existe um único “dia da invenção” aceito por todos.

O padrão veio depois da proposta do navegador

Em fevereiro de 1997, David Kristol e Montulli publicaram o RFC 2109, “HTTP State Management Mechanism”. O documento descreveu respostas Set-Cookie e requisições Cookie e tentou fixar uma gramática. Também reservou uma seção histórica para a compatibilidade com a proposta original da Netscape. Padronizar significava acomodar código e comportamento que já circulavam.

O RFC 2109 deixou claros os limites do mecanismo. O agente de usuário deveria permitir que as pessoas controlassem se os cookies seriam enviados e guardados. Os cabeçalhos trafegavam sem proteção, então um valor sensível podia ser exposto ou alterado. Para o navegador, o conteúdo era opaco, mas podia ser legível. No exemplo de login, a pessoa primeiro se identifica por um formulário; depois, o servidor devolve um cookie que reflete essa identidade. O cookie prolonga o estado da aplicação após essa etapa. Ele não faz uma verificação independente de identidade.

Essa distinção importa porque um valor guardado no navegador pode ser útil a um serviço sem provar quem o possui. Se a aplicação tratar a posse do valor como autoridade, cria uma capacidade de sessão ao portador. Quem obtiver o valor talvez possa reutilizá-lo dentro de seu escopo e prazo. A segurança depende de como a aplicação o emite, protege, expira e revoga — decisões que a troca básica de cookies não resolve sozinha.

A história do cookie é menos misteriosa que seu nome. Um fluxo de compras obrigou uma equipe de produto a escolher onde a continuidade ficaria. O navegador virou portador de um estado escolhido pelo servidor; uma exigência de cliente se tornou um recurso reutilizável; e um padrão posterior registrou a compatibilidade com práticas já implantadas. Aplicações Web passaram a lembrar uma transação entre requisições separadas. O navegador nunca se tornou testemunha da identidade humana por trás delas.

Fontes e limites