.net解析Transfer-Enccoding：chunked秒ネット上の無駄な方案を落とします。

昨日データを登りながら、あるウェブサイトのResonse.Getから来たデータはずっと空です。その時はとても不思議で、真剣に応答の頭を見ました。Transfer-Enccoding:chunkedというゲームを発見しました。
インターネットで資料を調べました。
一般的にHTTPのHeaderは、Conteet-Lengthドメインを含み、報告文体の長さを指定する。
場合によっては、サービスがHTTP応答を生成すると、大きなファイルのダウンロードや、バックグラウンドが複雑な論理を必要として、ページ全体の要求を処理するために、リアルタイムでメッセージ長を生成する必要があり、サーバーは一般的にchunked符号化を使用する。
Chunked符号化伝送を行う場合、返信メッセージのHeadersには、トランスポートコンテンツをchunkedで符号化するtransfer-encodingドメイン値があります。chunkedを使用して符号化されたHeadersは（FireFoxのFireBugプラグインまたはHttpWatchを利用してHeaders情報を調べられ、HttpWatchはchunkedの個数も調べられます）：
コードはいくつかのChunkを使用して構成され、長さ0を表記するchunkによって終了し、各Chunkには2つの部分があり、第1の部分はこのChunkの長さと長さの単位（一般には書かない）であり、第2の部分は長さを指定する内容であり、各部分はCRLFで区切られている。最後の長さが0のChunkでは、footerという内容で、書かれていない頭の内容があります。
これはネット上の原語です。詳しくは中を参考にしてみてください。
でもネット上の多くはchunked.net解析に関してはtmdが役に立たないので、コードを貼ってください。後ろの友達はもう痛くないでください。
兄も解析コードが書けなくて、インターネットで探したいです。国内で探しているのは全部千平たいです。最後に海外のフォーラムで方案を見つけました。
最後にFiddlerのデバッグを通して、POSTのウェブサイトがConteet-Lengthに戻ってきました。この時、心が爆発しました。長い間探しましたが、Lengthが戻ってきたと教えてくれました。しかし、ブラウザF 12で見たのはTransfer-Enccoding:chunkedです。
Fiddler上でデバッグをシミュレーションしてみて、要求前に、要求後の変化を見てください。
ブラウザ要求ヘッダの内容をFiddlerのパラメータにコピーして、execをクリックして、応答エリアが空と表示されます。私の神よ、このtmdはどんな状況ですか？パラメータに問題がありますか？よく照らし合わせると、問題があることが分かります。
があります
その時は特にCookieに注意していませんでした。Cookieは空です。ブラウザの中のCookie情報をコピーします。exec、断点が命中しました。。。。。。。このサイトのPOSTはクッキーを必要としています。
解析コードも見つけました。それでは.netコードをチェックします。運行して、データを手に入れました。。。書きません
コードを張る 

StringBuilder sb1 = new StringBuilder();
Byte[] buf = new byte[256];
Stream resStream = myHttpWebResponse.GetResponseStream();


resStream = new GZipStream(resStream, CompressionMode.Decompress);


string tmpString = null;
int count = 0;
do
{
	count = resStream.Read(buf, 0, buf.Length - 1);
	if (count != 0)
	{
		tmpString = Encoding.UTF8.GetString(buf, 0, count);
		sb1.Append(tmpString);
	}
} while (count > 0);

参照
https://imququ.com/post/transfer-encoding-header-in-http.html
もう一つのサイトが見つからなくなりました。かわいそうです。
http://www.dayuji1000.com/vrtechnews/index.html
http://www.xafuda.cn/article/jnd3.5.html