HTTP Response 204 crashes Android and Kindle Fire

Hey, there seems to be some serious badness in the network request calls for android…note, tested on teh GalaxyTab 7inch and the older Kindle fire. (This stuff works fine on iOS and in the simulator). There are missing reponse codes, as well as a NUll pointer that happens in the Android layers. I need this functionality in order to interoperate with Amazon’s S3, which makes heavy use of http status 204…which causes a null pointer in Android. Anyone have any insight?

  1. Code in corona to do a network request to a JSP page for testing:
 local successRect = display.newRect(0,0,100, 100);  
 successRect:setFillColor(0xff,0,0);  
  
 local url = "http://192.168.1.122:8080/server\_test/test204Explosion.jsp";  
  
 timer.performWithDelay(1000, function()  
  
 local params = {  
 body="varsPassed=blah"  
 }  
 print ("About to POST request to: ", url);  
  
 network.request( url, "POST", function(event)  
 successRect:setFillColor(0xff,0xff,0); --YELLOW, sometimes you'll get here before it crashes android  
  
 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------  
 --BUG#1 On iOS you get the line: "key status value XXX" --- the http status is not included in the table for android....200 is there, but a 403/404 is not returned etc, BIG problem for trying to do things based on response code  
 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------  
 for k, v in pairs(event) do  
 print ("key", k, "value", v);  
 end  
  
 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------  
 --BUG#2 - VERY serious - if status code 204 isOn iOS you get the line: "key status value XXX" ---this http status is not delivered in android, big problem for trying to do things based on response code  
 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------  
 timer.performWithDelay(1000, -- built into the timer so that there is time to make sure the asynch call has time to bail  
 function ()  
 successRect:setFillColor(0,0xff,0); --GREEN for GOOD  
 end  
 );  
 end, params);  
 end);  
  1. Setup your JSP at the location; dead simple JSP:
  
  
  1. Change the response code in the JSP and witness very different results for different codes:

With response.setStatus(200), everything works:

10-10 14:40:22.689 I/Corona ( 5757): About to POST request to: http://192.168.1.122:8080/server\_test/test204Explosion.jsp  
10-10 14:40:23.937 I/Corona ( 5757): key name value networkRequest  
10-10 14:40:23.937 I/Corona ( 5757): key status value 200  
10-10 14:40:23.937 I/Corona ( 5757): key url value http://192.168.1.122:8080/server\_test/test204Explosion.jsp  
10-10 14:40:23.937 I/Corona ( 5757): key isError value false  
10-10 14:40:23.937 I/Corona ( 5757): key response value   

With response.setStatus(404), the response code is NOT returned…i.e. can’t do things based on the response?:

10-10 14:42:13.022 I/Corona ( 5757): About to POST request to: http://192.168.1.122:8080/server\_test/test204Explosion.jsp  
10-10 14:42:13.156 I/Corona ( 5757): key isError value true  
10-10 14:42:13.156 I/Corona ( 5757): key url value http://192.168.1.122:8080/server\_test/test204Explosion.jsp  
10-10 14:42:13.156 I/Corona ( 5757): key name value networkRequest  
10-10 14:42:13.156 I/Corona ( 5757): key response value Not Found  

But the worst result is with a response.setStatus(204)…witness the destruction:

10-10 14:42:35.746 I/Corona ( 5757): About to POST request to: http://192.168.1.122:8080/server\_test/test204Explosion.jsp  
10-10 14:42:35.840 W/dalvikvm( 5757): threadid=24: thread exiting with uncaught exception (group=0x4001d7d0)  
10-10 14:42:35.840 E/AndroidRuntime( 5757): FATAL EXCEPTION: pool-11-thread-1  
10-10 14:42:35.840 E/AndroidRuntime( 5757): java.lang.NullPointerException  
10-10 14:42:35.840 E/AndroidRuntime( 5757): at com.loopj.android.http.AsyncHttpClient$2.process(Unknown Source)  
10-10 14:42:35.840 E/AndroidRuntime( 5757): at org.apache.http.protocol.BasicHttpProcessor.process(BasicHttpProcessor.java:304)  
10-10 14:42:35.840 E/AndroidRuntime( 5757): at org.apache.http.protocol.HttpRequestExecutor.postProcess(HttpRequestExecutor.java:319)  
10-10 14:42:35.840 E/AndroidRuntime( 5757): at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:543)  
10-10 14:42:35.840 E/AndroidRuntime( 5757): at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:555)  
10-10 14:42:35.840 E/AndroidRuntime( 5757): at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:487)  
10-10 14:42:35.840 E/AndroidRuntime( 5757): at com.loopj.android.http.AsyncHttpRequest.run(Unknown Source)  
10-10 14:42:35.840 E/AndroidRuntime( 5757): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1068)  
10-10 14:42:35.840 E/AndroidRuntime( 5757): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:561)  
10-10 14:42:35.840 E/AndroidRuntime( 5757): at java.lang.Thread.run(Thread.java:1096)  
10-10 14:42:35.847 W/ActivityManager( 2494): Force finishing activity com.smarterapps.testcase/com.ansca.corona.CoronaActivity  

[import]uid: 105599 topic_id: 31830 reply_id: 331830[/import]

James,

We’ve looked into the issues that you mentioned above and have confirmed that there are 2 bugs…

  1. A crash will occur when a response containing an empty bode has been received.
  2. The “event.isError” flag is set true when a status code less than 300 has been received.

Both of the above issues have been fixed and the fix will be made available in daily build #935, tomorrow.

Regarding error response handling, we’ve changed it so that “event.isError” is only set true if a connection error or a response timeout occurs. This mean that “event.isError” will be false when error responses are received, in which case it is up to you to look at the status code and handle it appropriately. This matches the behavior on all other platforms (iOS, OS X, and Windows).

Thank you for reporting these issues. The stack trace that you provided us was especially helpful. [import]uid: 32256 topic_id: 31830 reply_id: 127475[/import]

Fantastic! Thanks for the *ahem*, Quick turnaround Joshua.

Regarding stacktrace: NP, I’ve been on the other side and know just how ‘useful’ bug reports such as “there is a bug. It crashes. Please fix.” really are :slight_smile: [import]uid: 105599 topic_id: 31830 reply_id: 127480[/import]

Also, apologies for the name pun :slight_smile: I’m sure you’ve _never_ heard that one before. And yes, i do feel cheapened by it, but i had no choice really, since the bug was in fact fixed quickly :slight_smile: [import]uid: 105599 topic_id: 31830 reply_id: 127481[/import]

You weren’t the only one who raised this issue. Another person brought it up a week ago, so it was just perfect timing.
Oh and no worries about the name puns. I’m used to it by now. :slight_smile:
[import]uid: 32256 topic_id: 31830 reply_id: 127495[/import]

James,

We’ve looked into the issues that you mentioned above and have confirmed that there are 2 bugs…

  1. A crash will occur when a response containing an empty bode has been received.
  2. The “event.isError” flag is set true when a status code less than 300 has been received.

Both of the above issues have been fixed and the fix will be made available in daily build #935, tomorrow.

Regarding error response handling, we’ve changed it so that “event.isError” is only set true if a connection error or a response timeout occurs. This mean that “event.isError” will be false when error responses are received, in which case it is up to you to look at the status code and handle it appropriately. This matches the behavior on all other platforms (iOS, OS X, and Windows).

Thank you for reporting these issues. The stack trace that you provided us was especially helpful. [import]uid: 32256 topic_id: 31830 reply_id: 127475[/import]

Fantastic! Thanks for the *ahem*, Quick turnaround Joshua.

Regarding stacktrace: NP, I’ve been on the other side and know just how ‘useful’ bug reports such as “there is a bug. It crashes. Please fix.” really are :slight_smile: [import]uid: 105599 topic_id: 31830 reply_id: 127480[/import]

Also, apologies for the name pun :slight_smile: I’m sure you’ve _never_ heard that one before. And yes, i do feel cheapened by it, but i had no choice really, since the bug was in fact fixed quickly :slight_smile: [import]uid: 105599 topic_id: 31830 reply_id: 127481[/import]

You weren’t the only one who raised this issue. Another person brought it up a week ago, so it was just perfect timing.
Oh and no worries about the name puns. I’m used to it by now. :slight_smile:
[import]uid: 32256 topic_id: 31830 reply_id: 127495[/import]