Docs.

README.mkd

@@ -15,9 +15,9 @@ Capabilities
 - Intercept HTTP requests and responses and modify them on the fly.
 - Save complete HTTP conversations for later replay and analysis.
 - Replay the client-side of an HTTP conversations.
-- Replays HTTP responses of a previously recorded server.
-- Make scripted changes to HTTP traffic using a simple Python API. 
-- Dummy SSL certificate authority creates interception certificates on the fly.
+- Replay HTTP responses of a previously recorded server.
+- Make scripted changes to HTTP traffic using Python. 
+- SSL certificates for interception are generated on the fly.
 
 
 Download

doc-src/certinstall/index.py

@@ -2,8 +2,6 @@ from countershape import Page
 
 pages = [
     Page("firefox.html", "Firefox"),
-    Page("safari.html", "Safari"),
-    Page("ie.html", "Internet Explorer"),
     Page("osx.html", "OSX"),
     Page("windows7.html", "Windows 7"),
     Page("ios.html", "IOS"),

doc-src/certinstall/windows7.html

@@ -11,7 +11,7 @@ These instructions were tested on Windows 7.
 
 <img src="@!urlTo('win7-certstore.png')!@"/>
 
-### 4: Select "Place all certificates in the following store, and select "Trusted Root Certification Authorities":
+### 4: Select "Place all certificates in the following store", and select "Trusted Root Certification Authorities":
 
 <img src="@!urlTo('win7-certstore-trustedroot.png')!@"/>
 

doc-src/index.html

@@ -8,14 +8,10 @@
 * [Filter expressions](@!urlTo("filters.html")!@)
 * [Scripting API](@!urlTo("scripts.html")!@)
 * [SSL](@!urlTo("/ssl.html")!@)
-    * Browser certificate installation: 
-        * [Firefox](@!urlTo("certinstall/firefox.html")!@)
-        * [Safari](@!urlTo("certinstall/safari.html")!@)
-        * [Internet Explorer](@!urlTo("certinstall/ie.html")!@)
-    * System-wide certificate installation:
-        * [OSX](@!urlTo("certinstall/osx.html")!@)
-        * [Windows 7](@!urlTo("certinstall/windows7.html")!@)
-        * [iPhone/iPad](@!urlTo("certinstall/ios.html")!@)
+    * [Firefox](@!urlTo("certinstall/firefox.html")!@)
+    * [OSX](@!urlTo("certinstall/osx.html")!@)
+    * [Windows 7](@!urlTo("certinstall/windows7.html")!@)
+    * [iPhone/iPad](@!urlTo("certinstall/ios.html")!@)
 * [libmproxy](@!urlTo("library.html")!@)
 * Tutorials
     * Client replay: a 30 second example

doc-src/scripts.html

@@ -1,6 +1,10 @@
 
 Both __mitmproxy__ and __mitmdump__ allow you to modify requests and responses
-with external scripts. The script interface is simple - scripts simply read,
+with external scripts. This is often done through the __--reqscript__ and
+__--respscript__ options
+
+
+The script interface is simple - scripts simply read,
 modify and return a single __libmproxy.flow.Flow__ object, using the methods
 defined in the __libmproxy.script__ module. Scripts must be executable.
 

doc-src/serverreplay.html

@@ -5,13 +5,13 @@ conversation.
 Matching requests with responses
 --------------------------------
 
-By default, the __mitm*__ tools match incoming requests with responses from the
-save file based on all request parameters, except the request headers. 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__ option to both __mitmproxy__ and
-__mitmdump__ allows you to specify individual headers that should be included
-in the matching process.
+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__ option to both __mitmproxy__ and __mitmdump__ allows you to
+override this behaviour by specifying individual headers that should be
+included in matching.
 
 
 Response refreshing
@@ -20,12 +20,12 @@ 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, the __mitm*__ tools refresh 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.
+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__ option, available
 both on the command-line and using the "options" keyboard shortcut within

doc-src/ssl.html

@@ -13,25 +13,25 @@ directory (~/.mitmproxy by default):
     </tr>
     <tr>
         <td>mitmproxy-ca-cert.pem</td>
-        <td>Just the certificate in PEM format. Use this to distribute to most
+        <td>The certificate in PEM format. Use this to distribute to most
         non-Windows platforms.</td>
     </tr>
     <tr>
         <td>mitmproxy-ca-cert.p12</td>
-        <td>Just the certificate in PKCS12 format. For use on Windows.</td>
+        <td>The certificate in PKCS12 format. For use on Windows.</td>
     </tr>
 </table>
     
-This dummy CA is used for on-the-fly generation of
-dummy certificates for SSL interception. Since your browser won't trust the
-__mitmproxy__ dummy CA out of the box (and rightly so), so you will see an SSL
-cert warning every time you visit a new SSL domain through __mitmproxy__. When
-you're testing a single site through a browser, just accepting the bogus SSL
-cert manually is not too much of a hassle, but there are a number of cases
-where you will want to configure your testing system or browser to trust the
-__mitmproxy__ CA as a signing root authority:
+This CA is used for on-the-fly generation of dummy certificates for SSL
+interception. Since your browser won't trust the __mitmproxy__ CA out of the
+box (and rightly so), you will see an SSL cert warning every time you visit a
+new SSL domain through __mitmproxy__. When you're testing a single site through
+a browser, just accepting the bogus SSL cert manually is not too much trouble,
+but there are a number of cases where you will want to configure your testing
+system or browser to trust the __mitmproxy__ CA as a signing root authority:
 
-- If you are testing non-browser software that checks SSL cert validiy.
+- If you are testing non-browser software that checks SSL cert validiy using
+the system certificate store.
 - You are testing an app that makes non-interactive (JSONP, script src, etc.)
 requests to SSL resources. Another workaround in this case is to manually visit
 the page through the browser, and add a certificate exception.
@@ -42,12 +42,8 @@ exceptions.
 Installing the mitmproxy CA
 ===========================
 
+* [Firefox](@!urlTo("certinstall/firefox.html")!@)
+* [OSX](@!urlTo("certinstall/osx.html")!@)
+* [Windows 7](@!urlTo("certinstall/windows7.html")!@)
+* [iPhone/iPad](@!urlTo("certinstall/ios.html")!@)
 
-* Browser certificate installation: 
-    * [Firefox](@!urlTo("certinstall/firefox.html")!@)
-    * [Safari](@!urlTo("certinstall/safari.html")!@)
-    * [Internet Explorer](@!urlTo("certinstall/ie.html")!@)
-* System-wide certificate installation:
-    * [OSX](@!urlTo("certinstall/osx.html")!@)
-    * [Windows 7](@!urlTo("certinstall/windows7.html")!@)
-    * [iPhone/iPad](@!urlTo("certinstall/ios.html")!@)