チームテスト：ロードに失敗しました。要求が失敗しました：サーバーがプロトコル違反をコミットしました。 Section = ResponseHeader詳細= CRの後にLFを付ける必要があります

Question

QA部門の従業員は、Webアプリケーションに対して負荷テストを実行するためにVisual Studio Team Test（2008 IIRC）を使用します。

最新のテストはいくつかのページで失敗しました。報告されたエラーは、この使用して、Googleの検索

Request failed: The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF

でかなりの数の結果が得られます。このエラーメッセージは.NetフレームワークのWebRequestクラスから生成されるように見えます（つまり、Visual Studio固有のメッセージではありません）。最も有用な結果はthis oneです。これは私の正確な問題とその方法を詳しく説明していますをエラーを抑制します。

もちろん、このエラーが最初に発生する理由の一番下に行きたいと思います。 -

• このエラーは、以前のバージョンのWebアプリケーションに対してテストを実行したときに発生したことはありませんでした。ウェブアプリ。ホストOSとWebサーバー（Win 2003とIIS 6）はどちらの場合も同じです。
• 一部のページだけでこのエラーが発生するわけではありません。
• これらのページへの唯一の重大な変化が（私は考えることができることを）彼らはしなかった前に、彼らは今のに対し、いくつかのAJAXを使用することである（IIRC）

問題を絞り込むために、私は最も簡単に作成問題を再現できるページを作成してください。幸いにも、それほど難しくありませんでした。私はその後、Fiddlerを使用してヘッダーのバイトを検査しましたが、LF（0x0A）に続いていないCR（0x0D）の出現を見つけることができませんでした。

生のHTTPレスポンス（レスポンスの保存バイト数によってFiddlerから保存されたもので、保存中にエンコーディングを変更してはならない）は、私を信じていないとhere as textです！

これで、想定されるエラーが誤ったアラームである可能性があると考えられました。他の誰かがこれの経験を持っていますか？

Answer 1

これは誤った警告ではありません。Facebook APIと通信しようとしているときに、私のアプリでこのエラーが多く発生しています。 http://www.velocityreviews.com/forums/t302174-why-do-i-get-the-server-committed-a-protocol-violation.html - -

私はちょうどスティーブン・チェンから、この応答につまずいてきたと私は彼を引用してみましょう：あなたは にいくつかのHTTPリクエストを送信するために HttpWebRequestのコンポーネントを使用しているあなたの説明から、

をいくつかの外部Web リソースにASP.NET Web アプリケーションのリソース。

<system.net> 
<settings> 
<httpWebRequest useUnsafeHeaderParsing="true" /> 
</settings> 
</system.net> 

：しかし、あなたは常に あなたがweb.configファイルに次のセクション を設定しない限り、エラー 「サーバは プロトコル違反 節= ResponseStatusLineを犯した」取得していますそして、あなたはこの行動の原因を疑問に思っています、正しい？

は、この問題については、私はこの上でいくつかの 研究を行い、 問題が実際に HttpWebRequestのをコンポーネントの 重要なHTTPヘッダ 解析/検証することによって引き起こされていることがわかりました。 HTTP仕様（http1.1）によると、 HTTPヘッダーキーは特に の名前にスペースは含まれていません。 しかし、一部のWebサーバーでは、それらが意図している標準を完全に遵守していません。 Dotnet フレームワーク上で動作し、http リクエストを頻繁に使用するアプリケーションは、通常、 httpWebRequestクラスを使用します。 は、開発者が夢見るようなWebのすべてをカプセル化します。 セキュリティに関する最近の問題では、 "httpWebRequest"クラスは 自己防御メカニズムを提供し、 は、 が完全に仕様に適合しないHTTP応答を受け入れることを妨げています。

一般的なケースでは、「content-length」ヘッダーキーのスペースに「 」という空白があります。 サーバが実際に許可されていないスペース を想定していない、「コンテンツ 長さ」キーを返し、 攻撃ベクトルとして考えられている「HTTP プロトコル違反エラー」例外をトリガする、従って、（HTTP応答が 攻撃を分割します）。

後で

これが今の場合に役立ちます試してみて、その結果を掲載します