URLLoader in Flex2 dispatches HTTPStatusEvents. http://livedocs.adobe.com/flex/2/langref/flash/net/URLLoader.html#event:httpStatus http://livedocs.adobe.com/flex/2/langref/flash/events/HTTPStatusEvent.html However, according to the doc it's always 0 on every browser but Windows IE, which is why I think it's a browser issue and not an Adobe issue.
Also, Adobe chose the server-side route and fixed this in Flex Data Services with a proxy. http://livedocs.adobe.com/flex/201/html/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Book_Parts&file=dataservices_099_03.html Kind of a lame hack if the issue could have been fixed in the Player. --- In [email protected], "Troy Gilbert" <[EMAIL PROTECTED]> wrote: > > 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" <quai83@> 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 > > > > > > > > > >
