HTTP ETag

ETag o entity tag (etiqueta de entidad en español) es parte de HTTP, el protocolo para la World Wide Web. Es uno de los varios mecanismos que HTTP proporciona para la validación de caché web, y que permite a un cliente realizar peticiones condicionales. Esto permite que las cachés sean más eficientes y ahorra ancho de banda, puesto que un servidor web no necesita enviar una respuesta completa si el contenido no ha cambiado. Los ETags también pueden ser usados para el control de concurrencia optimista,​ como una manera de ayudar a prevenir que actualizaciones simultáneas de un recurso se sobrescriban entre sí.

Un ETag es un identificador opaco asignado por un servidor web a una versión específica de un recurso que se encuentra en una URL. Si el contenido del recurso en esa URL cambia, se le asigna un nuevo y diferente ETag. Usado de esta manera los ETags son similares a las huellas digitales, y se puede comparar de forma rápida para determinar si dos versiones de un recurso son la misma. Comparar ETags sólo tiene sentido con respecto a una URL - los ETags para los recursos obtenidos a partir de diferentes URLs pueden o no ser iguales, por lo que no se puede inferir ningún significado de su comparación.

Riesgos de implementación

El uso de ETags en la cabecera HTTP es opcional (no es obligatorio como ocurre con otros campos de la cabecera HTTP/1.1). El método por el cual se generan los ETags nunca se ha especificado en la especificación HTTP.

Los métodos comunes de generación de ETags incluyen el uso de una función hash resistente a colisiones del contenido del recurso, un hash del timestamp de última modificación, o incluso simplemente un número de revisión.

Con el fin de evitar el uso de datos de caché obsoletos, los métodos utilizados para generar ETags deben garantizar (tanto como sea práctico) que cada ETag es único. Sin embargo, una función de generación de ETags podría ser juzgada como "utilizable" si se puede demostrar (matemáticamente) que la duplicación de ETags sería "aceptablemente rara", aunque pudiese ocurrir.

En algunas funciones checksum, como CRC32 y CRC64, se sabe que sufren de este problema de colisión de hash. Debido a esto no son buenas candidatas para su uso en la generación de ETags.

Validación fuerte y débil

El mecanismo de ETag soporta a la vez validación fuerte y débil. Se distinguen por la presencia de un "W/" inicial en el identificador de ETag, como:

"123456789"   -- Un validador fuerte de ETag
W/"123456789"  -- Un validador débil de ETag

Una coincidencia de ETag fuertemente validado indica que el contenido de los dos recursos es byte por byte idéntico y que todos los demás campos de entidad (como Content-Language) tampoco están modificados. Los ETags fuertes permiten el almacenamiento en caché y reensamblaje de respuestas parciales, como con las solicitudes de intervalo de bytes.

Una coincidencia de ETag débilmente validada sólo indica que los dos recursos son semánticamente equivalentes, lo que significa que a efectos prácticos son intercambiables y que las copias en caché pueden ser utilizadas. Sin embargo, los recursos no son necesariamente byte por byte idénticos y, por lo tanto, los ETags débiles no son adecuados para las solicitudes de intervalo de bytes. Los ETags débiles pueden ser útiles para los casos en los que la generación de ETags fuertes no es práctica para un servidor web, como es el caso del contenido generado dinámicamente.

Uso típico

En un uso típico, cuando se recupera un URL, el servidor web devolverá el recurso junto con su valor ETag correspondiente, que se coloca en un campo HTTP "ETag":

ETag: "686897696a7c876b7e"

El cliente puede decidir entonces almacenar en caché el recurso, junto con su ETag. Más tarde, si el cliente quiere recuperar el mismo URL de nuevo, se enviará una copia previamente guardada del ETag junto con la solicitud en un campo "If-None-Match".

If-None-Match: "686897696a7c876b7e"

En esta solicitud posterior, el servidor puede ahora comparar el ETag del cliente con el ETag para la versión actual del recurso. Si los valores ETag coinciden, lo que significa que el recurso no ha cambiado, entonces el servidor puede enviar de vuelta una respuesta muy corta con un estado HTTP 304 Not Modified. El estado 304 indica al cliente que su versión en caché sigue siendo buena y que debería usar esa.

Sin embargo, si los valores ETag no coinciden, es decir, el recurso probablemente ha cambiado, entonces se devuelve una respuesta completa que incluya el contenido del recurso, como si no se estuviesen utilizando ETags. En este caso, el cliente puede optar por sustituir su versión previamente en caché con el recurso recién recuperado y el nuevo ETag.

Los valores ETag se pueden utilizar en sistemas de monitorización de páginas web. La monitorización de páginas web eficiente se ve obstaculizada por el hecho de que la mayoría de sitios web no establecen las cabeceras ETag para sus páginas web. Cuando un monitor web no tiene indicios de si el contenido web se ha cambiado todo el contenido tiene que ser recuperada, y analizado, utilizando recursos de computación, tanto del publicador como del suscriptor.

Seguimiento utilizando ETags

Los ETags se pueden utilizar para realizar un seguimiento de usuarios únicos,​ puesto que las cookies HTTP son borradas cada vez más por los usuarios preocupados por su privacidad. En julio de 2011, Ashkan Soltani y un equipo de investigadores de UC Berkeley informaron que un número de sitios web, incluyendo Hulu.com, estaban usando ETags con fines de seguimiento.​ Hulu y KISSmetrics han dejado el "respawning" a fecha de 29 de julio de 2011,​ puesto que KISSmetrics y más de 20 de sus clientes se enfrentan a una demanda colectiva por el uso de cookies de seguimiento "imborrables" que implican en parte el uso de ETags.​

Debido a que los ETags se almacenan en caché por el navegador, y son recuperados con las solicitudes posteriores para el mismo recurso, un servidor de seguimiento simplemente puede repetir cualquier ETag recibida desde el navegador para asegurar que un ETag asignado persiste indefinidamente (de forma similar a las cookies persistentes). Las cabeceras adicionales de almacenamiento en caché también pueden mejorar la conservación de los datos ETag.​

Los ETags pueden ser desechables limpiando la caché del navegador (las implementaciones varían).

Referencias

• ETag in HTTP/1.1 specification
• Concerning Etags and Datestamps by Lars R. Clausen (2004)

Enlaces externos

• Apache HTTP Server Documentation - FileETag Directive
• Editing the Web: Detecting the Lost Update Problem Using Unreserved Checkout, W3C Note, 10 May 1999.
• Old SQUID Development projects - ETag support Archivado el 23 de septiembre de 2012 en Wayback Machine. (completed in 2001)
• Using ETags to Reduce Bandwidth & Workload with Spring & Hibernate
• Live demo of zombie cookie using ETags

• Datos: Q282558