Steps to reproduce the problem:
- Save flows to a file,
saved.mitm - Wait a few minutes
- Use a command like
mitmdump -n -C saved.mitm -s myscript.py -w replayed.mtimto replay the saved flows. - The observe the flows with
mitmproxy -n -r replayed.mitmand see that the request-response time of the flows are inaccurate because it seems to be calculated using the start time of the requests insaved.mitm.
Any other comments? What have you tried so far?
If such behavior is intentional, what’s the recommended way to set the request timestamps so that they reflect the time when the requests are actually replayed rather than the previously saved timestamps?
System information
Mitmproxy: 4.0.4
Python: 3.7.0
OpenSSL: OpenSSL 1.0.2p 14 Aug 2018
Platform: Darwin-17.5.0-x86_64-i386-64bit