NetworkStream.DataAvailable markiert nicht das Ende einer HTTP-Antwort
Verhindern Sie abgeschnittene HTTP-Downloads, indem Sie Nachrichten-Framing statt NetworkStream.DataAvailable als Endbedingung verwenden.
NetworkStream.DataAvailable == false bedeutet, dass keine Bytes sofort zum Lesen bereitstehen. Es bedeutet nicht, dass eine HTTP-Antwort vollständig ist. Eine Schleife, die dort abbricht, kann einen völlig normalen SOCKS-Download während einer Lücke zwischen Paketen abschneiden.
Nachdem SOCKS die TCP-Verbindung aufgebaut hat, liefert weiterhin das HTTP-Framing die Vollständigkeitsregel:
- Ein Body mit Content-Length endet nach den angegebenen Inhaltsbytes.
- Eine chunked-Antwort benötigt ihren abschließenden Chunk und die zutreffenden Trailer.
- Eine verbindungsbegrenzte Antwort endet mit der Verbindung.
- Manche Statuscodes und Antworten auf HEAD haben keinen Body.
Lesen Sie Status und Header, um die zutreffende Regel zu bestimmen. Nur auf das Schließen zu warten ist keine allgemeine Lösung, denn eine vollständige HTTP-Antwort kann die Verbindung offen lassen. Die Kapazität eines Puffers ist ebenso unabhängig von der Länge der Antwort.
Verwenden Sie die Framing-Implementierung des HTTP-Clients, wenn sie den gewählten Proxy-Transport unterstützt. Auf einer kompatiblen modernen .NET-Laufzeit kommt die native SOCKS-Unterstützung von HttpClient infrage. Eine eigene Implementierung muss den Parsing-Zustand über Teil-Header und Body-Lesevorgänge hinweg halten und erfolgreichen Abschluss von Abbruch, Timeout und unerwartetem EOF unterscheiden. Bei einer nicht leeren Leseanfrage bedeutet null gelesene Bytes, dass der Stream beendet ist; das ist etwas anderes, als dass gerade keine Bytes in der Warteschlange stehen.
Der Proxy kann Zeitspitzen sichtbar machen, aber er verwandelt eine leere Empfangswarteschlange nicht in eine End-of-Message-Marke.