Validador de ETag Débil / Fuerte | Comparación según la RFC 7232

Coloca dos valores de cabecera HTTP ETag uno al lado del otro y observa cómo los compara la sección 2.3 de la RFC 7232. La herramienta detecta el prefijo W/, extrae el valor entre comillas y muestra a la vez una coincidencia fuerte y una débil, para que sepas si una caché, una petición condicional o una de rango funcionaría.

💡 Sobre esta herramienta

Para entender el ETag conviene empezar por su papel: es un identificador que representa "esta versión exacta de este recurso". El servidor lo envía en la respuesta y el cliente lo reutiliza en cabeceras como If-None-Match o If-Match. La RFC 7232 define dos tipos de validador: el fuerte ("abc") y el débil (W/"abc").

La regla de comparación es la parte que confunde a muchos. En la comparación fuerte el resultado es cierto solo si ambos ETags son fuertes y sus valores son idénticos byte a byte. En la comparación débil se ignora el prefijo W/ y basta con que los valores coincidan. Esta diferencia importa porque las peticiones Range e If-Range solo aceptan validadores fuertes: si tu servidor entrega un ETag débil, una descarga parcial se convierte en una respuesta completa (200) en lugar de un 206.

Pegando ambas cabeceras aquí, la línea de recomendación te dice qué cabeceras condicionales admitiría ese par. Todo ocurre en tu navegador.

🧐 Preguntas Frecuentes

¿W/"abc" es igual a "abc"? En coincidencia débil sí; en coincidencia fuerte no. Basta con que uno lleve W/ para que la comparación fuerte lo descarte, aunque los valores sean idénticos.

¿Por qué un valor suelto como abc123 da "sintaxis inválida"? La RFC 7232 exige que el valor vaya entre comillas dobles. Sin comillas, abc123 no es una entity-tag válida y no se puede comparar.

¿Se ignoran las mayúsculas y los espacios? No. El valor opaco se compara carácter a carácter, así que "ABC" y "abc" son distintos y los espacios internos también cuentan.

¿Cuál necesito para descargas reanudables? Un validador fuerte. Range e If-Range rechazan los débiles para no mezclar bytes de dos representaciones equivalentes pero no idénticas. Busca un par cuya Coincidencia fuerte sea SÍ.

¿Admite ETags con formato de hash o estructurados? Sí. Lo que esté entre comillas se trata como opaco, de modo que un hash hexadecimal como "686897696a7c876b7e" o una etiqueta versionada como "v2-2024-01" se comparan tal cual.

📚 Datos Curiosos

La cabecera ETag ya existía en HTTP/1.1 (RFC 2616), pero el algoritmo de comparación fuerte/débil no quedó bien definido hasta la RFC 7232 en 2014. Los validadores débiles nacieron por un motivo muy concreto: hay respuestas semánticamente idénticas que difieren byte a byte, como una página recomprimida con otro nivel de gzip o un contenido con una marca de tiempo incrustada. Etiquetarlas con un ETag fuerte rompería el almacenamiento en caché con 304, así que W/ se introdujo como señal de "equivalente a efectos prácticos". Un detalle histórico: Apache solía generar el ETag a partir del inodo, el tamaño y la fecha del archivo, por lo que el mismo fichero servido desde dos servidores con balanceo de carga producía ETags distintos, un fallo silencioso que arruinaba la caché.