ETag HTTP

La ETag o etiqueta de entidad es parte de HTTP, el protocolo para la World Wide Web. Es uno de varios mecanismos que proporciona HTTP para la validación de caché web, lo que permite que un cliente realice solicitudes condicionales. Este mecanismo permite que las cachés sean más eficientes y ahorra ancho de banda, ya que un servidor web no necesita enviar una respuesta completa si el contenido no ha cambiado. Las ETags también se pueden usar para el control de concurrencia optimista para ayudar a evitar que las actualizaciones simultáneas de un recurso se sobrescriban entre sí.

Una 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 la representación del recurso en esa URL cambia alguna vez, se asigna una ETag nueva y diferente. Usadas de esta manera, las ETags son similares a las huellas dactilares y se pueden comparar rápidamente para determinar si dos representaciones de un recurso son iguales.

Generación de etiquetas electrónicas

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

Los métodos comunes de generación de ETag incluyen el uso de una función hash resistente a colisiones del contenido del recurso, un hash de la marca de tiempo de la última modificación o incluso solo un número de revisión.

Para evitar el uso de datos de caché obsoletos, los métodos utilizados para generar ETag deben garantizar (en la medida de lo posible) que cada ETag sea único. Sin embargo, una función de generación de ETag podría considerarse "utilizable", si se puede demostrar (matemáticamente) que la duplicación de ETag sería "aceptablemente rara", incluso si pudiera o pudiera ocurrir.

RFC-7232 establece explícitamente que ETags debe ser consciente de la codificación de contenido, por ejemplo

ETag: "123-a" – sin codificación de contenido
ETag: "123-b" – para codificación de contenido: gzip

Se sabe que algunas funciones de suma de comprobación anteriores que eran más débiles que CRC32 o CRC64 sufren problemas de colisión de hash. Por lo tanto, no eran buenos candidatos para su uso en la generación de ETag.

Validación fuerte y débil

El mecanismo ETag admite tanto la validación fuerte como la débil. Se distinguen por la presencia de una "W/" inicial en el identificador de ETag, como:

"123456789": un fuerte validador de ETag
W/"123456789": un validador de ETag débil

Una coincidencia de ETag de validación sólida indica que el contenido de las dos representaciones de recursos es idéntico byte a byte y que todos los demás campos de entidad (como Contenido-Idioma) tampoco se modifican. Las ETag fuertes permiten el almacenamiento en caché y el reensamblaje de respuestas parciales, como con las solicitudes de rango de bytes.

Una coincidencia de ETag de validación débil solo indica que las dos representaciones son semánticamente equivalentes, lo que significa que para fines prácticos son intercambiables y que se pueden usar copias almacenadas en caché. Sin embargo, las representaciones de recursos no son necesariamente idénticas byte por byte y, por lo tanto, las ETag débiles no son adecuadas para solicitudes de rango de bytes. Las ETag débiles pueden ser útiles para casos en los que no es práctico generar ETag fuertes para un servidor web, como con contenido generado dinámicamente.

Uso típico

En el uso típico, cuando se recupera una URL, el servidor web devolverá la representación actual del recurso junto con su valor ETag correspondiente, que se coloca en un campo "ETag" del encabezado de respuesta HTTP:

Etiqueta electrónica: "686897696a7c876b7e"

El cliente puede entonces decidir almacenar en caché la representación, junto con su ETag. Más tarde, si el cliente desea recuperar el mismo recurso de URL nuevamente, primero determinará si la versión almacenada en caché local de la URL ha caducado (a través de los encabezados Cache-Control y Expire). Si la URL no ha caducado, recuperará el recurso almacenado en caché localmente. Si se determina que la URL ha caducado (es obsoleta), el cliente enviará una solicitud al servidor que incluye su copia previamente guardada de la ETag en el campo "Si no coincide".

Si no coincide: "686897696a7c876b7e"

En esta solicitud posterior, el servidor ahora puede comparar la ETag del cliente con la ETag de la versión actual del recurso. Si los valores de ETag coinciden, lo que significa que el recurso no ha cambiado, el servidor puede enviar una respuesta muy breve con un estado HTTP 304 No modificado. El estado 304 le dice al cliente que su versión en caché sigue siendo buena y que debería usarla.

Sin embargo, si los valores de ETag no coinciden, lo que significa que es probable que el recurso haya cambiado, se devuelve una respuesta completa que incluye el contenido del recurso, como si no se estuvieran utilizando ETags. En este caso, el cliente puede decidir reemplazar su versión previamente almacenada en caché con la representación recién devuelta del recurso y la nueva ETag.

Los valores de ETag se pueden usar en sistemas de monitoreo de páginas web. El monitoreo eficiente de la página web se ve obstaculizado por el hecho de que la mayoría de los sitios web no configuran los encabezados ETag para las páginas web. Cuando un monitor web no tiene indicios de si el contenido web ha cambiado, todo el contenido debe recuperarse y analizarse utilizando recursos informáticos tanto para el editor como para el suscriptor.

Detección de ETag no coincidente

En ocasiones, un sitio web con errores puede fallar al actualizar la ETag después de que se haya actualizado su recurso semántico. A partir de 2019, un ejemplo de un sitio prominente de este tipo es export.arxiv.org. Como resultado, la respuesta devuelta incorrectamente es el estado 304 y el cliente no puede recuperar el recurso actualizado. Para detectar un sitio web con errores:

• Guarde en caché la respuesta y la ETag, suponiendo que haya una ETag y que la respuesta no se anuló.
• Para una solicitud posterior que hubiera incluido el encabezado If-None-Match, no envíe este encabezado con una probabilidad aleatoria del 20%. Con esta probabilidad, si la respuesta devuelve un contenido alterado pero el mismo ETag que el que se almacenó en caché anteriormente, marque el sitio web como defectuoso y deshabilite el almacenamiento en caché de ETag. Como recordatorio, para un ETag fuerte, la comparación de contenido puede ser byte por byte, mientras que, para un ETag débil, verificaría solo la equivalencia semántica.

Seguimiento mediante ETags

Las ETags se pueden usar para rastrear usuarios únicos, ya que los usuarios conscientes de la privacidad eliminan cada vez más las cookies HTTP. En julio de 2011, Ashkan Soltani y un equipo de investigadores de UC Berkeley informaron que varios sitios web, incluido Hulu, estaban usando ETags con fines de seguimiento. Hulu y KISSmetrics dejaron de "reaparecer" a partir del 29 de julio de 2011, ya 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 involucran parcialmente el uso de ETags.

Debido a que el navegador almacena en caché los ETag y los devuelve con solicitudes posteriores del mismo recurso, un servidor de seguimiento puede simplemente repetir cualquier ETag recibido del navegador para garantizar que un ETag asignado persista indefinidamente (de manera similar a las cookies persistentes). Los encabezados de almacenamiento en caché adicionales también pueden mejorar la conservación de los datos de ETag.

Las ETags pueden desecharse borrando la memoria caché del navegador (las implementaciones varían).