Mitmproxy author here. It is kind of interesting that one of the best ways to get feedback for your software is reading random comments on the internet - thanks

Mitmproxy author here. It is kind of interesting that one of the best ways to get feedback for your software is reading random comments on the internet - thanks for that! :) > libmproxy is not recommended for external projects. This is true (for the reasons outlined in [1]), but your use case is the reason why we also offer the libmproxy API. That being said, you'll see improvments here in the next release (and hopefully a lot of stability afterwards). > The dumped streams are not in a standard format either We would love to use JSON, but JSON does not really work with streaming. We use tnetstrings (not serialized python objects) instead, and we do schema migrations for the last 5 releases now. We have an example on how to read dumpfiles in Python in the repo [2]. :) > Performance Thanks for bringing that up. Scaling beyond a few concurrent users is not a design goal for mitmproxy currently - otherwise we probably should start rewriting it in Rust/Go. If you need anything large-scale, the submission here is vastly superior. :) [1] http://docs.mitmproxy.org/en/stable/scripting/mitmproxy.html http://docs.mitmproxy.org/en/stable/scripting/mitmproxy.html [2] https://github.com/mitmproxy/mitmproxy/blob/master/examples/read_dumpfile https://github.com/mitmproxy/mitmproxy/blob/master/examples/...