Yeah, URLLoader is definitely a tease that way... almost perfect, but not really.
It does seem like a browser issue, but I find it really, really, really hard to believe that a browser plugin couldn't use the browser to retrieve a URL and not get a full HTTP response, particularly in a standards-compliant browser like Firefox. And its frustrating that the only fix for it is to use Flex Data Services, a not-so-cheap solution. It'd be great if Adobe simply provided a free PHP (or similar CGI) component that folks could drop onto their servers to do fully compliant proxying for them. I'm actually kinda surprised that the community hasn't provided something like that... Again, if I can write an HTTP utility on top of sockets in Flex that is fully compliant its frustrating that the player itself isn't. Troy. On 12 Mar 2007 16:36:14 -0700, Ed <[EMAIL PROTECTED]> wrote:
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] <flexcoders%40yahoogroups.com>, "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><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 > > > > > > > > > >
