サーバーはプロトコル違反をコミットしました。Section = ResponseStatusLine ERROR

プログラムを作成し、サイトに文字列を投稿しようとしたところ、次のエラーが発生しました。

「サーバーがプロトコル違反をコミットしました。Section= ResponseStatusLine」

このコード行の後：

gResponse = (HttpWebResponse)gRequest.GetResponse(); 

この例外を修正するにはどうすればよいですか？

これをapp / web.configに入れてみてください：

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

これが機能しない場合は、 KeepAliveプロパティをfalseに。

このエラーは時々発生します UserAgentリクエストパラメータが空の場合（場合はgithub.com api）に。

このパラメーターを空ではないカスタム文字列に設定すると、問題が解決しました。

私の場合の犯人はNo Content応答を返していましたが、同時に応答本文を定義していました。この答えが私やおそらく他の人に、体で再び応答を返さないNoContentように思い出させますように。

この動作はと一致している10.2.5 204ノーコンテンツのHTTPの仕様と言います：

204応答にはメッセージ本文を含めてはならないため、常にヘッダーフィールドの後の最初の空行で終了します。

もう1つの可能性：POSTを実行すると、サーバーは100継続で応答し、誤った方法で続行します。

これは私にとって問題を解決しました：

request.ServicePoint.Expect100Continue = false;

これは、ローカルマシンでSkypeを実行しているときに起こりました。私が閉鎖するとすぐに、例外はなくなりました。

このページの礼儀アイデア

これをデバッグする1つの方法（および問題の原因となっているプロトコル違反であることを確認する）は、Fiddler（Http Web Proxy）を使用して、同じエラーが発生するかどうかを確認することです。解決しない場合（つまり、Fiddlerが問題を処理した場合）、UseUnsafeHeaderParsingフラグを使用して修正できるはずです。

この値をプログラムで設定する方法を探している場合は、次の例を参照してください。http：//o2platform.wordpress.com/2010/10/20/dealing-with-the-server-committed-a-protocol-violation-sectionresponsestatusline /

多くの解決策は回避策について話しますが、エラーの実際の原因については話しません。

このエラーの1つの考えられる原因は、Webサーバーがヘッダー応答セクション以外のエンコーディングを使用しているASCIIかISO-8859-1、ヘッダー応答セクションを出力しているかどうかです。使用ISO-8859-1する理由は、Response-Phraseに拡張ラテン文字が含まれている場合です。

このエラーのもう1つの考えられる原因はUTF-8、バイトオーダーマーカー（BOM）を出力するWebサーバーが使用している場合です。たとえば、デフォルトの定数Encoding.UTF8はBOMを出力しますが、これは忘れがちです。ウェブページはFirefoxとChromeで正しく動作しますが、HttpWebRequest爆撃されます:)。クイックフィックスは出力BOM、例えばないUTF-8エンコーディングを使用するWebサーバを変更することであるnew UTF8Encoding(false)限りとしてOKです（Response-PhraseASCII文字のみが含まれているが、しかし実際にそれを使うべきASCIIかISO-8859-1、ヘッダーのため、その後、UTF-8または応答用の他のエンコーディング）。

expect 100を設定するとfalseが続き、ソケットのアイドル時間を2秒に減らすと問題が解決しました

ServicePointManager.Expect100Continue = false; 
ServicePointManager. MaxServicePointIdleTime = 2000; 

Skypeが私の問題の主な原因でした。

このエラーは通常、組み込みのASP.NETではなくIISで実行されている既存のWebアプリケーションをデバッグするようにVisual Studioを設定した場合に発生します。デバッグWebサーバーます。IISはデフォルトでポート80でWebリクエストをリッスンします。この場合、別のアプリケーションがすでにポート80でリクエストをリッスンしています。通常、問題のアプリケーションはSkypeで、インストール時にデフォルトでポート80と443をリッスンします。Skypeはすでにポート80を使用しています。そのため、IISを起動できません。

この問題を解決するには、次の手順に従います。

Skype->ツール->オプション->詳細->接続：

「着信接続の代替としてポート80および443を使用する」のチェックを外します。

また、以下で指摘するように、完了したらIISリセットを実行します。

プロキシの背後からLast.fm Rest APIにアクセスしようとすると、この有名なエラーが発生しました。

サーバーはプロトコル違反をコミットしました。Section = ResponseStatusLine

いくつかの回避策を試した後、これら2つだけが私のために働いた

HttpWebRequest HttpRequestObj = WebRequest.Create(BaseUrl) as HttpWebRequest;
HttpRequestObj.ProtocolVersion = HttpVersion.Version10;

そして

HttpWebRequest HttpRequestObj = WebRequest.Create(BaseUrl) as HttpWebRequest;
HttpRequestObj.ServicePoint.Expect100Continue = false;

解決策はどれも私にとってはうまくいかなかったので、HttpWebRequestの代わりにWebClientを使用する必要があり、問題はもうありませんでした。

私はCookieContainerを使用する必要があったので、このスレッドでPavel Savaraが投稿したソリューションを使用しました- を使用しました-WebClientクラスでのCookieContainerの使用

この行から "protected"を削除するだけです：

読み取り専用のCookieContainerコンテナ=新しいCookieContainer（）;

この問題の原因として考えられるのは、ネットワーク上のWebプロキシ自動検出プロトコル（WPAD）構成です。HTTP要求は、クライアントが受け入れないか、受け入れるように構成されていない応答を返信できるプロキシに透過的に送信されます。コードをビットにハッキングする前に、WPADが機能していないことを確認してください。特に、これが突然「発生し始めた」場合は特にそうです。

私の問題は、でhttpsエンドポイントを呼び出すことでしたhttp。

私たちが最初に試みたのは、IISの動的コンテンツ圧縮を無効にすることでした。これによりエラーが解決しましたが、エラーの原因はサーバー側ではなく、1つのクライアントだけが影響を受けました。

クライアント側では、VPNクライアントをアンインストールし、インターネット設定をリセットしてから、VPNクライアントを再インストールしました。このエラーは、ファイアウォールがあった以前のアンチウイルスによっても発生する可能性があります。次に、動的コンテンツ圧縮を有効にしましたが、以前と同様に正常に機能します。

Webサービスに接続するカスタムアプリケーションおよびTFSでエラーが発生しました。

私の場合、IISには関連するASPXパスにアクセスするために必要な権限がありませんでした。

IISユーザーに関連ディレクトリへのアクセス許可を与えましたが、すべて順調でした。

コードを見て、ヘッダーにNULLまたは空の値を設定しているかどうかを確認してください。

私のPHP JSON / RESTサービスからこのエラーが発生し始めました

ob_start("ob_gzhandler")最も頻繁にアクセスされるGET PHPスクリプトに追加した後、私は相対珍しいPOSTアップロードからエラーを取得し始めました

私はちょうど使用することができob_start()、すべてが大丈夫です。