Flex Monkey Patches

This question seems to come up a lot and there are various answers to it. I am just collecting a few here:

Questions:

*****
The best information I can get from Flex when I get a SOAP fault seems to be “Error #2032: Stream Error” which seems to me to be rubbish – there’s a SOAP fault being sent back to the client which I have verified with Charles, but the header response is a 500 – does Flex use this to decide to give the vague stream error? And if so, can I still retrieve the actual response text?
(http://www.mail-archive.com/flexcoders@yahoogroups.com/msg90996.html)

*****

When an error occurs a web service will typically return a HTTP error
code with the error message in the body. The problem is that Flex does not allow you to access the body and just throws a 2032 error. None of the information from the HTTP response describing the actual error is
available in the fault event.
(http://www.mail-archive.com/flexcoders@yahoogroups.com/msg88599.html)

*****

How can I display SOAP fault messages in Flex? Flex 2 currently seems to be reporting an IO error instead of the SOAP fault details.

*****

I don’t seem to be able to get the Soap fault of a webservice called from a flex client, I just get a generic fault. If I look in a webservice debugging tool I see the specific fault is being returned as a 500 error with the specific message. How can I get the specific error fault in the flex client, or is this a bug?

*****

Responses:

*****

Well there has been a bug logged:

WebService fault details are hidden by Flex SDK – http://bugs.adobe.com/jira/browse/SDK-11841

*****

This is a well known limitation of the various plugin APIs exposed to the Flash Player. For non-200 status code HTTP responses, the body is not exposed to the Flash Player and thus it cannot show you what the SOAP fault was. You’d need to change the server to use a 200 status code despite the SOAP response being a fault.
An alternative is to use the BlazeDS Proxy Service which will handle this situation for you and do the translation.

*****

This is generally a Flash Player/Web Browser limitation. The NPAPI that the plugin player uses in FireFox/Safari/etc does not providing anything useful to a plugin when an HTTP fault response is received. This is an area that the Flash Player team is currently investigating fixes in, but any improvements would depend on rev’ing the NPAPI and working with browser vendors to update their browsers. There are also apparently issues in IE7 that weren’t there in IE6. Using the browser HTTP stack buys the Flash Player team space savings because they didn’t have to implement all that directly, integrated browser/player cookies and basic HTTP auth state, SSL/TLS cert management, etc. but because the APIs exposed to the player by the various browsers differ and in some cases have outright holes there are long-standing, nasty limitations/bugs (like this one).

The way to work around this is to proxy requests either through BlazeDS, LCDS or you can write a simple HTTP proxy in the Server Scripting language of your choice (ColdFusion, JSP, PHP, etc).

*****

You need to make your calls through the BlazeDS or LCDS proxy service. SOAP faults are returned with an HTTP status code of 500 which the browsers don’t pass through into the player.

*****

And this is my favorite:

Tweet

1 Comment »