docs: scripts on saved flows

This commit is contained in:
Aldo Cortesi 2016-10-16 18:25:59 +13:00
parent 97b594b848
commit 57b8ed21a9
1 changed files with 23 additions and 7 deletions

View File

@ -1,7 +1,7 @@
.. _overview: .. _overview:
Introduction Overview
============ ========
Mitmproxy has a powerful scripting API that allows you to control almost any Mitmproxy has a powerful scripting API that allows you to control almost any
aspect of traffic being proxied. In fact, much of mitmproxy's own core aspect of traffic being proxied. In fact, much of mitmproxy's own core
@ -96,11 +96,27 @@ for advanced usage.
Running scripts on saved flows Running scripts on saved flows
------------------------------ ------------------------------
Sometimes, we want to run a script on :py:class:`~mitmproxy.models.Flow` objects that are already When a flow is loaded from disk, the sequence of events that the flow would
complete. This happens when you start a script, and then load a saved set of flows from a file have gone through on the wire is partially replayed. So, for instance, an HTTP
(see the "scripted data transformation" example :ref:`here <mitmdump>`). flow loaded from disk will trigger `requestheaders
It also happens when you run a one-shot script on a single flow through the ``|`` (pipe) shortcut <events.html#requestheaders>`_, `request <events.html#request>`_,
in mitmproxy. `responseheaders <events.html#responseheaders>`_ and `response
<events.html#response>`_ in order. We can use this behaviour to transform saved
traffic using scripts. For example, we can invoke the replacer script from
above on saved traffic as follows:
>>> mitmdump -dd -s "./arguments.py html faketml"
:py:class:`~mitmproxy.models.Flow`
objects that are already complete. This happens when you start a script, and
then load a saved set of flows from a file (see the "scripted data
transformation" example :ref:`here <mitmdump>`). It also happens when you run a
one-shot script on a single flow through the ``|`` (pipe) shortcut in
mitmproxy.
In this case, there are no client connections, and the events are run in the following order: In this case, there are no client connections, and the events are run in the following order:
**start**, **request**, **responseheaders**, **response**, **error**, **done**. **start**, **request**, **responseheaders**, **response**, **error**, **done**.