서버가 프로토콜 위반을 커밋했습니다. 섹션 = ResponseStatusLine 오류

프로그램을 만들고 사이트에 문자열을 게시하려고 시도했는데이 오류가 발생합니다.

"서버가 프로토콜 위반을 커밋했습니다. 섹션 = 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 상기 시키길 바랍니다.

이 동작은 다음과 같은 HTTP 사양 의 10.2.5 204 내용 없음 과 일치합니다 .

204 응답은 메시지 본문을 포함하지 않아야하며 따라서 항상 헤더 필드 다음의 첫 번째 빈 줄로 종료됩니다.

또 다른 가능성 : POST를 수행 할 때 서버가 잘못된 방식으로 100 계속으로 응답합니다.

이것은 나를 위해 문제를 해결했습니다.

request.ServicePoint.Expect100Continue = false;

이것은 내 로컬 컴퓨터에서 Skype를 실행했을 때 발생했습니다. 종료하자마자 예외가 사라졌습니다.

이 페이지의 아이디어 제공

이를 디버깅하는 한 가지 방법 (문제를 일으키는 프로토콜 위반인지 확인)은 Fiddler (Http 웹 프록시)를 사용하여 동일한 오류가 발생하는지 확인하는 것입니다. 그렇지 않은 경우 (예 : Fiddler가 문제를 처리 한 경우) UseUnsafeHeaderParsing 플래그를 사용하여 문제를 해결할 수 있습니다.

이 값을 프로그래밍 방식으로 설정하는 방법을 찾고 있다면 여기에서 예제를 참조하십시오. http://o2platform.wordpress.com/2010/10/20/dealing-with-the-server-committed-a-protocol-violation-sectionresponsestatusline /

많은 솔루션이 해결 방법에 대해 이야기하지만 오류의 실제 원인에 대해서는 설명하지 않습니다.

이 오류의 한 가지 가능한 원인은 웹 서버가 헤더 응답 섹션을 출력하기 위해 ASCII또는 이외의 인코딩을 사용하는 경우 ISO-8859-1입니다. 사용하는 이유 는 확장 라틴 문자 ISO-8859-1가 Response-Phrase포함 된 경우 입니다.

이 오류의 또 다른 가능한 원인은 웹 서버가 UTF-8BOM (byte-order-marker)을 출력하는 것을 사용 하는 경우 입니다. 예를 들어, 기본 상수 Encoding.UTF8는 BOM을 출력하며이를 잊기 쉽습니다. 웹 페이지는 파이어 폭스와 크롬에서 제대로 작동하지만 HttpWebRequest폭탄을 터뜨릴 것입니다 :). 빠른 수정 출력 BOM, 예를 들어하지 않는 UTF-8 인코딩 사용하도록 웹 서버를 변경하는 것입니다 new UTF8Encoding(false)오랫동안 같이으로 OK입니다 ( Response-PhraseASCII 문자 만 포함,하지만 정말 사용해야 ASCII또는 ISO-8859-1헤더에 대한 다음 UTF-8또는 응답을위한 다른 인코딩).

100을 계속해서 false로 설정하고 소켓 유휴 시간을 2 초로 줄이면 문제가 해결되었습니다.

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

Skype가 내 문제의 주요 원인이었습니다.

이 오류는 일반적으로 기본 제공 ASP.NET 디버그 웹 서버가 아닌 IIS에서 실행중인 기존 웹 응용 프로그램을 디버깅하도록 Visual Studio를 설정 한 경우에 발생 합니다. IIS는 기본적으로 포트 80에서 웹 요청을 수신합니다.이 경우 다른 응용 프로그램은 이미 포트 80에서 요청을 수신하고 있습니다. 일반적으로 문제가되는 응용 프로그램은 Skype이며 설치시 기본적으로 포트 80 및 443에서 수신 대기합니다. Skype는 이미 포트 80을 사용하고 있습니다. 따라서 IIS를 시작할 수 없습니다.

문제를 해결하려면 다음 단계를 따르십시오.

Skype-> 도구-> 옵션-> 고급-> 연결 :

"수신 연결에 대한 대안으로 포트 80 및 443 사용"을 선택 취소합니다.

그리고 아래에서 지적했듯이 IIS 재설정 을 수행하십시오.

프록시 뒤에서 Last.fm Rest API에 액세스하려고했는데이 유명한 오류가 발생했습니다.

서버가 프로토콜 위반을 커밋했습니다. Section = ResponseStatusLine

몇 가지 해결 방법을 시도한 후이 두 가지만 나를 위해 일했습니다.

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 컨테이너 = new CookieContainer ();

이 문제의 가능한 원인은 네트워크의 WPAD (Web Proxy Auto Discovery Protocol) 구성입니다. HTTP 요청은 클라이언트가 수락하지 않거나 수락하도록 구성되지 않은 응답을 다시 보낼 수있는 프록시로 투명하게 전송됩니다. 코드를 비트로 해킹하기 전에 WPAD가 작동하지 않는지 확인하십시오. 특히 이것이 갑자기 "시작된"경우에는 더욱 그렇습니다.

내 문제는 내가라는 것이 었습니다 https으로 엔드 포인트를 http.

가장 먼저 시도한 것은 IIS에 대한 동적 콘텐츠 압축을 비활성화하는 것이 었는데, 이로 인해 오류가 해결되었지만 오류는 서버 측에서 발생하지 않았으며 단 하나의 클라이언트 만 영향을 받았습니다.

클라이언트 측에서 VPN 클라이언트를 제거하고 인터넷 설정을 재설정 한 다음 VPN 클라이언트를 다시 설치했습니다. 방화벽이있는 이전 바이러스 백신으로 인해 오류가 발생할 수도 있습니다. 그런 다음 동적 콘텐츠 압축을 다시 활성화했으며 이제 이전과 같이 잘 작동합니다.

웹 서비스 및 TFS에 연결하는 사용자 지정 응용 프로그램에 오류가 나타났습니다.

제 경우에는 IIS에 관련 ASPX 경로에 액세스하는 데 필요한 권한이 없었습니다.

IIS 사용자에게 관련 디렉토리에 대한 권한을 부여했고 모든 것이 잘되었습니다.

코드를보고 NULL 또는 빈 값으로 헤더를 설정하고 있는지 확인하십시오.

내 PHP JSON / REST 서비스에서이 오류가 발생하기 시작했습니다.

ob_start("ob_gzhandler")가장 자주 액세스하는 GET PHP 스크립트에 추가 한 후 relativley 희귀 POST 업로드에서 오류가 발생하기 시작했습니다.

나는 단지을 사용할 수 ob_start()있으며 모든 것이 좋습니다.