[squid-users] Accelerating proxy with SSL cannot transmit data bigger than 4k

Hi,

I am using squid as an accelerating proxy between an applet and a web
application server. The applet opens connections to the application server
using the following code:

        java.net.URLConnection conn = url.openConnection();
        conn.setUseCaches(false);
        conn.setDoOutput(true);
        conn.setDoInput(true);
        conn.setRequestProperty ("Content-Type", "application/octet-stream");
        out = new java.io.ObjectOutputStream(conn.getOutputStream());
        out.writeObject(inputModel);
        out.flush();
        out.close();

        // receive data from connection servlet
        java.io.ObjectInputStream in = null;
        in = new java.io.ObjectInputStream(conn.getInputStream());
        outputModel = in.readObject();
        in.close();

Without SSL, everything works fine. With SSL, if the transmitted data size
from the applet to the servlet is bigger than about 4k, squid receives the
data and forwards it correctly to the application server, but never closes
the connection, thus the following code on my application server is stuck
in readObject():

        ObjectInputStream in = new ObjectInputStream(request.getInputStream());
        Object[] inputModel = (Object[]) in.readObject();
        in.close();

        ObjectOutputStream out = new ObjectOutputStream(
                                                        response.getOutputStream());
        response.setContentType("application/octet-stream");
        out.writeObject(outputModel);
        out.flush();
        out.close();

If I kill squid manually, readObject continues and also each transmitted
byte can be found here. It seems like squid is just not closing the output
stream.

The question is: why? And why does it depend on the amount of data to
transmit?

I would be happy, if someone could help me here. I am using squid 2.5
stable 6 and the SSL-enabled Windows build. I don't know, if this happens
under Linux too.

André
Received on Mon Sep 20 2004 - 07:14:34 MDT