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

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

---

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

"서버가 프로토콜 위반을 커밋했습니다. 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 응답은 메시지 본문을 포함해서는 안되므로 항상 헤더 필드 다음의 첫 번째 빈 줄로 종료됩니다.

---

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

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

request.ServicePoint.Expect100Continue = false;

---

로컬 컴퓨터에서 Skype를 실행하고있을 때 이런 일이 발생했습니다. 문을 닫 자마자 예외가 사라졌습니다.

이 페이지의 아이디어 제공

---

이것을 디버깅하고 문제를 일으키는 프로토콜 위반인지 확인하는 한 가지 방법은 Fiddler (Http Web Proxy)를 사용하여 동일한 오류가 발생하는지 확인하는 것입니다. 그렇지 않은 경우 (즉, 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-8바이트 순서 표시기 (BOM)를 출력 하는 웹 서버를 사용 하는 경우 입니다. 예를 들어, 기본 상수 Encoding.UTF8는 BOM을 출력하므로이를 쉽게 잊을 수 있습니다. 웹 페이지는 Firefox 및 Chrome에서 올바르게 작동하지만 HttpWebRequest폭탄 이 작동합니다 :). 빠른 수정 방법은 BOM을 출력하지 않는 UTF-8 인코딩을 사용하도록 웹 서버를 변경하는 것입니다 new UTF8Encoding(false)( 예 : 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 컨테이너 = 새 CookieContainer ();

---

A likely cause of this problem is Web Proxy Auto Discovery Protocol (WPAD) configuration on the network. The HTTP request will be transparently sent off to a proxy that can send back a response that the client won't accept or is not configured to accept. Before hacking your code to bits, check that WPAD is not in play, particularly if this just "started happening" out of the blue.

---

My problem was that I called https endpoint with http.

---

First thing we've tried was to disable dynamic content compression for IIS , that solved the errors but the error wasn't caused server side and only one client was affected by this.

On client side we uninstalled VPN clients, reset internet settings and then reinstalled VPN clients. The error could also be caused by previous antivirus which had firewall. Then we enabled back dynamic content compression and now it works fine as before.

Error appeared in custom application which connects to a web service and also at TFS.

---

In my case the IIS did not have the necessary permissions to access the relevant ASPX path.

I gave the IIS user permissions to the relevant directory and all was well.

---

See your code and find if you are setting some header with NULL or empty value.

---

I started getting this error from my php JSON/REST services

I started getting the error from relativley rare POST uploads after I added ob_start("ob_gzhandler") to most frequently accessed GET php script

I am able to use just ob_start(), and everything is fine.

참고URL : https://stackoverflow.com/questions/2482715/the-server-committed-a-protocol-violation-section-responsestatusline-error