manish patel
manish patel

Reputation: 1449

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?

Upvotes: 125

Views: 191161

Answers (18)

Stephan Møller
Stephan Møller

Reputation: 1305

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

Upvotes: 0

gneric
gneric

Reputation: 3685

My problem was that I called https endpoint with http.

Upvotes: 2

Skrymsli
Skrymsli

Reputation: 5313

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.

Upvotes: 2

Patrick
Patrick

Reputation: 1148

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.

Upvotes: 0

AltF4_
AltF4_

Reputation: 2460

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.

Upvotes: 6

nixda
nixda

Reputation: 2697

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;

Upvotes: 3

HasanG
HasanG

Reputation: 13161

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.

Upvotes: 1

Abdul Rauf
Abdul Rauf

Reputation: 972

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

Upvotes: 0

Vaiden
Vaiden

Reputation: 16112

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.

Upvotes: 0

Luke
Luke

Reputation: 23680

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

Upvotes: 9

Loathing
Loathing

Reputation: 5256

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).

Upvotes: 10

TH Todorov
TH Todorov

Reputation: 1159

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();

Upvotes: 2

Prashan Pratap
Prashan Pratap

Reputation: 484

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; 

Upvotes: 6

marq
marq

Reputation: 828

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;

Upvotes: 13

Tobias
Tobias

Reputation: 5108

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.

Upvotes: 39

Ivan Kochurkin
Ivan Kochurkin

Reputation: 4481

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.

Upvotes: 62

Dinis Cruz
Dinis Cruz

Reputation: 4269

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/

Upvotes: 9

Darin Dimitrov
Darin Dimitrov

Reputation: 1038710

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.

Upvotes: 77

Related Questions