remove old docs

16 files changed, 0 insertions, 574 deletions

diff --git a/doc-src/features/anticache.html b/doc-src/features/anticache.html
deleted file mode 100644
index f42903e8..00000000
--- a/doc-src/features/anticache.html
+++ /dev/null
@@ -1,18 +0,0 @@
-
-When the __anticache__ option is passed to mitmproxy, it removes headers
-(__if-none-match__ and __if-modified-since__) that might elicit a
-304-not-modified response from the server. This is useful when you want to make
-sure you capture an HTTP exchange in its totality. It's also often used during
-[client replay](@!urlTo("clientreplay.html")!@), when you want to make sure the
-server responds with complete data.
-
-<table class="table">
-    <tbody>
-        <tr>
-            <th width="20%">command-line</th> <td>--anticache</td>
-        </tr>
-        <tr>
-            <th>mitmproxy shortcut</th> <td><b>o</b> then <b>a</b></td>
-        </tr>
-    </tbody>
-</table>
diff --git a/doc-src/features/clientreplay.html b/doc-src/features/clientreplay.html
deleted file mode 100644
index 6638d078..00000000
--- a/doc-src/features/clientreplay.html
+++ /dev/null
@@ -1,22 +0,0 @@
-
-Client-side replay does what it says on the tin: you provide a previously saved
-HTTP conversation, and mitmproxy replays the client requests one by one. Note
-that mitmproxy serializes the requests, waiting for a response from the server
-before starting the next request. This might differ from the recorded
-conversation, where requests may have been made concurrently.
-
-You may want to use client-side replay in conjunction with the
-[anticache](@!urlTo("anticache.html")!@) option, to make sure the server
-responds with complete data. 
-
-
-<table class="table">
-    <tbody>
-        <tr>
-            <th width="20%">command-line</th> <td>-c path</td>
-        </tr>
-        <tr>
-            <th>mitmproxy shortcut</th> <td><b>c</b></td>
-        </tr>
-    </tbody>
-</table>
diff --git a/doc-src/features/filters.html b/doc-src/features/filters.html
deleted file mode 100644
index c7f0f78b..00000000
--- a/doc-src/features/filters.html
+++ /dev/null
@@ -1,36 +0,0 @@
-
-Many commands in __mitmproxy__ and __mitmdump__ take a filter expression.
-Filter expressions consist of the following operators:
-
-<table class="table">
-    <tbody>
-    <!--(for i in filt_help)-->
-        <tr>
-            <td class="filt_cmd">@!i[0]!@</td>
-            <td class="filt_help">@!i[1]!@</td>
-        </tr>
-    <!--(end)-->
-    </tbody>
-</table>
-
-- Regexes are Python-style
-- Regexes can be specified as quoted strings
-- Header matching (~h, ~hq, ~hs) is against a string of the form "name: value".
-- Strings with no operators are matched against the request URL.
-- The default binary operator is &amp;.
-
-Examples
-========
-
-URL containing "google.com":
-
-    google\.com
-
-Requests whose body contains the string "test":
-
-    ~q ~b test
-
-Anything but requests with a text/html content type:
-
-    !(~q & ~t \"text/html\")
-
diff --git a/doc-src/features/index.py b/doc-src/features/index.py
deleted file mode 100644
index fdab1714..00000000
--- a/doc-src/features/index.py
+++ /dev/null
@@ -1,19 +0,0 @@
-from countershape import Page
-
-pages = [
-    Page("anticache.html", "Anticache"),
-    Page("clientreplay.html", "Client-side replay"),
-    Page("filters.html", "Filter expressions"),
-    Page("passthrough.html", "Ignore Domains"),
-    Page("proxyauth.html", "Proxy Authentication"),
-    Page("replacements.html", "Replacements"),
-    Page("responsestreaming.html", "Response Streaming"),
-    Page("reverseproxy.html", "Reverse proxy mode"),
-    Page("socksproxy.html", "SOCKS Mode"),
-    Page("setheaders.html", "Set Headers"),
-    Page("serverreplay.html", "Server-side replay"),
-    Page("sticky.html", "Sticky cookies and auth"),
-    Page("tcpproxy.html", "TCP Proxy"),
-    Page("upstreamcerts.html", "Upstream Certs"),
-    Page("upstreamproxy.html", "Upstream proxy mode"),
-]
diff --git a/doc-src/features/passthrough.html b/doc-src/features/passthrough.html
deleted file mode 100644
index 101a337a..00000000
--- a/doc-src/features/passthrough.html
+++ /dev/null
@@ -1,84 +0,0 @@
-There are two main reasons why you may want to exempt some traffic from mitmproxy's interception mechanism:
-
-- **Certificate pinning:** Some traffic is is protected using
-  [certificate pinning](https://security.stackexchange.com/questions/29988/what-is-certificate-pinning) and mitmproxy's
-  interception leads to errors. For example, Windows Update or the Apple App Store fail to work if mitmproxy is active.
-- **Convenience:** You really don't care about some parts of the traffic and just want them to go away.
-
-If you want to peek into (SSL-protected) non-HTTP connections, check out the [tcp proxy](@!urlTo("tcpproxy.html")!@) feature.
-If you want to ignore traffic from mitmproxy's processing because of large response bodies, take a look at the
-[response streaming](@!urlTo("responsestreaming.html")!@) feature.
-
-## How it works
-
-
-<table class="table">
-    <tbody>
-        <tr>
-            <th width="20%">command-line</th> <td>--ignore regex</td>
-        </tr>
-        <tr>
-            <th>mitmproxy shortcut</th> <td><b>o</b> then <b>I</b></td>
-        </tr>
-    </tbody>
-</table>
-
-
-mitmproxy allows you to specify a regex which is matched against a <code>host:port</code> string (e.g. "example.com:443")
-to determine hosts that should be excluded.
-
-There are two important quirks to consider:
-
-- **In transparent mode, the ignore pattern is matched against the IP.** While we usually infer the hostname from the
-  Host header if the --host argument is passed to mitmproxy, we do not have access to this information before the SSL
-  handshake.
-- In regular mode, explicit HTTP requests are never ignored.[^explicithttp] The ignore pattern is applied on CONNECT
-  requests, which initiate HTTPS or clear-text WebSocket connections.
-
-
-### Tutorial
-
-If you just want to ignore one specific domain, there's usually a bulletproof method to do so:
-
-1. Run mitmproxy or mitmdump in verbose mode (-v) and observe the host:port information in the serverconnect
-messages. mitmproxy will filter on these.
-2. Take the host:port string, surround it with ^ and $, escape all dots (. becomes \\.)
-and use this as your ignore pattern:
-
-<pre class="terminal">
-$ mitmdump -v
-127.0.0.1:50588: clientconnect
-127.0.0.1:50588: request
-  -> CONNECT example.com:443 HTTP/1.1
-127.0.0.1:50588: Set new server address: example.com:443
-127.0.0.1:50588: serverconnect
-  -> example.com:443
-^C
-$ mitmproxy --ignore ^example\.com:443$
-</pre>
-
-Here are some other examples for ignore patterns:
-<pre>
-# Exempt traffic from the iOS App Store (the regex is lax, but usually just works):
---ignore apple.com:443
-# "Correct" version without false-positives:
---ignore '^(.+\.)?apple\.com:443$'
-
-# Ignore example.com, but not its subdomains:
---ignore '^example.com:'
-
-# Ignore everything but example.com and mitmproxy.org:
---ignore '^(?!example\.com)(?!mitmproxy\.org)'
-
-# Transparent mode:
---ignore 17\.178\.96\.59:443
-# IP address range:
---ignore 17\.178\.\d+\.\d+:443
-</pre>
-
-### See Also
-
-- [TCP Proxy](@!urlTo("tcpproxy.html")!@)
-- [Response Streaming](@!urlTo("responsestreaming.html")!@)
-
-[^explicithttp]: This stems from an limitation of explicit HTTP proxying: A single connection can be re-used for multiple target domains - a <code>GET http://example.com/</code> request may be followed by a <code>GET http://evil.com/</code> request on the same connection. If we start to ignore the connection after the first request, we would miss the relevant second one.
diff --git a/doc-src/features/proxyauth.html b/doc-src/features/proxyauth.html
deleted file mode 100644
index c22d50f3..00000000
--- a/doc-src/features/proxyauth.html
+++ /dev/null
@@ -1,26 +0,0 @@
-
-Asks the user for authentication before they are permitted to use the proxy.
-Authentication headers are stripped from the flows, so they are not passed to
-upstream servers. For now, only HTTP Basic authentication is supported. The
-proxy auth options are ignored if the proxy is in transparent or reverse proxy
-mode.
-
-<table class="table">
-    <tbody>
-        <tr>
-            <th width="20%">command-line</th>
-            <td>
-                <ul>
-                    <li>--nonanonymous</li>
-
-                    <li>--singleuser USER</li>
-
-                    <li>--htpasswd PATH</li>
-                </ul>
-            </td>
-        </tr>
-    </tbody>
-</table>
-
-
-
diff --git a/doc-src/features/replacements.html b/doc-src/features/replacements.html
deleted file mode 100644
index 6de06d5e..00000000
--- a/doc-src/features/replacements.html
+++ /dev/null
@@ -1,74 +0,0 @@
-Mitmproxy lets you specify an arbitrary number of patterns that define text
-replacements within flows. Each pattern has 3 components: a filter that defines
-which flows a replacement applies to, a regular expression that defines what
-gets replaced, and a target value that defines what is substituted in.
-
-Replace hooks fire when either a client request or a server response is
-received. Only the matching flow component is affected: so, for example, if a
-replace hook is triggered on server response, the replacement is only run on
-the Response object leaving the Request intact. You control whether the hook
-triggers on the request, response or both using the filter pattern. If you need
-finer-grained control than this, it's simple to create a script using the
-replacement API on Flow components.
-
-Replacement hooks are extremely handy in interactive testing of applications.
-For instance you can use a replace hook to replace the text "XSS" with a
-complicated XSS exploit, and then "inject" the exploit simply by interacting
-with the application through the browser. When used with tools like Firebug and
-mitmproxy's own interception abilities, replacement hooks can be an amazingly
-flexible and powerful feature.
-
-
-## On the command-line
-
-The replacement hook command-line options use a compact syntax to make it easy
-to specify all three components at once. The general form is as follows:
-
-    /patt/regex/replacement
-
-Here, __patt__ is a mitmproxy filter expression, __regex__ is a valid Python
-regular expression, and __replacement__ is a string literal. The first
-character in the expression (__/__ in this case) defines what the separation
-character is. Here's an example of a valid expression that replaces "foo" with
-"bar" in all requests:
-
-    :~q:foo:bar
-
-In practice, it's pretty common for the replacement literal to be long and
-complex. For instance, it might be an XSS exploit that weighs in at hundreds or
-thousands of characters. To cope with this, there's a variation of the
-replacement hook specifier that lets you load the replacement text from a file.
-So, you might start __mitmdump__ as follows:
-
-<pre class="terminal">
-mitmdump --replace-from-file :~q:foo:~/xss-exploit
-</pre>
-
-This will load the replacement text from the file __~/xss-exploit__.
-
-Both the _--replace_ and _--replace-from-file_ flags can be passed multiple
-times.
-
-
-## Interactively
-
-The _R_ shortcut key in the mitmproxy options menu (_o_) lets you add and edit
-replacement hooks using a built-in editor. The context-sensitive help (_?_) has
-complete usage information.
-
-<table class="table">
-    <tbody>
-        <tr>
-            <th width="20%">command-line</th>
-            <td>
-                <ul>
-                    <li>--replace</li>
-                    <li>--replace-from-file</li>
-                </ul>
-            </td>
-        </tr>
-        <tr>
-            <th>mitmproxy shortcut</th> <td><b>o</b> then <b>R</b></td>
-        </tr>
-    </tbody>
-</table>
diff --git a/doc-src/features/responsestreaming.html b/doc-src/features/responsestreaming.html
deleted file mode 100644
index 6511e913..00000000
--- a/doc-src/features/responsestreaming.html
+++ /dev/null
@@ -1,58 +0,0 @@
-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.
-
-By default, mitmproxy will read the entire response, perform any indicated
-manipulations on it and then send the (possibly modified) response to
-the client. In some cases this is undesirable and you may wish to "stream"
-the reponse back to the client. When streaming is enabled, the response is
-not buffered on the proxy but directly sent back to the client instead.
-
-<h2>On the command-line</h2>
-
-Streaming can be enabled on the command line for all response bodies exceeding a certain size.  The SIZE argument understands
-k/m/g suffixes, e.g. 3m for 3 megabytes.
-
-<table class="table">
-    <tbody>
-    <tr>
-        <th width="20%">command-line</th>
-        <td>
-            --stream SIZE
-        </td>
-    </tr>
-    </tbody>
-</table>
-
-
-<h2>Caveats</h2>
-
-When response streaming is enabled, <strong>streamed response contents will not be
-    recorded or preserved in any way.</strong>
-
-When response streaming is enabled, the response body cannot be modified.
-
-<h2>Customizing Response Streaming</h2>
-
-You can also use an <a href="@!urlTo("scripting/inlinescripts.html")!@">inline script</a> to customize exactly
-which responses are streamed.
-
-Responses that should be tagged for streaming by setting their respective .stream attribute to True:
-
-$!example("examples/stream.py")!$
-
-<h2>Implementation Details</h2>
-
-When response streaming is enabled, portions of the code which would have otherwise performed changes
-on the response body will see an empty response body instead (<code>libmproxy.protocol.http.CONTENT_MISSING</code>). Any modifications will be ignored.
-
-Streamed responses are usually sent in chunks of 4096 bytes. If the response is sent with a <code>Transfer-Encoding:
-    chunked</code> header, the response will be streamed one chunk at a time.
-
-<h2>Modifying streamed data</h2>
-If the <code>.stream</code> attribute is callable, .stream will work as a hook in chunk data processing.
-
-$!example("examples/stream_modify.py")!$
-
-### See Also
-
-- [Ignore Domains](@!urlTo("passthrough.html")!@)
diff --git a/doc-src/features/reverseproxy.html b/doc-src/features/reverseproxy.html
deleted file mode 100644
index af5a5c53..00000000
--- a/doc-src/features/reverseproxy.html
+++ /dev/null
@@ -1,47 +0,0 @@
-
-In reverse proxy mode, mitmproxy accepts standard HTTP requests and forwards
-them to the specified upstream server. This is in contrast to
-<a href="@!urlTo("upstreamproxy.html")!@">upstream proxy mode</a>, in which
-mitmproxy forwards HTTP proxy requests to an upstream proxy server.
-
-<table class="table">
-    <tbody>
-        <tr>
-            <th width="20%">command-line</th> <td>-R <i>scheme</i>://hostname[:port]</td>
-        </tr>
-    </tbody>
-</table>
-
-Here, **scheme** signifies if the proxy should use TLS to connect to the server.
-mitmproxy accepts both encrypted and unencrypted requests and transforms them to what the server
-expects.
-
-    mitmdump -R https://httpbin.org -p 80
-    mitmdump -R https://httpbin.org -p 443
-
-
-### Host Header
-
-In reverse proxy mode, mitmproxy does not rewrite the host header. While often useful, this
-may lead to issues with public web servers. For example, consider the following scenario:
-
-    $ python mitmdump -d -R http://example.com/ &
-    $ curl http://localhost:8080/
-
-    >> GET https://example.com/
-        Host: localhost:8080
-        User-Agent: curl/7.35.0
-        [...]
-
-    << 404 Not Found 345B
-
-Since the Host header doesn't match <samp>example.com</samp>, an error is returned.<br>
-There are two ways to solve this:
-<ol>
-    <li>Modify the hosts file of your OS so that example.com resolves to 127.0.0.1.</li>
-    <li>
-        Instruct mitmproxy to rewrite the host header by passing <kbd>&#8209;&#8209;setheader&nbsp;:~q:Host:example.com</kbd>.
-        However, keep in mind that absolute URLs within the returned document or HTTP redirects will cause the client application
-        to bypass the proxy.
-    </li>
-</ol>
\ No newline at end of file
diff --git a/doc-src/features/serverreplay.html b/doc-src/features/serverreplay.html
deleted file mode 100644
index 1282be06..00000000
--- a/doc-src/features/serverreplay.html
+++ /dev/null
@@ -1,35 +0,0 @@
-
-- command-line: _-S path_ 
-- mitmproxy shortcut: _S_
-
-Server-side replay lets us replay server responses from a saved HTTP
-conversation.
-
-Matching requests with responses
---------------------------------
-
-By default, __mitmproxy__ excludes request headers when matching incoming
-requests with responses from the replay file. This works in most circumstances,
-and makes it possible to replay server responses in situations where request
-headers would naturally vary, e.g. using a different user agent. The _--rheader
-headername_ command-line option allows you to override this behaviour by
-specifying individual headers that should be included in matching.
-
-
-Response refreshing
--------------------
-
-Simply replaying server responses without modification will often result in
-unexpected behaviour. For example cookie timeouts that were in the future at
-the time a conversation was recorded might be in the past at the time it is
-replayed. By default, __mitmproxy__ refreshes server responses before sending
-them to the client. The __date__, __expires__ and __last-modified__ headers are
-all updated to have the same relative time offset as they had at the time of
-recording. So, if they were in the past at the time of recording, they will be
-in the past at the time of replay, and vice versa. Cookie expiry times are
-updated in a similar way.
-
-You can turn off response refreshing using the _--norefresh_ argument, or using
-the _o_ options shortcut within __mitmproxy__.
-
-
diff --git a/doc-src/features/setheaders.html b/doc-src/features/setheaders.html
deleted file mode 100644
index 79850e35..00000000
--- a/doc-src/features/setheaders.html
+++ /dev/null
@@ -1,18 +0,0 @@
-
-This feature lets you specify a set of headers to be added to requests or
-responses, based on a filter pattern. You can specify these either on the
-command-line, or through an interactive editor in mitmproxy.
-
-<table class="table">
-    <tbody>
-        <tr>
-            <th width="20%">command-line</th>
-            <td>
-                --setheader PATTERN
-            </td>
-        </tr>
-        <tr>
-            <th>mitmproxy shortcut</th> <td><b>o</b> then <b>H</b></td>
-        </tr>
-    </tbody>
-</table>
diff --git a/doc-src/features/socksproxy.html b/doc-src/features/socksproxy.html
deleted file mode 100644
index f436cbf5..00000000
--- a/doc-src/features/socksproxy.html
+++ /dev/null
@@ -1,10 +0,0 @@
-
-In this mode, mitmproxy acts as a SOCKS5 proxy server.
-
-<table class="table">
-    <tbody>
-        <tr>
-            <th width="20%">command-line</th> <td>--socks</td>
-        </tr>
-    </tbody>
-</table>
diff --git a/doc-src/features/sticky.html b/doc-src/features/sticky.html
deleted file mode 100644
index 18e6a4c5..00000000
--- a/doc-src/features/sticky.html
+++ /dev/null
@@ -1,60 +0,0 @@
-
-## Sticky cookies
-
-When the sticky cookie option is set, __mitmproxy__ will add the cookie most
-recently set by the server to any cookie-less request. Consider a service that
-sets a cookie to track the session after authentication. Using sticky cookies,
-you can fire up mitmproxy, and authenticate to a service as you usually would
-using a browser. After authentication, you can request authenticated resources
-through mitmproxy as if they were unauthenticated, because mitmproxy will
-automatically add the session tracking cookie to requests. Among other things,
-this lets you script interactions with authenticated resources (using tools
-like wget or curl) without having to worry about authentication.
-
-Sticky cookies are especially powerful when used in conjunction with [client
-replay](@!urlTo("clientreplay.html")!@) - you can record the authentication
-process once, and simply replay it on startup every time you need to interact
-with the secured resources.
-
-<table class="table">
-    <tbody>
-        <tr>
-            <th width="20%">command-line</th>
-            <td>
-                <ul>
-                    <li>-t FILTER</li>
-                </ul>
-            </td>
-        </tr>
-        <tr>
-            <th>mitmproxy shortcut</th> <td><b>o</b> then <b>t</b></td>
-        </tr>
-    </tbody>
-</table>
-
-
-## Sticky auth
-
-The sticky auth option is analogous to the sticky cookie option, in that HTTP
-__Authorization__ headers are simply replayed to the server once they have been
-seen. This is enough to allow you to access a server resource using HTTP Basic
-authentication through the proxy. Note that __mitmproxy__ doesn't (yet) support
-replay of HTTP Digest authentication.
-
-<table class="table">
-    <tbody>
-        <tr>
-            <th width="20%">command-line</th>
-            <td>
-                <ul>
-                    <li>-u FILTER</li>
-                </ul>
-            </td>
-        </tr>
-        <tr>
-            <th>mitmproxy shortcut</th> <td><b>o</b> then <b>A</b></td>
-        </tr>
-    </tbody>
-</table>
-
-
diff --git a/doc-src/features/tcpproxy.html b/doc-src/features/tcpproxy.html
deleted file mode 100644
index 48dd92f1..00000000
--- a/doc-src/features/tcpproxy.html
+++ /dev/null
@@ -1,30 +0,0 @@
-WebSockets or other non-HTTP protocols are not supported by mitmproxy yet. However, you can exempt hostnames from
-processing, so that mitmproxy acts as a generic TCP forwarder. This feature is closely related to the
-[ignore domains](@!urlTo("passthrough.html")!@) 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
-
-
-<table class="table">
-    <tbody>
-        <tr>
-            <th width="20%">command-line</th> <td>--tcp HOST</td>
-        </tr>
-        <tr>
-            <th>mitmproxy shortcut</th> <td><b>o</b> then <b>T</b></td>
-        </tr>
-    </tbody>
-</table>
-
-For a detailed description on the structure of the hostname pattern, please refer to the [Ignore Domains](@!urlTo("passthrough.html")!@) feature.
-
-### See Also
-
-- [Ignore Domains](@!urlTo("passthrough.html")!@)
-- [Response Streaming](@!urlTo("responsestreaming.html")!@)
diff --git a/doc-src/features/upstreamcerts.html b/doc-src/features/upstreamcerts.html
deleted file mode 100644
index a86ed67d..00000000
--- a/doc-src/features/upstreamcerts.html
+++ /dev/null
@@ -1,24 +0,0 @@
-When mitmproxy receives a connection destined for an SSL-protected service, it
-freezes the connection before reading its request data, and makes a connection
-to the upstream server to "sniff" the contents of its SSL certificate. The
-information gained - the __Common Name__ and __Subject Alternative Names__ - is
-then used to generate the interception certificate, which is sent to the client
-so the connection can continue.
-
-This rather intricate little dance lets us seamlessly generate correct
-certificates even if the client has specifed only an IP address rather than the
-hostname. It also means that we don't need to sniff additional data to generate
-certs in transparent mode.
-
-Upstream cert sniffing is on by default, and can optionally be turned off.
-
-<table class="table">
-    <tbody>
-        <tr>
-            <th width="20%">command-line</th> <td>--no-upstream-cert</td>
-        </tr>
-        <tr>
-            <th>mitmproxy shortcut</th> <td><b>o</b> then <b>U</b></td>
-        </tr>
-    </tbody>
-</table>
diff --git a/doc-src/features/upstreamproxy.html b/doc-src/features/upstreamproxy.html
deleted file mode 100644
index bb354cd3..00000000
--- a/doc-src/features/upstreamproxy.html
+++ /dev/null
@@ -1,13 +0,0 @@
-
-In this mode, mitmproxy accepts proxy requests and unconditionally forwards all
-requests to a specified upstream proxy server. This is in contrast to <a
-href="@!urlTo("reverseproxy.html")!@">reverse proxy mode</a>, in which
-mitmproxy forwards ordinary HTTP requests to an upstream server.
-
-<table class="table">
-    <tbody>
-        <tr>
-            <th width="20%">command-line</th> <td>-U http://hostname[:port]</td>
-        </tr>
-    </tbody>
-</table>