Support creating a pidfile/portfile

[xmo-odoo]

Problem Description

When driving mitmproxy / mitmdump externally, it can be useful to tell mitmproxy to use port 0 to ensure there is no port conflict and be able to run multiple instances concurrently.

While mitmproxy will bind fine,

• it can be difficult to know when it's started, stable, and ready to be interacted with
• it only outputs the port to stdout
• if the output mode is default or verbose (no output in quiet mode)
• and stdout being fully buffered makes it difficult to retrieve (the only way I've found is to run mitmdump under PYTHONUNBUFFERED=1)

Furthermore, once the port has been parsed out it requires additional infrastructure to ensure the pipe is read from to avoid the risk of mitmproxy blocking (no sure it actually happens in this case).

Proposal

The ability to specify a file to which (colloquially a pidfile, although in this case it wouldn't contain the pid, or not just the pid). Or a directory in which mitmproxy will create a well named file (that might be a bit less tricky in terms of ACLs). The file can be structured in order to provide more content (e.g. both pid and port), but ideally should be written atomically in order to ensure clients polling for the file can't do partial reads.

Prior Art

Under certain conditions, Chrome creates a file called DevToolsActivePort in the user data dir.

[mhils]

Happy to take a look at a PR that adds an addon for this! :)

[xmo-odoo]

Hmmm looking into things I see that I was a tiny bit naive as I only ever used mitmproxy in regular mode with a single proxy, so I'm just discovering you can run not just multiple modes but also the same mode bound multiple times (e.g. --mode regular:8888 --mode regular:8889).

So I see two options:

• Only work in single-mode, well, mode.

• Or have the portfile be structured and storing a mapping of mode spec to port (could store in json which also means there's no need to faff around with atomic renames, the client would just have to retry reading until they get a valid JSON file).

  Since mitmproxy already rejects having two modes with the same port (even if it's port 0) there should be no conflict or ambiguity.

[mhils]

Outputting as JSON sounds reasonable to me. :)

[xmo-odoo]

Outputting as JSON sounds reasonable to me. :)

👍