docs: concurrency, developing scripts

This commit is contained in:
Aldo Cortesi 2016-10-16 20:21:43 +13:00
parent 9a0195bf64
commit 00603021d9
3 changed files with 20 additions and 32 deletions

View File

@ -105,38 +105,37 @@ flow loaded from disk will trigger `requestheaders
traffic using scripts. For example, we can invoke the replacer script from traffic using scripts. For example, we can invoke the replacer script from
above on saved traffic as follows: above on saved traffic as follows:
>>> mitmdump -dd -s "./arguments.py html faketml" >>> mitmdump -dd -s "./arguments.py html fakehtml" -r saved -w changed
This command starts the ``arguments`` script, reads all the flows from
``saved`` transforming them in the process, then writes them all to
``changed``.
The mitmproxy console tool provides interactive ways to run transforming
scripts on flows - for instance, you can run a one-shot script on a single flow
through the ``|`` (pipe) shortcut.
: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:
**start**, **request**, **responseheaders**, **response**, **error**, **done**.
If the flow doesn't have a **response** or **error** associated with it, the matching events will
be skipped.
Concurrency Concurrency
----------- -----------
We have a single flow primitive, so when a script is blocking, other requests The mitmproxy script mechanism is single threaded, and the proxy blocks while
are not processed. While that's usually a very desirable behaviour, blocking script handlers execute. This hugely simplifies the most common case, where
scripts can be run threaded by using the :py:obj:`mitmproxy.script.concurrent` handlers are light-weight and the blocking doesn't have a performance impact.
decorator. It's possible to implement a concurrent mechanism on top of the blocking
framework, and mitmproxy includes a handy example of this that is fit for most
purposes. You can use it as follows:
.. literalinclude:: ../../examples/nonblocking.py .. literalinclude:: ../../examples/nonblocking.py
:caption: :src:`examples/nonblocking.py` :caption: :src:`examples/nonblocking.py`
:language: python :language: python
Developing scripts Developing scripts
------------------ ------------------
Mitmprxoy monitors scripts for modifications, and reloads them on change. When
this happens, the script is shut down (the `done <events.html#done>`_ event is
called), and the new instance is started up as if the script had just been
loaded (the `start <events.html#start>`_ and `configure
<events.html#configure>`_ events are called).

View File

@ -267,7 +267,7 @@ class ScriptLoader():
ochain = ctx.master.addons.chain ochain = ctx.master.addons.chain
pos = ochain.index(self) pos = ochain.index(self)
ctx.master.addons.chain = ochain[:pos+1] + ordered + ochain[pos+1:] ctx.master.addons.chain = ochain[:pos + 1] + ordered + ochain[pos + 1:]
for s in newscripts: for s in newscripts:
ctx.master.addons.startup(s) ctx.master.addons.startup(s)

View File

@ -1,15 +1,4 @@
General build and release utilities for the mitmproxy, netlib and pathod
projects. These tools assume a directory structure with all repositories at the
same level, for example:
/src
/mitmproxy
/netlib
/pathod
/release
# Release policies # Release policies
- By default, every release is a new minor (`0.x`) release and it will be - By default, every release is a new minor (`0.x`) release and it will be