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