Tidsgränser för inaktivitet hos proxyservrar under långa HTTP-jobb
Välj polling eller ett definierat streamingformat när långt serverarbete möter en proxys inaktivitetsgräns, i stället för att infoga godtyckliga byte i det slutliga svaret.
Om en tjänst är tyst i minuter och en proxy får timeout, välj vad klienten ska få innan du lägger till hjärtslagsbyte. Att förlänga en timer kan hjälpa en väntan; svarskontraktet avgör vilken framdrift som är giltig.
| Applikationsdesign | Framdriftskontrakt |
|---|---|
| Asynkront jobb | 202 Accepted med en representation som beskriver övervakning, följt av ändliga statusförfrågningar och explicita slutförande-/feltillstånd |
| Server-Sent Events-ström | Content-Type: text/event-stream och poster som SSE-klienten förstår |
202 lovar inte att jobbet lyckas. För SSE kan en kommentarpost se ut så här:
: heartbeat
Kolonet gör den till en kommentar i stället för en applikationshändelse. HTML:s författarnoter föreslår periodiska kommentarer ungefär var 15:e sekund mot visst äldre proxy-inaktivitetsbeteende; det är vägledning, inte en universell timeoutgaranti.
Slutför rubrikerna och se till att applikationen/serveringsstacken släpper posterna i stället för att buffra dem lokalt. Byte som ännu inte skickats kan inte hålla en nedströms mellanhand aktiv.
Infoga inte SSE-kommentarer i vanligt JSON- eller binärt innehåll. En HTTP/1.1-chunk med noll längd avslutar en chunked body, så det är inte en repeterbar tom hjärtslag.
Behåll en operationsdeadline och en avbrottspolicy. Enbart trafikaktivitet visar inte användbar jobbframdrift eller ett giltigt slutresultat.