La etiqueta ETag o entidad es parte de HTTP , el protocolo para la World Wide Web . Es uno de los varios mecanismos que proporciona HTTP para la validación de la caché web , lo que permite a un cliente realizar solicitudes condicionales. Este mecanismo permite que los 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. Los ETags también se pueden usar para un control de simultaneidad 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 . Si la representación de recursos en esa URL alguna vez cambia, se asigna una ETag nueva y diferente. Usados de esta manera, los ETag son similares a las huellas digitales y se pueden comparar rápidamente para determinar si dos representaciones de un recurso son iguales.
Generación ETag
El uso de ETags en el encabezado HTTP es opcional (no es 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 última marca de tiempo de 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 ETags sería "aceptablemente rara", incluso si pudiera o ocurriría.
RFC-7232 establece explícitamente que los ETag deben tener en cuenta la codificación de contenido , p. Ej.
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 sufren problemas de colisión de hash. Por lo tanto, no eran buenos candidatos para su uso en la generación ETag.
Validación fuerte y débil
El mecanismo ETag admite tanto una validación fuerte como una validación 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 fuerte validación indica que el contenido de las dos representaciones de recursos es idéntico byte por byte y que todos los demás campos de entidad (como Content-Language) tampoco se modifican. Los ETag potentes permiten el almacenamiento en caché y el reensamblaje de respuestas parciales, como ocurre 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 en caché. Sin embargo, las representaciones de recursos no son necesariamente idénticas byte por byte y, por lo tanto, los ETag débiles no son adecuados para solicitudes de rango de bytes. Los ETag débiles pueden ser útiles para los casos en los que los ETag potentes no son prácticos para que los genere un servidor web, como en el caso de 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" de encabezado de respuesta HTTP:
ETag: "686897696a7c876b7e"
El cliente puede entonces decidir almacenar en caché la representación, junto con su ETag. Más adelante, si el cliente desea recuperar el mismo recurso de URL nuevamente, primero determinará si la versión de la URL almacenada en caché local ha caducado (a través de los encabezados Cache-Control y Expire). Si la URL no ha caducado, recuperará el recurso almacenado en caché local. Si se determina que la URL ha caducado (está obsoleta ), el cliente enviará una solicitud al servidor que incluye su copia de ETag previamente guardada en el campo "If-None-Match". [2]
If-None-Match: "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 devolver una respuesta muy breve con un estado HTTP 304 No modificado . El estado 304 le dice al cliente que su versión en caché todavía es 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 ETag. 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 ETag se pueden utilizar en sistemas de supervisión de páginas web . La supervisión eficiente de las 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 indicios de si se ha cambiado el contenido web, 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
Un sitio web con errores a veces puede fallar al actualizar la ETag después de que se haya actualizado su recurso semántico. A partir de 2019[actualizar], un ejemplo de un sitio 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:
- Almacene en caché la respuesta y ETag, asumiendo que hay una ETag y que la respuesta no fue abortada.
- Para una solicitud posterior que hubiera incluido el encabezado If-None-Match, no envíe este encabezado con quizás una probabilidad aleatoria del 20%. Con esta probabilidad, si la respuesta devuelve un contenido alterado pero la misma ETag que se almacenó en caché anteriormente, marque el sitio web como con errores y desactive el almacenamiento en caché de ETag. Como recordatorio, para una ETag fuerte, la comparación de contenido puede ser byte por byte, mientras que, para una ETag débil, solo verificaría la equivalencia semántica.
Seguimiento mediante ETags
Los 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 UC Berkeley informaron que varios sitios web, incluido Hulu , utilizaban ETag 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 las ETag en caché y las devuelve con solicitudes posteriores para el mismo recurso, un servidor de seguimiento puede simplemente repetir cualquier ETag recibida 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]
Los ETags se pueden desechar borrando la caché del navegador (las implementaciones varían).
Referencias
- ^ "Edición de la Web: detección del problema de actualización perdida mediante el pago sin reservas" . Nota del W3C . 10 de mayo de 1999.
- ^ Mozilla. "Etag" . Etag . Mozilla.
- ^ "ETag export.arxiv.org no coincidente" .
- ^ "seguimiento sin cookies" . 17 de febrero de 2003.
- ^ "Flash Cookies y Privacidad II: Ahora con HTML5 y ETag Respawning". 29 de julio de 2011. SSRN 1898390 . Cite journal requiere
|journal=
( ayuda ) - ^ "Respawn Redux" . 11 de agosto de 2011.
- ^ AOL, Spotify, GigaOm, Etsy, KISSmetrics demandaron por cookies de seguimiento indelebles
- ^ Cookies sin cookies (usando ETags como cookies)
- ETag en la especificación HTTP / 1.1
- Acerca de las etiquetas electrónicas y los sellos de fecha por Lars R. Clausen (2004)
enlaces externos
- Documentación del servidor HTTP Apache - Directiva FileETag
- Editando la Web: Detectando el Problema de Actualización Perdida usando Pago sin Reserva , Nota W3C, 10 de mayo de 1999.
- Demostración en vivo de la cookie zombie usando ETags
- Antiguos proyectos de desarrollo de SQUID - Soporte ETag (completado en 2001)
- Uso de ETags para reducir el ancho de banda y la carga de trabajo con Spring & Hibernate