Edit on GitHub

#  Protocols

#  HTTP/1.0 and HTTP/1.1

RFC7230: HTTP/1.1: Message Syntax and Routing

RFC7231: HTTP/1.1: Semantics and Content

HTTP/1.0 and HTTP/1.1 support in mitmproxy is based on our custom HTTP stack, which takes care of all semantics and on-the-wire parsing/serialization tasks.

mitmproxy currently does not support HTTP trailers - but if you want to send us a PR, we promise to take look!

#  HTTP/2

RFC7540: Hypertext Transfer Protocol Version 2 (HTTP/2)

HTTP/2 support in mitmproxy is based on hyper-h2. It fully encapsulates the internal state of HTTP/2 connections and provides an easy-to-use event-based API. mitmproxy supports the majority of HTTP/2 feature and tries to transparently pass-through as much information as possible.

mitmproxy currently does not support HTTP/2 trailers - but if you want to send us a PR, we promise to take look!

mitmproxy currently does not support HTTP/2 Cleartext (h2c) since none of the major browser vendors have implemented it.

Some websites are still having problems with correct HTTP/2 support in their webservers and can cause errors, dropped connectiones, or simply no response at all. We are trying to be as tolerant and forgiving as possible with the types of data we send and receive, but some faulty implementations simply don’t work well with mitmproxy.

In order to increase the compatibility of mitmproxy with HTTP/2 webservers, we default to NOT forward any priority information that is sent by a client. You can enable it with: http2_priority=true.

#  WebSocket

RFC6455: The WebSocket Protocol

RFC7692: Compression Extensions for WebSocket

WebSocket support in mitmproxy is based on wsproto project. It fully encapsulates WebSocket frames/messages/connections and provides an easy-to-use event-based API.

mitmproxy fully supports the compression extension for WebSocket messages, provided by wsproto. Message contents are automatically compressed and decompressed before firing events.

mitmproxy currently does not display WebSocket messages in the console or web UI. Only the WebSocket handshake flow is shown, which contains a reference to the parent flow for all messages exchanged over this connection.

If an endpoint sends a PING to mitmproxy, a PONG will be sent back immediately (with the same payload if present). To keep the other connection alive, a new PING (without a payload) is sent to the other endpoint. Unsolicited PONG’s are not forwarded. All PING’s and PONG’s are logged (with payload if present).

#  Raw TCP / TCP Proxy / Fallback

In case mitmproxy does not handle a specific protocol, you can exempt hostnames from processing, so that mitmproxy acts as a generic TCP forwarder. This feature is closely related to the passthrough functionality, but differs in two important aspects:

Please note that message interception or modification are not possible yet. If you are not interested in the raw TCP messages, you should use the ignore domains feature.

command-line alias --tcp HOST
mitmproxy shortcut press O then T