Resumo

  • A RFC 2109 padronizou Set-Cookie e Cookie para formar uma sessão lógica sobre trocas HTTP distintas, independente de conexão persistente.
  • Domain, Path, Max-Age, Secure e controles de cache limitavam o estado; a especificação também exigia controle do usuário e restringia carregamentos automáticos e redirecionamentos não verificáveis.
  • O retorno de uma cookie comprovava seleção de estado pelo agente do usuário, não pessoa presente, consentimento informado, autorização, frescor, intenção transacional ou efeito final.

A sessão existia acima da conexão

A RFC 2109 definiu “sessão” como contexto lógico. Ela não era uma conexão de rede persistente, e abrir ou fechar conexões não deveria alterar a sessão derivada de cookies. A origem iniciava com Set-Cookie; o agente podia continuar com Cookie; ambos podiam encerrar, e Max-Age=0 solicitava descarte.

Assim, uma conexão ativa não comprovava uma sessão aceita. A sessão podia sobreviver a várias conexões, e uma cookie podia permanecer no navegador depois de revogada no servidor. Transporte, custódia local e decisão do serviço precisavam de registros próprios.

O carrinho guardava estado, não autoridade

No exemplo, Customer, Part_Number e Shipping acumulavam-se enquanto os caminhos correspondiam. O fio comprova que o servidor emitiu valores, o navegador os conservou e as regras os selecionaram. Não comprova que a pessoa atual é o cliente nomeado, que ainda quer a mercadoria, que pode aprovar o pagamento ou que a resposta HTTP resultou em entrega.

O valor era opaco para o agente do usuário e podia ser legível para quem inspecionasse o cabeçalho. Domain usava as regras históricas de correspondência; Path selecionava prefixos de URI; Max-Age definia vida pretendida; Version=1 identificava o mecanismo. Cookies homônimas podiam aparecer juntas quando caminhos diferentes correspondiam.

Esses atributos delimitavam envio. Não criavam poder de decisão. Path não era isolamento de confidencialidade, e um Domain compartilhado não tornava todos os serviços igualmente confiáveis.

Secure era conselho, não testemunho

Secure recomendava um meio seguro, mas o agente do usuário podia decidir qual nível considerava adequado. O atributo não cifrava sozinho, não autenticava quem operava o navegador e não vinculava uma ordem a uma autorização vigente. A seção de segurança tratava separadamente da leitura e alteração de cabeçalhos em texto claro.

Uma cookie podia conter estado legível ou uma chave de banco de dados. Em ambos os casos, o servidor precisava validar a interpretação recebida. Presença não era integridade, e integridade não seria autorização.

Memória de sessão e cache continuavam separados

Separar estado de URL e conteúdo preservava a escala das caches. Uma representação pública podia ser reutilizada; conteúdo privado de sessão não deveria entrar em cache compartilhado. Proxies deviam encaminhar campos e obedecer a validade, private e no-cache="set-cookie".

Logo, representação armazenada, Set-Cookie emitido, estado admitido e sessão aceita depois são quatro fatos. A RFC 2068 fornecia a semântica HTTP/1.1. Caches HTTP/1.0 podiam reter o cabeçalho porque não tinham mecanismo geral para suprimi-lo, criando risco.

A reprodução automática já exigia controle

RFC 2109 chamava de verificável a transação cujo URI o usuário podia examinar. Objetos embutidos e redirecionamentos automáticos eram tipicamente não verificáveis. A regra tentou impedir que uma origem fizesse o navegador iniciar ou continuar sessão com domínio alheio; exceções deveriam vir desligadas.

O ponto continua atual: a cookie é útil porque retorna automaticamente, e justamente por isso não representa um ato humano novo. O usuário deveria poder desativar gravação e envio, perceber uma sessão, inspecionar conteúdo e controlar retenção por Domain. A especificação reconhecia rastreamento intrusivo mesmo sem identidade evidente e a possibilidade de formulário posterior tornar a pessoa identificável.

A RFC 2964 falou depois em consentimento informado. A RFC 2965 substituiu a RFC 2109 após experiência de implementação. A RFC 6265 registrou o modelo amplamente implantado, e a revisão de autores da RFC 10025 pertence a outra geração. A sucessão normativa não comprova a migração de um produto específico.

Um elo em uma cadeia maior

Um recibo honesto separa: servidor emitiu; agente admitiu; usuário reteve; contexto selecionou; sessão foi aceita; política autorizou; ação foi confirmada; resultado foi observado. Cookie cobre apenas parte dessa cadeia.

Em Running-Code Primacy, Lu Heng exige voltar ao fato executado. Minimum Initial Specification mantém o núcleo comum estreito. Reality Layers impede que um registro tome emprestada a autoridade de outro. A memória da RFC 2109 era real; a identidade, o consentimento e o resultado continuavam fora dela.

Fontes