mirror of
https://github.com/Grasscutters/mitmproxy.git
synced 2024-11-26 18:18:25 +00:00
36 lines
1.4 KiB
HTML
36 lines
1.4 KiB
HTML
|
|
||
|
|
- command-line: _-S path_
|
||
|
|
- mitmproxy shortcut: _S_
|
||
|
|
|
||
|
|
Server-side replay lets us replay server responses from a saved HTTP
|
||
|
|
conversation.
|
||
|
|
|
||
|
|
Matching requests with responses
|
||
|
|
--------------------------------
|
||
|
|
|
||
|
|
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.
|
||
|
|
|
||
|
|
|
||
|
|
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, __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__.
|
||
|
|
|
||
|
|
|