Tratamiento de cookies y cuando enviarlas

Actualización (2012): esta entrada fue publicada originalmente el 13 de mayo del 2007 (incluso conserva los comentarios de esa época).

Lo que inicialmente es una breve (apenas 3 párrafos) entrada sobre cuando es el mejor momento para enviar una cookie la he rehecho para tratar el tema de forma más amplia. Y el problema que generan las cookies con dominios con / sin www (también conocidos como "naked domains").

PD: "resucitando" entradas de hace 5 años, esto sí son habilidades de nigromancia y lo demás son chorradas.

Esta tarde he tenido una pequeña discusión bastante interesante aunque inicialmente (y aparentemente) estúpida: el mejor "momento" para enviar una "cookie" al navegador.

Introducción

Muchos usuarios "noveles" desconocen directamente lo que es o para qué sirve una cookie. En el caso de los usuarios de nivel medio y/o avanzado sin embargo es más común conocerlas e incluso tenerlas desactivadas en algunos sitios o con la opción "Aceptar la cookie cuando: [preguntar cada vez]" para ir haciéndose una bonita "lista blanca" con los sitios de los que aceptamos recibir cookies y una "lista negra" con los que no.

Bueno, en realidad no las conocen tanto, muchos desarrolladores web las desconocen o incluso las ignoran directamente.

Como decía esta opción al principio es un coñazo: cada página que entras te salta el aviso. Incluso 3 ó 4 avisos por sitio: uno por cada cookie. Pero este filtrado es útil para impedir por ejemplo almacenar "cookies rastreadores" como las de "Double Click" (usar las cookies para rastrear tus hábitos de navegación es lo que les dió mala fama de entrada).

Sin embargo las cookies son necesarias para conservar ciertos datos en el lado de cliente que sirvan en el lado de servidor: mantener sesiones de "login" activas (se pueden hacer "sesiones" con variables añadidas en la URL pero no es lo más recomendado) o guardar variables como por ejemplo las preferencias que haya elegido el usuario en sitios dinámicos.

El problema: aumento de ancho de banda

Sin embargo por cada petición HTTP (GET) que haga el usuario deberá mandar la(s) cookie(s) que tenga almacenados para ese dominio / subdominio. Concretamente TODO el sitio (dominio y subdominios) si las cookies están en el dominio "desnudo" (naked domain, por ejemplo http://sigt.net) o en el subdominio si se usan las www. (si pones una cookie para http://www.sigt.net entonces no se aplicará en peticiones HTTP a otros subdominios).

Inicialmente por ancho de banda es un asunto trivial: si una página realiza por visita 20 peticiones HTTP (pocas para sitios recargados o con muchos plugins y mucho si son sitios minimalistas) y envía una cookie de 125 bytes (por ejemplo) supone añadir apenas 2.44kB extras.

El problema es que es un efecto acumulativo: si tenemos 1000 visitas diarias subimos a (2.44 x 1000 x 30) 73.200kB mensuales (redondeando: 72 megabytes extras). Añade una sola petición HTTP más (una imagen por ejemplo) y aumentas el tráfico mensual 3.5 megabytes más sin contar lo que pese la imagen. En sitios de muchas visitas podemos hablar de gigabytes de ancho de banda gastados de forma estúpida en cookies inservibles y eso significa dinero tirado a la basura.

Pero es que, lo más gracioso, nadie envía 20 peticiones HTTP de contenidos HTML (que es lo que puede "necesitar" la cookie): ¡las imágenes, css, javascripts y otros contenidos no necesitan las cookies!¹.

Es precisamente por eso que se recomienda en plugins como YSlow separar los datos "multimedia" (imágenes, CSS, javascript, etcétera) en otro subdominio. Aunque como ya indicamos anteriormente si usamos un "naked domain" (dominio sin las www. es decir http://sigt.net) en lugar de uno con www. tendremos el problema que al poner una cookie esta se aplicará tanto al dominio (sigt.net) como a los subdominios (www.sigt.net, otrosubdominio.sigt.net, etcétera).

Si, por algún motivo, no podemos prescindir de un "naked domain" y añadir las www. para fijar las cookies al subdominio en lugar del dominio entero una solución sería utilizar otro dominio para el contenido estático: es la solución que usan sitios como Menéame o Facebook.

Una ventaja adicional de utilizar un dominio con las www. para las páginas web (sean estáticas o no) y un subdominio para el contenido 100% estático y/o "para descargar" (imágenes, css, vídeos, pdfs, etcétera) o la opción de usar dos dominios es que te permite simplificar las reglas de filtrado (anti-hotlinking), los robots.txt, cabeceras de cache-control, etcétera. No es la "mega-rehostia" pero hacer las mismas cosas de forma más simple siempre mola.

Vale y... ¿de qué iba eso de "cuando enviar las cookies"?

La pregunta original era: ¿cuándo es el mejor momento para "meter" una cookie? Pues sencillamente cuando haga falta. Si entro en una nueva web y ésta me intenta enviar una cookie el navegador me avisará de ello: si me sirve la dejaré entrar y si no, pues no.

Sin embargo una vez "denegada" si veo que el sitio me interesa (registrarme, comentar, etcétera) tengo que borrar la prohibición a mano. Todo por haberme enviado la cookie antes siquiera de necesitarla.

Apliquemos la teoría a un blog que, para comentar, envía una cookie que guardará la información de usuario para no rellenar los datos (no es un "registro"). Es decir, lo que hacen el 100% de blogs en WordPress: una vez has comentado, la cookie se encarga que el siguiente comentario no requiera introducir de nuevo el nombre / email / URL de tu sitio.

Podemos enviar la cookie en cuatro momentos:

1. Cuando se entra en la web.
2. Cuando se entra en el artículo a comentar.
3. Cuando se rellena el formulario.
4. La tercera opción al activar una casilla que diga "Recordar información de usuario".

La lista va claramente de peor a mejor: la última opción es la mejor mientras que la primera es el peor momento. La idea de fondo debería ser no molestar a los usuarios con cookies si no hace falta y elegir el mejor momento.

Esto también nos beneficia: si vemos el ejemplo del ancho de banda veremos que enviar cookies cuando no hace falta solamente servirá para aumentar el ancho de banda (que sí, que son apenas unos pocos megas al mes pero todo escala rápidamente hacía arriba).

Ejemplos "sangrantes" de mal uso

Hay una serie de prácticas que pueden ser consideradas "sangrantes" porque te envían cookies de forma incluso "abusiva" veamos algunos ejemplos:

• Algunos sitios de compras "te fulminan" a cookies. Las rechazas y luego no puedes ni registrarte. Cualquier sistema serio de compra debería poder utilizar sesiones sí o sí en caso de que las cookies estén desactivadas: de no hacerlo estás perdiendo una posible compra.

  La jugada se "puede rematar" si, además de lo anterior, ni siquiera informas que el motivo para no poder registrarse es debido a que las cookies son rechazadas. El usuario pensará que la página no funciona y seguramente realice la compra en una web de la competencia.

• Sitios que le permites la cookie en sitio.com y luego resulta que no funcionan porque en algún otro momento has rechazado la cookie desde www.sitio.com. Es uno de tantos problemas de no tener URLs canónicas.

• Empresas que para ofrecerte un servicio te intentan poner cookies rastreadores a saco desde cientos de subdominios como una página a la que entre (no me acuerdo la URL) que tenías que aceptar unas 30-40 cookies distintas. Obviamente nunca volví a entrar.

• Y por último un caso reciente (me está pasando ahora mismo mientras reescribo esta entrada en marzo del 2012): estoy suscrito a un foro que tiene una "característica" curiosa: envía una cookie por cada hilo que visitas.

  Lo divertido del asunto es que todos los servidores tienen un límite de cookies y tamaño de las mismas que aceptan por petición por lo que cuando has visitado suficientes hilos aparece este error:

  Bad Request
  
  Your browser sent a request that this server could not understand.
  Size of a request header field exceeds server limit.
  Cookie
  /n
  

  Y claro, cuando esto pasa te toca hacer limpieza de cookies de ese foro, de lo contrario pierdes la posibilidad de acceder a él.

Y así, algo tan "inocente" como una cookie se puede volver un coñazo para el usuario medio-avanzado por no saber elegir cuando ponerlas.

Un contra-argumento es que hay que pensar en el usuario doméstico y no en el medio-avanzado. Estoy totalmente en desacuerdo: al hacer una web hay que intentar pensar en todos. Incluso con los :censurado: que usan Internet Explorer (por mucho que me joda tener que poner hacks para este engendro de navegador). De lo contrario acabas haciendo cutre-webs de 2MB en Flash con un logo y tres tristes párrafos...