Leerlauf-Timeouts von Proxys bei langen HTTP-Aufträgen
Wählen Sie Polling oder ein definiertes Streaming-Format, wenn lange Serverarbeit das Leerlauf-Limit eines Proxys erreicht, statt beliebige Bytes in die endgültige Antwort einzufügen.
Wenn ein Dienst minutenlang schweigt und ein Proxy in einen Timeout läuft, entscheiden Sie, was der Client erhalten soll, bevor Sie Heartbeat-Bytes hinzufügen. Eine Frist zu verlängern kann einem Warten helfen; der Antwortvertrag bestimmt, welcher Fortschritt gültig ist.
| Anwendungsdesign | Fortschrittsvertrag |
|---|---|
| Asynchroner Auftrag | 202 Accepted mit einer Darstellung, die die Überwachung beschreibt, gefolgt von endlichen Statusabfragen und expliziten Abschluss-/Fehlerzuständen |
| Server-Sent-Events-Stream | Content-Type: text/event-stream und Datensätze, die der SSE-Client versteht |
202 verspricht nicht, dass der Auftrag gelingt. Für SSE kann ein Kommentardatensatz so aussehen:
: heartbeat
Der Doppelpunkt macht ihn zu einem Kommentar statt zu einem Anwendungsereignis. Die Autorenhinweise von HTML empfehlen periodische Kommentare etwa alle 15 Sekunden gegen ein gewisses altes Leerlaufverhalten von Proxys; das ist eine Empfehlung, keine allgemeine Timeout-Garantie.
Schließen Sie die Header ab und stellen Sie sicher, dass der Anwendungs-/Auslieferungs-Stack Datensätze freigibt, statt sie lokal zu puffern. Noch nicht gesendete Bytes können einen nachgelagerten Vermittler nicht aktiv halten.
Fügen Sie SSE-Kommentare nicht in gewöhnliche JSON- oder Binärinhalte ein. Ein HTTP/1.1-Chunk der Länge null beendet einen chunked Body, ist also kein wiederholbarer leerer Heartbeat.
Behalten Sie eine Operationsfrist und eine Abbruchrichtlinie bei. Verkehrsaktivität allein zeigt keinen nützlichen Auftragsfortschritt oder ein gültiges Endergebnis.