[c#] The server committed a protocol violation. Section=ResponseStatusLine ERROR

I have created a program, tried to post a string on a site and I get this error:

"The server committed a protocol violation. Section=ResponseStatusLine"

after this line of code:

gResponse = (HttpWebResponse)gRequest.GetResponse(); 

How can I fix this exception?

Setting expect 100 continue to false and reducing the socket idle time to two seconds resolved the problem for me

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

I tried to access the Last.fm Rest API from behind a proxy and got this famous error.

The server committed a protocol violation. Section=ResponseStatusLine

After trying some workarounds, only these two worked for me

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

and

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

Another possibility: when doing a POST, the server responds with a 100 continue in an incorrect way.

This solved the problem for me:

request.ServicePoint.Expect100Continue = false;

Sometimes this error occurs when UserAgent request parameter is empty (in github.com api in my case).

Setting this parameter to custom not empty string solved my problem.

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.

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.

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.

One way to debug this (and to make sure it is the protocol violation that is causing the problem), is to use Fiddler (Http Web Proxy) and see if the same error occurs. If it doesn't (i.e. Fiddler handled the issue for you) then you should be able to fix it using the UseUnsafeHeaderParsing flag.

If you are looking for a way to set this value programatically see the examples here: http://o2platform.wordpress.com/2010/10/20/dealing-with-the-server-committed-a-protocol-violation-sectionresponsestatusline/

I just had the same issue. In my particular case git was removing CR in a http file on check-in, but disregarding the cause, you can follow these steps for debugging the issue: https://technical.fail/posts/2021-01-26-dotnet-framework-throwing-the-server-committed-a-protocol-violation-section-responsestatusline

None of the solutions worked for me, so I had to use a WebClient instead of a HttpWebRequest and the issue was no more.

I needed to use a CookieContainer, so I used the solution posted by Pavel Savara in this thread - Using CookieContainer with WebClient class

just remove "protected" from this line:

private readonly CookieContainer container = new CookieContainer();

Many solutions talk about a workaround, but not about the actual cause of the error.

One possible cause of this error is if the webserver uses an encoding other than ASCII or ISO-8859-1 to output the header response section. The reason to use ISO-8859-1 would be if the Response-Phrase contains extended Latin characters.

Another possible cause of this error is if a webserver uses UTF-8 that outputs the byte-order-marker (BOM). For example, the default constant Encoding.UTF8 outputs the BOM, and it's easy to forget this. The webpages will work correctly in Firefox and Chrome, but HttpWebRequest will bomb :). A quick fix is to change the webserver to use the UTF-8 encoding that doesn't output the BOM, e.g. new UTF8Encoding(false) (which is OK as long as the Response-Phrase only contains ASCII characters, but really it should use ASCII or ISO-8859-1 for the headers, and then UTF-8 or some other encoding for the response).

Try putting this in your app/web.config:

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

If this doesn't work you may also try setting the KeepAlive property to false.

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.

This was happening for me when I had Skype running on my local machine. As soon as I closed that the exception went away.

Idea courtesy of this page

Skype was the main cause of my problem:

This error usually occurs when you have set up Visual Studio to debug an existing web application running in IIS rather than the built in ASP.NET debug web server. IIS by default listens for web requests on port 80. In this case, another application is already listening for requests on port 80. Typically, the offending application is Skype, which by default takes over listening on ports 80 and 443 when installed. Skype is already occupy the port 80. So IIS is unable to start.

To resolve the issue follow the steps:

Skype -> Tools -> Options -> Advanced -> Connection:

Uncheck "Use port 80 and 443 as alternatives for incoming connections".

And as pointed out below perform an IIS reset once done.

The culprit in my case was returning a No Content response but defining a response body at the same time. May this answer remind me and maybe others not to return a NoContent response with a body ever again.

This behavior is consistent with 10.2.5 204 No Content of the HTTP specification which says:

The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.

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