Protocol violation (Section=ResponseStatusLine)

This post has been republished via RSS; it originally appeared at: IIS Support Blog articles.

Companies use network devices such as load balancers, proxies, and firewalls in front of the web servers. These devices may edit the network traffic between client and IIS servers.

I troubleshot a web application that was taking too much time to load. We saw this error in the logs:

System.Net.WebException: “The server committed a protocol violation. Section=ResponseStatusLine”




Root Cause

One of the most common cause of this error is the corrupt or missing headers in the request.

IIS checks if headers are complete in the request. If there is an issue with headers, it may reject the request.


The change in the requests and responses could be made by network devices in between the client and IIS server.



Review the flow of the traffic. If the flow is similar to the one below, try to bypass network devices one by one to narrow down the issue.


User -> Load Balancer 1 -> API consumer application -> Load Balancer 2 -> Web Service


In my case, the application worked without issues after we bypassed Load Balancer 2. We also performed a test by replacing it with another load balancer. It also worked. These tests showed that there is an issue with the load balancer.


Workarounds on IIS side

There are ways for IIS to ignore corrupted/missing headers. However, these are workarounds, not permanent solutions. I don’t recommend implementing them as they may cause unexpected issues in the future.

<> <settings> <httpWebRequest useUnsafeHeaderParsing="true" /> </settings> </>
  • Set KeepAlive to “false” to prevent keeping the connection open which may solve the violation error
<configuration> <system.webServer> <httpProtocol allowKeepAlive="false" /> </system.webServer> </configuration>


  • Set Expect100Continue to “true” to ensure that the client doesn’t send the entire data before getting confirmation from the server
<> <settings> <servicePointManager expect100Continue="false"/> </settings> </>


REMEMBER: these articles are REPUBLISHED. Your best bet to get a reply is to follow the link at the top of the post to the ORIGINAL post! BUT you're more than welcome to start discussions here:

This site uses Akismet to reduce spam. Learn how your comment data is processed.