Explicación de la cabecera If-Modified-Since

Inspirado en el artículo de Ricardo Galli “Reducción de Tráfico RSS” escribo este apunte, para explicar en resumidas cuentas la cabecera If-Modified-Since del protocolo HTTP.

Ricardo apunta a un artículo en inglés “Administrative: RSS rate limiting” en el cual explican lo siguiente:

En Diciembre del 2005, cerca de 17.000 direcciones IP únicas solicitaron el canal RSS más de un millón de veces en total.

El fichero XML enviado ocupa 7KB de tamaño, eso son 7GB de tráfico, casi la mitad del tráfico generado.

Muchos clientes al pedir los ficheros no envían la cabecera If-Modified-Since si así fuera como dicen en el artículo, la respuesta sería un 304 Not Modified (de 84 bytes). Es decir las posibilidades “de gastar ancho de banda” son:

1. Que el RSS se haya actualizado y nos lo bajemos (7KB)
2. Que el RSS NO se haya actualizado y nos lo bajemos (7KB)
3. Que el RSS NO se haya actualizado y recibamos un código 304 (84 bytes)

El primer caso y el tercero son correctos, el segundo no lo es, en un mundo perfecto todos los programas actuarían perfectamente entre ellos y estos detalles no pasarían.

Suponiendo en el caso anterior que “sólo” el 10% de las peticiones no requieran volver a bajar el RSS y lo hagan suponen un gasto de 700MB frente a los 8.2MB que deberían ser. Casi 90 veces más gasto por un detalle a priori insignificante.

Soluciones por el lado del servidor

Lo único que se puede hacer (aunque no poco) es comprobar que si el cliente envía la cabecera, está no sea ignorada (como por desgracia pasa en bastantes aplicaciones) como el caso va de los canales RSS usaré el RSS de SigT usando wget como ejemplo “manual” (los clientes RSS deben hacer esto automático):

 # Nos bajamos una vez el RSS
 # El parámetro -S es para ver cabeceras
 # La parte irrelevante la filtro:
 wget -S http://sigt.net/feed/

 Petición HTTP enviada, esperando respuesta...
 HTTP/1.1 200 OK
 Last-Modified: Wed, 22 Mar 2006 04:57:02 GMT

 'feed' guardado [86209]

¿Os fijasteis en el campo Last-Modified? si no varía con el del cliente el If-Modified-Since hará saltar el Error 304 Not Modified, vemos que hemos descargado 86209 bytes (84KB), si no enviamos la petición con la cabecera If-Modified-Since (o el servidor la ignorase) cada petición descargara esos 84KB.

¡Y algún usuario pone en su cliente RSS que se actualice cada minuto! Si un día no actualizamos, 85KB cada minuto son 122MB diarios de tráfico INUTIL, lo cual puede fastidiar a algunos webmasters.

Pero veamos que pasa si enviamos la dichosa cabecera:

 wget -S --header='If-Modified-Since: 
 Mon, 13 Mar 2006 17:36:53 +0000' http://sigt.net/feed/
 Petición HTTP enviada, esperando respuesta... 
 HTTP/1.1 304 Not Modified

 ERROR 304: Not Modified.

Un “Error 304″ hace que los navegadores web usen la copia en cache de la web o en los lectores RSS que advierta que el canal no contiene nuevas entradas.

Soluciones del lado cliente

1. Usar un cliente que haga uso del If-Modified-Since (según el artículo en inglés, un 50% lo hacen).
2. Si tu cliente favorito no lo usa pide al autor que lo implemente o sigue el punto siguiente.
3. No poner intervalos de actualización demasiado cortos, la mayoría de sitios NO se actualizan cada 5 minutos, un intervalo de 60 minutos es óptimo.

Comentarios cerrados