0

過去 2 日間のコードをまとめて、HTTP 1.1/1.0 プロキシをサポートする SSL を作成しました。HTTPWebResponse/HTTPWebRequest クラスを使用して、サーバーからデータを取得しました。サーバーからデータを中継している間、ヘッダーを取得したらすぐに最初にブラウザーに送信し、次にサーバーからの応答ストリームを送信します。ストリーム リーダーを使用して読み取り、それをブラウザーに転送すると、応答が Chunked にHTTPWebresponse.GetResponseStream()なると、ブラウザーがページの読み込みに失敗することに気付きました。しばらく時間を費やした後、GetResponseStream()既にデチャンクされているように見えるため、ブラウザーはそれを解析できません (チャンクされた応答ヘッダーが既にブラウザーに送信されて混乱しているため)。チャンクされたヘッダーを削除し、チャンクresponsestreamせずに一緒に送信することで回避策を作成しました。

しかし、fiddlercore (ロイヤルティ フリーのプロキシ ライブラリ) が、私が行った回避策を実行せずにチャンク データを中継していることに気付きました。.NET で記述されているため、チャンクを 1 つずつ中継する方法があるはずです。

私の質問は、ストリームを使用するときにプロキシでチャックされた応答を適切に中継する方法ですか? また、プロキシがローカル マシンを対象としている場合、チャンクせずにブラウザにデータを一緒に送信するとパフォーマンスが低下しますか (プロキシはサーバーでチャンクを使用し、要求された場合はその逆を行います)。

4

2 に答える 2

0

実際には、応答ストリームからバッファーに読み込むたびに、データを再度チャンクすることにしました (応答ヘッダーがチャンクされた応答を示している場合のみ)。再チャンクによるパフォーマンスの低下は無視できると思います。回避策で述べたように、すべてのチャンクが読み取られるのを待っていた場合、プロキシに使用できるメモリを爆破する可能性があります。

于 2013-09-03T20:51:43.133 に答える
0

FiddlerCore は HTTP/1.1 プロトコルの完全な実装であり、TCP/IP ソケットの上に直接記述されています。

そのため、上位レベルの WebRequest クラスに固有の制限に悩まされることはありません (プロトコルを自分で完全に実装しなければならなかったという代償を払って)。

于 2013-09-03T02:10:16.683 に答える