HttpURLConnection readLine() hanging on Sprint 4G network

Question

I have a routine that uses a HttpURLConnection to upload a file via a multipart/form-data content type. The server does some processing on the uploaded file and returns a short response code. This works fine in all cases so far except with one user with an HTC Evo when on 4G. If the user switches to 3G then everything works fine. When on 4G the app will wait on the while ((line = reader.readLine()) != null) { until a socket connection timeout exception is thrown. I have the connection timeout set to 70 seconds. The server is in php here is the relevant snippet

//all ob_ related entries were added because I found some info indicating
//that some clients would not acknowledge the response without the content-length header

ob_end_clean(); 
header("Connection: close");
ob_start();
...
//the response is one of either
echo "BACKGROUND"; //this one works!
//or
echo $rv //$rv = "1336757671374T37171FR"
//or
echo "FailedQA";

$size = ob_get_length();
header("Content-Length: $size");
ob_end_flush(); 
ob_flush();
flush();        
die();
?>

Note that the 'BACKGROUND' response works, and the rest cause the client to sit until the timeout exception. I have currently 2 notions on this, but I am not in a 4G area so I can only test this through the end user and I really want to limit the number of attempts. My first thought is that the 'BACKGROUND' is slightly longer than the 'FailedQA', and while the other one is longer it has a numeric start. So maybe adding white space to the response would help? The other aspect is response time. The 'BACKGROUND' message is normally sent faster than the other ones. But, I do have a counter example here so I am not sire. Example: the 'BACKGROUND' message normally goes out within 15 to 20 seconds. The other messages are normally 30-40 seconds. However, I have one example where the '1336757671374T37171FR' style response went out in 24 seconds and was not received and one where the 'BACKGROUND' message went out in 27 seconds and was received.

So to sum up: This only happens on Sprint 4G. I suspect it might either be content length or response time that is causing the issue, but in both cases I have a counter example to the contrary. Except with the length case the one that is the longer counter example has a numeric beginning, so there's that.

Answer 1

It seems to be the delay before a response that was causing the problem. I used this guide Easy Parallel Processing in PHP to set up a multi-tasking php configuration. This way I have a script that just counts and echos the elapsed seconds while the other one does the job processing. The problem is now resolved.