NetworkStream.DataAvailable markearret net it ein fan in HTTP-antwurd
Foarkom ôfbrutsen HTTP-downloads troch berjochtkadearring te brûken ynstee fan NetworkStream.DataAvailable as eindbetingst.
NetworkStream.DataAvailable == false betsjut dat der gjin bytes klear binne om daliks te lêzen. It betsjut net dat in HTTP-antwurd foltôge is. In lus dy't dêr stopt, kin in folslein normale SOCKS-download ôfbrekke yn in gat tusken pakketten.
Nei't SOCKS de TCP-ferbining oanmakke hat, jout de HTTP-kadearring noch altyd de foltôgingsregel:
- In Content-Length-lichem einiget nei de oanjûne ynhâldsbytes.
- In chunked-antwurd hat syn ôfslutende chunk en de tapaslike trailers nedich.
- In antwurd dat troch de ferbining beheind wurdt, einiget mei de ferbining.
- Guon statussen en antwurden op HEAD hawwe gjin lichem.
Lês de status en de kopteksten om de tapaslike regel te bepalen. Allinnich op sluting wachtsje is gjin algemiene oplossing, om't in folslein HTTP-antwurd de ferbining iepen litte kin. De kapasiteit fan ien buffer is like ûnferbânlik mei de lingte fan it antwurd.
Brûk de kadearringsimplemintaasje fan 'e HTTP-klient as dy it keazen proxyferfier stipet. Op in kompatibele moderne .NET-runtime kinst de native SOCKS-stipe fan HttpClient beskôgje. In rûge ymplemintaasje moat parsearstatus behâlde oer partiele kopteksten en lichemslêzingen en slagge foltôging ûnderskiede fan annulearring, time-out en ûnferwachte EOF. Foar in net-lege lêsopdracht betsjut nul lêzen bytes dat de stream einige is; dat is oars as dat der op dit stuit gjin bytes yn 'e rige steane.
De proxy kin tiidgatten opfallend meitsje, mar hy feroaret in lege ûntfangstrige net yn in marker foar it ein fan in berjocht.