Resumen

  • RFC 5861, publicada en mayo de 2010 como documento informativo independiente, creó dos extensiones: stale-while-revalidate permite entregar una copia caducada mientras se valida; stale-if-error permite usarla ante errores del servidor.
  • Los ejemplos fijan números distintos. max-age=600, stale-while-revalidate=30 ofrece diez minutos de frescura y hasta treinta segundos adicionales; max-age=600, stale-if-error=1200 puede sustituir a los 900 segundos un 500 por un 200 guardado con Age: 900.
  • RFC 9111, de junio de 2022, mantiene la necesidad de permiso expreso para entregar contenido caducado y declara obsoleta la antigua cabecera Warning.

Una copia vieja compra tiempo

La caché almacena una respuesta para evitar viajes repetidos al origen. La copia es fresca durante el periodo que indican las reglas HTTP. Al terminar, volver a consultar al servidor consume tiempo de red y cómputo, incluso si el archivo sigue igual. RFC 5861 permitió al origen ofrecer un margen estrecho para responder primero y comprobar después.

Su ejemplo Cache-Control: max-age=600, stale-while-revalidate=30 deja la respuesta fresca 600 segundos. Durante los siguientes treinta, la caché puede enviar de inmediato la copia ya caducada mientras intenta validarla en segundo plano. El usuario evita la espera; la comprobación continúa por detrás. Si el origen confirma o entrega otra versión, los siguientes lectores podrán ver el estado renovado.

El margen termina aunque nadie haya pedido la página para activar la comprobación. Si la validación no da resultado en treinta segundos, la siguiente solicitud vuelve a esperar el tratamiento normal. Una página con poco tráfico quizá no aproveche el mecanismo. La duración elegida y la frecuencia de visitas determinan cuánto retraso se oculta. Publicar un margen amplio significa aceptar que los cambios tarden más en llegar al lector.

El fallo que quedó detrás de un 200

La segunda extensión responde a otra escena. La caché intenta consultar el origen y encuentra una situación que produciría 500, 502, 503 o 504. stale-if-error le permite entregar, durante un intervalo definido, la copia exitosa que ya tenía. El cliente recibe un cuerpo antiguo en lugar del error presente.

RFC 5861 muestra una respuesta con max-age=600, stale-if-error=1200. A los 900 segundos de edad, un intento de validación obtiene un 500. La caché puede devolver el antiguo 200 OK con Age: 900. El estado 200 describe la representación finalmente entregada, no el resultado del intento fallido ante el origen. La edad indica que el contenido llevaba tiempo guardado.

El segundo límite concede 1.200 segundos más después de los 600 de frescura. Cuando la edad total pasa de 1.800 segundos en el ejemplo, el error debe llegar al cliente. Así, una página que tolera veinte minutos de antigüedad puede sobrevivir a una interrupción corta, pero un origen no ha firmado un cheque en blanco para enseñar la misma versión indefinidamente.

Una espera lenta y un error del servidor crean apuestas distintas. stale-while-revalidate esconde la latencia mientras corre una comprobación. stale-if-error cubre la falta de una respuesta actual. Se pueden publicar límites diferentes, porque el costo de esperar y el costo de mostrar un dato viejo cambian según el recurso. Un horario público y una autorización de pago no deberían recibir el mismo margen por pura comodidad del operador.

Desapareció el aviso, quedó la edad

La edición de 2010 esperaba que el contenido caducado llevara Age distinto de cero y la cabecera Warning bajo las reglas de entonces. En 2022, RFC 9111 declaró obsoleta Warning: apenas se generaba o mostraba a los usuarios. Age sigue estimando el tiempo desde la creación o validación por el origen. Una respuesta 200 puede, por tanto, necesitar lectura de su edad y de su política para revelar que la caché entregó una copia anterior.

RFC 9111 también impide servir contenido caducado cuando una instrucción como no-cache o must-revalidate lo prohíbe. En los demás casos exige desconexión, permiso explícito del cliente o del origen, como las extensiones de RFC 5861, o un acuerdo externo. La caché decide dentro de un poder concedido; no posee carta blanca sobre la actualidad del contenido.

El documento de 2010 fue una contribución informativa independiente. El estándar de caché de 2022 cita sus extensiones como ejemplo de permiso explícito. Para saber qué servicios las usaron hacen falta respuestas con fecha, configuraciones y capturas durante fallos. La historia de los textos muestra el trato: el origen fija cuánto puede durar una respuesta antigua; la caché convierte esa duración en rapidez o continuidad; el lector vive con el resultado.