Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 7.8K All Categories
- 11 Help with translations
- 4.2K General questions
- 107 Roadmap
- 358 Game & application design
- 317 Plugins
- 70 User experience
- 75 Marketplace
- 291 Code snippets
- 34 Building a team?
- 269 Suggestions & requests
- 352 Announce your apps made with Gideros.
- 90 Step by step tutorials
- 668 Bugs and issues
- 195 Introduce yourself
- 239 Announcements
- 106 Forum talk
- 404 Relax cafe
Feature request: httpResponseStatus for UrlLoader onComplete
ianchia
Member
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
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
Comments
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
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.
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