diff options
author | Aldo Cortesi <aldo@nullcube.com> | 2016-02-21 11:41:59 +1300 |
---|---|---|
committer | Aldo Cortesi <aldo@nullcube.com> | 2016-02-21 11:47:17 +1300 |
commit | 08f44b9fad2c0922a9f3dfa7835f3be59c5e6f52 (patch) | |
tree | df7f7400880e680cd17406896d0080056d1d6af1 /docs/howmitmproxy.rst | |
parent | cf3182a6d46f64fe0b34a0ec6b01d0aaa886e029 (diff) | |
download | mitmproxy-08f44b9fad2c0922a9f3dfa7835f3be59c5e6f52.tar.gz mitmproxy-08f44b9fad2c0922a9f3dfa7835f3be59c5e6f52.tar.bz2 mitmproxy-08f44b9fad2c0922a9f3dfa7835f3be59c5e6f52.zip |
Doc tweaks
This patch does the following:
- Fixes all warnings in the doc tree
- Adds a modd + devd conf file that renders HTML and treats doc warnings as
errors. This lets you send warning output to your desktop notifier, and gives
livereload similar to the livehtml entry in the Makefile.
- Some small tweaks
Sphinx currently has a bug that causes unknown options to generate a warning:
https://github.com/sphinx-doc/sphinx/issues/2229
This is fixed in stable, but not yet released. You can update Sphinx to the
latest stable like so:
pip install --upgrade https://github.com/sphinx-doc/sphinx/archive/stable.zip
Diffstat (limited to 'docs/howmitmproxy.rst')
-rw-r--r-- | docs/howmitmproxy.rst | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/docs/howmitmproxy.rst b/docs/howmitmproxy.rst index b0b187d3..93602afe 100644 --- a/docs/howmitmproxy.rst +++ b/docs/howmitmproxy.rst @@ -18,7 +18,7 @@ the client and the server is well defined, and usually reliable. In the simplest possible interaction with mitmproxy, a client connects directly to the proxy, and makes a request that looks like this: -.. code-block:: http +.. code-block:: none GET http://example.com/index.html HTTP/1.1 @@ -39,7 +39,7 @@ Explicit HTTPS The process for an explicitly proxied HTTPS connection is quite different. The client connects to the proxy and makes a request that looks like this: -.. code-block:: http +.. code-block:: none CONNECT example.com:443 HTTP/1.1 @@ -80,7 +80,7 @@ blush, it seems that the CONNECT request above gives us all we need - in this example, both of these values are "example.com". But what if the client had initiated the connection as follows: -.. code-block:: http +.. code-block:: none CONNECT 10.1.1.1:443 HTTP/1.1 @@ -169,7 +169,7 @@ form of a firewall on the same host as the proxy server - `iptables`_ on Linux o pf_ on OSX. Once the client has initiated the connection, it makes a vanilla HTTP request, which might look something like this: -.. code-block:: http +.. code-block:: none GET /index.html HTTP/1.1 |