NetworkStream.DataAvailable ne markas la finon de HTTP-respondo
Evitu tranĉitajn HTTP-elŝutojn uzante mesaĝkadrigon anstataŭ NetworkStream.DataAvailable kiel fina kondiĉo.
NetworkStream.DataAvailable == false signifas, ke neniu bajto pretas por tuja legado. Ĝi ne signifas, ke HTTP-respondo estas kompleta. Buklo, kiu haltas tie, povas tranĉi tute normalan SOCKS-elŝuton dum paŭzo inter pakoj.
Post kiam SOCKS starigas la TCP-ligon, la HTTP-kadrigo ankoraŭ donas la kompletigan regulon:
- Korpo kun Content-Length finiĝas post la deklaritaj enhavbajtoj.
- Chunked-respondo bezonas sian finan chunk kaj la aplikeblajn trailers.
- Respondo limigita per la konekto finiĝas kun la konekto.
- Iuj statusoj kaj respondoj al HEAD havas neniun korpon.
Legu la statuson kaj kapliniojn por determini la aplikeblan regulon. Atendi nur fermon ne estas ĝenerala solvo, ĉar kompleta HTTP-respondo povas lasi la konekton malfermita. La kapacito de unu bufro same rilatas neniom al la longo de la respondo.
Uzu la kadrigan implementon de la HTTP-kliento kiam ĝi subtenas la elektitan prokuran transporton. Sur kongrua moderna .NET-rultempo, konsideru la denaskan SOCKS-subtenon de HttpClient. Kruda implemento devas konservi analizan staton trapartaj kaplinioj kaj korpaj legadoj kaj distingi sukcesan kompletigon de nuligo, tempolimo kaj neatendita EOF. Por ne-malplena legopeto, nulo da legita bajtoj signifas, ke la fluo finiĝis; tio malsamas de tio, ke neniu bajto estas en la vico ĝuste nun.
La prokuro povas igi tempopaŭzojn rimarkeblaj, sed ĝi ne transformas malplenan ricevan vicon en markilon de mesaĝfino.