A resposta referente a um artigo no SitePoint não está totalmente completa. Consulte a RFC 6265 (para ser justo, esta RFC foi lançada em 2011 depois que esta pergunta foi postada, que substitui a RFC 2965 anterior de 2000 e a RFC 2109 de 1997).
Seção 5.4 , subseção 2 tem o seguinte:
O agente do usuário DEVE classificar a lista de cookies na seguinte ordem:
- Cookies com caminhos mais longos são listados antes dos cookies com caminhos mais curtos.
NOTA: Nem todos os agentes de usuário classificam a lista de cookies nesta ordem, mas essa ordem reflete a prática comum quando este documento foi escrito e, historicamente, houve servidores que (erroneamente) dependiam dessa ordem.
Há também esta pequena joia na seção 4.2.2 :
... os servidores NÃO DEVEM confiar na ordem de serialização. Em particular, se o cabeçalho do Cookie contém dois cookies com o mesmo nome (por exemplo, que foram configurados com diferentes atributos de Caminho ou Domínio), os servidores NÃO DEVEM confiar na ordem em que esses cookies aparecem no cabeçalho.
Em seu cookie de solicitação de exemplo ( Cookie: a = 2; a = 1 ), observe que o cookie definido com o caminho / exemplo ( a = 2 ) tem um caminho mais longo do que aquele com o caminho / ( a = 1 ) e assim é enviado de volta para você primeiro na linha, o que corresponde à recomendação da especificação. Portanto, você está mais ou menos correto em sua suposição de que pode selecionar o primeiro valor.
Infelizmente, a linguagem usada nas RFCs é extremamente específica - o uso das palavras DEVE e NÃO DEVE introduzir ambigüidade nas RFCs. Eles indicam as convenções que devem ser seguidas, mas não precisam estar em conformidade com as especificações. Embora eu compreenda o RFC para isso muito bem, não fiz a pesquisa para ver o que os clientes do mundo real fazem; é possível que um ou mais navegadores ou outros softwares agindo como clientes HTTP não enviem o cookie de caminho mais longo (por exemplo: / exemplo ) primeiro no cabeçalho Cookie : .
Se você está em posição de controlar o valor do cookie e deseja tornar sua solução infalível, é melhor:
usando um nome de cookie diferente para substituir em certos caminhos, como:
- Set-cookie: a-global = 1; Caminho = /; Versão = 1
- Set-cookie: a-example = 2; Caminho = / exemplo; Versão = 1
armazenando o caminho de que você precisa no próprio valor do cookie:
- Set-cookie: a = 1 & path = /; Path = /; Versão = 1
- Set-cookie: a = 2 & path = / example; Path = / example; Versão = 1
Ambas as soluções alternativas requerem lógica adicional no servidor para selecionar o valor do cookie desejado, comparando o URL solicitado com a lista de cookies disponíveis. Não é muito bonito. É uma pena que o RFC não teve a previsão de exigir que um caminho mais longo substitua completamente um cookie por um caminho mais curto (por exemplo: em seu exemplo, você receberia Cookie: a = 2 apenas ).