NetworkStream.DataAvailable dui nie die einde van 'n HTTP-antwoord aan nie
Voorkom afgekapte HTTP-aflaaie deur boodskapraamwerk te gebruik in plaas van NetworkStream.DataAvailable as die eindvoorwaarde.
NetworkStream.DataAvailable == false beteken daar is geen grepe wat onmiddellik gelees kan word nie. Dit beteken nie dat 'n HTTP-antwoord voltooi is nie. 'n Lus wat daar stop, kan 'n heeltemal normale SOCKS-aflaai tydens 'n gaping tussen pakkette afkap.
Nadat SOCKS die TCP-verbinding opgestel het, verskaf HTTP-raamwerk steeds die voltooiingsreël:
- 'n Content-Length-liggaam eindig ná sy verklaarde inhoudgrepe.
- 'n Chunked-antwoord benodig sy afsluitende chunk en toepaslike trailers.
- 'n Verbinding-afgebakende antwoord eindig saam met die verbinding.
- Sommige statusse en antwoorde op HEAD het geen liggaam nie.
Lees status en koptekste om die toepaslike reël te bepaal. Om net op sluiting te wag is nie 'n algemene oplossing nie, want 'n volledige HTTP-antwoord kan die verbinding oop laat. Die kapasiteit van een buffer is ewe onverwant aan die antwoordlengte.
Gebruik die HTTP-kliënt se raamwerkimplementering wanneer dit die gekose proxy-vervoer ondersteun. Op 'n versoenbare moderne .NET-looptyd kan jy HttpClient se ingeboude SOCKS-ondersteuning oorweeg. 'n Rou implementering moet ontledingstoestand oor gedeeltelike koptekste en liggaamslees behou en suksesvolle voltooiing van kansellasie, tydsverloop en onverwagte EOF onderskei. Vir 'n nie-leë leesversoek beteken nul grepe gelees dat die stroom geëindig het; dit verskil van geen grepe wat nou in die ry is nie.
Die proxy kan tydsgapinge opvallend maak, maar dit verander nie 'n leë ontvangsry in 'n einde-van-boodskap-merker nie.