La etiqueta de entidad o ETag 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 , lo que permite a un cliente realizar 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 ETag también se pueden utilizar para el control de concurrencia optimista [1] 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 . [2] Si la representación del recurso en esa URL cambia alguna vez, se asigna una ETag nueva y diferente. Utilizadas de esta manera, las ETags son similares a las huellas digitales y se pueden comparar rápidamente para determinar si dos representaciones de un recurso son iguales.
El uso de ETags en el encabezado HTTP es opcional (no obligatorio como sucede con otros campos del encabezado HTTP 1.1). El método por el cual se generan las 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 ETags deben garantizar (en la medida de lo posible) que cada ETag sea única. Sin embargo, una función de generación de ETags podría considerarse "utilizable" si se puede demostrar (matemáticamente) que la duplicación de ETags sería "aceptablemente rara", incluso si pudiera o debiera ocurrir.
RFC-7232 establece explícitamente que las ETags deben tener en cuenta la codificación del contenido , por ejemplo
ETag: "123-a" – sin codificación de contenidoETag: "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 sufrían problemas de colisión de hash, por lo que no eran buenas candidatas para su uso en la generación de ETag.
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 ETag, como:
"123456789": un validador de ETag potenteW/"123456789" – Un validador ETag débil
Una coincidencia de ETag con una 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 Content-Language) también permanecen inalterados. Las ETags sólidas permiten el almacenamiento en caché y el reensamblado de respuestas parciales, como en el caso de las solicitudes de rango de bytes .
Una coincidencia de ETag con una validación débil solo indica que las dos representaciones son semánticamente equivalentes , lo que significa que, a efectos prácticos, son intercambiables y que se pueden utilizar copias en caché. Sin embargo, las representaciones de recursos no son necesariamente idénticas byte a 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 que un servidor web genere ETags fuertes, como en el caso del contenido generado dinámicamente .
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 URL nuevamente, primero determinará si la versión almacenada en caché localmente de la URL ha expirado (a través de los encabezados Cache-Control y Expire). Si la URL no ha expirado, recuperará el recurso almacenado en caché localmente. Si se determina que la URL ha expirado (está obsoleta ), el cliente enviará una solicitud al servidor que incluye su copia previamente guardada de la ETag en el campo "If-None-Match". [2]
Si no hay coincidencia: "686897696a7c876b7e"
En esta solicitud posterior, el servidor puede comparar la ETag del cliente con la ETag de la versión actual del recurso. Si los valores de la ETag coinciden, es decir, 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 indica al cliente que su versión en caché aún es válida 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 almacenada previamente en caché con la nueva representación del recurso y la nueva ETag.
Los valores ETag se pueden utilizar en sistemas de monitorización de páginas web . La monitorización eficiente de páginas web se ve obstaculizada por el hecho de que la mayoría de los sitios web no establecen los encabezados ETag para las páginas web. Cuando un monitor web no tiene pistas sobre si se ha modificado el contenido web, todo el contenido debe recuperarse y analizarse utilizando recursos informáticos tanto del editor como del suscriptor.
A veces, un sitio web con errores puede no actualizar la ETag después de que se haya actualizado su recurso semántico. En 2019 [actualizar], un ejemplo de un sitio web destacado de este tipo es export.arxiv.org . [3] 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 de este tipo:
Las ETags se pueden utilizar para rastrear usuarios únicos, [4] 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 la UC Berkeley informaron que varios sitios web, incluido Hulu , estaban utilizando ETags con fines de seguimiento. [5] Hulu y KISSmetrics dejaron de "reaparecer" a partir del 29 de julio de 2011, [6] ya que KISSmetrics y más de 20 de sus clientes enfrentan una demanda colectiva por el uso de cookies de seguimiento "indelebles" que involucran parcialmente el uso de ETags. [7]
Debido a que el navegador almacena en caché las ETags y las devuelve con solicitudes posteriores del mismo recurso, un servidor de seguimiento puede simplemente repetir cualquier ETag que reciba del navegador para garantizar que una ETag asignada 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. [8]
Las ETags se pueden eliminar borrando el caché del navegador (las implementaciones varían).