HTTP client socket inputstream help

[tsxn26]

I'm trying to code a simple http client that receives a requested
resource from an http server. Something that is puzzling me is that
the InputStream from the socket is coming up empty after requesting the
resource. Here is an similar example of my code:

Socket sock = new Socket(server, port);

OutputStream out = sock.getOutputStream();
InputStream in = sock.getInputStream();

/* Code to send http request to http server here */

System.out.println("The size of the input stream is: " +
in.available());

The output from the println statement is always 0. I'm positive that
the request has been received from the http server because I'm also
running a http server class that shows the file name of the GET
request. The server sends the resource by the following code:

FileInputStream fis = new FileInputStream(req);

byte[] data = new byte[fis.available()];
fis.read(data);
out.write(data);

Can anyone spot out why my clientside InputStream is always empty?

 

[Knute Johnson]

I'm trying to code a simple http client that receives a requested
resource from an http server. Something that is puzzling me is that
the InputStream from the socket is coming up empty after requesting the
resource. Here is an similar example of my code:

Socket sock = new Socket(server, port);

OutputStream out = sock.getOutputStream();
InputStream in = sock.getInputStream();

/* Code to send http request to http server here */

System.out.println("The size of the input stream is: " +
in.available());

The output from the println statement is always 0. I'm positive that
the request has been received from the http server because I'm also
running a http server class that shows the file name of the GET
request. The server sends the resource by the following code:

FileInputStream fis = new FileInputStream(req);

byte[] data = new byte[fis.available()];
fis.read(data);
out.write(data);

Can anyone spot out why my clientside InputStream is always empty?

You might take a look at the docs for InputStream.available(). You
don't need it anyway because the HTTP response will have the size of the
data in it.

 

[tsxn26]

I see now that InputStream.available() doesn't provide the size of the
stream. I also see that the http server class I was testing doesn't
properly implement the protocol by not including headers.

Also is there any way to determine the size of the resource if the
server doesn't include the Content-Length header in its response?

 

[Knute Johnson]

I see now that InputStream.available() doesn't provide the size of the
stream. I also see that the http server class I was testing doesn't
properly implement the protocol by not including headers.

Also is there any way to determine the size of the resource if the
server doesn't include the Content-Length header in its response?

The simplest way is to read until the stream is closed. Then you have
it all.

 

[tsxn26]

I see now that InputStream.available() doesn't provide the size of the
stream. I also see that the http server class I was testing doesn't
properly implement the protocol by not including headers.

Also is there any way to determine the size of the resource if the
server doesn't include the Content-Length header in its response?

 

[tsxn26]

Correct me if I'm wrong... That way requires a counter variable and a
byte array to store the bytes read from the InputStream. I could get
the size by incrementing the counter until the stream is closed but
what about the byte array size? I would have to instantiate the array
with a size before doing any stream reading. The problem is the size
of the byte array. Since you don't know the size of the stream you
have to make a guess of what to make the size of the byte array tp hold
all the contents of the stream. If you make it too big and the stream
isn't very big then you'll just be wasting memory and if you make it
too small and the stream is big then you won't capture all the stream
content.

 

[Knute Johnson]

Correct me if I'm wrong... That way requires a counter variable and a
byte array to store the bytes read from the InputStream. I could get
the size by incrementing the counter until the stream is closed but
what about the byte array size? I would have to instantiate the array
with a size before doing any stream reading. The problem is the size
of the byte array. Since you don't know the size of the stream you
have to make a guess of what to make the size of the byte array tp hold
all the contents of the stream. If you make it too big and the stream
isn't very big then you'll just be wasting memory and if you make it
too small and the stream is big then you won't capture all the stream
content.

Well if your server isn't going to tell you how big it is then you have
to have some other plan. What is the data and what are you going to do
with it? If it is going to be written to media then it probably doesn't
matter how big it is. If you are just going to hold on to the data then
you need to have a clue. But if the data isn't just random bytes then
it will probably have a practical limit to it's size. Make the buffer a
local object and get rid of it when you are done with it.

 

[Chris Uppal]

Correct me if I'm wrong... That way requires a counter variable and a
byte array to store the bytes read from the InputStream. I could get
the size by incrementing the counter until the stream is closed but
what about the byte array size?

Use a java.io.ByteArrayOutputStream to buffer the data as you're reading it.
That provides a buffer which will grow as necessary.

-- chrid

 

[Roedy Green]

Also is there any way to determine the size of the resource if the
server doesn't include the Content-Length header in its response?

You have to read it to the end. Presumably the length of each chunk
is still in there. You can see it if you read HTTP with a raw socket.
see http://mindprod.com/applets/fileio.html