Тайм-ауты простоя прокси во время длительных HTTP-задач
Выберите опрос или определённый формат потоковой передачи, когда длительная работа сервера упирается в предел простоя прокси, вместо вставки произвольных байтов в окончательный ответ.
Если служба молчит минутами, а у прокси истекает тайм-аут, выберите, что должен получить клиент, прежде чем добавлять байты пульса. Продление таймера может помочь одному ожиданию; контракт ответа определяет, какой прогресс допустим.
| Дизайн приложения | Контракт прогресса |
|---|---|
| Асинхронная задача | 202 Accepted с представлением, описывающим мониторинг, затем конечные запросы состояния и явные состояния завершения/сбоя |
| Поток Server-Sent Events | Content-Type: text/event-stream и записи, которые понимает клиент SSE |
202 не обещает, что задача завершится успешно. Для SSE запись-комментарий может выглядеть так:
: heartbeat
Двоеточие делает её комментарием, а не событием приложения. Заметки об авторинге HTML предлагают периодические комментарии примерно каждые 15 секунд против некоторого устаревшего поведения прокси при простое; это рекомендация, а не универсальная гарантия тайм-аута.
Завершите заголовки и убедитесь, что приложение/стек обслуживания освобождает записи, а не буферизует их локально. Ещё не отправленные байты не могут поддерживать активность нижестоящего посредника.
Не вставляйте комментарии SSE в обычное JSON- или бинарное содержимое. Чанк нулевой длины HTTP/1.1 завершает chunked-тело, поэтому это не повторяемый пустой пульс.
Сохраняйте крайний срок операции и политику отмены. Одна лишь активность трафика не показывает полезный прогресс задачи или допустимый итоговый результат.