> 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
[quoted text clipped - 23 lines]
>
> 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.

Signature
Knute Johnson
email s/nospam/knute/
tsxn26@gmail.com - 14 Feb 2006 02:36 GMT
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 - 14 Feb 2006 02:50 GMT
> 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.

Signature
Knute Johnson
email s/nospam/knute/
tsxn26@gmail.com - 14 Feb 2006 03:08 GMT
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 - 14 Feb 2006 05:18 GMT
> 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
[quoted text clipped - 7 lines]
> 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.

Signature
Knute Johnson
email s/nospam/knute/
Chris Uppal - 14 Feb 2006 11:53 GMT
> 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
tsxn26@gmail.com - 14 Feb 2006 02:57 GMT
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?
Roedy Green - 14 Feb 2006 16:56 GMT
>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

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.