Timeout di inattività dei proxy durante lavori HTTP lunghi
Scegli il polling o un formato di streaming definito quando il lungo lavoro del server incontra il limite di inattività di un proxy, invece di inserire byte arbitrari nella risposta finale.
Se un servizio resta silenzioso per minuti e un proxy va in timeout, scegli cosa deve ricevere il client prima di aggiungere byte di heartbeat. Estendere un timer può aiutare un'attesa; il contratto di risposta determina quale progresso è valido.
| Progettazione dell'applicazione | Contratto di avanzamento |
|---|---|
| Lavoro asincrono | 202 Accepted con una rappresentazione che descrive il monitoraggio, seguita da richieste di stato finite e stati espliciti di completamento/errore |
| Flusso Server-Sent Events | Content-Type: text/event-stream e record che il client SSE comprende |
202 non promette che il lavoro riesca. Per SSE, un record di commento può apparire così:
: heartbeat
I due punti lo rendono un commento anziché un evento dell'applicazione. Le note di authoring di HTML suggeriscono commenti periodici all'incirca ogni 15 secondi contro alcuni vecchi comportamenti di inattività dei proxy; è una guida, non una garanzia universale di timeout.
Completa le intestazioni e assicurati che l'applicazione/stack di servizio rilasci i record invece di tenerli in buffer localmente. I byte non ancora inviati non possono mantenere attivo un intermediario a valle.
Non inserire commenti SSE in contenuti JSON o binari ordinari. Un chunk di lunghezza zero HTTP/1.1 termina un corpo chunked, quindi non è un heartbeat vuoto ripetibile.
Mantieni una scadenza operativa e una politica di annullamento. La sola attività del traffico non mostra un progresso utile del lavoro né un risultato finale valido.