Today I basically spent the vast majority of the day fighting an annoying an unexpected problem. We migrated our app from Flex Builder 2 to Flex Builder 3 and after some changes here and there it appeared everything worked. Then one of the developers discovered that a Save method was triggering an error dialog.

We started to look into and and essentially lost the day to the problem.

The call today looks like this:

service.SavePlan(projectVo.guid, xmlString, userGuid);

Where service is a WebService class. Notice the xmlString variable.

After spending a lot of time with Fiddler, Soap Sonar, and Firebug only to conclude I still didn't have a clue why the actual call was returning a 200, but had zero content, I stumbled across a few lines of code buried at the bottom of our ASP.NET Global.asax.

In essence it was taking any request that had a response that wasn't 200 and had a header that contained SoapAction and setting the response to 200. Stepping into it I found that the server was really returning a 400 error.

Now that I knew the request was actually throwing a 400 error I at least had an idea of where to narrow the scope of my research. Finally, I stumbled upon this blog. Item number 3) is the one that triggered a light bulb. We are using web services, not HttpService, but the description of the problem and something I had seen earlier in Soap Sonar came together.

To prove we were experiencing this problem I simply called escape(xxx) on the XML string we were sending in the Soap body. Sure enough, the server processed the request, and then promptly blew up because the backend didn't know it had to call HttpUtilities.UrlDecode(xxxx).

So the problem is that in Flex 2 the body of the entire request was encoded, but in Flex 3 the XML portion of the body was not encoded, resulting in the server trying to process the incoming XML.