The server committed a protocol violation with WebRequest

March 29, 2007 • from Maui, Hawaii • 9 comments

On this page:

I've been working with a host of different OFX financial services to retrieve data from remote servers and merge them into one of my client's systems. These servers are a wide variety of different Web Servers and using various versions of the OFX protocols which has been nothing short of a nightmare to deal with.

One thing that I've run in with several servers however are pure HTTP problems which apparently are caused by the server application returning invalid results. Specifically 'The server has committed a protocol violation'.

One service specifically kept failing in this fashion and initially I had no way to figure out WTF is wrong. I actually went as far and fired up my trusty WinInet test client app to check this out and sure enough the request worked just fine. Even more confusing is the fact that the server on the other end is IIS 5 and is apparently serving stock IIS headers with its result - yet every attempt to access it with the .NET WebRequest would fail.

Apparently the problem is that starting with .NET 1.1 SP2 the HTTP protocol usage has been made more strict and any issApparently the problem is that starting with .NET 1.1 SP2 the HTTP protocol usage has been made more strict and any issue ue in the HTTP headers - such as returning only a CR intead of CRLF pair at the end of a header - apparently throws the header for a loop.

The solution is to set a configuration flag to disable this strict handling in the configuration file.

<?xml version="1.0"?>

  <system.net>

    <settings>

      <httpWebRequest useUnsafeHeaderParsing="true" />

    </settings>

    <defaultProxy>

      <proxy   bypassonlocal="True"  usesystemdefault="False" />

    </defaultProxy>

  </system.net>

</configuration>

This has fixed up the issue with his particular server (which is probably masquerading as an IIS server rather than really running it - IIS 5 doesn't natively generate invalid headers <s>) and I was able to get on with live.

Unfortunately though it looks like this Config flag is required to change this value in the application as there is no corrsponding property on the actual WebRequest object or the ServicePoint (which is responsible for many of the low level request settings) for that matter.

The Voices of Reason

Peter Bromberg
March 30, 2007

# re: The server committed a protocol violation with WebRequest

Rick,
This is good stuff. This may not be directly related, but I have seen a number of instances where my WebRequests (any flavor) fail, and when I add a UserAgent string (your favorite browser, whatever it is) - all of a sudden they work. You can do this with WebClient as well as with the HttpWebRequest/Response combo.
Peter

Rick Strahl
March 30, 2007

# re: The server committed a protocol violation with WebRequest

Peter, I think when that fails it's the SERVER rejecting the request, not the client as is the case here. Here the server is apparently sending data with missing line feeds (even though it claims to be an IIS server which is unlikely if the LFs are missing). Headers can be important, but then again I use WebRequest wrapper class (wwHTTP) that adds that kind of stuff automatically anyway.

http://www.west-wind.com/presentations/dotnetWebRequest/dotnetWebRequest.htm

Speaking of handling things automatically - there are a few other things that are kind of non-obvious to 'fix' on WebRequest. For example if you need to handle certificate errors there's no easy way to do this on the individual request, or even the request's servicepoint, but you need to set configuration on the ServicePointManager interface which controls many global settings and which are also settable in web.config. <shrug>

The architecture of WebRequest is pretty damn flexible and you can set just about anything, but finding the right setting to tweak over the range of objects involved can be tricky <s>...

AB
April 03, 2007

# re: The server committed a protocol violation with WebRequest

For me when i have had 'The server has committed a protocol violation' error it has always been the 'Access Denied' custom HTTP header. If i temporarily remove it from IIS it works fine. Obviously if the server was IIS and you had easy access you may be able to try it.

Rick Strahl's Web Log
June 23, 2007

# Rick Strahl's Web Log

Dynamo
November 20, 2008

# re: The server committed a protocol violation with WebRequest

A good article regarding this topic:
http://www.cookcomputing.com/blog/archives/000556.html

Praveen
February 24, 2009

# re: The server committed a protocol violation with WebRequest

Thank you for providing code
its working absolutely perfect

Ufuk
July 20, 2009

# re: The server committed a protocol violation with WebRequest

Hi,

in app.config file add useUnsafeHeaderParsing="true"

it solves your problem

like below

<?xml version="1.0" encoding="utf-8" ?>
<configuration>

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

</configuration>

Yousef
April 06, 2010

# re: The server committed a protocol violation with WebRequest

I have the same problem, except that i use windows service which doesn't allow me adding system.net section in it's config file

Eric
November 18, 2010

# re: The server committed a protocol violation with WebRequest

I was having a similar problem, but the configuration setting in app.config did not remedy the situation.

The exception that I was getting was:

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

Debugging with Fiddler v2 I saw that the Content-Length reported in the Header by the remote server was 2 bytes less than the actual length of the data returned. It appeared there was an extra CR/LF returned.

The suggested app.config work-around did not work for me. It only worked when I disabled the KeepAlive property on the HttpWebRequest instance:

webRequest.KeepAlive = false;

I was also using Basic Authentication to send a username/password (as required by the remote server) in addition to attaching a client certificate. I'm guessing that had something to do with my problem.

I'm just adding this to the pile of suggestions for anyone else who comes along and finds this page.

Rick Strahl's Weblog