Could you test that and see how it works? Here's a revised patch that does catch the CancelledError. Which still worries me, apparenly nobody else had this issue so far. If you have more suggestions then I will try them out, this is dead easy for me to reproduce. In other words, while we drain the upstream send buffer, our own downstream receive buffer fills up and the OS' TCP implementation signals to downstream that they need to slow down. So while mitmproxy is slowly shoveling bits upstream, your client is done uploading for minutes already, hits a timeout, and aborts the connection 1.ĭraining the upstream connection aftere each read means we wait for space in the upstream send buffer to be available before we continue reading from the downstream socket again.

mitmproxy would very quickly read everything from your local device and then have an immense send buffer for the upstream connection. Assume you have a very fast connection to your laptop, a slower connection upstream, and you want to upload a large file. I do not fully understand the code in server.py, for instance, why there is a need to drain all writers As we have already cancelled our own coroutine this await drain() immediately throws a CancelledError, which as you correctly pointed out both of us did not catch before! The problem just happens to be much more visible in my patch. What's may be happening here is that we first cancel our very own connection handler task we're currently in, and after that then drain() another transport. This confused me for a bit, but I think I have a working theory now: When a coroutine/task is cancelled, it continues to run normally until the next await statement, which throws a CancelledError. After the first or second click already the connection stalls consistently. It made it worse for pass-through connections ( on my iPad). But let's focus on the initial issue here. Very impressive! I'm actually somewhat puzzled which part silently swallows the OSError here, I definitely need to figure out why exceptions are ignored and correct that. After narrowing down this far I started inserting self.log() until I found that the one after drain() sometimes was not logging. I also noticed that for the connection that stalled, the log entry client disconnect in ConnectionHandler() after watch.cancel() was missing for that connection. With tcpdump I noticed that when a page load stalled that I could still tap on links and that the browser then still sent data to the proxy after that transport has been closed (HTTP/2 does that) so it had to be the stream management at a low level. The hard way, with tcpdump/wireshark, -set proxy_debug=true and putting self.log() all over the place in server.py. My main driver is a Windows machine in regular mode, so that's quite a different stack. I run mitmdump in transparent mode (easy for me to add and remove my machines), from the git repo directly on a CentOS 8 Stream on a laptop.

I wonder what it takes to reproduce this on your side. Thanks for looking into this! Apart from this issue the new sansio design rocks! I can even scroll around in Google Maps and the CPU usage of the proxy machine remains in the one digit range.

Mitmproxy github