Skip to content
This repository has been archived by the owner on Jun 11, 2024. It is now read-only.

How to migrate to mitmproxy #395

Open
dkbarn opened this issue Jun 11, 2024 · 1 comment
Open

How to migrate to mitmproxy #395

dkbarn opened this issue Jun 11, 2024 · 1 comment

Comments

@dkbarn
Copy link

dkbarn commented Jun 11, 2024

The README states that this project is deprecated and mitmproxy is intended to be the replacement. But after reading through the documentation for mitmproxy it is unclear to me how to migrate from browserup-proxy to it, because it seems to operate in a fundamentally different way.

Are there any guides or tutorials available to help users of browserup-proxy migrate to mitmproxy?

With browserup-proxy you are running a persistent proxy server in the background, and the API allows you to "attach" to that running process, enabling you to begin and end sessions and capture traffic from a separate process.

In contrast, mitmproxy does not operate with this same client/server model. There is only the running instance of the proxy server, but no way to "attach" to that running process from your own application. Instead the Python API can only hook into events in the same process, and thus any Python addons must be passed as arguments to the mitmproxy command itself. So it is unclear to me how someone is expected to accomplish the same functionality as browserup-proxy using mitmproxy.

@ericbeland
Copy link
Contributor

There aren't any guides or tutorials per se. I agree that the model is a bit different. In terms of starting/stopping the proxy via a client-server approach, yes, that is different.

For many use-cases, you could substitute the idea of "telling the proxy server to launch a proxy set to a port" as "a shell command is executed to launch an mitmproxy process (mitmdump) on a port." The main feature of browserup proxy was to capture HAR information for traffic passing through it. This is now native in mitmproxy. From there, you would need to dump the har, but that gets you a full capturing-setup that already captures more than browserup-prox could (websocket, http/2, http/3).

I totally agree that the model is different, and there is more DIY there. Unfortunately, the cost of trying to maintain the browserup proxy wasn't worth the tradeoff given the massive investment needed for us. We'd be happy if someone forked it, though.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants