The server committed a protocol violation. Section=ResponseStatusLine ERROR

Question

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?

Upward

Answer 1

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.

Lapboard

I had 6 urls throwing this error. Setting useUnsafeHeaderParsing fixed it for one link, but setting KeepAlive=false fixed it for all 6. – Cameroncameroon

The same can be placed inside <configuration> root tag at the App.copnfig for non-web applications (for example, I fixed WPF app that way - thanks!). – Insurgent

anyone know why this safety measure is imposed by IIS? It worked, but I don't understand the reason for the restriction on header values (manually setting them in my case). – Kiki

This is merely avoiding the problem rather than actually fixing it. I think this should not be the default solution. – Keele

Agree with Tobias - you are avoiding the problem. Now it may be that the problem is in a server which you cannot fix, and thus avoidance may be your only option... but still, let's be clear about the difference between avoiding a protocol error and actually fixing it. – Figurative

I had this problem once but the issue was the calling had to be done using HTTPS and was being done using HTTP. – Addy

I get ServerProtocolViolation Error. I set useUnsafeHeaderParsing to true. Now I get ArgumetOutOfRangeException: System.Net.Http.HttpResponseMessage..ctor(HttpStatusCode statusCode) – With

I got "The server committed a protocol violation" error. Adding useUnsafeHeaderParsing helps fixing it – Mook

techcommunity.microsoft.com/t5/iis-support-blog/… – Aymara

useUnsafeHeaderParsing, allowKeepAlive and expect100Continue is not working. – Aymara

@DavidHammond https://mcmap.net/q/182010/-c-odata-the-server-committed-a-protocol-violation-section-responsestatusline/3239434 – Aymara

Why disabling keep-alive fixes the issue? – Neela

Answer 2

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.

Compliant

Ah this is what I needed. Thanks. Here is a user-agent example: https://mcmap.net/q/182011/-webclient-downloadfile-aspx-file-won-39-t-open – Laoighis

A quick line to use with WebClient here https://mcmap.net/q/182012/-setting-the-user-agent-header-for-a-webclient-request – Dosia

Thanks. If you want query GitHub via HttpClient add: client.DefaultRequestHeaders.Add("User-Agent", "Anything"); line for fix. – Rosebud

Answer 3

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.

Keele

Just read this after I got the The server committed a protocol violation. Section=ResponseStatusLine error when using WebApi to return a custom NoContent() response that was sending No Content in the response for some bizarre reason! Once I took that out the problem went away :) – Chopine

This was also my problem, though it was tricky because it was the call AFTER the No Content response that was failing. – Baalbeer

Fixed by removing someContent from return Request.CreateResponse(HttpStatusCode.NoContent, someContent); +1 – Walsh

That was the problem in my case as well, the next call/request after the No Content response was failing and that took place in an integration test of mine, so the next integration test was failing... Thanks @Keele for pointing that out, I have spent 5 hours on that! – Simile

This solved it for my LabVIEW webservice, thanks! Hint: Don't flush any (even empty) string when returning 204 in LabVIEW. – Stole

Answer 4

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;

Gabe

This worked for me when accessing the MediaFire API. – Hepta

I know I am coming late but, what do you mean by "in an incorrect way"? – Bloem

For anyone using HttpClient, the following worked for me: var http = new HttpClient(); http.DefaultRequestHeaders.ExpectContinue = false; – Cordi

Answer 5

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

Gomer

This is the best response. It explains why the web server is misbehaving. Thanks! (I have to emulate a web server with sockets because of deployment problems with HttpListener.) – Shikoku

Answer 6

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/

Dreyer

Fiddler is indeed fixing the problem that I have with a GET HTTP request. Can we see what is done by fiddler ? – Uchish

Answer 7

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

Pettifog

Had same issue. Turned out to be Skype. Its so unfortunate that proper messages cannot be provided. – Columbuscolumbyne

you don't actually need to close Skype, i added an answer below for this to show how to tackle it without closing Skype. – Bun

Answer 8

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; 

Diacritic

Answer 9

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.

Bun

and remember to restart IIS after doing so – Declarer

Answer 10

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;

Recalcitrate

Answer 11

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

Jevons

Answer 12

My problem was that I called https endpoint with http.

Thorvald

Answer 13

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.

Windswept

Answer 14

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.

Calculator

Answer 15

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.

Pasley

Answer 16

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

Bream

Answer 17

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.

Skit

Answer 18

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

Gish