¿Cómo funcionan los dominios de cookies del navegador?

Debido a problemas extraños de cookies de dominio / subdominio que recibo, me gustaría saber cómo los navegadores manejan las cookies. Si lo hacen de diferentes maneras, también sería bueno conocer las diferencias.

En otras palabras, cuando un navegador recibe una cookie, esa cookie PUEDE tener un dominio y una ruta adjunta. O no, en cuyo caso el navegador probablemente sustituya algunos valores predeterminados por ellos. Pregunta 1: ¿qué son?

Más tarde, cuando el navegador está a punto de realizar una solicitud, verifica sus cookies y filtra las que debe enviar para esa solicitud. Lo hace comparándolos con la ruta y el dominio de las solicitudes. Pregunta 2: ¿cuáles son las reglas de coincidencia?


Adicional:

La razón por la que estoy preguntando esto es porque estoy interesado en algunos casos extremos. Me gusta:

  • ¿Habrá una cookie para .example.com disponible para www.example.com ?
  • ¿Habrá una cookie para .example.com disponible para example.com ?
  • ¿Habrá una cookie para example.com disponible para www.example.com ?
  • ¿Estará disponible una cookie de example.com para anotherexample.com ?
  • ¿Podrá www.example.com establecer cookies para example.com ?
  • ¿Podrá www.example.com establecer cookies para www2.example.com ?
  • ¿Podrá www.example.com establecer cookies para .com ?
  • Etc.

Añadido 2:

Además, ¿alguien podría sugerir cómo debo configurar una cookie para que:

  • Se puede configurar ya sea en www.example.com o example.com ;
  • Es accesible tanto en www.example.com como en example.com .

Aunque existe el RFC 2965 ( Set-Cookie2 , que ya había quedado obsoleto RFC 2109 ) que debería definir la cookie hoy en día, la mayoría de los navegadores no lo admiten por completo, pero solo cumplen con la especificación original de Netscape .

Existe una distinción entre el valor del atributo del Dominio y el dominio efectivo: el primero se toma del campo del encabezado Set-Cookie y el último es la interpretación de ese valor del atributo. De acuerdo con el RFC 2965, debe aplicarse lo siguiente:

  • Si el campo del encabezado Set-Cookie no tiene un atributo de Dominio , el dominio efectivo es el dominio de la solicitud.
  • Si hay un atributo de dominio presente, su valor se usará como dominio efectivo (si el valor no comienza con a, será agregado por el cliente).

Al tener el dominio efectivo, también debe coincidir con el dominio solicitado actual para establecerse; de lo contrario, la cookie será revisada. La misma regla se aplica para elegir las cookies que se enviarán en una solicitud.


Al asignar este conocimiento a sus preguntas, debe aplicarse lo siguiente:

  • Cookie con Domain=.example.com estará disponible para http://www.example.com
  • Cookie con Domain=.example.com estará disponible para example.com
  • Cookie con Domain=example.com se convertirá en .example.com y, por lo tanto , también estará disponible para http://www.example.com
  • Cookie con Domain=example.com no estará disponible para anotherexample.com
  • http://www.example.com podrá establecer cookies para example.com
  • http://www.example.com no podrá establecer cookies para www2.example.com
  • http://www.example.com no podrá establecer cookies para .com

Y para establecer y leer una cookie para / por http://www.example.com y example.com , .www.example.com para .www.example.com y .example.com respectivamente. Pero el primero ( .www.example.com ) solo será accesible para otros dominios debajo de ese dominio (por ejemplo, foo.www.example.com o bar.www.example.com ) donde también se puede acceder a .example.com por cualquier otro dominio debajo de example.com (ej. foo.example.com o bar.example.com ).

Las respuestas anteriores están un poco desactualizadas.

RFC 6265 fue publicado en 2011, basado en el consenso del navegador en ese momento. Desde entonces, ha habido algunas complicaciones con los dominios públicos de sufijos. Escribí un artículo explicando la situación actual: http://bayou.io/draft/cookie.domain.html

Para resumir, reglas a seguir con respecto al dominio de cookies:

  • El dominio de origen de una cookie es el dominio de la solicitud de origen.

  • Si el dominio de origen es una IP, el atributo de dominio de la cookie no se debe establecer.

  • Si el atributo de dominio de una cookie no está establecido, la cookie solo se aplica a su dominio de origen.

  • Si se establece un atributo de dominio de cookie,

    • la cookie es aplicable a ese dominio y a todos sus subdominios;
    • el dominio de la cookie debe ser el mismo o el padre del dominio de origen
    • el dominio de la cookie no debe ser un TLD, un sufijo público o un padre de un sufijo público.

Se puede deducir que una cookie siempre es aplicable a su dominio de origen.

El dominio de las cookies no debe tener un punto .foo.com , como en .foo.com , simplemente use foo.com

Como ejemplo,

  • xyzcom puede establecer un dominio de cookies para sí mismo o sus padres: xyzcom , yzcom , yzcom . Pero no com , que es un sufijo público.
  • una cookie con dominio = yzcom es aplicable a yzcom , xyzcom , axyzcom , etc.

Ejemplos de sufijos públicos: com , edu , uk , co.uk , blogspot.com , compute.amazonaws.com

Para una extensa revisión de cobertura, los contenidos de RFC2965 . Por supuesto, eso no significa necesariamente que todos los navegadores se comporten exactamente de la misma manera.

Sin embargo, en general, la regla para la ruta predeterminada si no se especifica en la cookie es la ruta en la URL desde la que llegó el encabezado Set-Cookie. De manera similar, el valor predeterminado para el Dominio es el nombre de host completo en la URL desde la cual llegó Set-Cookie.

Las reglas coincidentes para el dominio requieren el dominio de la cookie para que coincida con el host al que se realiza la solicitud. La cookie puede especificar una coincidencia de dominio más amplia con include *. en el atributo de dominio de Set-Cookie (esta área que los navegadores pueden variar). Coincidir con la ruta (suponiendo que el dominio coincida) es una cuestión sencilla de que la ruta solicitada debe estar dentro de la ruta especificada en la cookie. Normalmente, las cookies de sesión se establecen con path = / o path = / applicationName / para que la cookie esté disponible para todas las solicitudes en la aplicación.


Respuesta a Agregado:

  • ¿Habrá una cookie para .example.com disponible para http://www.example.com?
  • ¿Habrá una cookie para .example.com disponible para example.com? No sé
  • ¿Habrá una cookie para example.com disponible para http://www.example.com? No debería pero … *
  • ¿Estará disponible una cookie de example.com para anotherexample.com? No
  • ¿Podrá http://www.example.com establecer cookies para example.com?
  • ¿Podrá http://www.example.com establecer cookies para www2.example.com? No (excepto a través de .example.com)
  • ¿Podrá http://www.example.com establecer cookies para .com? No (No se puede configurar una cookie en el espacio de nombres ni se puede establecer una para algo como .co.uk) .

* No puedo probar esto en este momento, pero tengo una idea de que al menos IE7 / 6 trataría la ruta example.com como si fuera .example.com .

El último (el tercero para ser exactamente) RFC para este problema es RFC-6265 (obsoletos RFC-2965 que a su vez obsoletos RFC-2109).

De acuerdo con esto, si el servidor omite el atributo de Dominio, el agente de usuario devolverá la cookie solo al servidor de origen (el servidor en el que reside un recurso dado). Pero también advierte que algunos agentes de usuario existentes tratan un atributo de dominio ausente como si el atributo de dominio estuviera presente y contuviera el nombre de host actual (por ejemplo, si example.com devuelve un encabezado Set-Cookie sin un atributo de dominio, estos agentes de usuario envíe erróneamente la cookie a http://www.example.com también).

Cuando se ha especificado el atributo de Dominio, se tratará como un nombre de dominio completo (si hay un punto de referencia en el atributo, se ignorará). El servidor debe coincidir con el dominio especificado en el atributo (tener exactamente el mismo nombre de dominio o ser un subdominio del mismo) para obtener esta cookie. Más exactamente, especificó aquí .

Así por ejemplo:

  • El atributo de cookie Domain=.example.com es equivalente a Domain=example.com
  • las cookies con dichos atributos de dominio estarán disponibles para example.com y http://www.example.com
  • las cookies con tales atributos de Dominio no estarán disponibles para otro-ejemplo.com
  • la especificación de un atributo de cookie como Domain=www.example.com cerrará el camino para www4.example.com

PD: la coma al final en el atributo de dominio hará que el agente de usuario ignore el atributo = (

Existen reglas que determinan si un navegador aceptará el encabezado de respuesta del conjunto de encabezados (escritura de cookies del lado del servidor), unas reglas / interpretaciones ligeramente diferentes para el conjunto de cookies utilizando Javascript (no he probado VBScript).

Luego, existen reglas que determinan si el navegador enviará una cookie junto con la solicitud de la página.

Existen diferencias entre los principales motores de búsqueda de cómo se manejan las coincidencias de dominio y cómo se interpretan los parámetros en los valores de ruta. Puede encontrar evidencia empírica en el artículo Cómo los diferentes navegadores manejan las cookies de forma diferente

Se sabe que los RFCs no reflejan la realidad.

Mejor verifique draft-ietf-httpstate-cookie , trabajo en progreso.

Me sorprendió leer la sección 3.3.2 sobre el rechazo de cookies:

http://tools.ietf.org/html/rfc2965

Eso dice que un navegador debe rechazar una cookie de xyzcom con el dominio .z.com, porque ‘xy’ contiene un punto. Entonces, a menos que esté malinterpretando el RFC y / o las preguntas anteriores, podría haber preguntas agregadas:

¿Habrá una cookie para .example.com disponible para http://www.yyy.example.com? No.

¿Una cookie configurada por el servidor de origen http://www.yyy.example.com, con el dominio .example.com, tendrá su valor enviado por el agente de usuario a xxx.example.com? No.

¿Podrá www.example.com establecer cookies para .com ?

No, pero example.com.fr puede establecer una cookie para example2.com.fr . Firefox protege contra esto manteniendo una lista de TLD: http://securitylabs.websense.com/content/Blogs/3108.aspx

Aparentemente, Internet Explorer no permite que los dominios de dos letras establezcan cookies, lo que supongo explica por qué o2.ie simplemente redirige a o2online.ie . A menudo me lo había preguntado.