Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / February 2006

Tip: Looking for answers? Try searching our database.

HTTP client socket inputstream help

Thread view: 
tsxn26@gmail.com - 13 Feb 2006 23:08 GMT
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 - 14 Feb 2006 01:13 GMT
> 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.



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.