Unable to read InputStream in Signed Applet when interacting with ISA proxy
Background info:
We have an applet that we use for incremental refresh of data items.
The applet model works for all but one of our customers
Client info:
VeriSIgn signed applet.
IE 6.0 browser
Java JRE version: 1.5.0_06-b05
OS: Windows XP Version 2002 service pack 2
Problem description:
I am consistently getting a premature EOF exception when trying to read from a BufferedInputStream.
The stack trace, if captured ends up in the ChunkedInputStream reader.
I have tried a variety of request header settings to no avail.
Connection: close
Connection: Keep-Alive
etc...
Any comments are welcome
Thanks for reading and considering
Kurt
[744 byte] By [
Kurt-Javaa] at [2007-10-2 14:53:45]
Are you using a Socket or URL?
The URL object uses keep-alive and needs to be red until the end or when an
exceptions occures the errorstream needs to be red:
http://forum.java.sun.com/thread.jspa?threadID=645830
3rd post
I assume you use a polling style to refresh the data items (connect to server ->
get info from server -> close the connection) because you tried connection: close
request header. The jre uses a default of keep-alive and I don't think this should
be a problem
I do remember the isa proxy here doing something with the applet when it
was found not to be safe but that made the whole applet unusable (key signature
corrupt or something) It does the same thinig with javascript that isa does
not like (can be configured on the isa but not by me).
A Full trace might help us out:
http://forum.java.sun.com/thread.jspa?threadID=656028
We are using the HttpURLConnection. If I have to go down the stack to the Socket object, well I guess I have to re event the wheel so to speak.
I have tried both Connection: close and Connection: Keep-Alive. Not at the same time :) but in different intrim releases of test applet.
// Here is the current incarnation of how I am trying to connect.
URL url = new URL(sURL);
trace("attempting to connect to URL: " + sURL, DEBUG);
connection = (HttpURLConnection)url.openConnection();
connection.setDoOutput(true);
connection.setDoInput( true );
connection.setRequestMethod("POST");
connection.setUseCaches( false );
connection.setInstanceFollowRedirects( true );
connection.setAllowUserInteraction( false );
connection.setRequestProperty("Pragma", "no-cache");
connection.setRequestProperty("Expires", "-1");
connection.setRequestProperty("Connection", "Keep-Alive");
connection.connect();
// Now I write our form POST data and flush and close the output stream.
BufferedOutputStream bos = new BufferedOutputStream(connection.getOutputStream());
bos.write(sForm.getBytes());
bos.flush();
bos.close();
// Get the input and read
bis = new BufferedInputStream(connection.getInputStream());
trace( "reading input stream for action: " + sAction );
byte[] responseBuffer = new byte[4096];
int bytesRead = 0;
while( (bytesRead = bis.read( responseBuffer, 0, responseBuffer.length )) != -1 )
{
sbResponse.append( new String( responseBuffer, 0, bytesRead ));
totalBytesRead += bytesRead;
}
}
catch (Throwable e)
{
e.printStackTrace();
try
{
m_connections.remove( sAction );
connection.disconnect();
}
catch ( Throwable t ) {}
}
finally
{
if ( bis != null )
{
try
{
bis.close();
}
catch( Throwable t ) {}
}
}
With the above code in place what I am now seeing, as opposed to a premature EOF exception, is blocking behavior on the read.
