NetworkStream.DataAvailable markeert niet het einde van een HTTP-antwoord
Voorkom afgekapte HTTP-downloads door berichtframing te gebruiken in plaats van NetworkStream.DataAvailable als eindvoorwaarde.
NetworkStream.DataAvailable == false betekent dat er geen bytes klaarstaan om direct te lezen. Het betekent niet dat een HTTP-antwoord compleet is. Een lus die daar stopt, kan een volstrekt normale SOCKS-download afkappen tijdens een gat tussen pakketten.
Nadat SOCKS de TCP-verbinding tot stand heeft gebracht, levert de HTTP-framing nog steeds de voltooiingsregel:
- Een body met Content-Length eindigt na de opgegeven inhoudsbytes.
- Een chunked-antwoord heeft zijn afsluitende chunk en de toepasselijke trailers nodig.
- Een door de verbinding begrensd antwoord eindigt met de verbinding.
- Sommige statussen en antwoorden op HEAD hebben geen body.
Lees de status en de headers om de toepasselijke regel te bepalen. Alleen op sluiting wachten is geen algemene oplossing, omdat een compleet HTTP-antwoord de verbinding open kan laten. De capaciteit van één buffer is evenmin gerelateerd aan de lengte van het antwoord.
Gebruik de framing-implementatie van de HTTP-client wanneer die het gekozen proxytransport ondersteunt. Op een compatibele moderne .NET-runtime kun je de native SOCKS-ondersteuning van HttpClient overwegen. Een eigen implementatie moet de parseerstatus vasthouden over gedeeltelijke headers en body-lezingen, en een geslaagde voltooiing onderscheiden van annulering, time-out en een onverwachte EOF. Bij een niet-lege leesaanvraag betekent nul gelezen bytes dat de stream is beëindigd; dat is iets anders dan dat er op dit moment geen bytes in de wachtrij staan.
De proxy kan timinggaten zichtbaar maken, maar hij verandert een lege ontvangstwachtrij niet in een eind-van-bericht-markering.