-
Notifications
You must be signed in to change notification settings - Fork 778
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Zombie client connections with SSL proxy server? #276
Comments
Hi @maxcellent, thank you very much for your observations. I'm using LittleProxy with a MitmManager and I think I've seen volatile connection problems too, I couldn't dig into. I use LittleProxy based on version: 1.1.0-beta2-SNAPSHOT. It's difficult to test a released version since I depend on modifications in #230. Using an ActivityTracker is a great idea. I'm happy to test your suggested modification in 4. too - I assume it is working better for you. But I would like to reproduce it before to understand the problem(s). In my experiences both Netty/NIO and SSL depends on the platform sometimes. What's your platform? |
The code in 4 seems not to be complete. Please push a PR if you think it's a solution or it reproduces the problem. I've never used an ActivityTracker. Eventually you've added special logging or conditional debug to show your observations. |
@jekh I've noticed a blocking behavior in a situation easy possible in IO/TLS processing. It seems to be an undefined or incomplete exception handling in connection flow. Please verify. At The point is the proxy was blocking after logging the Exception. An Exception in the flow at this stage leads to a blocked connection. |
LittleProxy version: 1.1.0-beta1
Hi,
We are running a SSL proxy and tracking client connection with ActivityTracker. Here are some observations. I believe not all of them are relevant, but I am no expert to proxy technology so trying to provide as much information as I can.
because nothing has been sent / received from server (ssl handshake is not performed), currentServerConnection.lastReadTime is always 0, which means clientReadMoreRecentlyThanServer is always true, which then explains 3. Shall we change this to something like this?
I am happy to test and submit a patch. But would like to confirm if this is the desired behaviour first.
Thanks,
The text was updated successfully, but these errors were encountered: