Кратко

  • Retry-After задаёт ожидание перед следующим запросом, но не гарантирует момент восстановления.
  • Значением может быть абсолютная дата HTTP или задержка в секундах, поэтому часы и разбор входят в доказательство.
  • 503 или 429 описывают полученный ответ, а не будущую ёмкость и состояние всех зависимостей.
  • Нужен журнал решения о повторном запросе, связывающий указание с актуальными данными и фактическим исходом.

Представим контроллер восстановления, получивший 503 Service Unavailable с Retry-After: 120. Он удерживает все запросы, ставит зелёную отметку через две минуты и выпускает всю очередь в одну секунду. Инцидент закрывается до первой успешной новой операции. Когда срок наступает, исходный сервер всё ещё перегружен, одна зависимость недоступна, а синхронная волна продлевает перегрузку.

Заголовок был корректным. Вывод о восстановлении был выдуман.

RFC 9110 определяет Retry-After узко: он указывает, сколько пользовательскому агенту следует ждать перед последующим запросом. Вместе с 503 сервер может предложить подходящее время новой попытки. В ответе с перенаправлением поле может указать, сколько следует подождать перед переходом по новому адресу. Ни один вариант не превращает время в прогноз состояния сервиса.

Поле принимает дату HTTP либо неотрицательное число секунд после получения. Дата зависит от часов; задержка — от фактического времени приёма и от того, как посредники, очереди и таймеры учитывают прошедшее время. Если сохранить только вычисленный срок, исходное указание исчезает.

RFC 9110 описывает 503 как временную неспособность из-за перегрузки или планового обслуживания. Сервер может предложить время, но не гарантирует, что ограничение исчезнет именно тогда. Спецификация также не требует, чтобы каждый перегруженный сервер отвечал кодом 503. Восстановление бывает ранним, поздним, частичным, региональным, зависящим от контекста доступа или заблокированным другой системой.

RFC 6585 определяет 429 Too Many Requests. Ответ может содержать Retry-After, однако способ распознавания пользователя и подсчёта запросов выбирает сервер. Для токена, учётной записи, маршрута, арендатора или пограничного узла могут действовать разные пределы. Таймер без этой области действия не доказывает, что следующий запрос будет принят.

Журнал решения о повторном запросе сохраняет запрос, ответ, точку наблюдения, статус, исходное значение, его форму, время получения, вычисленный момент, источник времени и возраст, добавленный посредником. Он связывает указание с областью учётной записи, токена, маршрута или арендатора, не сохраняя секреты.

Затем записываются способ увеличения паузы, случайное изменение интервала, лимит попыток, предел одновременных запросов, отмена и фактическое время отправки. Перед новой попыткой добавляются свежие данные о состоянии сервиса, доступных ресурсах, зависимостях и авторизации. В конце сохраняются полученный ответ и результат транзакции. Окончание ожидания, успешная проверка, разрешение на новую попытку и завершение операции — разные события.

Источники

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