We previously relied on the state of `Flow.reply` to check if a flow can be killed,
but this doesn't work anymore with `Flow.reply` being removed. Instead, we now
reintroduce the `Flow.live` attribute, which signals if we are on a live connection.
Killing still is not ideal (see comment in `Flow.killable`), but this paves the way.
The major, breaking change is that it is no longer possible to "take" a reply in
order to block the effect of a later addon hook.
This is patch 4/4 of the reply-ectomy.
In principle, a flow is killable as long as the connection handler is still
checking the error status of the flow.
This is patch 2/4 of the reply-ectomy.
This should improve behaviour, since calls to @concurrent will now be serialized
relative to other hooks on the same flow (but will still run in parallel with
hooks on different flows). Unlike a plain async hook, @concurrent allows blocking
sync APIs to run concurrently (e.g. requests).
This is patch 1/4 of the reply-ectomy.
Previously, it was throwing the following error:
File mitmproxy/addons/dumper.py, line 133, in _echo_request_line
elif flow.client_conn.peername:
AttributeError: 'bool' object has no attribute 'peername'
* await server_connected hook before doing something with the connection
* refine changelog wording
Co-authored-by: Maximilian Hils <github@maximilianhils.com>
* Example addon for saving streamed data including a small bug fix to make it work.
* Revert "Example addon for saving streamed data including a small bug fix to make it work."
This reverts commit 02ab78def9a52eaca1a89d0757cd9475ce250eaa.
* Fix for issue #5077
* add keyboard shortcut n to mitmweb (by creating /flows/create route)
* add keyboard shortcut n to mitmweb (simplified, by using runCommand instead of a new route)
When I call shutdown with a different loop in the current thread from MITM loop, it's crashes with the error:
`ValueError: The future belongs to a different loop than the one specified as the loop argument`
Setting a loop explicit fixes the problem.
