I use mitmproxy and mitmdump a lot. I really recommend it. Someone else said it's not easy to hack on, I do not agree. It's a really approachable project and great if you're doing anything HTTP related. That said, there are some pain points:

* libmproxy is not recommended for external projects. Instead you should use "inline scripts" (embedding functionality in mitmproxy). This is a pain point for me since I wanted to work on the captured streams in an external program that already existed and I shouldn't need to run mitmdump to do that work. The dumped streams are not in a standard format either, they're serialized python objects and dumps from different mitmproxy versions sometimes break the format.

* Performance. Having more than a couple of concurrent requests at the time tends to eat CPU. Running the requests of one browser through it is fine. Running multiple browser instances (e.g., using the new headless library in chromium for automated testing) through it, continuously performing requests is not a good idea. Memory footprint is also quite high, but is not a limiting factor for me.

I would like it if the dump format was a standard format and if libmproxy was a stable API.

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 [2] https://github.com/mitmproxy/mitmproxy/blob/master/examples/...

Performance is actually the reason I started this project.

A friend of mine was creating a product based on mitmproxy for a client and was running in to performance projects. He asked me for advice and I pointed him to just how little work it was to do exactly what he wanted with openresty, instead of mitmproxy.

If you want everything, mitmproxy might be for you. If you want fast, minimal, hackable, and not a pile of python then openresty and my approach might be for you.

My problem with using mitm proxy is that it isn't as easy to hack on.

I'm an nginx person, so learning a new python code base to hack on features I want is way harder than having something simple I can add on to, as needed.

I found easy to get started, it's as simple as the post. The real benefit I see is to plug arbitrary python code to hack requests and responses. It's very good, but I've noticed some crashes in my experiments too.

That's what the benefit of using openresty is. I can print and hack on http requests in an already mature ecosystem.

It's two ways to do the same thing, but I like my way, and mine uses software that is production ready as a proxy :)

Open testy is awesome for lots of things. However, if I'm doing HTTP debugging, I use curl, Charles, ZAP ( https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Proje... ), tcpdump, and wireshark, in order from simplest to most complex problems.