I noticed the same issue using just URLLoader (which I believe HTTPService
uses under the hood). For 404 errors, etc., the app just spins, forever,
doesn't even time out, and for a lot of conditions it doesn't fire the
proper status events. This is incredibly frustrating, particularly since I'd
love to do a *pure* REST style API for my web service, but can't because
URLLoader can't handle PUT and DELETE and because I can't get proper
responses back form the server (other than 200 OK).
Not quite sure why Adobe can't fix this... I could write an HTTP service
using the binary sockets and it'd be able to do it correctly, so I find that
it seems to be a shortcoming of Adobe's stuff, not the browser.
Though I'd be curious... does URLLoader just turn into a request in the
browser? I.e., does Adobe just piggyback, thus leveraging the browser's
built-in caching, DNS, proxy, etc.? If so, I find it frustrating that Adobe
chooses to pushes more stringent security restrictions on URLLoader, etc.,
than the browser places on those same requests... an odd hybrid if you ask
me.
And not very web 2.0! ;-)
Troy.
On 3/12/07, Ed <[EMAIL PROTECTED]> wrote:
This is killing me as well. When my server returns anything other
than HTTP status 200, like a 404 or 503, even if that's an
appropriate response, neither the success nor fault handlers are
executed. As far as Flash/Flex is concerned, it will continue waiting
as if a response is forthcoming.
I have a Flex 1.5 fix, but I don't think it works very well.
Say you have a RemoteObject:
<mx:RemoteObject id="services" source="com.company.Facade"
fault="handleFault(event);" result="handleResult(event);"/>
Somewhere you make a call to the facade.
services.doSomething();
Say the request is really long running. Using Apache/Tomcat, the
server may decide to timeout with a 503 (Service Unavailable), which
is an entirely appropriate and expected response.
The 503 response will arrive at my Flex app and be completely ignored.
If I've defined a busy cursor for this request.
<mx:method name="doSomething" showBusyCursor="true" />
Then busy cursor will never go away and the Flex App will just spin.
To fix this, I created a initialize event handler in the class that
contains my RemoteObject.
private function doInitialize(pEvent:Object):Void
{
pEvent.target.services.__conn.onStatus = onConnectionFailure;
}
private function onConnectionFailure(pEvent:Object):Void
{
// 1. do something to indicate a connection failure
// 2. remove the busy cursor
}
This takes advantage of a connection level fault handler which
documented at
http://livedocs.adobe.com/fms/2/docs/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000742.html
If you just want *something* in your code to execute on request
failures, this will do it for you.
But there's a big problem with this fix. Not only will you respond to
404s, 503s, and whatever else, but you'll also respond to generic
connection failures, like pulling your network cable out. At first,
that sounds like a bonus. But in practice, connections come and go
all the time. Sometimes the server will just time you out for
inactivity. Sometimes you'll lose your connection for a few seconds
in the middle of a request. Those are false positives.
You should be able to solve that problem by checking the argument
passed to Connection.onStatus. While that is documented, in my case
(Flex 1.5), this argument is always undefined. So when a fault is
detected, you have no way of figuring out whether or not it's legit.
To top it all off, more often than not my entire App becomes
unresponsive after connection failures. You have to hit refresh.
It's disappointing to see that this isn't fixed in Flex 2 yet:
http://livedocs.adobe.com/flex/201/html/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Book_Parts&file=dataservices_099_03.html
I suspect this isn't an Adobe problem, but a browser problem, but I
don't know for sure.
Anyway, even though the cure is probably worse than the disease, this
is something you can try out as well.
--- In [email protected] <flexcoders%40yahoogroups.com>, "Chua
Chee Seng" <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> I am building a data adapter using web service. The
> mx.rpc.soap.WebService class works fine for me except in handling the
> exception thrown from server side. The problem cause that I found out
> from the docs is that Flash Player doesn't read the SOAP Fault details
> when the Response status code is 500.
>
> The following URL suggest a solution:
>
>
http://stackoverflowexception.blogspot.com/2007/02/handing-web-service-exception-in-flex.html
>
> However, after I set the status code to 200 by using response wrapper,
> I got the result handler get called and not the fault handler as
> explained by the URL.
>
> Does anyone have better idea to achieve exception handling of web
service?
>
> Thanks.
>
> Best Regards,
> Chua Chee Seng
>
