Hi Ken,
Thanks for your suggestion. Certainly helped but not the whole ten
yards. I found that by not reading the 'null' at the end of the buffer
the IO exception is not thrown. I did this using the ready() method of
BufferedReader. ready() returns false if there is no data in the buffer
to be
it you can force it.
Ken.
[EMAIL PROTECTED] on 12/12/2000 06:27:04
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:(bcc: Ken X Horn)
Subject: RE: Multiple GETs on an SSLSocket
Hi Ken,
Thanks for your suggestion. Certainly helped but not the whole ten
yards. I found
is
probably best it you can force it.
Ken.
[EMAIL PROTECTED] on 12/12/2000 06:27:04
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:(bcc: Ken X Horn)
Subject: RE: Multiple GETs on an SSLSocket
Hi Ken,
Thanks for your suggestion. Certainly helped
[EMAIL PROTECTED] wrote:
Chunking is a transfer encoding, introduced in HTTP 1.1. In 1.0, the
server can set a header, at the start of the stream like:
Content-length: 400\r\n
\r\n
400 bytes of content
Meaning 400 bytes in the body. The problem with this is that the server
Have you tried this on a non-SSL connection?
A general problem with the IO in java (afaik) is that, if you read from the
stream, such that you get a -1 returned, then the stream is effectively
closed. You have to reconnect (I haven't tried SSL on this, but a plain
socket works like this). If
