Comprobador de ETag

Qué es un ETag, y qué significa la W/

Un ETag es una cadena opaca que el servidor asocia a una versión de un recurso. El cliente la guarda, la devuelve en la siguiente petición, y el servidor puede responder con un 304 en vez del cuerpo entero si nada ha cambiado. El valor tiene una gramática pequeña: un prefijo W/ opcional y, a continuación, la etiqueta entre comillas dobles obligatorias.

Las comillas forman parte del valor y no son un adorno, y los caracteres permitidos son más estrechos de lo que la gente supone: el conjunto es %x21 y de %x23 a %x7E, lo que deja fuera la comilla doble y, menos obviamente, el espacio. La barra invertida sí se admite, aunque la especificación desaconseja usarla porque los destinatarios antiguos pueden intentar desescaparla.

El prefijo W/ indica que la etiqueta es un validador débil. La explicación habitual es que una etiqueta débil identifica una versión semánticamente equivalente y no idéntica byte a byte, lo cual es cierto y hace que suene a una anotación menor sobre precisión. No lo es: cambia para qué sirve la etiqueta.

Cómo se usa

1. Pon el ETag del servidor en el primer campo. Tal cual aparece en la cabecera de la respuesta, con comillas y prefijo W/ incluidos. Lo que esté mal formado se explica en vez de ignorarse en silencio.
2. Pon en el segundo la etiqueta con la que se compara. Normalmente es lo que un cliente enviaría en If-None-Match o en If-Match.
3. Lee los dos resultados y luego la tabla de cabeceras. Cuando las dos funciones discrepan, la respuesta depende por completo de qué cabecera pregunta, y la tabla de abajo detalla qué haría cada una.

Dos funciones de comparación, y la que nadie menciona

HTTP no tiene una función de comparación para etiquetas de entidad. Tiene dos, y exige una distinta en cada sitio. El apartado 13.1.2 del RFC 9110 dice que el destinatario debe usar la comparación débil para If-None-Match. El 13.1.1 dice que el servidor de origen debe usar la comparación fuerte para If-Match.

La comparación débil ignora del todo el prefijo W/ y compara las etiquetas opacas. La fuerte exige que sean iguales y que las dos sean fuertes. La consecuencia es lo que conviene llevarse: un ETag débil nunca satisface la comparación fuerte, ni siquiera contra una copia idéntica de sí mismo. La especificación lo imprime en su propia tabla: W/"1" contra W/"1" coincide con la comparación débil y no coincide con la fuerte.

Así que un ETag débil se cachea perfectamente y no admite escrituras. Todo PUT o PATCH condicional que use If-Match para concurrencia optimista falla, siempre, mande lo que mande el cliente. No hay ningún error que lo explique: la condición sencillamente no se cumple nunca. Si tu API devuelve 412 en cada actualización y el ETag empieza por W/, ese es el motivo.

No es una configuración rara. Sobre los 250 dominios más visitados, de los que respondieron 173, solo el 20,2 % manda algún ETag, y de esos el 25,7 % son débiles, incluidos wikipedia.org, github.com y apache.org. Para una página que se cachea es una decisión sensata, porque una etiqueta débil sobrevive a la compresión y a otras transformaciones que cambian los bytes sin cambiar el significado. Para un endpoint de API que la gente actualiza, elimina una función que nadie sabe que ha perdido.

If-Range es el tercer caso y funciona de otra manera. Ahí la restricción recae en el cliente: el apartado 13.1.5 dice que un cliente no debe generar una cabecera If-Range que contenga una etiqueta débil, así que reanudar una descarga parcial exige un validador fuerte por construcción y no por comparación.

Límites honestos y cómo se ha comprobado

Esto compara dos etiquetas que pegas tú. No hace ninguna petición, así que no puede decirte qué manda tu propio servidor: un navegador no puede leer cabeceras de respuesta arbitrarias de otro origen, y cualquier herramienta que diga lo contrario está pasando la petición por un servidor. Las herramientas de desarrollo de tu navegador te enseñan la cabecera con un clic, que es la forma correcta de obtenerla.

Una cosa que esta página no afirma a propósito: que los servidores manden habitualmente ETags con la sintaxis mal. Esa era la segunda mitad de la idea, y medirla la mató. Cero de los 35 ETags reales de la muestra estaban mal formados. Esta cabecera la emiten los frameworks; casi nadie escribe una a mano. El validador sigue explicando la entrada mal formada, porque quien haya tecleado una merece una respuesta, pero no es el dato interesante y la página no finge que lo sea.

La lógica de comparación se contrasta con la tabla de cuatro filas de la propia especificación, reextraída del texto del RFC en cada ejecución de las pruebas en vez de transcrita, así que un error de copia no puede sobrevivir. Hay 513 comprobaciones y 14 controles negativos. Dos de mis propias pruebas resultaron codificar suposiciones en vez de la gramática: tenía una etiqueta con espacio anotada como válida y una con barra invertida como inválida, y la gramática dice lo contrario en ambos casos.

¿Por qué es gratis?

Esto es comparar cadenas. Se ejecuta en tu navegador, no hay servidor que pagar y no hay a qué registrarse.

Nada de lo que escribas se sube, se guarda ni se registra. Los ETags son opacos por diseño y a veces codifican más sobre un recurso de lo que pretendía quien los generó, así que conviene decir que se quedan en la pestaña.