RE: Hessian failure with "Proxy-Connection: keep-alive"

It looks like the attached files prevented my post from going through.
You can download them from http://logan.carbonfive.com/~alon/proxy.zip.

Alon

________________________________

From: Alon J Salant
Sent: Friday, May 26, 2006 1:47 PM
To: 'hessian-interest@xxx.com'
Subject: RE: Hessian failure with "Proxy-Connection: keep-alive"

Thanks Scott,

The problem does appear to be on the server.

I've attached a zip file with the results from packet sniffing a working
and failing Hessian call. These calls are being made between a Java
applet and a licensed Resin 3.0 Pro 3.0.14 server.

If for some reason the zip does not come through, let me know and I can
arrange to get it to you some other way.

Alon

________________________________

From: owner-hessian-interest@xxx.com
[mailto:owner-hessian-interest@xxx.com] On Behalf Of Scott Ferguson
Sent: Friday, May 26, 2006 1:16 PM
To: hessian-interest@xxx.com
Subject: Re: Hessian failure with "Proxy-Connection: keep-alive"

On May 26, 2006, at 9:51 AM, Alon J Salant wrote:

We have found an issue with Hessian running through some proxy servers.
The issue appears to be with using keep-alives to send chunked data.

Do you know if the problem is on the server or client side?

The Proxy-Connection should be a red-herring, since it should only
affect following requests (and keep-alive is the default value anyway).

My guess would be something about the chunked encoding is wrong. Either
the client or the proxy is producing bad chunked encoding, or Resin
isn't decoding it properly. In other words, there might be something
about the particular chunked encoding bytes that the Resin HTTP parser
isn't decoding properly.

So, assuming it's the server that's choking, getting a dump of the exact
bytes would help.

-- Scott

Here are Hessian POST headers for a working call:

      HTTP: 1: POST /tops-services/remote/ContentManagerRemote
HTTP/1.1

      HTTP: 2: Authorization: Basic NTcyMDA2L2NsZWFjaDpjbGVhY2gx

      HTTP: 3: Content-Type: text/xml

      HTTP: 4: User-Agent: Mozilla/4.0 (Windows 2000 5.0)
Java/1.5.0_06

      HTTP: 5: Host: tops.taylorpub.com

      HTTP: 6: Accept: text/html, image/gif, image/jpeg, *; q=.2, */*;
q=.2

      HTTP: 7: Connection: keep-alive

      HTTP: 8: Transfer-Encoding: chunked

      HTTP: 9: Cookie: JSESSIONID=aDLoOoVXfLj9c3TXRT

Here are Hessian POST headers for the failing call:

      HTTP: 1: POST
http://tops.taylorpub.com/tops-services/remote/ContentManagerRemote
HTTP/1.1

      HTTP: 2: Authorization: Basic NTcyMDA2L2NsZWFjaDpjbGVhY2gx

      HTTP: 3: Content-Type: text/xml

      HTTP: 4: User-Agent: Mozilla/4.0 (Windows 2000 5.0)
Java/1.5.0_06

      HTTP: 5: Host: tops.taylorpub.com

      HTTP: 6: Accept: text/html, image/gif, image/jpeg, *; q=.2, */*;
q=.2

      HTTP: 7: Proxy-Connection: keep-alive

      HTTP: 8: Transfer-Encoding: chunked

      HTTP: 9: Cookie: JSESSIONID=a6ODB1JO8wDcjDtYRT

The only significant difference appears to be the 'Connection:
keep-alive' v. 'Proxy-Connection: keep-alive' headers.

We used a network sniffer to inspect the packets being sent. In the
working case, the following packets include chunked data. In the failing
case, the server responds with a 400 Bad Request and the client throws
an exception:

Caused by: java.io.IOException: Error writing request body to server

    at
sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.checkE
rror(Unknown Source)

    at
sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.write(
Unknown Source)

    at
com.caucho.hessian.io.HessianOutput.writeBytes(HessianOutput.java:664)

Hessian on the server reports an exception:

com.caucho.hessian.io.HessianProtocolException: addContent: expected end
of call ('z') at end of stream.

        at
com.caucho.hessian.io.HessianInput.error(HessianInput.java:1640)

        at
com.caucho.hessian.io.HessianInput.completeCall(HessianInput.java:259)

        at
com.caucho.hessian.server.HessianSkeleton.invoke(HessianSkeleton.java:15
2)

        at
org.springframework.remoting.caucho.HessianServiceExporter.handleRequest
(HessianServiceExporter.java:87)

        ...

In the failing case it appears that Resin/Hessian think that the call is
finished after the first chunk of the request is sent instead of waiting
for the coming content as it does in the succeeding case.

My conclusion is that Resin/Hessian are not handling the
'Proxy-Connection: keep-alive' header correctly.

This is a fairly significant issue for us right now. I'd be happy to
take some time to dig a bit deeper into the code if that would be
helpful. Pointers on where to look would be appreciated. A fix would be
appreciated even more :-)

Alon

 
Received on Fri 26 May 2006 14:47:31 -0700