2015-09-05 23:37:15 +00:00
|
|
|
.. _serverreplay:
|
|
|
|
|
|
|
|
Server-side replay
|
|
|
|
==================
|
|
|
|
|
|
|
|
Server-side replay lets us replay server responses from a saved HTTP
|
|
|
|
conversation.
|
|
|
|
|
|
|
|
Matching requests with responses
|
|
|
|
--------------------------------
|
|
|
|
|
|
|
|
By default, :program:`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.
|
2016-06-07 02:08:46 +00:00
|
|
|
The ``--rheader headername`` command-line option allows you to override
|
2015-09-05 23:37:15 +00:00
|
|
|
this behaviour by specifying individual headers that should be included in matching.
|
|
|
|
|
|
|
|
|
|
|
|
Response refreshing
|
|
|
|
-------------------
|
|
|
|
|
|
|
|
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, :program:`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.
|
|
|
|
|
2016-06-07 02:08:46 +00:00
|
|
|
You can turn off response refreshing using the ``--norefresh`` argument, or using
|
2015-09-05 23:37:15 +00:00
|
|
|
the :kbd:`o` options shortcut within :program:`mitmproxy`.
|
|
|
|
|
2017-01-08 00:58:30 +00:00
|
|
|
|
|
|
|
Replaying a session recorded in Reverse-proxy Mode
|
|
|
|
--------------------------------------------------
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
2016-06-07 02:08:46 +00:00
|
|
|
================== ===========
|
|
|
|
command-line ``-S path``
|
2016-10-11 21:57:05 +00:00
|
|
|
mitmproxy shortcut :kbd:`R` then :kbd:`s`
|
2016-06-07 02:08:46 +00:00
|
|
|
================== ===========
|