Resumen

  • Retry-After dice cuándo debería hacerse una solicitud posterior, no cuándo está garantizada la recuperación.
  • El valor puede ser una fecha HTTP o un retraso en segundos, de modo que el reloj y el análisis forman parte de la evidencia.
  • Un 503 o 429 describe la respuesta observada, no la capacidad futura ni todas las dependencias.
  • Hace falta un registro de decisión del reintento que una la instrucción con datos recientes del servicio y el resultado real.

Imaginemos un controlador que recibe 503 Service Unavailable con Retry-After: 120. Retiene todas las solicitudes, marca en verde el punto situado dos minutos después y libera toda la cola en el mismo segundo. El incidente se cierra antes de que una sola petición nueva haya tenido éxito. Al vencer el plazo, el servidor de origen sigue sobrecargado, una dependencia continúa caída y la oleada sincronizada prolonga la sobrecarga.

El encabezado era válido. La conclusión de recuperación era inventada.

RFC 9110 define Retry-After con un alcance preciso: indica cuánto debería esperar un agente de usuario antes de una solicitud posterior. Con 503, el servidor puede sugerir un momento adecuado para reintentar. En una respuesta de redirección puede indicar cuánto convendría esperar antes de seguir la nueva dirección. Ninguno de esos usos convierte el tiempo en un pronóstico de salud.

El campo admite una fecha HTTP absoluta o un número no negativo de segundos desde la recepción. La fecha depende de los relojes; el retraso, del momento efectivo de recepción y de cómo intermediarios, colas y temporizadores cuentan el tiempo. Guardar sólo la hora calculada elimina la instrucción original.

RFC 9110 describe 503 como una incapacidad temporal causada por sobrecarga o mantenimiento planificado. El servidor puede sugerir cuándo reintentar, pero no garantiza que la restricción termine exactamente entonces. La especificación tampoco obliga a todo servidor sobrecargado a responder con 503. La recuperación puede ser anterior, posterior, parcial, regional o dependiente del contexto de acceso.

RFC 6585 define 429 Too Many Requests. Puede incluir Retry-After, pero deja al servidor la forma de identificar al usuario y contar las solicitudes. Un token, cuenta, dirección, ruta, tenant o nodo puede tener un límite distinto. El temporizador sin ese ámbito no demuestra que la próxima petición será admitida.

También importa quién emitió la respuesta. Puede ser el origen, una pasarela, un proxy, una CDN o un gestor de API. La observación prueba que ese componente dio esa instrucción para ese intercambio, no que todas las capas compartan el estado.

El registro de decisión conserva solicitud, respuesta, punto de observación, código, valor bruto, forma de fecha o retraso, hora de recepción, instante calculado, fuente del reloj y edad añadida por intermediarios. Lo vincula al ámbito de cuenta, token, ruta o tenant sin guardar secretos.

Después registra la estrategia de espera, la variación aleatoria, el presupuesto de reintentos, el límite de solicitudes simultáneas, la cancelación y la hora real de envío. Antes de autorizar el nuevo intento añade datos actuales sobre el estado del servicio, la capacidad disponible, las dependencias y la autorización. Por último, almacena la respuesta obtenida y el resultado final de la transacción.

Así el panel separa «reintento permitido», «salud comprobada», «solicitud admitida» y «transacción completada». Pueden mostrarse juntos, pero uno no crea automáticamente el siguiente.

Fuentes

RFC 9110 — HTTP Semantics; RFC 6585 — Additional HTTP Status Codes.