Posted by tom1234
on September 9, 2010 at 7:50 AM PDT
This may be the wrong place but i needed to start somewhere.
I am working with a Java based product that really benefits from using the HTTP 1.1 connection:keepalive option.
Client is on Windows (XP, Vista) Proxy configured or no proxy configured
Browser version does not matter, we can reproduce failue without browser.
Application Server is Sun Solaris
Apache Proxy server in front of application server
Cisco load balancer (CSS) in front Apache Proxy
My problem is this:
1. While using JRE1.6.0_21 without a proxy server on the client side (browser and JRE are unaware of or not configured for proxy), if the server side decides to close a persistent connection, there is a window where the JRE can make an HTTP request that goes unanswered due to the connection being closed on one side. When this happens, the JRE appears to back off, create a new connection and then retries the request that failed. This works very well.
2. While using JRE1.6.0_21 with a proxy server configured on the client side (browser or JRE are aware of the proxy and have to encapsulate their requests), if the server side decides to close a persistent connection, the same window exists for an unanswered HTTP request to be sent out on the closing connection. When this happens, the JRE appears to back off, create a new connection and then retries the request that failed. Unfortunately, the "new" request will be missing important fields in the Headers and the server responds with an HTTP 400 error. I have wireshark captures and detailed java logs (debug=all) that clearly show the retry is missing Header information even as the JRE prepares to send it.
3. We have tried various configuration changes on our side, including ssl-unclean-shutdown with no luck in fixing this issue. It resembles an issue that is documented for MSIE and JRE in days of old. (JRE1.4.2_x will not even retry and gets a java io exception). The difference here is that it does retry but fails consistently and the failure seems obvious, the cause does not.
4. Disabling http 1.1, keepalives etc...fixes the issue but returns us to a lesser performance state and we want to avoid that. So far, our only recourse has been to disable connection: keepalive for clients who are using a visible proxy server.
5. Can't understand why this works without the client side proxy and consistently fails with it. It's as if the JRE calls different routines (one to encapsulate the data for proxy and one that does not have to for non-proxy) and in so doing, manages to garble the original request.
6. I am new to this but it makes sense that we can't be the only ones who have this issue. As a matter of fact, I have seen this in 2 different products written by 2 different vendors.
Sorry about the long winded description. Any suggestions would be greatly appreciated!