aboutsummaryrefslogtreecommitdiffstats
path: root/doc-src
diff options
context:
space:
mode:
authorAldo Cortesi <aldo@nullcube.com>2012-09-17 11:05:20 +1200
committerAldo Cortesi <aldo@nullcube.com>2012-09-17 11:05:20 +1200
commit21f74efa10374d99df29a3eb666370b28b30d5b3 (patch)
tree7638b0fa90c9a0029ed1034fbb9c22fbf6ca5426 /doc-src
parente039940f49aa057903c50aa9e0feb13da9990820 (diff)
downloadmitmproxy-21f74efa10374d99df29a3eb666370b28b30d5b3.tar.gz
mitmproxy-21f74efa10374d99df29a3eb666370b28b30d5b3.tar.bz2
mitmproxy-21f74efa10374d99df29a3eb666370b28b30d5b3.zip
Stub out ctypes structures for OSX transparent mode.
Diffstat (limited to 'doc-src')
-rw-r--r--doc-src/library.html12
-rw-r--r--doc-src/scripts.html129
2 files changed, 0 insertions, 141 deletions
diff --git a/doc-src/library.html b/doc-src/library.html
deleted file mode 100644
index e2d2ff6a..00000000
--- a/doc-src/library.html
+++ /dev/null
@@ -1,12 +0,0 @@
-
-All of mitmproxy's basic functionality is exposed through the __libmproxy__
-library. The example below shows a simple implementation of the "sticky cookie"
-functionality included in the interactive mitmproxy program. Traffic is
-monitored for __cookie__ and __set-cookie__ headers, and requests are rewritten
-to include a previously seen cookie if they don't already have one. In effect,
-this lets you log in to a site using your browser, and then make subsequent
-requests using a tool like __curl__, which will then seem to be part of the
-authenticated session.
-
-$!example("examples/stickycookies")!$
-
diff --git a/doc-src/scripts.html b/doc-src/scripts.html
deleted file mode 100644
index 860ad9b6..00000000
--- a/doc-src/scripts.html
+++ /dev/null
@@ -1,129 +0,0 @@
-
-__mitmproxy__ has a powerful scripting API that allows you to modify flows
-on-the-fly or rewrite previously saved flows locally.
-
-The mitmproxy scripting API is event driven - a script is simply a Python
-module that exposes a set of event methods. Here's a complete mitmproxy script
-that adds a new header to every HTTP response before it is returned to the
-client:
-
-$!example("examples/add_header.py")!$
-
-The first argument to each event method is an instance of ScriptContext that
-lets the script interact with the global mitmproxy state. The __response__
-event also gets an instance of Flow, which we can use to manipulate the
-response itself.
-
-
-## Events
-
-### start(ScriptContext)
-
-Called once on startup, before any other events.
-
-
-###clientconnect(ScriptContext, ClientConnect)
-
-Called when a client initiates a connection to the proxy. Note that
-a connection can correspond to multiple HTTP requests.
-
-
-###request(ScriptContext, Flow)
-
-Called when a client request has been received. The __Flow__ object is
-guaranteed to have a non-None __request__ attribute.
-
-
-### response(ScriptContext, Flow)
-
-Called when a server response has been received. The __Flow__ object is
-guaranteed to have non-None __request__ and __response__ attributes.
-
-
-### error(ScriptContext, Flow)
-
-Called when a flow error has occurred, e.g. invalid server responses, or
-interrupted connections. This is distinct from a valid server HTTP error
-response, which is simply a response with an HTTP error code. The __Flow__
-object is guaranteed to have non-None __request__ and __error__ attributes.
-
-
-### clientdisconnect(ScriptContext, ClientDisconnect)
-
-Called when a client disconnects from the proxy.
-
-### done(ScriptContext)
-
-Called once on script shutdown, after any other events.
-
-
-## API
-
-The main classes you will deal with in writing mitmproxy scripts are:
-
-<table class="kvtable">
- <tr>
- <th>libmproxy.flow.ClientConnection</th>
- <td>Describes a client connection.</td>
- </tr>
- <tr>
- <th>libmproxy.flow.ClientDisconnection</th>
- <td>Describes a client disconnection.</td>
- </tr>
- <tr>
- <th>libmproxy.flow.Error</th>
- <td>A communications error.</td>
- </tr>
- <tr>
- <th>libmproxy.flow.Flow</th>
- <td>A collection of objects representing a single HTTP transaction.</td>
- </tr>
- <tr>
- <th>libmproxy.flow.Headers</th>
- <td>HTTP headers for a request or response.</td>
- </tr>
- <tr>
- <th>libmproxy.flow.ODict</th>
-
- <td>A dictionary-like object for managing sets of key/value data. There
- is also a variant called CaselessODict that ignores key case for some
- calls (used mainly for headers).</td>
- </tr>
- <tr>
- <th>libmproxy.flow.Response</th>
- <td>An HTTP response.</td>
- </tr>
- <tr>
- <th>libmproxy.flow.Request</th>
- <td>An HTTP request.</td>
- </tr>
- <tr>
- <th>libmproxy.flow.ScriptContext</th>
- <td> A handle for interacting with mitmproxy's from within scripts. </td>
- </tr>
- <tr>
- <th>libmproxy.certutils.SSLCert</th>
- <td>Exposes information SSL certificates.</td>
- </tr>
-</table>
-
-The canonical API documentation is the code. You can view the API documentation
-using pydoc (which is installed with Python by default), like this:
-
-<pre class="terminal">
-> pydoc libmproxy.flow.Request
-</pre>
-
-
-## Running scripts on saved flows
-
-Sometimes, we want to run a script on __Flow__ objects that are already
-complete. This happens when you start a script, and then load a saved set of
-flows from a file (see the "scripted data transformation" example on the
-[mitmdump](@!urlTo("mitmdump.html")!@) page). It also happens when you run a
-one-shot script on a single flow through the _|_ (pipe) shortcut in mitmproxy.
-
-In this case, there are no client connections, and the events are run in the
-following order: __start__, __request__, __response__, __error__, __done__. If
-the flow doesn't have a __response__ or __error__ associated with it, the
-matching event will be skipped.