Proxyers inaktivitets-timeouts under lange HTTP-job
Vælg polling eller et defineret streamingformat, når langt serverarbejde møder en proxys inaktivitetsgrænse, i stedet for at indsætte vilkårlige bytes i det endelige svar.
Hvis en tjeneste forbliver tavs i minutter, og en proxy får timeout, skal du vælge, hvad klienten skal modtage, før du tilføjer heartbeat-bytes. At forlænge en timer kan hjælpe én venten; svarkontrakten bestemmer, hvilken fremdrift der er gyldig.
| Applikationsdesign | Fremdriftskontrakt |
|---|---|
| Asynkront job | 202 Accepted med en repræsentation, der beskriver overvågning, efterfulgt af endelige statusanmodninger og eksplicitte afslutnings-/fejltilstande |
| Server-Sent Events-stream | Content-Type: text/event-stream og poster, som SSE-klienten forstår |
202 lover ikke, at jobbet lykkes. For SSE kan en kommentarpost se sådan ud:
: heartbeat
Kolonnet gør det til en kommentar i stedet for en applikationshændelse. HTML's forfatternoter foreslår periodiske kommentarer cirka hvert 15. sekund mod en vis ældre proxy-inaktivitetsadfærd; det er vejledning, ikke en universel timeoutgaranti.
Afslut headers, og sørg for, at applikations-/serveringsstakken frigiver poster i stedet for at buffere dem lokalt. Bytes, der endnu ikke er sendt, kan ikke holde en nedstrøms mellemled aktiv.
Indsæt ikke SSE-kommentarer i almindeligt JSON eller binært indhold. En HTTP/1.1-chunk med nul længde afslutter en chunked body, så det er ikke et gentageligt tomt heartbeat.
Behold en operationel deadline og en annulleringspolitik. Trafikaktivitet alene viser ikke nyttig jobfremdrift eller et gyldigt slutresultat.