サーバーはプロトコル違反をコミットしました。 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応答を返していましたが、同時に応答本体を定義していました。この回答が私とおそらく他の人に、bodyでNoContent応答を返さないことを思い出させてください。
この動作は、10.2.5 204 HTTP仕様 のコンテンツなしと一致します。
204応答にはメッセージ本文を含めてはならない（MUST NOT）ため、ヘッダーフィールドの後の最初の空行で常に終了します。
別の可能性：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に拡張ラテン文字が含まれている場合です。
このエラーの別の考えられる原因は、WebサーバーがUTF-8を使用して、バイトオーダーマーカー（BOM）を出力する場合です。たとえば、デフォルトの定数Encoding.UTF8はBOMを出力しますが、これは簡単に忘れてしまいます。 WebページはFirefoxおよびChromeで正常に動作しますが、HttpWebRequestは爆撃します:)。簡単な修正方法は、BOMを出力しないUTF-8エンコードを使用するようにWebサーバーを変更することです。 new UTF8Encoding(false)（Response-Phraseに含まれるのはASCII文字だけですが、実際にはヘッダーにASCIIまたはISO-8859-1を使用する必要があります。次にUTF-8または応答の他のエンコード）。
スカイプが私の問題の主な原因でした：
このエラーは通常、既存のWebアプリケーションをデバッグするようにVisual Studioをセットアップしたときに発生しますASP.NETに組み込まれているのではなく、IISで実行されている Webサーバーをデバッグします。 IISはデフォルトでポート80でWebリクエストをリッスンします。この場合、別のアプリケーションはすでにポート80でリクエストをリッスンしています。通常、問題のアプリケーションはSkypeです。インストール時に443。 Skypeはすでにポート80を占有しています。そのため、IISは起動できません。
この問題を解決するには、次の手順に従います。
Skype->ツール->オプション->詳細->接続：
「着信接続の代替としてポート80および443を使用する」のチェックを外します。
そして、以下で指摘したように、IISリセットを実行一度実行します。
Expect 100をfalseに設定し続けると、ソケットのアイドル時間が2秒に短縮され、問題が解決しました
ServicePointManager.Expect100Continue = false;
ServicePointManager. MaxServicePointIdleTime = 2000;
プロキシの背後から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;
この問題の考えられる原因は、ネットワーク上のWebプロキシ自動検出プロトコル（WPAD）構成です。 HTTP要求は透過的にプロキシに送信され、プロキシはクライアントが受け入れない、または受け入れるように構成されていない応答を送り返すことができます。コードを少しずつハッキングする前に、WPADが機能していないことを確認してください。特に、これが突然発生した場合はなおさらです。
いずれのソリューションも役に立たなかったため、HttpWebRequestの代わりにWebClientを使用する必要があり、問題はもうなくなりました。
CookieContainerを使用する必要があったため、このスレッドでPavel Savaraが投稿したソリューションを使用しました- WebClientクラスでのCookieContainerの使用
この行から「保護」を削除するだけです：
プライベート読み取り専用CookieContainer container = new CookieContainer（）;
私の問題は、httpsでhttpエンドポイントを呼び出したことです。
最初に試みたのは、IISの動的コンテンツ圧縮を無効にすることでした。これにより、エラーは解決されましたが、サーバー側ではなく、1つのクライアントのみが影響を受けました。
クライアント側では、VPNクライアントをアンインストールし、インターネット設定をリセットしてから、VPNクライアントを再インストールしました。このエラーは、ファイアウォールを備えた以前のアンチウイルスによっても発生した可能性があります。その後、バックダイナミックコンテンツ圧縮を有効にし、以前と同様に正常に動作するようになりました。
WebサービスおよびTFSに接続するカスタムアプリケーションでエラーが発生しました。
コードを参照して、ヘッダーにNULLまたは空の値を設定しているかどうかを確認してください。
私は私のPHP JSON/RESTサービスからこのエラーを取得し始めました
最も頻繁にアクセスするGET phpスクリプトにob_start("ob_gzhandler")を追加した後、まれなPOSTアップロードからエラーが発生し始めました
ob_start()だけを使用できますが、すべて問題ありません。
私の場合、IISには、関連するASPXパスにアクセスするために必要な権限がありませんでした。
関連ディレクトリへのIISユーザー権限を付与しましたが、すべてうまくいきました。