Consigna y contexto
Una puerta de enlace de caché agrega Warning: 110 - "Response is stale" y Warning: 111 - "Revalidation failed". Los navegadores y los servicios posteriores no exponen estos campos de manera consistente, y los estándares más nuevos ya no los recomiendan. Explica la semántica histórica, el límite de validación de caché, los campos de reemplazo y una migración sin pérdida de información.
Esta pregunta encaja en entrevistas de backend, puertas de enlace, CDN y plataformas. La clave es separar los metadatos de protocolo, los errores de usuario y la observabilidad interna en lugar de reemplazar un encabezado en desuso por otro encabezado de formato libre.
Qué está evaluando el entrevistador
Una respuesta sólida explica que Warning podía describir problemas en los mensajes y que las advertencias 1xx relacionadas con la caché podían eliminarse tras una validación exitosa. También señala que el campo está en desuso (deprecated) porque no se generaba ni se exponía ampliamente, mientras que parte de su información se puede inferir a partir de campos como Age. El candidato debe utilizar Cache-Control, Date, Age, validadores, códigos de estado y métricas estructuradas en lugar de contratos de cliente de formato libre.
Preguntas aclaratorias para hacer primero
- ¿Warning es generado por el origen, una caché compartida o una puerta de enlace de borde (edge gateway), y existen múltiples capas de proxy?
- ¿Son 110 y 111 solo de diagnóstico, o los clientes modifican su comportamiento de negocio debido a ellos?
- ¿Las respuestas incluyen
Date,Age,Cache-Control,ETagyLast-Modified? - ¿Qué clientes heredados (legacy) deben ser compatibles y pueden los sistemas realizar escritura dual (dual-write) temporalmente?
- ¿Quién necesita "fresh", "stale" y "revalidation failed": los usuarios, la lógica de negocio o los operadores?
Estructura para una respuesta de 30 segundos
"Trataría a Warning como un diagnóstico de caché histórico, no como un contrato estable de errores para el usuario. 110 describía una respuesta obsoleta (stale) y 111 una revalidación fallida, pero el campo está en desuso y no es adecuado para texto de formato libre. Realizaría un inventario de consumidores y capas de proxy, expresaría los hechos con Cache-Control, Date, Age, validadores y métricas estructuradas, mantendría una escritura dual solo durante una ventana de compatibilidad acotada y luego eliminaría Warning tras observar el comportamiento del cliente. La tasa de aciertos de caché, la entrega de contenido obsoleto, los fallos de revalidación y las métricas de presupuesto de errores verificarían la migración."
Respuesta detallada paso a paso
Paso 1: Recuperar el rol histórico de Warning
Warning era un encabezado de solicitud y respuesta que contenía un código de tres dígitos, el agente generador y texto. Los códigos 110 y 111 relacionados con la caché describían una respuesta obsoleta y una revalidación fallida; no eran códigos de estado HTTP y no significaban un 4xx o 5xx. Múltiples proxies podían anexar campos, lo que hacía que el origen y la confiabilidad del texto libre fueran inestables.
Paso 2: Explicar por qué es necesaria la migración
MDN marca Warning como en desuso porque no se generaba ni se exponía ampliamente y los estándares pertinentes ya no recomiendan este mecanismo general de advertencia. Depender de él vincula el diagnóstico de caché a texto inestable y dificulta razonar sobre la duplicación, el reordenamiento o el filtrado por parte de proxies. Primero demuestre que ningún cliente lo trata como una señal de negocio.
Paso 3: Expresar hechos con campos de caché estándar
Date identifica el momento de generación de la respuesta, mientras que Age aproxima el tiempo de permanencia en una caché compartida. Cache-Control define los requisitos de frescura y revalidación, y ETag o Last-Modified respaldan las solicitudes condicionales. Juntos describen el estado de la caché; una cadena personalizada X-Warning no es un sustituto. El origen también debe configurar Vary correctamente para que las representaciones de diferentes solicitudes no se mezclen.
Paso 4: Mover los diagnósticos a la observabilidad
La puerta de enlace debe registrar eventos estructurados como cache_status=stale, revalidation=failed, upstream=timeout, la capa de caché y el trace ID. Los logs deben evitar valores sensibles en las consultas de URL; las métricas deben agregarse por ruta, familia de claves de caché y clase de error de upstream. La respuesta solo debe transportar el estado relevante para el usuario, mientras que el detalle operativo permanece en sistemas controlados.
Paso 5: Diseñar una ventana de compatibilidad con escritura dual
Deje de consumir Warning en tráfico espejo (shadow traffic) o en una ruta pequeña primero, verificando dependencias en SDKs, scripts y reglas de proxy. Si existe un cliente heredado, mantenga Warning brevemente mientras publica un campo de reemplazo o una guía de actualización. El reemplazo necesita un enum estable y un contrato versionado, no texto arbitrario copiado. Asigne una fecha límite explícita a la escritura dual.
Paso 6: Manejar cachés en capas y fallos de validación
Una revalidación fallida no significa necesariamente que el origen esté caído; puede ser un tiempo de espera agotado (timeout), una solicitud condicional rechazada o un 5xx de upstream. Decida si se sirve contenido obsoleto, se devuelve un error o se aplica una directiva stale-if-error, y registre el motivo. Eliminar Warning no debe ocultar la entrega de contenido obsoleto ni crear reintentos infinitos.
Paso 7: Separar 103 Early Hints de las advertencias de caché
103 Early Hints precede a la respuesta final y sugiere recursos probables, comúnmente a través de Link para preconnect o preload. No informa sobre la frescura de la caché ni fallos de revalidación, y no reemplaza a Age o Cache-Control. Indique la temporización, el consumidor y la semántica de fallos de cada campo en lugar de tratar cada indicio como un Warning.
Paso 8: Eliminarlo por etapas y verificar
Compare las lecturas de Warning, la tasa de aciertos de caché, la proporción de entrega obsoleta, el éxito de solicitudes condicionales, los errores de origen, la latencia P95 y los errores de clientes antes y después de la migración. Deshabilite la generación en una capa de caché, expándala a lo largo de la cadena y luego elimine el código, la documentación y las alertas una vez que los clientes heredados estén limpios. Un interruptor de reversión (rollback switch) solo debe restaurar la salida de compatibilidad, nunca restaurar la dependencia de negocio sobre Warning.
Compensaciones y límites
Mantener Warning tiene un bajo costo de compatibilidad a corto plazo, pero prolonga un contrato inestable y una resolución de problemas ambigua. La eliminación inmediata reduce el ruido del protocolo, pero puede romper scripts heredados. El camino más seguro observa las dependencias reales y luego traslada la necesidad a campos de caché estándar y observabilidad estructurada.
No interprete Age como la hora de generación en el origen ni Cache-Control: no-cache como "no almacenar en caché"; este último requiere revalidación antes de su reutilización. La política de caché, los validadores y las respuestas de error deben diseñarse con la ventana de frescura aceptable para el negocio.
Plan de despliegue y evidencia
En la primera semana, exporte las rutas de lectura de Warning desde el borde, las cachés compartidas y los clientes, estableciendo una línea base por ruta y capa de caché. Luego, realice una escritura dual de métricas estructuradas en una ruta sin dependencias críticas y compare Age, solicitudes condicionales y tasas de error. Finalmente, deshabilite Warning capa por capa manteniendo un interruptor de salida de compatibilidad de un solo clic.
La aceptación requiere que ningún cliente de producción lea Warning; que la tasa de aciertos de caché y el éxito de revalidación no sufran regresiones; que los eventos stale-if-error sean explicables; que los logs y las métricas se correlacionen por trace ID; y que la documentación, los SDKs y las alertas estén actualizados.
Errores comunes y preguntas de seguimiento
Tratar 110 como un 4xx o 5xx
110 es un código histórico de Warning, no un estado de respuesta. Los errores de negocio pertenecen al estado y a los contratos de respuesta; el diagnóstico de caché pertenece a las métricas.
Recrear el problema con X-Warning
El texto libre, las anexiones por parte de proxies y la compatibilidad de versiones siguen siendo inciertos. Si se requiere compatibilidad, use un enum estable, versiones y consumidores explícitos.
Eliminar el encabezado sin observabilidad
Eliminar el campo no soluciona la entrega de contenido obsoleto ni las revalidaciones fallidas. Establezca métricas de estado de caché, rastreo (tracing) y alertas antes de eliminar el encabezado externo.
Tratar 103 Early Hints como una advertencia de caché
La temporización y el propósito de 103 son sugerencias de recursos; no puede expresar frescura o fallos de revalidación. Mantenga campos y rutas de procesamiento separados.
¿Cómo demuestras que se puede eliminar?
Observe las lecturas de los clientes, la configuración del proxy, las tasas de error y las métricas de caché; ejecute una ventana de escritura dual acotada y expándala tras un canary de una sola capa. No elimine globalmente sin evidencia de dependencias.