ETag

Un ETag (Entity Tag) es una cabecera de respuesta HTTP — típicamente un hash o sello de versión del cuerpo de la respuesta — que permite a un cliente revalidar un recurso en caché sin descargarlo de nuevo.

Flujo de trabajo:

1. Primera solicitud: el servidor devuelve el recurso con ETag: "abc123".
2. El cliente almacena en caché la respuesta con el ETag.
3. Siguiente solicitud: el cliente envía If-None-Match: "abc123".
4. El servidor compara el ETag actual con el del cliente. Si son iguales: 304 Not Modified con cuerpo vacío, el cliente usa su copia en caché. Si son diferentes: 200 OK con el nuevo cuerpo y nuevo ETag.

Dos variantes de ETag:

• ETags fuertes — cambian si cambian los bytes. Por defecto.
• ETags débiles — con prefijo W/, pueden coincidir entre respuestas “semánticamente equivalentes” (p. ej., comprimido vs sin comprimir del mismo contenido).

ETag es uno de los tres mecanismos de validación de caché HTTP (junto con Last-Modified + If-Modified-Since, y Cache-Control max-age). Para sitios estáticos modernos con URLs de activos con hash de contenido, ETag raramente es necesario — pero sigue siendo el caballo de batalla para las APIs dinámicas que quieren caché del lado del cliente.

Ejemplo práctico

Un navegador obtiene /api/profile por primera vez. El servidor responde: HTTP/1.1 200 OK, ETag: "v42-7a8b9c", cuerpo = 4,2 KB de JSON. El navegador guarda ambos en caché. En la siguiente carga de página, el navegador envía GET /api/profile con If-None-Match: "v42-7a8b9c". El servidor calcula el ETag actual — sigue siendo "v42-7a8b9c" porque nada ha cambiado — y responde HTTP/1.1 304 Not Modified con cero bytes de cuerpo. El navegador sirve su copia en caché. Ancho de banda ahorrado: 4,2 KB; la latencia de ida y vuelta sigue pagándose. Compara con Cache-Control: max-age=300, que omite el viaje de ida y vuelta por completo durante 5 minutos — y verás por qué ETag es la segunda mejor estrategia de caché: confirma la frescura cuando debe evitarse la obsolescencia, pero no ahorra realmente el viaje de red. Los sitios estáticos modernos prefieren URLs con huella digital + max-age lejano y omiten ETag por completo.

Cuándo y por qué importa

ETag importa para dos flujos de trabajo distintos: revalidación de caché (ahorro de ancho de banda cuando las respuestas son grandes e invariantes) y control de concurrencia optimista (prevención de errores de actualización perdida en APIs REST). El error a evitar en el caché es generar un ETag débil a partir de una marca de tiempo que incluya precisión de subgundos — cada servidor en un clúster balanceado calcula un valor diferente para el mismo recurso, y los clientes invalidan constantemente. Usa un hash de contenido estable (SHA-256 del cuerpo, a menudo truncado a 16 caracteres) para que todas las réplicas produzcan el mismo ETag. El error a evitar en concurrencia es no validar If-Match en el servidor — muchos desarrolladores añaden la cabecera en las escrituras pero el servidor la ignora, dejando la condición de carrera sin resolver. AWS S3, Google Cloud Storage y la API de Stripe hacen cumplir estrictamente la concurrencia basada en ETag; seguir su patrón es el diseño de referencia más seguro. Referencia: MDN — Cabecera HTTP ETag.

Control de concurrencia optimista — el segundo trabajo de ETag: ETag es también el mecanismo estándar para “no sobreescribas mis datos si alguien más los cambió”. El cliente obtiene el recurso con GET, captura el ETag, hace ediciones, luego envía PUT con If-Match: "abc123". Si el recurso del servidor ha cambiado desde entonces (diferente ETag), el servidor devuelve 412 Precondition Failed y el cliente sabe que debe actualizar y volver a combinar. AWS S3, Google Cloud Storage y la mayoría de las APIs REST que admiten ediciones simultáneas usan exactamente este patrón. El mecanismo es anterior al bloqueo pesimista de aplicaciones web y es más escalable porque no se necesita estado de bloqueo en el servidor.

El problema de privacidad con los ETags: los servidores pueden usar valores ETag únicos por usuario (esencialmente una cookie emitida por el servidor incrustada en los metadatos del caché) para rastrear a usuarios que regresan sin establecer una cookie real — la llamada “cookie ETag” o “supercookie”. Incluso después de que un usuario borre las cookies, el navegador sigue enviando el ETag de vuelta en la siguiente solicitud, identificándole. Los navegadores ahora particionan los cachés HTTP por sitio de nivel superior (Chrome 86, Firefox 85) para neutralizar este ataque, pero la técnica sigue siendo una nota de privacidad conocida en el diseño de caché HTTP. Referencia: RFC 9110 §8.8.3 — ETag.