aboutsummaryrefslogtreecommitdiffstats
path: root/docs/features/streaming.rst
diff options
context:
space:
mode:
authorAldo Cortesi <aldo@nullcube.com>2018-02-22 17:21:34 +1300
committerAldo Cortesi <aldo@nullcube.com>2018-02-22 18:07:58 +1300
commit982508d30f887b4fe8b2a855792ae1e33f378222 (patch)
tree9d749a57929a950f0e177a9bf4d6cd7d9a88c16b /docs/features/streaming.rst
parent1cacefa104626e4e0df5ffb2aa8b0c6f16b615b2 (diff)
downloadmitmproxy-982508d30f887b4fe8b2a855792ae1e33f378222.tar.gz
mitmproxy-982508d30f887b4fe8b2a855792ae1e33f378222.tar.bz2
mitmproxy-982508d30f887b4fe8b2a855792ae1e33f378222.zip
All new documentation
This patch does a lot. - Ditch sphinx in favor of hugo. This gives us complete control of the layout and presentation of our docs. Henceforth, docs will be hosted on our website rather than ReadTheDocs. - Create a simple, clean doc layout and theme. - Remove large parts of the documentaion. I've ditched anything that was a) woefully out of date, b) too detailed, or c) too hard to maintain in the long term. - Huge updates to the docs themselves: completely rewrite addons documentation, add docs for core concepts like commands and options, and revise and tweak a lot of the existing docs. With this patch, we're also changing the way we publish and maintain the docs. From now on, we don't publish docs for every release. Instead, the website will contain ONE set of docs for each major release. The online docs will be updated if needed as minor releases are made. Docs are free to improve during minor releases, but anything that changes behaviour sufficiently to require a doc change warrants a new major release. This also leaves us free to progressively update and improve docs out of step with our release cadence. With this new scheme, I feel CI over the docs is less important. I've removed it for now, but won't object if someone wants to add it back in.
Diffstat (limited to 'docs/features/streaming.rst')
-rw-r--r--docs/features/streaming.rst102
1 files changed, 0 insertions, 102 deletions
diff --git a/docs/features/streaming.rst b/docs/features/streaming.rst
deleted file mode 100644
index 82510843..00000000
--- a/docs/features/streaming.rst
+++ /dev/null
@@ -1,102 +0,0 @@
-.. _streaming:
-
-HTTP Streaming
-==============
-
-By default, mitmproxy will read the entire request/response, perform any indicated
-manipulations on it and then send the (possibly modified) message to
-the other party. In some cases this is undesirable and you may wish to "stream"
-the request/response. When streaming is enabled, the request/response is
-not buffered on the proxy but directly sent to the server/client instead.
-HTTP headers are still fully buffered before being sent.
-
-Request Streaming
------------------
-
-Request streaming can be used to incrementally stream a request body to the server
-before it has been fully received by the proxy. This is useful for large file uploads.
-
-Response Streaming
-------------------
-
-By using mitmproxy's streaming feature, response contents can be passed to the client incrementally
-before they have been fully received by the proxy. This is especially useful for large binary files
-such as videos, where buffering the whole file slows down the client's browser.
-
-On the command-line
--------------------
-
-Streaming can be enabled on the command line for all request and response bodies exceeding a certain size.
-The SIZE argument understands k/m/g suffixes, e.g. 3m for 3 megabytes.
-
-================== =================
-command-line ``--set stream_large_bodies=SIZE``
-================== =================
-
-.. warning::
-
- When streaming is enabled, **streamed request/response contents will not be
- recorded or preserved in any way.**
-
-.. note::
-
- When streaming is enabled, the request/response body cannot be modified by the usual means.
-
-Customizing Streaming
----------------------
-
-You can also use a script to customize exactly which requests or responses are streamed.
-
-Requests/Responses that should be tagged for streaming by setting their ``.stream``
-attribute to ``True``:
-
-.. literalinclude:: ../../examples/complex/stream.py
- :caption: examples/complex/stream.py
- :language: python
-
-Implementation Details
-----------------------
-
-When response streaming is enabled, portions of the code which would have otherwise performed
-changes on the request/response body will see an empty body. Any modifications will be ignored.
-
-Streamed bodies are usually sent in chunks of 4096 bytes. If the response is sent with a
-``Transfer-Encoding: chunked`` header, the response will be streamed one chunk at a time.
-
-Modifying streamed data
------------------------
-
-If the ``.stream`` attribute is callable, ``.stream`` will wrap the generator that yields all
-chunks.
-
-.. literalinclude:: ../../examples/complex/stream_modify.py
- :caption: examples/complex/stream_modify.py
- :language: python
-
-WebSocket Streaming
-===================
-
-The WebSocket streaming feature can be used to send the frames as soon as they arrive. This can be useful for large binary file transfers.
-
-On the command-line
--------------------
-
-Streaming can be enabled on the command line for all WebSocket frames
-
-================== =================
-command-line ``--set stream_websockets=true``
-================== =================
-
-.. note::
-
- When Web Socket streaming is enabled, the message payload cannot be modified.
-
-Implementation Details
-----------------------
-When WebSocket streaming is enabled, portions of the code which may perform changes to the WebSocket message payloads will not have
-any effect on the actual payload sent to the server as the frames are immediately forwarded to the server.
-In contrast to HTTP streaming, where the body is not stored, the message payload will still be stored in the WebSocket Flow.
-
-.. seealso::
-
- - :ref:`passthrough`