The server committed a protocol violation. Section=ResponseStatusLine ERROR

Question

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.

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.

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.

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;

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

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