Comprobar ETag débil o fuerte
Pegue un ETag y sepa al instante si es débil o fuerte: W/"abc123" es débil, con abc123 como etiqueta interior, mientras que "v1-hash" es fuerte. Si faltan las comillas o la w/ va en minúscula, se señala en lugar de adivinarse. Gratis en su navegador.
- Gratis
- Funciona en su navegador
- Sin registro
- Sus datos no salen de su equipo
Ejecutar — gratis
Ejemplo resuelto
- ETag
- W/"abc123"
- Intensidad
- weak
- Etiqueta opaca
- abc123
- Etiqueta entrecomillada
- "abc123"
- Prefijo
- W/
Un validador fuerte afirma una coincidencia exacta byte a byte; un validador débil, marcado con el prefijo W/ sensible a mayúsculas antes del opaque-tag entre comillas, solo afirma equivalencia semántica. Interpretar mal ese prefijo o aceptar un token sin comillas provoca decisiones erróneas en If-Match e If-None-Match, aciertos de caché obsoletos y actualizaciones condicionales perdidas. Esta capacidad acepta un único valor de cabecera ETag (o una línea completa ETag:), comprueba que el opaque-tag esté correctamente entre comillas dobles según RFC 9110, clasifica el validador como débil o fuerte y devuelve las partes normalizadas de la etiqueta.
Qué significan los ETags débiles y fuertes según RFC 9110
Un entity-tag es una cadena opaca entre comillas que un servidor asocia con una representación concreta de un recurso. Cuando el servidor pretende un validador fuerte, emite solo la etiqueta entre comillas, por ejemplo "v3-a1b2c3". Cuando pretende un validador débil, antepone a esa etiqueta el token sensible a mayúsculas W/, de modo que el valor completo queda como W/"v3-a1b2c3".
Los validadores fuertes pueden usarse tanto para revalidación de caché como para decisiones seguras de contenido parcial o de rangos que exigen coincidencia exacta. Los validadores débiles solo garantizan que las representaciones son equivalentes a efectos de caché; no deben tratarse como prueba de que cada byte es idéntico. Cabeceras de petición condicional como If-Match, If-None-Match e If-Range comparan las etiquetas del cliente con la del servidor actual según estas reglas.
Si un cliente o un middleware elimina por accidente el prefijo W/, una etiqueta débil se trata como fuerte y puede permitir indebidamente una petición de rango o una escritura condicional. Si se omiten las comillas, intermediarios y analizadores discrepan sobre dónde termina el token. Este comprobador existe para que usted valide una cadena ETag almacenada o registrada antes de compararla, documentarla o enviarla a otro sistema que espere la forma estricta de la RFC.
Contrato de entrada, campos de respuesta y reglas de rechazo
Puede pegar el entity-tag desnudo o una línea de cabecera completa como ETag: W/"abc". Se recortan espacios iniciales y finales; un prefijo opcional ETag: se elimina sin distinguir mayúsculas. El valor restante debe ser "opaque" para un validador fuerte o W/"opaque" para uno débil.
La W debe ir en mayúscula; una w/ minúscula se rechaza porque RFC 9110 define el marcador débil como sensible a mayúsculas. El opaque-tag debe empezar y terminar con comillas dobles, no debe contener una comilla doble interna sin escapar y solo puede usar caracteres etagc: ASCII imprimible excepto comilla, más obs-text. Ejemplo: "v1-hash" produce strong true y strength strong.
Qué puede hacer con ella
Auditorías de cabeceras en CDN y pasarelas
Pegue muestras de ETag de producción y confirme qué respuestas usan validadores débiles frente a fuertes antes de ajustar las reglas de caché y revalidación.
Soporte y triage de HAR
Clasifique ETags de archivos HAR o tickets en la herramienta gratuita del navegador para diagnosticar fallos de peticiones condicionales sin scripts a medida.
Preguntas frecuentes
¿Cómo sé si un ETag es débil o fuerte?
Envíe el valor ETag (por ejemplo W/"abc" o "abc"). Si empieza con el prefijo W/ sensible a mayúsculas antes de la etiqueta entre comillas, strength es weak; en caso contrario, una etiqueta bien entrecomillada es strong.
¿Qué ocurre si el ETag no va entre comillas?
RFC 9110 exige que el opaque-tag vaya entre comillas dobles; los tokens sin comillas se rechazan en lugar de adivinarse.
¿El prefijo W/ distingue mayúsculas y minúsculas?
Sí. Solo la W/ mayúscula es el marcador débil. Valores como w/"tag" se rechazan para no tratar en silencio un prefijo no conforme como fuerte o débil.
¿Puedo pegar una línea de cabecera ETag: completa?
Sí. Un nombre inicial ETag: se elimina sin distinguir mayúsculas; el entity-tag restante se clasifica a continuación.
¿Cuándo importa que un ETag sea débil o fuerte?
Cuando una caché o un cliente compara etiquetas para decidir si algo cambió. Uno fuerte demuestra una coincidencia exacta byte a byte y sirve para descargas parciales o escrituras seguras; uno débil solo indica que dos versiones son equivalentes para la caché.
Herramientas relacionadas
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/web/etag-weak-strong-check \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"etag":"W/\"abc123\""}'const res = await fetch("https://api.kit.forhosting.com/web/etag-weak-strong-check", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"etag": "W/\"abc123\""
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/web/etag-weak-strong-check",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"etag": "W/\"abc123\""
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/web/etag-weak-strong-check", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"etag":"W/\\"abc123\\""}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"etag":"W/\"abc123\""}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/web/etag-weak-strong-check", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Ejemplo de solicitud
{
"etag": "W/\"abc123\""
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "web.etag_weak_strong_check",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Límites
timeout_sec | 30 |
max_crawl_pages | 25 |
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |
Notas técnicas
Las etiquetas de entidad HTTP (ETags) indican a cachés y clientes si dos representaciones de un recurso son la misma. Comillas inválidas, valores vacíos y prefijos débiles no conformes con la RFC fallan con invalid_input en lugar de una clasificación falsa silenciosa. La misma lógica de análisis puro alimenta la herramienta gratuita del navegador y la ruta API de prepago.
Contrato de entrada, campos de respuesta y reglas de rechazo
Envíe un cuerpo JSON con un campo de cadena obligatorio llamado etag (se aceptan los alias value, header, tag y entity_tag). En caso de éxito la respuesta incluye etag (forma normalizada con W/ y comillas, o solo entre comillas), booleanos weak y strong, strength como la cadena weak o strong, opaque_tag (contenido interior sin comillas), quoted_tag, prefix (vacío o W/), valid true y una nota breve sobre la clase de validador. Entrada ausente, cadenas vacías tras quitar el nombre de cabecera, etiquetas sin comillas como abc123, comillas desparejadas, caracteres ilegales y prefijos débiles incorrectos provocan invalid_input y no se facturan. Ejemplo: W/"abc123" produce weak true, strength weak, opaque_tag abc123.
Dónde un comprobador de fuerza de ETag aporta valor
La validación fallida no consume saldo. Las revisiones de configuración de pasarelas API y CDN suelen reunir cabeceras de respuesta de ejemplo y necesitan una respuesta rápida y determinista sobre si cada ETag es débil o fuerte antes de redactar políticas de caché. Las pruebas automatizadas de contrato para servicios REST pueden afirmar que los documentos JSON versionados emiten etiquetas fuertes mientras las páginas HTML renderizadas usan deliberadamente etiquetas débiles, fallando la compilación cuando las comillas o el prefijo W/ se desvían. Los sitios de contenido orientados a consultas como validador etag débil fuerte obtienen una herramienta en vivo cuya ruta de cliente gratuita coincide con la ruta API de pago sobre el mismo módulo puro. Como la implementación es parse puro de nivel A, cada llamada correcta cuesta el precio base publicado $0.002 sin tokens de modelo ni red saliente. Mantenga el opaque-tag opaco en su documentación de producto: este endpoint nunca calcula el hash de su cuerpo por usted; solo clasifica el formato de la etiqueta que ya tiene, y fije los goldens al integrar el comprobador en CI.
Casos de integración
Contratos API y comprobaciones en CI
Afirme en las pruebas que un servicio emite ETags fuertes o débiles correctamente entre comillas y que el pipeline falla si faltan comillas o el prefijo W/ es incorrecto.
Preguntas técnicas
¿Cuánto cuesta la comprobación de ETag débil o fuerte?
La herramienta del navegador es gratuita. Las peticiones API usan saldo KIT prepago a $0.002 por llamada correcta; la entrada inválida no se factura.