Expirarea inactivității proxy în timpul lucrărilor HTTP lungi
Alegeți interogarea sau un format de streaming definit când munca lungă a serverului întâlnește limita de inactivitate a unui proxy, în loc să inserați octeți arbitrari în răspunsul final.
Dacă un serviciu rămâne tăcut minute în șir și un proxy expiră, alegeți ce trebuie să primească clientul înainte de a adăuga octeți de bătaie a inimii. Prelungirea unui temporizator poate ajuta o așteptare; contractul răspunsului determină ce progres este valid.
| Designul aplicației | Contractul de progres |
|---|---|
| Sarcină asincronă | 202 Accepted cu o reprezentare care descrie monitorizarea, urmată de cereri de stare finite și stări explicite de finalizare/eșec |
| Flux Server-Sent Events | Content-Type: text/event-stream și înregistrări pe care clientul SSE le înțelege |
202 nu promite că sarcina va reuși. Pentru SSE, o înregistrare de comentariu poate arăta astfel:
: heartbeat
Două puncte o fac comentariu în loc de eveniment al aplicației. Notele de autor ale HTML sugerează comentarii periodice aproximativ la fiecare 15 secunde împotriva unor comportamente vechi de inactivitate ale proxy-urilor; aceasta este o indicație, nu o garanție universală de expirare.
Terminați anteturile și asigurați-vă că aplicația/stiva de servire eliberează înregistrările în loc să le stocheze local în buffer. Octeții încă netrimiși nu pot menține activ un intermediar din aval.
Nu inserați comentarii SSE în conținut JSON sau binar obișnuit. Un chunk de lungime zero HTTP/1.1 încheie un corp chunked, deci nu este o bătaie goală repetabilă.
Păstrați un termen limită de operare și o politică de anulare. Doar activitatea traficului nu arată progres util al sarcinii sau un rezultat final valid.