Limity bezczynności proxy podczas długich zadań HTTP
Wybierz odpytywanie lub zdefiniowany format strumieniowania, gdy długa praca serwera napotyka limit bezczynności proxy, zamiast wstawiać dowolne bajty do końcowej odpowiedzi.
Jeśli usługa milczy przez minuty i proxy przekracza limit czasu, wybierz, co klient ma otrzymać, zanim dodasz bajty pulsu. Wydłużenie licznika może pomóc jednemu oczekiwaniu; kontrakt odpowiedzi określa, jaki postęp jest ważny.
| Projekt aplikacji | Kontrakt postępu |
|---|---|
| Zadanie asynchroniczne | 202 Accepted z reprezentacją opisującą monitorowanie, po czym następują skończone żądania stanu i jawne stany zakończenia/błędu |
| Strumień Server-Sent Events | Content-Type: text/event-stream i rekordy, które rozumie klient SSE |
202 nie obiecuje, że zadanie się powiedzie. W przypadku SSE rekord komentarza może wyglądać tak:
: heartbeat
Dwukropek czyni go komentarzem, a nie zdarzeniem aplikacji. Notatki autorskie HTML sugerują okresowe komentarze mniej więcej co 15 sekund przeciw pewnym starym zachowaniom bezczynności proxy; to wskazówka, a nie uniwersalna gwarancja limitu czasu.
Dokończ nagłówki i upewnij się, że aplikacja/stos serwujący zwalnia rekordy zamiast buforować je lokalnie. Bajty jeszcze niewysłane nie mogą utrzymać aktywnego pośrednika niższego poziomu.
Nie wstawiaj komentarzy SSE do zwykłej treści JSON lub binarnej. Fragment o zerowej długości HTTP/1.1 kończy ciało chunked, więc nie jest powtarzalnym pustym pulsem.
Zachowaj termin operacji i politykę anulowania. Sama aktywność ruchu nie pokazuje użytecznego postępu zadania ani ważnego wyniku końcowego.