Resumo
- O RFC 10025 dá obrigações diferentes a produtores e consumidores de cookies. Mesmo uma instrução
Set-Cookiebem formada pode ser ignorada, rejeitada, normalizada, substituída ou removida pelo agente do usuário. - Estado armazenado pode ser excluído de uma requisição; estado enviado pode ser recusado pela sessão ou pela autorização. Um recibo útil liga essas etapas com identificadores opacos e nunca registra o valor secreto.
Considere uma falha reconstruída, sem atribuí-la a produto algum. O serviço de autenticação responde sob TLS com duas linhas Set-Cookie. A captura confirma bytes e horário. O painel declara a criação da sessão concluída. Na navegação seguinte, o identificador não volta. Em outra requisição, voltam duas entradas de mesmo nome.
A captura não prova que houve perda. A política local pode ter ignorado a instrução. Uma condição de prefixo pode ter falhado. A nova linha pode ter substituído uma entrada anterior com a mesma chave de armazenamento, ou ter sido rejeitada e deixado a antiga intacta. A linha aceita pode ter sido removida por expiração, encerramento de sessão ou limite de capacidade. Pode também continuar armazenada e apenas não pertencer ao domínio, caminho, canal ou contexto SameSite da nova requisição.
O RFC 10025, publicado pela IETF em julho de 2026 como Standards Track e substituto do RFC 6265, descreve justamente essa separação. Set-Cookie leva nome, valor e atributos na resposta. Cookie leva mais tarde os pares escolhidos para uma requisição. O segundo campo não confirma o primeiro nem devolve seu histórico.
A produção é estrita; o consumo precisa conviver com a realidade
O documento distingue implementações que produzem cookies daquelas que os consomem. Produtores devem se limitar ao perfil bem-comportado. Consumidores precisam executar regras mais liberais para interoperar com servidores existentes. Essa diferença evita que a Web quebre, mas impede tratar a validação no produtor como previsão completa do estado no cliente.
Um verificador do serviço conhece o texto emitido. Ele não conhece a versão do mecanismo consumidor, a política efetiva, o contexto da resposta ou a decisão final do algoritmo. O modelo de armazenamento começa permitindo que o agente do usuário ignore por inteiro o cookie recebido.
Também não há um único dono operacional. A aplicação formula a instrução. A pilha HTTP transporta as linhas sem combiná-las indevidamente. O agente do usuário analisa e armazena. Usuário ou administrador pode restringir a política. O tipo de navegação, documento ou worker fornece o contexto posterior. A aplicação receptora, por fim, decide sessão, identidade e permissão.
Admitir significa construir outro objeto
O consumidor rejeita caracteres de controle proibidos, pares acima do limite, domínios incompatíveis e combinações inválidas de atributos. SameSite=None exige Secure. Nomes com __Secure- e __Host- só recebem as garantias esperadas quando cumprem seus requisitos, e o agente do usuário compara esses prefixos sem diferenciar maiúsculas de minúsculas para evitar uma garantia falsa criada pelo servidor.
A linha admitida ganha estado estruturado: nome, valor, prazo efetivo, domínio, caminho, criação, último acesso e flags de persistência, host exclusivo, canal seguro, HttpOnly e SameSite. Max-Age prevalece sobre Expires. A ausência de Domain cria escopo exclusivo do host. A substituição usa a combinação de nome, domínio e caminho, não apenas o nome.
Por isso, a resposta e o registro interno precisam de provas separadas. Uma impressão digital sem o segredo identifica a instrução. O veredito de admissão informa aceitação ou classe de recusa. O registro normalizado informa o escopo que realmente será testado. Sem esses três pontos, sintaxe, privacidade, substituição e escopo viram a mesma causa genérica.
Prazo máximo não é garantia de retenção
Expires e Max-Age expressam um teto pedido pelo servidor. O agente do usuário pode ajustar esse teto, aplicar seu limite de idade, retirar entradas expiradas e remover excesso quando ultrapassa limites por domínio ou no armazenamento total. A pessoa pode apagar dados, uma política pode encurtar a retenção e cookies não persistentes terminam quando acaba a sessão segundo a definição local.
Logo, uma data futura não comprova que o estado permanecerá até ela. Um evento de retenção é mais honesto: expiração efetiva, substituição, exclusão explícita, fim de sessão, pressão de quota ou limpeza por política. Em um dispositivo administrado, esse evento pode ser auditado dentro do próprio limite administrativo. Na Web pública, diagnósticos detalhados não devem criar uma janela para o inventário privado do usuário.
O RFC recomenda que servidores degradem de modo aceitável quando cookies não retornam, pois qualquer entrada pode ser removida. Essa recomendação transfere a pergunta de “quem descumpriu a data?” para “qual dependência a aplicação assumiu sem observar?”.
A seleção ocorre de novo a cada pedido
Uma entrada presente pode não ser elegível para uma requisição concreta. O modelo avalia URI, status de mesmo site e tipo de recuperação. Prazo, host ou domínio, caminho, canal seguro, HttpOnly e SameSite excluem linhas. A política do agente do usuário pode omitir o campo Cookie por completo.
O WHATWG Fetch integra cookies ao processamento de credenciais na Web. A interface document.cookie do HTML é uma API não HTTP e não atravessa a barreira HttpOnly. Documentos ancestrais, navegações, recargas e workers alteram como o “site para cookies” é calculado. A URL de destino sozinha não reproduz o contexto.
SameSite é uma defesa condicionada, não um voto do usuário. Strict, Lax, None e Default têm resultados diferentes conforme navegação e iniciador. O modo Lax-allowing-unsafe pode abrir uma janela curta para um cookie Default recente. O RFC o apresenta como defesa em profundidade, não como solução completa para CSRF, e observa que é o servidor que define o atributo.
O pedido devolve o par, não a justificativa
O servidor recebe nome e valor, não Domain, Path, SameSite, horário de criação ou motivo de seleção. Entradas com o mesmo nome e escopos diferentes podem coexistir. Sua ordem não deve ser usada como prioridade de negócio. HTTP/2 e HTTP/3 ainda podem transportar uma cadeia lógica em mais de uma linha de campo; isso muda a representação, não devolve a história.
Depois da chegada há decisões da aplicação. Qual parser tratou nomes repetidos? O identificador aponta para uma sessão viva? Houve rotação ou revogação? A identidade está autenticada? Ela pode executar esse método nesse recurso? Há prova anti-CSRF adequada? A semântica do HTTP organiza a mensagem, mas não concede a autorização local.
O RFC chama o cookie de autoridade ambiente. Um terceiro pode induzir o agente do usuário a fazer uma requisição e o cliente anexar a credencial sem que esse terceiro conheça o valor. Assim, presença não prova intenção. Ausência tampouco prova escolha consciente: pode ser escopo, política, expiração ou quota.
Um recibo em seis partes
Emissão registra URL da resposta, horário, linhas Set-Cookie em ordem e sem combinação, versão de configuração e impressão digital protegida. Admissão registra motor consumidor, versão de política, resultado da análise e classe de recusa. Armazenamento registra escopo normalizado, flags, prazo efetivo, alvo substituído e tratamento do horário de criação.
Retenção registra expiração, exclusão, fim de sessão, substituição ou expulsão quando houver visibilidade legítima. Recuperação liga URI, método, iniciador, contexto superior, cálculo SameSite e IDs opacos incluídos ou retidos. Aplicação separa parser, busca de sessão, autenticação, controle anti-CSRF, autorização e resultado final.
Esse recibo é uma proposta editorial de Daniel Kade, não uma exigência do RFC 10025. Ele não contém cookie, token portador nem segredo de sessão. A informação detalhada permanece no limite que tem legitimidade para observá-la.
É a prática coerente com a tese de Heng Lu sobre código em execução como prova primária. O espelho de políticas mostra quem decidiu cada transição, sem transformar intenção do servidor em fato do cliente. Esse cuidado preserva a realidade, e não a defesa de uma narrativa, como produto.
Fontes
- RFC 10025 — Cookies: HTTP State Management Mechanism
- Registro de publicação do RFC 10025
- RFC 6265 — HTTP State Management Mechanism
- RFC 9110 — HTTP Semantics
- RFC 9113 — HTTP/2
- RFC 9114 — HTTP/3
- WHATWG Fetch
- WHATWG HTML —
document.cookie - Public Suffix List
- Heng Lu — Why reality, not advocacy, is the product
- Heng Lu — Running Code Primary
- Heng Lu — The Policy Mirror
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
