http - secure - que son los cookies de una pagina web
¿Cómo manejar múltiples cookies con el mismo nombre? (5)
Digamos, por ejemplo, que tenía una aplicación que enviaba los siguientes encabezados HTTP para configurar la cookie llamada "a":
Set-Cookie: a=1;Path=/;Version=1
Set-Cookie: a=2;Path=/example;Version=1
Si accedo /example en el servidor ambas rutas son válidas, ¡entonces tengo dos cookies llamadas "a"! Como el navegador no envía información de ruta, las dos cookies no se pueden distinguir.
Cookie: a=2; a=1
¿Cómo debe manejarse este caso? Elija el primero? Crear una lista con todos los valores de cookies? ¿O debería considerarse un caso como un error del desarrollador?
Ciertamente, estoy al tanto de las aplicaciones que hacen esto de manera extensiva usando múltiples identificadores de sesión, y parecen funcionar de manera consistente. Sin embargo, no sé, y no tengo intención de averiguarlo, si lo hacen porque el navegador devuelve las cookies en un orden coherente, dependiendo de cuándo se establecieron, de qué ruta se establecieron o si la aplicación intenta hacer coincidir cada una. uno a una sesión existente.
Recomiendo encarecidamente que se evite esta práctica.
Sin embargo, si realmente desea saber cómo los navegadores (y las aplicaciones) manejan este escenario, ¿por qué no construir un equipo de prueba y probarlo?
De este artículo en SitePoint :
Si varias cookies del mismo nombre coinciden con un URI de solicitud determinado, el navegador lo elige.
Cuanto más específico sea el camino, mayor será la precedencia. Sin embargo, la precedencia basada en otros atributos, incluido el dominio, no está especificada, y puede variar entre los navegadores. Esto significa que si ha configurado las cookies del mismo nombre contra ".example.org" y "www.example.org", no puede estar seguro de cuál será devuelto.
Editar: esta información de 2010 parece estar desactualizada, parece que los navegadores ahora pueden enviar múltiples cookies a cambio, vea la respuesta por @Nate a continuación para obtener más detalles.
La respuesta que hace referencia a un artículo sobre SitePoint no está del todo completa. Consulte RFC 6265 (para ser justos, este RFC se publicó en 2011 después de que se publicó esta pregunta, que sustituye a RFC 2965 anterior de 2000 y RFC 2109 de 1997).
La Sección 5.4, subsección 2 tiene esto para decir:
El agente de usuario DEBERÍA ordenar la lista de cookies en el siguiente orden:
- Las cookies con rutas más largas se enumeran antes que las cookies con rutas más cortas.
NOTA: No todos los agentes de usuario clasifican la lista de cookies en este orden, pero este orden refleja la práctica común cuando se escribió este documento, e históricamente, ha habido servidores que (erróneamente) dependían de este pedido.
También hay esta pequeña joya en la sección 4.2.2:
... los servidores NO DEBEN confiar en el orden de serialización. En particular, si el encabezado Cookie contiene dos cookies con el mismo nombre (por ejemplo, que se establecieron con diferentes atributos de Ruta o Dominio), los servidores NO DEBERÍAN confiar en el orden en que estas cookies aparecen en el encabezado.
En su cookie de solicitud de ejemplo ( Cookie: a = 2; a = 1 ) observe que la cookie establecida con la ruta / ejemplo ( a = 2 ) tiene una ruta más larga que la que tiene la ruta / ( a = 1 ) y por lo tanto se envía de vuelta a usted primero en línea, que coincide con la recomendación de la especificación. Por lo tanto, usted es más o menos correcto al suponer que puede seleccionar el primer valor.
Lamentablemente, el lenguaje utilizado en las RFC es extremadamente específico: el uso de las palabras DEBERÍA y NO DEBERÍA introducir ambigüedad en las RFC. Estos indican convenciones que se deben seguir, pero no se requiere que cumplan con la especificación. Si bien entiendo bastante bien el RFC para esto, no he hecho la investigación para ver qué hacen los clientes del mundo real; es posible que uno o más navegadores u otros softwares que actúen como clientes HTTP no puedan enviar la cookie de ruta más larga (ej .: / example ) primero en el encabezado Cookie : .
Si está en condiciones de controlar el valor de la cookie y desea que su solución sea infalible, es mejor que:
utilizar un nombre de cookie diferente para anular en ciertas rutas, como:
- Set-cookie: a-global = 1; Path = /; Version = 1
- Set-cookie: a-example = 2; Path = / example; Version = 1
almacenar la ruta que necesita en el valor de la cookie en sí:
- Set-cookie: a = 1 & path = /; Path = /; Version = 1
- Set-cookie: a = 2 & path = / example; Path = / example; Version = 1
Ambas soluciones requieren una lógica adicional en el servidor para elegir el valor de cookie deseado, comparando la URL solicitada con la lista de cookies disponibles. No es muy bonito. Es lamentable que el RFC no haya tenido la previsión de exigir que una ruta más larga anule por completo una cookie con una ruta más corta (por ejemplo: en su ejemplo, usted recibiría Cookie: a = 2 solamente ).
No tiene nada de malo tener múltiples valores para el mismo nombre ... si los quiere. Incluso podría incluir un contexto adicional en el valor.
Si no lo hace, entonces, por supuesto, los diferentes nombres son una solución si desea ambos contextos.
La alternativa es enviar el mismo nombre de cookie con la misma ruta (y dominio) incluso desde las rutas más específicas. Esas instrucciones de cookies configuradas sobrescribirán el valor de esa cookie.
Ahora que conoce la parte más importante (cómo funcionan) y que puede lograr lo que necesita de diferentes maneras, mi respuesta a su pregunta es: este es un problema para el desarrollador.
Si necesita distinguirlos, debe darles valores clave diferentes.