Server-side replay lets us replay server responses from a saved HTTP conversation.
By default, mitmproxy excludes request headers when matching incoming requests with responses from the replay file. This works in most circumstances, and makes it possible to replay server responses in situations where request headers would naturally vary, e.g. using a different user agent. The --rheader headername command-line option allows you to override this behaviour by specifying individual headers that should be included in matching.
Simply replaying server responses without modification will often result in unexpected behaviour. For example cookie timeouts that were in the future at the time a conversation was recorded might be in the past at the time it is replayed. By default, mitmproxy refreshes server responses before sending them to the client. The date, expires and last-modified headers are all updated to have the same relative time offset as they had at the time of recording. So, if they were in the past at the time of recording, they will be in the past at the time of replay, and vice versa. Cookie expiry times are updated in a similar way.
You can turn off response refreshing using the --norefresh argument, or using the o options shortcut within mitmproxy.
If you have captured the session in reverse proxy mode, in order to replay it you still have to specify the server URL, otherwise you may get the error: 'HTTP protocol error in client request: Invalid HTTP request form (expected authority or absolute...)'.
During replay, when the client's requests match previously recorded requests, then the respective recorded responses are simply replayed by mitmproxy. Otherwise, the unmatched requests is forwarded to the upstream server. If forwarding is not desired, you can use the --kill (-k) switch to prevent that.
| command-line | -S path |
| mitmproxy shortcut | R then s |