Come gestire più cookie con lo stesso nome?

Supponiamo ad esempio che io abbia un'applicazione che invia le seguenti intestazioni HTTP da impostare sul cookie denominato "a":

Set-Cookie: a=1;Path=/;Version=1
Set-Cookie: a=2;Path=/example;Version=1

Se accedo /examplesul server sono validi entrambi i percorsi, quindi ho due cookie denominati "a"! Poiché il browser non invia alcuna informazione sul percorso, i due cookie non possono essere distinti.

Cookie: a=2; a=1

Come dovrebbe essere gestito questo caso? Scegli il primo? Creare un elenco con tutti i valori dei cookie? O un caso del genere dovrebbe essere considerato un errore dello sviluppatore?

Da questo articolo su SitePoint :

Se più cookie con lo stesso nome corrispondono a un determinato URI di richiesta, uno viene scelto dal browser.

Più specifico è il percorso, maggiore è la precedenza. Tuttavia, la precedenza basata su altri attributi, incluso il dominio, non è specificata e può variare tra i browser. Ciò significa che se hai impostato cookie con lo stesso nome su ".example.org" e "www.example.org", non puoi essere sicuro di quale verrà rispedito.

Modifica: queste informazioni del 2010 sembrano obsolete, sembra che i browser possano ora inviare più cookie in cambio, vedere la risposta di @Nate di seguito per i dettagli

La risposta che fa riferimento a un articolo su SitePoint non è del tutto completa. Si prega di consultare RFC 6265 (per essere onesti, questa RFC è stata rilasciata nel 2011 dopo che è stata pubblicata questa domanda, che sostituisce la precedente RFC 2965 del 2000 e RFC 2109 del 1997).

La sezione 5.4 , sottosezione 2 dice quanto segue:

L'agente utente DOVREBBE ordinare l'elenco dei cookie nel seguente ordine:

• I cookie con percorsi più lunghi sono elencati prima dei cookie con percorsi più brevi.

NOTA: Non tutti i programmi utente ordinano l'elenco dei cookie in questo ordine, ma questo ordine riflette la pratica comune quando questo documento è stato scritto e, storicamente, ci sono stati server che (erroneamente) dipendevano da questo ordine.

C'è anche questo piccolo gioiello nella sezione 4.2.2 :

... i server NON DOVREBBERO fare affidamento sull'ordine di serializzazione. In particolare, se l'intestazione del cookie contiene due cookie con lo stesso nome (ad esempio, che sono stati impostati con attributi di percorso o dominio diversi), i server NON DOVREBBERO fare affidamento sull'ordine in cui questi cookie appaiono nell'intestazione.

Nel tuo esempio di richiesta cookie ( Cookie: a = 2; a = 1 ) nota che il cookie impostato con il percorso / esempio ( a = 2 ) ha un percorso più lungo di quello con il percorso / ( a = 1 ) e quindi ti viene rimandato prima in linea, che corrisponde alla raccomandazione della specifica. Quindi sei più o meno corretto nell'ipotesi di poter selezionare il primo valore.

Sfortunatamente il linguaggio utilizzato nelle RFC è estremamente specifico: l'uso delle parole DOVREBBE e NON DOVREBBE introdurre ambiguità nelle RFC. Indicano le convenzioni che dovrebbero essere seguite, ma non devono essere conformi alle specifiche. Sebbene comprenda abbastanza bene l'RFC per questo, non ho fatto la ricerca per vedere cosa fanno i clienti del mondo reale; è possibile uno o più browser o altri software che agiscono come HTTP client non può inviare il cookie più lungo percorso (ad esempio: / esempio ) prima nel cookie: intestazione.

Se sei in grado di controllare il valore del cookie e vuoi rendere la tua soluzione infallibile, ti conviene:

1. utilizzando un nome di cookie diverso per eseguire l'override in determinati percorsi, ad esempio:

   • Set-cookie: a-global = 1; Path = /; Version = 1
   • Set-cookie: a-example = 2; Path = / example; Version = 1

2. memorizzare il percorso di cui hai bisogno nel valore del cookie stesso:

   • Set-cookie: a = 1 & path = /; Path = /; Version = 1
   • Set-cookie: a = 2 & path = / example; Path = / example; Version = 1

Entrambe queste soluzioni richiedono una logica aggiuntiva sul server per scegliere il valore del cookie desiderato, confrontando l'URL richiesto con l'elenco dei cookie disponibili. Non è troppo carino. E 'un peccato l'RFC non ha avuto l'accortezza di richiedere che un percorso più lungo sostituisce completamente un cookie con un percorso più breve (ad esempio: nel tuo esempio, si riceverà Cookie: a = 2 solo ).

Non c'è niente di sbagliato nell'avere più valori per lo stesso nome ... se li vuoi. Potresti persino incorporare un contesto aggiuntivo nel valore.

Se non lo fai, ovviamente nomi diversi sono una soluzione se vuoi entrambi i contesti.

L'alternativa è inviare lo stesso nome di cookie con lo stesso percorso (e dominio) anche dai percorsi più specifici. Quelle istruzioni sui cookie impostati sovrascriveranno il valore di quel cookie.

Ora che conosci la parte più importante (come funzionano) e che puoi realizzare ciò di cui hai bisogno in diversi modi, la mia risposta alla tua domanda è: questo è un problema degli sviluppatori.

Sono certamente a conoscenza di applicazioni che lo fanno ampiamente utilizzando più ID di sessione e sembrano funzionare in modo coerente. Tuttavia non so - e non ho intenzione di scoprirlo - se lo fanno perché il browser restituisce i cookie in un ordine coerente a seconda di quando sono stati impostati / per quale percorso sono stati impostati o se l'app cerca di abbinarli uno a una sessione esistente.

Consiglio vivamente di evitare questa pratica.

Tuttavia, se vuoi davvero sapere come i browser (e le app) gestiscono questo scenario, perché non costruire un banco di prova e provarlo.

Se usi il framework Java / Scala Riproduci: fai attenzione! Se una richiesta contiene più cookie con lo stesso nome, Play ne presenterà solo 1 al tuo codice.

Se è necessario distinguerli, è necessario assegnare loro valori chiave diversi.