Six years after mitmproxy's first checkin, we've finally released version 1.0.0 of the project. Our version numbering persisted below 1.0 well into the project's maturity, for reasons that are a tad difficult to explain. My mental model of software development is of an eternal pilgrimage - the roadmap of possible improvements stretches on forever, and we never quite reach a point where we look back and feel that we've arrived. From this perspective, it makes sense for 1.0 to always be out of reach. Rather than adopting more transcendental options, I've stuck with simply incrementing the minor version with each release. This release sees two changes in our process. First, we're committing to a much more regular cadence, aiming for a new release every two months or so (with minor bugfix and patch releases in between). Second, each of these releases will see a major version number increment - this is v1.0, we'll release v2.0 by the end of February, and so forth. This retains something of the flavor of our previous eccentric version numbering strategy by de-emphasizing major version increments as flagfall events, without being as restrictive. Let the pilgrimage continue.

The project's momentum continues to be excellent - since the last release, we've had 459 commits by 10 contributors, resulting in 104 closed issues and 172 closed PRs, all in just over 70 days. All this activity has resulted in a number of very significant developments.

Over the last year, we've done a huge amount of work converting the project from Python 2 to Python 3. Our previous release straddled the two versions, retaining compatibility with Python 2.7. This release is strictly Python3-only. We are now well positioned to take full advantage of things like optional type checking, the new asyncio module and the many small and large interface improvements that Python 3 brings.

Our user interfaces continue to improve by leaps and bounds. The console interface now has a much cleaner core, sports a number of new features like flow ordering, and has seen significant speed improvements. We're also finally releasing something we've been cooking up for quite a while - mitmweb, a web interface to mitmproxy. It's doesn't have feature parity with the console tool yet, but we feel it's ready to step onto the stage as one of our primary interfaces. Since mitmproxy console doesn't run on Windows (yet), mitmweb is the best GUI option for our Windows users for now. We're also improving our distribution mechanisms on Windows, with a new installer package kindly provided by BitRock. These two developments together mean much better support for our Windows users.

At a protocol level, we're happy to announce that our support for Websockets is now mature, and enabled by default. For the moment, the best way to interact with Websockets traffic is to use our scripting mechanism - we will have support in the GUIs very soon. On the HTTP/2 front, the news is mixed. We're very happy with the quality of our own implementation of the protocol, but we've discovered that some server implementations still have problems with certain protocol edge cases. Over the last few months we found multiple bugs affecting some very prominent websites and CDNs. We are working closely with the affected companies to get these issues fixed - but big wheels turn slowly, especially when it comes to business-critical infrastructure, and all the needed repairs haven't been rolled out yet. This has left us in a bit of a quandary - we know that fixes for these issues are imminent, and we believe that the particular problems are idiosyncratic and shouldn't prompt a redevelopment of our core to make us bug-for-bug compatible. None the less, the effect is that mitmproxy's HTTP2 implementation will currently do unexpected things when talking to large sites like Twitter and Reddit. We've decided to disable HTTP/2 by default for this release - you can explicitly re-enable it using the --http2 flag.

Finally, if you're interested in hacking on mitmproxy, now is an excellent time to join us. Contributing is simple - pick one of the issues that we've tagged as good first contributions, join us on Slack to discuss your approach, and then send a PR.

Changelog

• All mitmproxy tools are now Python 3 only! We plan to support Python 3.5 and higher.
• Web-Based User Interface: Mitmproxy now offically has a web-based user interface called mitmweb. We consider it stable for all features currently exposed in the UI, but it still misses a lot of mitmproxy’s options.
• Windows Compatibility: With mitmweb, mitmproxy is now useable on Windows. We are also introducing an installer (kindly sponsored by BitRock) that simplifies setup.
• Configuration: The config file format is now a single YAML file. In most cases, converting to the new format should be trivial - please see the docs for more information.
• Console: Significant UI improvements - including sorting of flows by size, type and url, status bar improvements, much faster indentation for HTTP views, and more.
• HTTP/2: Significant improvements, but is temporarily disabled by default due to wide-spread protocol implementation errors on some large website
• WebSocket: The protocol implementation is now mature, and is enabled by default. Complete UI support is coming in the next release. Hooks for message interception and manipulation are available.
• A myriad of other small improvements throughout the project.