son que las habilitar google funcionan como chrome celular borrar activar http cookies path dns rules

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



que es cookies de google (8)

Debido a los problemas extraños de cookies de dominio / subdominio que estoy recibiendo, me gustaría saber cómo los navegadores manejan las cookies. Si lo hacen de diferentes maneras, también sería bueno saber 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 los sustituya por defecto. Pregunta 1: ¿Qué son?

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

Adicional:

La razón por la que pregunto esto es porque me interesan algunos casos de vanguardia. Me gusta:

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

Agregado 2:

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

  • Se puede establecer en www.example.com o example.com ;
  • Es accesible por www.example.com y example.com .

¿Podrá www.example.com configurar 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

Al parecer, Internet Explorer no permite que los dominios de dos letras establezcan cookies, lo que supongo que explica por qué o2.ie simplemente redirige a o2online.ie . A menudo me preguntaba eso.

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

Existe una distinción entre el valor del atributo Dominio y el dominio efectivo: el primero se toma del campo de encabezado Set-Cookie y el último es la interpretación de ese valor de atributo. De acuerdo con el RFC 2965, se debe aplicar 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 un . Será agregado por el cliente).

Tener el dominio efectivo también debe domain-match el dominio solicitado actual para que se establezca; De lo contrario la cookie será revisada. La misma regla se aplica para elegir las cookies que se enviarán en una solicitud.

Asignando este conocimiento a sus preguntas, se debe aplicar lo siguiente:

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

Y para configurar y leer una cookie para / por 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 que se encuentren por debajo de ese dominio (por ejemplo, foo.www.ejemplo.com o bar.www.ejemplo.com ), donde también se puede acceder a .example.com desde cualquier otro dominio debajo de example.com (por ejemplo, foo.example.com o bar.example.com ).

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

De acuerdo con esto, si el servidor omite el atributo Dominio, el agente de usuario devolverá la cookie solo al servidor de origen (el servidor en el que reside un recurso determinado). 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 erróneamente envíe la cookie a www.example.com también).

Cuando se haya especificado el atributo de dominio, se tratará como un nombre de dominio completo (si hay un punto inicial en el atributo, se ignorará). El servidor debe coincidir con el dominio especificado en el atributo (debe tener exactamente el mismo nombre de dominio o para ser un subdominio) para obtener esta cookie. Más exactamente se domain-match .

Así por ejemplo:

  • 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 www.example.com
  • las cookies con dichos atributos de dominio no estarán disponibles para otro-example.com
  • especificar un atributo de cookie como Domain=www.example.com cerrará el camino para www4.example.com

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

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

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

Hay 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 alguna evidencia empírica en el artículo Cómo diferentes navegadores manejan las cookies de manera diferente

Las respuestas anteriores son un poco anticuadas.

RFC 6265 se publicó en 2011, según el consenso del navegador en ese momento. Desde entonces, ha habido algunas complicaciones con los dominios públicos de sufijos. He escrito un artículo que explica 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, no se debe establecer el atributo de dominio de la cookie.

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

  • Si se establece el atributo de dominio de una cookie,

    • la cookie es aplicable a ese dominio y todos sus subdominios;
    • el dominio de la cookie debe ser el mismo que el 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 cookie para sí mismo o para los 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

Me sorprendió leer la sección 3.3.2 sobre rechazar 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 www.yyy.example.com? No.

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

Para una cobertura extensa revise 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 ninguna 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 completo del host en la URL desde la cual llegó el Set-Cookie.

Las reglas de coincidencia para el dominio requieren que el dominio de la cookie coincida con el host al que se realiza la solicitud. La cookie puede especificar una coincidencia de dominio más amplia mediante include *. en el atributo de dominio de Set-Cookie (esta área en la que los navegadores pueden variar). Hacer coincidir la ruta (suponiendo que las coincidencias del dominio) es una cuestión simple de que la ruta solicitada debe estar dentro de la ruta especificada en la cookie. Normalmente, las cookies de sesión se configuran con ruta = / o ruta = / 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 www.example.com? Sí
  • ¿Estará disponible una cookie para .example.com para example.com? No se
  • ¿Habrá una cookie para example.com disponible para www.example.com? No debería, pero ... *
  • ¿Estará disponible una cookie para example.com para anotherexample.com? No
  • ¿Podrá www.example.com configurar cookies para example.com? Sí
  • ¿Podrá www.example.com configurar cookies para www2.example.com? No (Excepto a través de .example.com)
  • ¿Podrá www.example.com configurar cookies para .com? No (no se puede establecer una cookie tan arriba en el espacio de nombres ni se puede configurar una para algo como .co.uk) .

* No puedo probar esto ahora mismo pero tengo el indicio de que al menos IE7 / 6 trataría la ruta example.com como si fuera .example.com .