C＃でHTTPのための誤ったのContent-Lengthヘッダをシミュレート

Question

私たちは、アプリケーションをホストするためにIIS7を使用してHTTPの上に存在する我々のアプリケーションのためのC＃での包括的な統合テストフレームワークを構築しています。

クライアントは、それが実際に送信よりも大きなボディサイズを示すHTTPヘッダを送信するときに発生する、我々はEndOfStreamExceptionsになります着信要求をテストしたい私たちの統合テスト（「ストリームの終わりを超えて読み取ることができません」）の一環として、体の一部として。我々は要求のこれらの種類をシミュレートする必要があるので、この条件のために、当社のエラー回復コードをテストしたい。

私は、特に開発者は、当社の統合テストスイートに追加する、そのような条件をシミュレートすることができます.NET FxのベースソケットライブラリまたはカスタムHttpWebRequestの交換を探しています。誰がどのようなライブラリーを知っていますか？スクリプト化ソリューションも同様に動作します。

Answer 1

前GetRequestStream（またはBeginGetRequestStream）を呼び出すにん。ContentLengthプロパティを設定し、そのストリームに少ないバイト数を書き込みます。あなたが要求ストリームを得て後にそれを設定しようとするん。ContentLengthがスローされます。あなたはん。ContentLengthを設定しない場合、ストリームが閉じられるまで、HttpWebRequestのは、それが適切ん。ContentLengthを設定することができるように（交互に、あなたはSendChunkedを使用することができますが、それはここであなたのために動作しません）ヘッダをバッファリングします。あなたはこのを最大限に制御したい場合は、手でmalormed要求または2を作成し、サーバー上のポート80にソケットを開き、TCPストリームに書き込み要求をし、応答を読んで、それが閉じられたかどうかを確認するために、接続を確認してくださいます。

ただし、次の私は、このテストは良いアイデアであるとは思いません。ここに問題があります：

クライアントがサーバに要求を送信します。これは、コンテンツは100バイトになりますと主張します。その後、90のバイトを送信し、ちょうど送信を停止し、接続を開いたままに。サーバーは、クライアントが100のバイトが送信されるだろうと言ったので、その後、残りのを待ち、90のバイトを読み取ります。さて、クライアントが第2の要求を送信します。サーバーは、新しい要求の最初の10バイトで何をしますか？

答えは、サーバーがこれらのバイトは、前の要求の一部であったと仮定し、そのように扱われるということです、そして、明らかに不正な形式のヘッダーになりますこれは、その開始後に「新」要求10のバイトを読み始めます。それはの4xxエラーをお送りしますし、それは接続を閉じますので、サーバーは、以下のことを好きではないだろう。それは今それに送信されるデータは意味しないと回復する方法かを知る方法がないので、それが接続を閉じる理由があります。また、接続の閉鎖は優雅ではありません、それは（それらはキューに入れられている場合または第三または第四）第2の要求を提出しているもう一方の端に突然のこととHttpWebRequestのだろうと言ってWebExceptionをスローします基になる接続が閉じられ、理由を推測あなたを残しました。

この同じ現象は、接続が期待100-続けるヘッダで閉鎖させるものであり、サーバ100-続けるような認証が必要とされる場合として4XX続い返します。それは要求を拒否していますにもかかわらず、それはまだそれは100-続ける送信することによって、それらのバイトを受信することにコミットしているので、次のバイトは同じ要求の一部であると仮定しなければなりません。それはその要求にサービスを提供しない場合や、クライアントが（おそらく認証資格情報を使用して）新しいものを要求をキャンセルして提出したい場合、それは接続を閉じ、新しいものを開くことがあります。

最後に、TCPを使用して、ネットワークストリームからEndOfStreamExceptionのためのテストは全く私にはどんな意味がありません。 TCPストリームの「終わり」をマークしていない、それはちょうどそれがソケットに書き込まれると、データを送信し続けます。それには、「EOF」とあなたが期待するデータの量を知っている限り、データが全て送信されたかどうかを検出する方法はありません。 TCPは本当にあなたがスタックにあなたが動作している場所に応じてWebExceptionかのSocketExceptionを得るでしょう。その場合には、接続がクローズされていない限り、そのストリームに「終わり」を、持っていません。プロトコル内の任意の送信エラーがWinsockのに扱われます。それ以上のデータが送信されない場合は、接続の一端は、最終的には接続がまだ実際に開いていることを保証するために、他にキープアライブを送信すると、ホストは1つだけで、それをドロップしませんでした。アウトキープアライブ回場合は、接続が閉じられます、あなたはWebExceptionあなたがそれから読み取るしようとする次の時間を得ることができます。このすべてがどのように機能するかを考えると、私はちょうどあなたがこのテストのうちのいずれかの値を取得するつもりだ方法が表示されません。あなただけの不正なリクエストを送信すると、エラーがそれに応じて処理され、適切に4xxメッセージがクライアントに送り返されていると、接続が正しく閉じられていることを確実にオフはるかに良いです。

Answer 2

私はどのようなライブラリを知らないが、それはあなたがコーディングされている場合それがある場合には、受信側で、非常に簡単になります私には思える。

単に全体のWebRequestを取得し、それは前方に、その後にあなたが好きなだけかのように少し切り捨て、および。あなたは、プロセスにWebRequestクラスの新しいコピーを作成するのではなく、その場で切り捨てる必要があるかもしれませんが、それはまだストレートフォワードする必要があります。

Answer 3

あなただけのデータの実際のサイズよりも小さいか大きい値にクライアント上HttpWebRequest.ContentLengthプロパティを設定することができませんか？

Answer 4

あなたはHTTPプロトコルに違反している。このような任意のものを、シミュレートしたい場合は、それを行うには、独自のコードを記述する必要があります。 HttpWebRequestのは、あなたがこのようなことを行うことができません。