We’re using mitmproxy to playback recorded sessions.
The live TLS connections to upstream servers were introducing noise into our performance tests so we’re attempting to disable them with the “upstream_cert=false” or “–no-upstream-cert” option (using mitmdump 2.02).
However I noticed that this prevents HTTP/2 playback (http1.1 chosen during alpn).
Is there any way to playback HTTP/2 without connecting to the live upstream servers?
Reading up on how ALPN is implemented (in the TLS handshake), my question becomes,
“Is there any way that I can record the server’s choice of h2 as the protocol in the mitmdump session recording?”
Can anyone confirm whether it’s possible to playback HTTP/2 with upstream cert sniffing disabled?
This would be very helpful for us (offline playback).
If it’s not supported I’d be happy to write up feature request use-case.
Hi @andrewMoz,
This is a tricky problem we currently don’t have a good answer for. We currently don’t do HTTP/2 <-> HTTP/1 translation, so when we negotiate HTTP/2 with the client we kind of need to make sure that the server supports it as well (as we can’t determine if a replay will happen at this point).
One viable approach might be to provide some form of ALPN callback to the scripting interface, but we haven’t implemented anything of that sort yet.
If you really really do need HTTP/2, one viable workaround might be to put mitmproxy into upstream/reverse proxy mode and point to some dummy server running on the same machine that advertises h2. This will trick mitmproxy into thinking that upstream does support it.