Feature request: httpResponseStatus for UrlLoader onComplete

ianchia

Hello @atilim and other engineering team members,

Here's a feature request/bug report since bugs.gideromobile.com seems to gone 404. (I did file a issue for the missing bugbase via your swanky new website but haven't heard anything back yet.)

When making calls using UrlLoader, can we please implement a httpResponseStatus value within the event object being returned? This would be similar to the ActionScript 2 and 3 implementation. Adobe doc reference: http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/URLLoader.html#event:httpResponseStatus

This is the use-case I'm encountering:

The thin-client app I'm working on is retrieving image data using Rackspace's file storage service. When the server is under heavy load, instead of serving a 503 (Service unavailable) status, Rackspace's proprietary system serves a wacky 404 and a brief line of HTML saying the resource is missing. If I try a second or two later, it responds appropriately with a 200 and the correct data.

I'm having to write a HTTP HEAD using LuaSocket to try the URL repeatedly until I get a status 200, and then use UrlLoader GET to try again and hopefully get a 200 with my data. This is a duplication of requests, and not an optimal solution. As it stands, there is still no guarantee that I will get a status 200 with my UrlLoader GET request (although a much higher percentage that it will work.)

For each UI screen being presented to the user, there can be 10 to 50 image requests. Even when queued, there's a lot of HTTP traffic going back and forth. Using the HTTP HEAD and then the UrlLoader GET approach, the amount of HTTP requests are *doubled* which is less than optimal.

What would be best is if UrlLoader returned the server's HTTP response within the onComplete event. Hence if I received a non-200 response, I could parse what went wrong (whether it's a 503 or 403 etc) and respond appropriately.

(An addendum: the Rackspace file storage server is part of my client's backend system, and all the traffics is going via HTTPS, not HTTP. Security is a high concern since this product is part of a security monitoring suite, so I can't go via HTTP only. We could possibly increase the server's provisioning on the backend - I'd have to talk to our cloud server guy, but this is sporadic server response from Rackspace. The server load seems to be distributed/contributed within their cloud infrastructure and not particularly among our own cloud application usage, so I'm not sure we'd have any control over that anyway.)

Many thanks for your consideration.

Best,

- Ian

ianchia

PS: What would be appreciated if it's not too much trouble is if UrlLoader also implemented UrlLoader.HEAD in addition to the current list:

HTTP Request Methods
**UrlLoader.GET = "get"**
**UrlLoader.POST = "post"**
**UrlLoader.PUT = "put"**
**UrlLoader.DELETE = "delete"**

This would be useful for checking status call types on remote REST APIs.

Thank you again,

- Ian

atilim

Hi @ianchia,

Your request is kinda easy to add one and I'll try to add it to the next release. (both httpResponseStatus and UrlLoader.HEAD)

And most probably we won't bring bugs.gideromobile.com back. But we can work on a custom bug reporting system.

ianchia

Thank you very much for your quick response and possibly adding this to the next release @atilim - especially during the weekend and especially during a time of unrest in Turkey. I hadn't expected a response until at least Monday! (-:

A proper bug reporting system would be appreciated instead of just a generic support ticket system. It would be good to be able to browse submitted bugs and see if one's already hitting a known issue etc. Even something like the mantis bugtracker or bugzilla would be fine. Whatever works best for your team.

All the best,

- Ian