Merge pull request #2890 from mitmproxy/newdocs

All new documentation

4 files changed, 0 insertions, 84 deletions

diff --git a/docs/protocols/http1.rst b/docs/protocols/http1.rst
deleted file mode 100644
index 21e68785..00000000
--- a/docs/protocols/http1.rst
+++ /dev/null
@@ -1,15 +0,0 @@
-.. _http1_protocol:
-
-HTTP/1.0 and HTTP/1.1
-===========================
-
-.. seealso::
-
-    - `RFC7230: HTTP/1.1: Message Syntax and Routing <http://tools.ietf.org/html/rfc7230>`_
-    - `RFC7231: HTTP/1.1: Semantics and Content <http://tools.ietf.org/html/rfc7231>`_
-
-HTTP/1.0 and HTTP/1.1 support in mitmproxy is based on our custom HTTP stack,
-which takes care of all semantics and on-the-wire parsing/serialization tasks.
-
-mitmproxy currently does not support HTTP trailers - but if you want to send
-us a PR, we promise to take look!
diff --git a/docs/protocols/http2.rst b/docs/protocols/http2.rst
deleted file mode 100644
index b3268ae5..00000000
--- a/docs/protocols/http2.rst
+++ /dev/null
@@ -1,16 +0,0 @@
-.. _http2_protocol:
-
-HTTP/2
-======
-
-.. seealso::
-
-    - `RFC7540: Hypertext Transfer Protocol Version 2 (HTTP/2) <http://tools.ietf.org/html/rfc7540>`_
-
-HTTP/2 support in mitmproxy is based on the amazing work by the python-hyper
-community with the `hyper-h2 <https://github.com/python-hyper/hyper-h2>`_
-project. It fully encapsulates the internal state of HTTP/2 connections and
-provides an easy-to-use event-based API.
-
-mitmproxy currently does not support HTTP/2 trailers - but if you want to send
-us a PR, we promise to take look!
diff --git a/docs/protocols/tcpproxy.rst b/docs/protocols/tcpproxy.rst
deleted file mode 100644
index 77248573..00000000
--- a/docs/protocols/tcpproxy.rst
+++ /dev/null
@@ -1,31 +0,0 @@
-.. _tcp_proxy:
-
-TCP Proxy / Fallback
-====================
-
-In case mitmproxy does not handle a specific protocol, you can exempt
-hostnames from processing, so that mitmproxy acts as a generic TCP forwarder.
-This feature is closely related to the :ref:`passthrough` functionality,
-but differs in two important aspects:
-
-- The raw TCP messages are printed to the event log.
-- SSL connections will be intercepted.
-
-Please note that message interception or modification are not possible yet.
-If you are not interested in the raw TCP messages, you should use the ignore domains feature.
-
-How it works
-------------
-
-================== ======================
-command-line       ``--tcp HOST``
-mitmproxy shortcut :kbd:`O` then :kbd:`T`
-================== ======================
-
-For a detailed description how the hostname pattern works, please look at the :ref:`passthrough`
-feature.
-
-.. seealso::
-
-    - :ref:`passthrough`
-    - :ref:`streaming`
diff --git a/docs/protocols/websocket.rst b/docs/protocols/websocket.rst
deleted file mode 100644
index 8a7e807f..00000000
--- a/docs/protocols/websocket.rst
+++ /dev/null
@@ -1,22 +0,0 @@
-.. _websocket_protocol:
-
-WebSocket
-=========
-
-.. seealso::
-
-    - `RFC6455: The WebSocket Protocol <http://tools.ietf.org/html/rfc6455>`_
-    - `RFC7692: Compression Extensions for WebSocket <http://tools.ietf.org/html/rfc7692>`_
-
-WebSocket support in mitmproxy is based on the amazing work by the python-hyper
-community with the `wsproto <https://github.com/python-hyper/wsproto>`_
-project. It fully encapsulates WebSocket frames/messages/connections and
-provides an easy-to-use event-based API.
-
-mitmproxy fully supports the compression extension for WebSocket messages,
-provided by wsproto.
-
-If an endpoint sends a PING to mitmproxy, a PONG will be sent back immediately
-(with the same payload if present). To keep the other connection alive, a new
-PING (without a payload) is sent to the other endpoint. Unsolicited PONG's are
-not forwarded. All PING's and PONG's are logged (with payload if present).