android app failed to get content at 80 port with HttpClient

Question

I want to develop an android app to get post.xml with HttpClient. But it failed to get content with 80 port.

If I start the web server(WEBrick here) with 3000 port, the URI is http://192.168.1.103:3000/posts.xml ; Android App can get response with correct length, like 568;

The same web files, I started them with another server (Nignx here) with 80 port, the uri is "http://192.168.1.103/posts.xml; The Android App can NOT get content with length, it's -1 here.
This URI can be opened with browser(both PC and android emulator) correctly. Furthermore, the response is "HTTP/1.1 200 OK" with responsep.getStatusLine().

is it related with "Socket ports below 1024 can NOT access in linux like system", which is on http://groups.google.com/group/android-developers/browse_thread/thread/660123ca64ba1229#

Any Ninja can tell me what should I do if I can to get content with 80 port?

The following is my code.

public class AndroidWorldActivity extends Activity { /** Called when the activity is first created. */

TextView tv; 

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);        
    retreiveProjects();
}


private void retreiveProjects()
{
  HttpClient httpClient = new DefaultHttpClient();
  try
  {
    String url3000 = "http://192.168.1.103:3000/posts.xml";
    String url = "http://192.168.1.103/posts.xml";

    Log.d( "posts", "performing get " + url3000);
    HttpGet httpGet=new HttpGet(url3000);

    HttpResponse responsep=httpClient.execute(httpGet);        
    System.out.println(responsep.getStatusLine());

    HttpEntity httpEntity = responsep.getEntity();
    int length = ( int ) httpEntity.getContentLength();

// print the lenght of content

    System.out.println("The content length is: "+length);
    Log.d( "posts", "The content length is: " + length );

Answer 1

From your description, I understand that you are trying to connect from adroid to an external HTTP server attached to port 80? If so, restriction about port lower than 1024 on android has nothing to do (you are not trying to listen on port 80 on android device). I think, that you have a problem with Nginx.

Try to execute GET request from an external machine to Nginx and investigate response content (headers, payload). I would recommend to do it with some more low-level tool instead of web browser (almost all web browser nowadays are able to "repair" illegal server responses), for example curl:

curl -D - http://192.168.1.103/posts.xml

Answer 2

You seem to have two separate problems.

The problem on WeBrick seems to be that the UNIX / Linux won't allow your web server to bind to port 80. There are two obvious things to check:

• Is the web server running with root privilege when it attempts to bind to the port? See Is there a way for non-root processes to bind to "privileged" ports on Linux? for a variety of ways to work around this problem.

• Is some other application already bound to port 80? Is so, kill it and try to run your web server again.

---

The problem with Nignx is different. Here, the server is up and running and giving your client responses, but the client is seeing -1 as the content length.

This is normal behaviour. The getContentLength() method returns -1 if the response doesn't have a "Content-length" header, and it is perfectly legitimate (according to the HTTP specification) for a response to not have this header. You have two choices:

• Change your client-side application to deal with the case where the content length is unspecified; eg just read the body into a buffer and count how many bytes you got.

• Change the server to set the relevant header.

---

FOLLOWUP

I see. Your original question was hard to understand and I misinterpreted. You seemed to be saying that WEBrick wasn't working at all.

The difference between WEBrick and Nginx is that they simply implement the response differently. Both are legitimate (valid) implementation. The real problem is that your application is assuming that a web server will always set the "Content-length" header. That is an incorrect assumption.

To repeat, the problem / fault is in your client code, not in Nginx.