Strange HTTP Socket Problem...

[Craig Lindley]

Hi,

I've written a small HTTP server that also handles servlets. It works
perfectly fine for files and almost perfectly fine for servlets. The
strange problem that occurs with servlets is as follows:

The servlet runs fine, fills the PrintWriter (backed onto a
ByteArrayOutputStream) fine, I output the HTTP header to the socket
(Internet Explorer) flush it, then write the body of the servlet. This
seems to work fine for smaller servlets, but as soon as the servlet outputs
a larger amount of data it gives a 90% "page cannot be displayed" message.
The REALLY strange thing is, if I wait 50ms or so after flushing the streams
and before I close the socket, all works fine. Although on one machine the
50ms delay had to be cranked upto 1000ms before it didn't "page cannot be
displayed".

ANY and all ideas welcome!!!

Thanks,
Craig.

 

[Chris Uppal]

as soon as the servlet
outputs a larger amount of data it gives a 90% "page cannot be displayed"
message. The REALLY strange thing is, if I wait 50ms or so after flushing
the streams and before I close the socket, all works fine.

Are you closing the socket itself, or the OutputStream that is connected to it
?

-- chris

 

[Craig Lindley]

Are you closing the socket itself, or the OutputStream that is connected

to it

I've flushed the stream, closed the stream and then closed the socket. I've
tried various combinations of the above, even tried NOT closing anything and
seeing if IE will do that for me. I've also tried checking that there's no
more data on the inputstream.

 

[Silvio Bierman]

to it

I've flushed the stream, closed the stream and then closed the socket. I've
tried various combinations of the above, even tried NOT closing anything and
seeing if IE will do that for me. I've also tried checking that there's no
more data on the inputstream.

Do you generate a content length header with the correct bytecount? Do you
handle the connection keep alive header?

A HTTP server has quite some nifty demands to fullfill. Connection and
content length handling are examples of this.

Silvio Bierman

 

[Craig Lindley]

Do you generate a content length header with the correct bytecount? Do you
handle the connection keep alive header?

I do indeed. I don't handle keep alive, I return connection close.

A HTTP server has quite some nifty demands to fullfill. Connection and
content length handling are examples of this.

Most of them are straightforward enough I've found.

 

[Kevin McMurtrie]

Hi,

I've written a small HTTP server that also handles servlets. It works
perfectly fine for files and almost perfectly fine for servlets. The
strange problem that occurs with servlets is as follows:

The servlet runs fine, fills the PrintWriter (backed onto a
ByteArrayOutputStream) fine, I output the HTTP header to the socket
(Internet Explorer) flush it, then write the body of the servlet. This
seems to work fine for smaller servlets, but as soon as the servlet outputs
a larger amount of data it gives a 90% "page cannot be displayed" message.
The REALLY strange thing is, if I wait 50ms or so after flushing the streams
and before I close the socket, all works fine. Although on one machine the
50ms delay had to be cranked upto 1000ms before it didn't "page cannot be
displayed".

ANY and all ideas welcome!!!

Thanks,
Craig.

Got code? Here are some random thoguhts -

Did you mess with Socket.setSoLinger(boolean on, int linger)? When you
close your socket, it waits the specified amount of time for the client
to finish. The socket is reset (aborted) if time runs out. Fussing
with the OS defaults can cause the same problem.

Make sure you're closing everything in the opposite order you opened it.
Closing the socket before closing the output stream can abort some data.
Character to byte converters properly is important because they lag by a
few bytes. Check that your streams pass along close() properly.

Don't share buffers between threads while they're in use.

Socket.close() is asynchronous. The JVM shouldn't quit right after
closing a socket or server socket. Don't try to re-open a specific port
unless you've manually specified the SO_LINGER value and have waited
that long.

If you're using transfer encoding or compression, double check that it
is correct. They're very tricky to get right.