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