mirror of
https://github.com/Grasscutters/mitmproxy.git
synced 2024-11-23 08:11:00 +00:00
apply js-beautify changes selectivly
This commit is contained in:
parent
b3b4a63b05
commit
427e6d23ef
@ -18,5 +18,5 @@
|
||||
"wrap_line_length": 80,
|
||||
"wrap_attributes": "auto",
|
||||
"wrap_attributes_indent_size": 4,
|
||||
"end_with_newline": false
|
||||
"end_with_newline": true
|
||||
}
|
||||
|
@ -33,8 +33,8 @@
|
||||
<h2>OFFSET</h2>
|
||||
|
||||
<p>
|
||||
Offsets are calculated relative to the base message, before any injections or other transforms
|
||||
are applied. They have 3 flavors:
|
||||
Offsets are calculated relative to the base message, before any injections or other
|
||||
transforms are applied. They have 3 flavors:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
@ -66,8 +66,8 @@
|
||||
<h3>Files</h3>
|
||||
|
||||
<p>
|
||||
You can load a value from a specified file path. To do so, you have to specify a _staticdir_
|
||||
option to pathod on the command-line, like so:
|
||||
You can load a value from a specified file path. To do so, you have to specify a
|
||||
_staticdir_ option to pathod on the command-line, like so:
|
||||
</p>
|
||||
|
||||
<pre class="example">pathod -d ~/myassets</pre>
|
||||
@ -88,8 +88,8 @@
|
||||
|
||||
<p>
|
||||
An @-symbol lead-in specifies that generated data should be used. There are two components
|
||||
to a generator specification - a size, and a data type. By default pathod assumes
|
||||
a data type of "bytes".
|
||||
to a generator specification - a size, and a data type. By default pathod
|
||||
assumes a data type of "bytes".
|
||||
</p>
|
||||
|
||||
<p>Here's a value specifier for generating 100 bytes:
|
||||
@ -98,15 +98,15 @@
|
||||
</p>
|
||||
|
||||
<p>
|
||||
You can use standard suffixes to indicate larger values. Here, for instance, is a specifier
|
||||
for generating 100 megabytes:
|
||||
You can use standard suffixes to indicate larger values. Here, for instance, is a
|
||||
specifier for generating 100 megabytes:
|
||||
</p>
|
||||
|
||||
<pre class="example">@100m</pre>
|
||||
|
||||
<p>
|
||||
Data is generated and served efficiently - if you really want to send a terabyte of data
|
||||
to a client, pathod can do it. The supported suffixes are:
|
||||
Data is generated and served efficiently - if you really want to send a terabyte
|
||||
of data to a client, pathod can do it. The supported suffixes are:
|
||||
</p>
|
||||
|
||||
<table class="table table-bordered">
|
||||
@ -135,8 +135,8 @@
|
||||
</table>
|
||||
|
||||
<p>
|
||||
Data types are separated from the size specification by a comma. This specification generates
|
||||
100mb of ASCII:
|
||||
Data types are separated from the size specification by a comma. This specification
|
||||
generates 100mb of ASCII:
|
||||
</p>
|
||||
|
||||
<pre class="example">@100m,ascii</pre>
|
||||
|
@ -7,16 +7,17 @@
|
||||
<td>method</td>
|
||||
<td>
|
||||
<p>
|
||||
A <a href="#valuespec">VALUE</a> specifying the HTTP method to use. Standard
|
||||
methods do not need to be enclosed in quotes, while non-standard methods
|
||||
can be specified as quoted strings.
|
||||
A <a href="#valuespec">VALUE</a> specifying the HTTP method to
|
||||
use. Standard methods do not need to be enclosed in quotes, while
|
||||
non-standard methods can be specified as quoted strings.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The special method <b>ws</b> creates a valid websocket upgrade GET
|
||||
request, and signals to pathoc to switch to websocket recieve mode
|
||||
if the server responds correctly. Apart from that, websocket requests
|
||||
are just like any other, and all aspects of the request can be over-ridden.
|
||||
The special method <b>ws</b> creates a valid websocket upgrade
|
||||
GET request, and signals to pathoc to switch to websocket recieve
|
||||
mode if the server responds correctly. Apart from that, websocket
|
||||
requests are just like any other, and all aspects of the request
|
||||
can be over-ridden.
|
||||
</p>
|
||||
</td>
|
||||
</tr>
|
||||
@ -66,8 +67,8 @@
|
||||
<tr>
|
||||
<td>b<a href="#valuespec">VALUE</a></td>
|
||||
<td>
|
||||
Set the body. The appropriate Content-Length header is added automatically unless the
|
||||
"r" flag is set.
|
||||
Set the body. The appropriate Content-Length header is added automatically unless
|
||||
the "r" flag is set.
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
@ -88,24 +89,24 @@
|
||||
<tr>
|
||||
<td>d<a href="#offsetspec">OFFSET</a></td>
|
||||
<td>
|
||||
<span class="badge badge-info">HTTP/1 only</span>
|
||||
Disconnect after OFFSET bytes.
|
||||
<span class="badge badge-info">HTTP/1 only</span> Disconnect after
|
||||
OFFSET bytes.
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>i<a href="#offsetspec">OFFSET</a>,<a href="#valuespec">VALUE</a></td>
|
||||
<td>
|
||||
<span class="badge badge-info">HTTP/1 only</span>
|
||||
Inject the specified value at the offset.
|
||||
<span class="badge badge-info">HTTP/1 only</span> Inject the specified
|
||||
value at the offset.
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>p<a href="#offsetspec">OFFSET</a>,SECONDS</td>
|
||||
<td>
|
||||
<span class="badge badge-info">HTTP/1 only</span>
|
||||
Pause for SECONDS seconds after OFFSET bytes. SECONDS can be an integer or "f" to pause
|
||||
<span class="badge badge-info">HTTP/1 only</span> Pause for SECONDS
|
||||
seconds after OFFSET bytes. SECONDS can be an integer or "f" to pause
|
||||
forever.
|
||||
</td>
|
||||
</tr>
|
||||
|
@ -7,10 +7,10 @@
|
||||
<td>
|
||||
<p>An integer specifying the HTTP response code.</p>
|
||||
<p>
|
||||
The special method <b>ws</b> creates a valid websocket upgrade response
|
||||
(code 101), and moves pathod to websocket mode. Apart from that, websocket
|
||||
responses are just like any other, and all aspects of the response
|
||||
can be over-ridden.
|
||||
The special method <b>ws</b> creates a valid websocket upgrade
|
||||
response (code 101), and moves pathod to websocket mode. Apart
|
||||
from that, websocket responses are just like any other, and all
|
||||
aspects of the response can be over-ridden.
|
||||
</p>
|
||||
</td>
|
||||
</tr>
|
||||
@ -18,8 +18,8 @@
|
||||
<tr>
|
||||
<td>m<a href="#valuespec">VALUE</a></td>
|
||||
<td>
|
||||
<span class="badge badge-info">HTTP/1 only</span>
|
||||
HTTP Reason message. Automatically chosen according to the response code if not specified.
|
||||
<span class="badge badge-info">HTTP/1 only</span> HTTP Reason message.
|
||||
Automatically chosen according to the response code if not specified.
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
@ -55,32 +55,32 @@
|
||||
<tr>
|
||||
<td>b<a href="#valuespec">VALUE</a></td>
|
||||
<td>
|
||||
Set the body. The appropriate Content-Length header is added automatically unless the
|
||||
"r" flag is set.
|
||||
Set the body. The appropriate Content-Length header is added automatically unless
|
||||
the "r" flag is set.
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>d<a href="#offsetspec">OFFSET</a></td>
|
||||
<td>
|
||||
<span class="badge badge-info">HTTP/1 only</span>
|
||||
Disconnect after OFFSET bytes.
|
||||
<span class="badge badge-info">HTTP/1 only</span> Disconnect after
|
||||
OFFSET bytes.
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>i<a href="#offsetspec">OFFSET</a>,<a href="#valuespec">VALUE</a></td>
|
||||
<td>
|
||||
<span class="badge badge-info">HTTP/1 only</span>
|
||||
Inject the specified value at the offset.
|
||||
<span class="badge badge-info">HTTP/1 only</span> Inject the specified
|
||||
value at the offset.
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>p<a href="#offsetspec">OFFSET</a>,SECONDS</td>
|
||||
<td>
|
||||
<span class="badge badge-info">HTTP/1 only</span>
|
||||
Pause for SECONDS seconds after OFFSET bytes. SECONDS can be an integer or "f" to pause
|
||||
<span class="badge badge-info">HTTP/1 only</span> Pause for SECONDS
|
||||
seconds after OFFSET bytes. SECONDS can be an integer or "f" to pause
|
||||
forever.
|
||||
</td>
|
||||
</tr>
|
||||
|
@ -15,8 +15,8 @@
|
||||
<td> c<a href="#valuespec">INTEGER</a> </td>
|
||||
<td>
|
||||
|
||||
Set the op code. This can either be an integer from 0-15, or be one of the following opcode
|
||||
names: <b>text</b> (the default),
|
||||
Set the op code. This can either be an integer from 0-15, or be one of the following
|
||||
opcode names: <b>text</b> (the default),
|
||||
<b>continue</b>, <b>binary</b>, <b>close</b>, <b>ping</b>,
|
||||
<b>pong</b>.
|
||||
|
||||
@ -47,9 +47,10 @@
|
||||
<tr>
|
||||
<td> k<a href="#valuespec">VALUE</a> </td>
|
||||
<td>
|
||||
Set the masking key. The resulting value must be exactly 4 bytes long. The special form
|
||||
<b>knone</b> specifies that no key should be set, even
|
||||
if the mask bit is on.
|
||||
Set the masking key. The resulting value must be exactly 4 bytes long. The special
|
||||
form
|
||||
<b>knone</b> specifies that no key should be set, even if the mask
|
||||
bit is on.
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
@ -70,8 +71,8 @@
|
||||
<tr>
|
||||
<td> p<a href="#offsetspec">OFFSET</a>,SECONDS </td>
|
||||
<td>
|
||||
Pause for SECONDS seconds after OFFSET bytes. SECONDS can be an integer or "f" to pause
|
||||
forever.
|
||||
Pause for SECONDS seconds after OFFSET bytes. SECONDS can be an integer or "f" to
|
||||
pause forever.
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
|
@ -9,10 +9,10 @@
|
||||
<div class="row">
|
||||
<div class="span6">
|
||||
<p>
|
||||
Behind the pathod and pathoc command-line tools lurks <b>libpathod</b>, a
|
||||
powerful library for manipulating and serving HTTP requests and responses.
|
||||
The canonical documentation for the library is in the code, and can be accessed
|
||||
using pydoc.
|
||||
Behind the pathod and pathoc command-line tools lurks <b>libpathod</b>,
|
||||
a powerful library for manipulating and serving HTTP requests and responses.
|
||||
The canonical documentation for the library is in the code, and can be
|
||||
accessed using pydoc.
|
||||
</p>
|
||||
</div>
|
||||
<div class="span6">
|
||||
|
@ -7,12 +7,12 @@
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Pathoc is a perverse HTTP daemon designed to let you craft almost any conceivable HTTP
|
||||
request, including ones that creatively violate the standards. HTTP requests are specified
|
||||
using a
|
||||
<a href="/docs/language">small, terse language</a>, which pathod shares with its server-side
|
||||
twin <a href="/docs/pathod">pathod</a>. To view pathoc's complete range of options,
|
||||
use the command-line help:
|
||||
Pathoc is a perverse HTTP daemon designed to let you craft almost any conceivable
|
||||
HTTP request, including ones that creatively violate the standards. HTTP requests
|
||||
are specified using a
|
||||
<a href="/docs/language">small, terse language</a>, which pathod shares with
|
||||
its server-side twin <a href="/docs/pathod">pathod</a>. To view pathoc's complete
|
||||
range of options, use the command-line help:
|
||||
</p>
|
||||
|
||||
<pre class="terminal">pathoc --help</pre>
|
||||
@ -27,8 +27,8 @@
|
||||
<pre class="terminal">pathoc hostname request [request ...]</pre>
|
||||
|
||||
<p>
|
||||
That is, we specify the hostname to connect to, followed by one or more requests. Lets
|
||||
start with a simple example:
|
||||
That is, we specify the hostname to connect to, followed by one or more requests.
|
||||
Lets start with a simple example:
|
||||
</p>
|
||||
|
||||
<pre class="terminal">
|
||||
@ -36,10 +36,10 @@
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Here, we make a GET request to the path / on port 80 of google.com. Pathoc's output tells
|
||||
us that the server responded with a 301. We can tell pathoc to connect using SSL,
|
||||
in which case the default port is changed to 443 (you can over-ride the default
|
||||
port with the <b>-p</b> command-line option):
|
||||
Here, we make a GET request to the path / on port 80 of google.com. Pathoc's output
|
||||
tells us that the server responded with a 301. We can tell pathoc to connect
|
||||
using SSL, in which case the default port is changed to 443 (you can over-ride
|
||||
the default port with the <b>-p</b> command-line option):
|
||||
</p>
|
||||
|
||||
<pre class="terminal">
|
||||
@ -64,8 +64,8 @@
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
In this case, pathoc issues the specified requests over the same TCP connection - so in
|
||||
the above example only one connection is made to google.com
|
||||
In this case, pathoc issues the specified requests over the same TCP connection -
|
||||
so in the above example only one connection is made to google.com
|
||||
</p>
|
||||
|
||||
<p>The other way to issue multiple requets is to use the <b>-n</b> flag:</p>
|
||||
@ -76,8 +76,8 @@
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The output is identical, but two separate TCP connections are made to the upstream server.
|
||||
These two specification styles can be combined:
|
||||
The output is identical, but two separate TCP connections are made to the upstream
|
||||
server. These two specification styles can be combined:
|
||||
</p>
|
||||
|
||||
<pre class="terminal">
|
||||
@ -96,8 +96,9 @@
|
||||
</div>
|
||||
|
||||
<p>
|
||||
The combination of pathoc's powerful request specification language and a few of its command-line
|
||||
options makes for quite a powerful basic fuzzer. Here's an example:
|
||||
The combination of pathoc's powerful request specification language and a few of
|
||||
its command-line options makes for quite a powerful basic fuzzer. Here's
|
||||
an example:
|
||||
</p>
|
||||
|
||||
<pre class="terminal">
|
||||
@ -105,18 +106,18 @@
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The request specified here is a valid GET with a body consisting of 10 random bytes, but
|
||||
with 1 random byte inserted in a random place. This could be in the headers, in
|
||||
the initial request line, or in the body itself. There are a few things to note
|
||||
here:
|
||||
The request specified here is a valid GET with a body consisting of 10 random bytes,
|
||||
but with 1 random byte inserted in a random place. This could be in the headers,
|
||||
in the initial request line, or in the body itself. There are a few things
|
||||
to note here:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
Corrupting the request in this way will often make the server enter a state where it's
|
||||
awaiting more input from the client. This is where the
|
||||
<b>-t</b> option comes in, which sets a timeout that causes pathoc to disconnect
|
||||
after two seconds.
|
||||
Corrupting the request in this way will often make the server enter a state where
|
||||
it's awaiting more input from the client. This is where the
|
||||
<b>-t</b> option comes in, which sets a timeout that causes pathoc to
|
||||
disconnect after two seconds.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
@ -124,16 +125,16 @@
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <b>-I</b> option tells pathoc to ignore HTTP 200 response codes. You can
|
||||
use this to fine-tune what pathoc considers to be an exceptional condition,
|
||||
and therefore log-worthy.
|
||||
The <b>-I</b> option tells pathoc to ignore HTTP 200 response codes.
|
||||
You can use this to fine-tune what pathoc considers to be an exceptional
|
||||
condition, and therefore log-worthy.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
The <b>-e</b> option tells pathoc to print an explanation of each logged request,
|
||||
in the form of an expanded pathoc specification with all random portions and
|
||||
automatic header additions resolved. This lets you precisely replay a request
|
||||
that triggered an error.
|
||||
The <b>-e</b> option tells pathoc to print an explanation of each logged
|
||||
request, in the form of an expanded pathoc specification with all random
|
||||
portions and automatic header additions resolved. This lets you precisely
|
||||
replay a request that triggered an error.
|
||||
</li>
|
||||
</ul>
|
||||
</section>
|
||||
@ -146,25 +147,26 @@
|
||||
|
||||
<p>
|
||||
Pathoc has a reasonably sophisticated suite of features for interacting with proxies.
|
||||
The proxy request syntax very closely mirrors that of straight HTTP, which means
|
||||
that it is possible to make proxy-style requests using pathoc without any additional
|
||||
syntax, by simply specifying a full URL instead of a simple path:
|
||||
The proxy request syntax very closely mirrors that of straight HTTP, which
|
||||
means that it is possible to make proxy-style requests using pathoc without
|
||||
any additional syntax, by simply specifying a full URL instead of a simple
|
||||
path:
|
||||
</p>
|
||||
|
||||
<pre class="terminal">> pathoc -p 8080 localhost "get:'http://google.com'"</pre>
|
||||
|
||||
<p>
|
||||
Another common use case is to use an HTTP CONNECT request to probe remote servers via
|
||||
a proxy. This is done with the <b>-c</b> command-line option, which allows
|
||||
you to specify a remote host and port pair:
|
||||
Another common use case is to use an HTTP CONNECT request to probe remote servers
|
||||
via a proxy. This is done with the <b>-c</b> command-line option,
|
||||
which allows you to specify a remote host and port pair:
|
||||
</p>
|
||||
|
||||
<pre class="terminal">> pathoc -c google.com:80 -p 8080 localhost get:/</pre>
|
||||
|
||||
<p>
|
||||
Note that pathoc does <b>not</b> negotiate SSL without being explictly instructed
|
||||
to do so. If you're making a CONNECT request to an SSL-protected resource, you
|
||||
must also pass the <b>-s</b> flag:
|
||||
to do so. If you're making a CONNECT request to an SSL-protected resource,
|
||||
you must also pass the <b>-s</b> flag:
|
||||
</p>
|
||||
|
||||
<pre class="terminal">> pathoc -sc google.com:443 -p 8080 localhost get:/</pre>
|
||||
@ -177,19 +179,19 @@
|
||||
</div>
|
||||
|
||||
<p>
|
||||
One interesting feature of the Request sppecification language is that you can embed a
|
||||
response specifcation in it, which is then added to the request path. Here's an
|
||||
example:
|
||||
One interesting feature of the Request sppecification language is that you can embed
|
||||
a response specifcation in it, which is then added to the request path. Here's
|
||||
an example:
|
||||
</p>
|
||||
|
||||
<pre class="terminal">> pathoc localhost:9999 "get:/p/:s'401:ir,@1'"</pre>
|
||||
|
||||
<p>
|
||||
This crafts a request that connects to the pathod server, and which then crafts a response
|
||||
that generates a 401, with one random byte embedded at a random point. The response
|
||||
specification is parsed and expanded by pathoc, so you see syntax errors immediately.
|
||||
This really becomes handy when combined with the <b>-e</b> flag to show
|
||||
the expanded request:
|
||||
This crafts a request that connects to the pathod server, and which then crafts a
|
||||
response that generates a 401, with one random byte embedded at a random
|
||||
point. The response specification is parsed and expanded by pathoc, so you
|
||||
see syntax errors immediately. This really becomes handy when combined with
|
||||
the <b>-e</b> flag to show the expanded request:
|
||||
</p>
|
||||
|
||||
<pre class="terminal">
|
||||
@ -197,13 +199,13 @@
|
||||
<< 401 Unoauthorized: 0 bytes </pre>
|
||||
|
||||
<p>
|
||||
Note that the embedded response has been resolved <i>before</i> being
|
||||
sent to the server, so that "ir,@1" (embed a random byte at a random location)
|
||||
has become "i15,\'o\'" (embed the character "o" at offset 15). You now
|
||||
have a pathoc request specification that is precisely reproducable, even
|
||||
with random components. This feature comes in terribly handy when testing
|
||||
a proxy, since you can now drive the server repsonse completely from the
|
||||
client, and have a complete log of reproducible requests to analyse afterwards.
|
||||
Note that the embedded response has been resolved <i>before</i> being sent
|
||||
to the server, so that "ir,@1" (embed a random byte at a random location)
|
||||
has become "i15,\'o\'" (embed the character "o" at offset 15). You now have
|
||||
a pathoc request specification that is precisely reproducable, even with
|
||||
random components. This feature comes in terribly handy when testing a proxy,
|
||||
since you can now drive the server repsonse completely from the client, and
|
||||
have a complete log of reproducible requests to analyse afterwards.
|
||||
</p>
|
||||
</section>
|
||||
{% endblock %}
|
||||
|
@ -10,8 +10,8 @@
|
||||
Pathod is a pathological HTTP daemon designed to let you craft almost any conceivable
|
||||
HTTP response, including ones that creatively violate the standards. HTTP responses
|
||||
are specified using a
|
||||
<a href="/docs/language">small, terse language</a>, which pathod shares with its evil
|
||||
twin <a href="/docs/pathoc">pathoc</a>.
|
||||
<a href="/docs/language">small, terse language</a>, which pathod shares with
|
||||
its evil twin <a href="/docs/pathoc">pathoc</a>.
|
||||
</p>
|
||||
|
||||
<section>
|
||||
@ -24,27 +24,27 @@
|
||||
<pre class="terminal">./pathod</pre>
|
||||
|
||||
<p>
|
||||
By default, the service listens on port 9999 of localhost. Pathod's documentation is self-hosting,
|
||||
and the pathod daemon exposes an interface that lets you play with the specifciation
|
||||
language, preview what responses and requests would look like on the wire, and
|
||||
view internal logs. To access all of this, just fire up your browser, and point
|
||||
it to the following URL:
|
||||
By default, the service listens on port 9999 of localhost. Pathod's documentation
|
||||
is self-hosting, and the pathod daemon exposes an interface that lets you
|
||||
play with the specifciation language, preview what responses and requests
|
||||
would look like on the wire, and view internal logs. To access all of this,
|
||||
just fire up your browser, and point it to the following URL:
|
||||
</p>
|
||||
|
||||
<pre class="example">http://localhost:9999</pre>
|
||||
|
||||
<p>
|
||||
The default crafting anchor point is the path <b>/p/</b>. Anything after this
|
||||
URL prefix is treated as a response specifier. So, hitting the following URL will
|
||||
generate an HTTP 200 response with 100 bytes of random data:
|
||||
The default crafting anchor point is the path <b>/p/</b>. Anything after
|
||||
this URL prefix is treated as a response specifier. So, hitting the following
|
||||
URL will generate an HTTP 200 response with 100 bytes of random data:
|
||||
</p>
|
||||
|
||||
<pre class="example">http://localhost:9999/p/200:b@100</pre>
|
||||
|
||||
<p>
|
||||
See the <a href="/docs/language">language documentation</a> to get (much) fancier.
|
||||
The pathod daemon also takes a range of configuration options. To view those,
|
||||
use the command-line help:
|
||||
See the <a href="/docs/language">language documentation</a> to get (much)
|
||||
fancier. The pathod daemon also takes a range of configuration options. To
|
||||
view those, use the command-line help:
|
||||
</p>
|
||||
|
||||
<pre class="terminal">./pathod --help</pre>
|
||||
@ -57,17 +57,17 @@
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Pathod automatically responds to both straight HTTP and proxy requests. For proxy requests,
|
||||
the upstream host is ignored, and the path portion of the URL is used to match
|
||||
anchors. This lets you test software that supports a proxy configuration by spoofing
|
||||
responses from upstream servers.
|
||||
Pathod automatically responds to both straight HTTP and proxy requests. For proxy
|
||||
requests, the upstream host is ignored, and the path portion of the URL is
|
||||
used to match anchors. This lets you test software that supports a proxy
|
||||
configuration by spoofing responses from upstream servers.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
By default, we treat all proxy CONNECT requests as HTTPS traffic, serving the response
|
||||
using either pathod's built-in certificates, or the cert/key pair specified by
|
||||
the user. You can over-ride this behaviour if you're testing a client that makes
|
||||
a non-SSL CONNECT request using the -C command-line option.
|
||||
using either pathod's built-in certificates, or the cert/key pair specified
|
||||
by the user. You can over-ride this behaviour if you're testing a client
|
||||
that makes a non-SSL CONNECT request using the -C command-line option.
|
||||
</p>
|
||||
</section>
|
||||
|
||||
@ -78,16 +78,16 @@
|
||||
</div>
|
||||
|
||||
<p>
|
||||
Anchors provide an alternative to specifying the response in the URL. Instead, you attach
|
||||
a response to a pre-configured anchor point, specified with a regex. When a URL
|
||||
matching the regex is requested, the specified response is served.
|
||||
Anchors provide an alternative to specifying the response in the URL. Instead, you
|
||||
attach a response to a pre-configured anchor point, specified with a regex.
|
||||
When a URL matching the regex is requested, the specified response is served.
|
||||
</p>
|
||||
|
||||
<pre class="terminal">./pathod -a "/foo=200"</pre>
|
||||
|
||||
<p>
|
||||
Here, "/foo" is the regex specifying the anchor path, and the part after the "=" is a
|
||||
response specifier.
|
||||
Here, "/foo" is the regex specifying the anchor path, and the part after the "="
|
||||
is a response specifier.
|
||||
</p>
|
||||
</section>
|
||||
|
||||
@ -98,11 +98,11 @@
|
||||
</div>
|
||||
|
||||
<p>
|
||||
There are two operators in the <a href="/docs/language">language</a> that load
|
||||
contents from file - the <b>+</b> operator to load an entire request specification
|
||||
from file, and the <b>></b> value specifier. In pathod, both of these operators
|
||||
are restricted to a directory specified at startup, or disabled if no directory
|
||||
is specified:</p>
|
||||
There are two operators in the <a href="/docs/language">language</a> that
|
||||
load contents from file - the <b>+</b> operator to load an entire request
|
||||
specification from file, and the <b>></b> value specifier. In pathod,
|
||||
both of these operators are restricted to a directory specified at startup,
|
||||
or disabled if no directory is specified:</p>
|
||||
<pre class="terminal">./pathod -d ~/staticdir"</pre>
|
||||
</section>
|
||||
|
||||
@ -131,8 +131,8 @@
|
||||
</div>
|
||||
|
||||
<p>
|
||||
pathod exposes a simple API, intended to make it possible to drive and inspect the daemon
|
||||
remotely for use in unit testing and the like.
|
||||
pathod exposes a simple API, intended to make it possible to drive and inspect the
|
||||
daemon remotely for use in unit testing and the like.
|
||||
</p>
|
||||
|
||||
<table class="table table-bordered">
|
||||
@ -158,13 +158,12 @@
|
||||
/api/log
|
||||
</td>
|
||||
<td>
|
||||
Returns the current log buffer. At the moment the buffer size is 500 entries - when the
|
||||
log grows larger than this, older entries are discarded. The returned
|
||||
data is a JSON dictionary, with the form:
|
||||
Returns the current log buffer. At the moment the buffer size is 500 entries - when
|
||||
the log grows larger than this, older entries are discarded.
|
||||
The returned data is a JSON dictionary, with the form:
|
||||
|
||||
<pre>{ 'log': [ ENTRIES ] } </pre>
|
||||
|
||||
You can preview the JSON data returned for a log entry through the built-in web interface.
|
||||
<pre>{ 'log': [ ENTRIES ] } </pre> You can preview the JSON data
|
||||
returned for a log entry through the built-in web interface.
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
@ -7,10 +7,10 @@
|
||||
</div>
|
||||
|
||||
<p>The <b>libpathod.test</b> module is a light, flexible testing layer for HTTP clients.
|
||||
It works by firing up a Pathod instance in a separate thread, letting you use Pathod's
|
||||
full abilities to generate responses, and then query Pathod's internal logs to establish
|
||||
what happened. All the mechanics of startup, shutdown, finding free ports and so forth
|
||||
are taken care of for you.
|
||||
It works by firing up a Pathod instance in a separate thread, letting you use
|
||||
Pathod's full abilities to generate responses, and then query Pathod's internal
|
||||
logs to establish what happened. All the mechanics of startup, shutdown, finding
|
||||
free ports and so forth are taken care of for you.
|
||||
</p>
|
||||
|
||||
<p>The canonical docs can be accessed using pydoc: </p>
|
||||
@ -19,9 +19,9 @@
|
||||
|
||||
<p>
|
||||
The remainder of this page demonstrates some common interaction patterns using
|
||||
<a
|
||||
href="http://nose.readthedocs.org/en/latest/">nose</a>. These examples are also applicable with only minor modification to most
|
||||
commonly used Python testing engines.
|
||||
<a href="http://nose.readthedocs.org/en/latest/">nose</a>. These examples are
|
||||
also applicable with only minor modification to most commonly used Python testing
|
||||
engines.
|
||||
</p>
|
||||
|
||||
<section>
|
||||
|
@ -8,7 +8,9 @@
|
||||
|
||||
<pre>pip install pathod</pre>
|
||||
|
||||
<p>This will automatically pull in all the dependencies, and you should be good to go.</p>
|
||||
<p>
|
||||
This will automatically pull in all the dependencies, and you should be good to go.
|
||||
</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
|
@ -19,6 +19,7 @@
|
||||
padding-top: 60px;
|
||||
padding-bottom: 40px;
|
||||
}
|
||||
|
||||
</style>
|
||||
<!-- Le HTML5 shim, for IE6-8 support of HTML5 elements -->
|
||||
<!--[if lt IE 9]>
|
||||
@ -68,5 +69,7 @@
|
||||
}
|
||||
});
|
||||
});
|
||||
|
||||
</script>
|
||||
|
||||
</html>
|
||||
|
@ -7,8 +7,10 @@
|
||||
<a class="innerlink" data-toggle="collapse" data-target="#requestexamples">examples</a>
|
||||
|
||||
<div id="requestexamples" class="collapse">
|
||||
<p>Check out the <a href="/docs/language">complete language docs</a>. Here are some examples
|
||||
to get you started:</p>
|
||||
<p>
|
||||
Check out the <a href="/docs/language">complete language docs</a>. Here are
|
||||
some examples to get you started:
|
||||
</p>
|
||||
|
||||
<table class="table table-bordered">
|
||||
<tbody>
|
||||
|
@ -1,15 +1,19 @@
|
||||
<form style="margin-bottom: 0" class="form-inline" method="GET" action="/response_preview">
|
||||
<input style="width: 18em" id="spec" name="spec" class="input-medium" value="{{spec}}"
|
||||
placeholder="code:[features]">
|
||||
<input type="submit" class="btn" value="preview"> {% if not nocraft %}
|
||||
<a href="#" id="submitspec" class="btn">go</a> {% endif %}
|
||||
<input type="submit" class="btn" value="preview">
|
||||
{% if not nocraft %}
|
||||
<a href="#" id="submitspec" class="btn">go</a>
|
||||
{% endif %}
|
||||
</form>
|
||||
|
||||
<a class="innerlink" data-toggle="collapse" data-target="#responseexamples">examples</a>
|
||||
|
||||
<div id="responseexamples" class="collapse">
|
||||
<p>Check out the <a href="/docs/language">complete language docs</a>. Here are some examples
|
||||
to get you started:</p>
|
||||
<p>
|
||||
Check out the <a href="/docs/language">complete language docs</a>. Here are
|
||||
some examples to get you started:
|
||||
</p>
|
||||
|
||||
<table class="table table-bordered">
|
||||
<tbody>
|
||||
@ -19,7 +23,9 @@
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/response_preview?spec=200:r">200:r</a></td>
|
||||
<td>A basic HTTP 200 response with no Content-Length header. This will hang.</td>
|
||||
<td>A basic HTTP 200 response with no Content-Length header. This will
|
||||
hang.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/response_preview?spec=200:da">200:da</a></td>
|
||||
@ -27,8 +33,10 @@
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/response_preview?spec=200:b@100">200:b@100</a></td>
|
||||
<td>100 random bytes as the body. A Content-Lenght header is added, so the
|
||||
disconnect is no longer needed.</td>
|
||||
<td>
|
||||
100 random bytes as the body. A Content-Lenght header is added, so the disconnect
|
||||
is no longer needed.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href='/response_preview?spec=200:b@100:h"Server"="';drop table servers;"'>200:b@100:h"Etag"="';drop table servers;"</a></td>
|
||||
@ -58,8 +66,10 @@
|
||||
<td>
|
||||
<a href="/response_preview?spec=200:b@100:h@1k,ascii_letters='foo'">200:b@100:h@1k,ascii_letters='foo'</a>
|
||||
</td>
|
||||
<td>100 ASCII bytes as the body, randomly generated 100k header name, with
|
||||
the value 'foo'.</td>
|
||||
<td>
|
||||
100 ASCII bytes as the body, randomly generated 100k header name, with the value
|
||||
'foo'.
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
Loading…
Reference in New Issue
Block a user