WCF: Bug Handling Content-Type Header in 3.0

29. August 2007 07:25

Recently, I have been using WCF as the consumer of a Java web service that is running in the Apache Axis environment.  Initially, I thought this project would be extremely simple.  Well, I guess that it is what I get for thinking!  

Shortly after I finished the initial implementation, I fired up the debugger to test the interaction with the web service.  As soon as the request was submitted, I received an unusual error indicating that a substring operation failed due to an invalid length.  As I researched the cause of the exception, I discovered that it was being thrown by TextMessageEncoderFactory.GetEncodingFromContentType.  This was occurring when the response from the web service was being processed by the text encoder. 

Naturally, I fired up Reflector to get a closer look at exactly what this method was doing.

Well, it turns out that WCF has very specific expectations regarding how the content-type parameters should be ordered.  Typically, the content-type header appears as follows:

Content-Type: application/soap+xml; charset=utf-8

Unfortunately, the Apache Axis environment inserts an optional action parameter between content type and charset as follows:

Content Type: application/soap+xml; action="urn: myMethod"; charset=utf-8

Based on the applicable W3C specs, there is no requirement for the parameters to be listed in a specific order.  However, WCF's current parsing logic doesn't account for this possibility.  It ultimately results in an invalid substring operation due to a negative length.

I did some more searching around the web and stumbled onto a couple of posts in the MSDN forum where someone had complained about this exact problem.  Surprisingly, it has received extremely little attention and I have been unable to find any references about the problem elsewhere on the web.  In the MSDN posts, it was mentioned that this issue would probably be addressed in WCF 3.5.  Well, I am happy to verify that it has been resolved as of Beta 2...at least for my specific scenario.

While it is great to see the problem is being addressed for the next release of WCF, I'm sure there are quite a few people out there who are in the same boat as me and need a solution immediately.  From what little information I have seen regarding this problem, it appears as though it is passed back over to the Apache environment to deal with it by reordering the parameters in the content-type header.  If this isn't an option for you, I have written a quick solution that can be used as a workaround on the .NET side of things.  Admittedly, it isn't the most elegant solution that I have ever developed, but it should be sufficient when you are in a bind.

Later today or tonight, I will post the solution and source code.

Comments are closed

About Me

I'm a passionate software developer and advocate of the Microsoft .NET platform.  In my opinion, software development is a craft that necessitates a conscious effort to continually improve your skills rather than falling into the trap of complacency.  I was also awarded as a Microsoft MVP in Connected Systems in 2008, 2009, and 2010.

Can’t code withoutThe best C# & VB.NET refactoring plugin for Visual Studio
Follow jeff_barnes on Twitter

View Jeff Barnes's profile on LinkedIn


Shared Items


Anything you read or see on this site is solely based on my own thoughts.  The material on this site does not necessarily reflect the views of my employer or anyone else.  In other words, I don't speak for anyone other than myself.  So, don't assume I am the official spokesperson for anyone.