From e037fe05ff1f0c2893b3f51e06e0261ca4245d63 Mon Sep 17 00:00:00 2001 From: Aldo Cortesi Date: Tue, 7 Jun 2016 12:55:32 +1200 Subject: Migrate pathod docs to Sphinx All the content of the pathod docs are moved into Sphinx. The interactive format has not translated well to static docs, and there's still a lot of rewriting, format fixing, structuring, etc to be done. --- pathod/templates/docs_pathoc.html | 211 -------------------------------------- 1 file changed, 211 deletions(-) delete mode 100644 pathod/templates/docs_pathoc.html (limited to 'pathod/templates/docs_pathoc.html') diff --git a/pathod/templates/docs_pathoc.html b/pathod/templates/docs_pathoc.html deleted file mode 100644 index d38c3a77..00000000 --- a/pathod/templates/docs_pathoc.html +++ /dev/null @@ -1,211 +0,0 @@ -{% extends "docframe.html" %} {% block body %} -
-

- pathoc - A perverse HTTP client. -

-
- -

- 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 - small, terse language, which pathod shares with - its server-side twin pathod. To view pathoc's complete - range of options, use the command-line help: -

- -
pathoc --help
- -
-
-

Getting Started

-
- -

The basic pattern for pathoc commands is as follows:

- - 
pathoc hostname request [request ...]
- -

- That is, we specify the hostname to connect to, followed by one or more requests. - Lets start with a simple example: -

- - 
-        > pathoc google.com get:/ << 301 Moved Permanently: 219 bytes
-
- -

- 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 -p command-line option): -

- - 
-        > pathoc -s google.com get:/ << 301 Moved Permanently: 219 bytes
-
-
- - -
-
-

Multiple Requests

-
- -

- There are two ways to tell pathoc to issue multiple requests. The first is to specify - them on the command-line, like so: -

- - 
-        > pathoc google.com get:/ get:/ << 301 Moved Permanently: 219 bytes <<
-        301 Moved Permanently: 219 bytes
-
- -

- 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 -

- -

The other way to issue multiple requets is to use the -n flag:

- - 
-        > pathoc -n 2 google.com get:/ << 301 Moved Permanently: 219 bytes << 301
-        Moved Permanently: 219 bytes
-
- -

- The output is identical, but two separate TCP connections are made to the upstream - server. These two specification styles can be combined: -

- - 
-        > pathoc -n 2 google.com get:/ get:/ << 301 Moved Permanently: 219 bytes <<
-        301 Moved Permanently: 219 bytes << 301 Moved Permanently: 219 bytes <<
-        301 Moved Permanently: 219 bytes
-
- -

Here, two distinct TCP connections are made, with two requests issued over each.

-
- - -
-
-

Basic Fuzzing

-
- -

- 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: -

- - 
-        > pathoc -e -I 200 -t 2 -n 1000 localhost get:/:b@10:ir,@1
-
- -

- 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: -

- - -
- - -
-
-

Interacting with Proxies

-
- -

- 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: -

- - 
> pathoc -p 8080 localhost "get:'http://google.com'"
- -

- Another common use case is to use an HTTP CONNECT request to probe remote servers - via a proxy. This is done with the -c command-line option, - which allows you to specify a remote host and port pair: -

- - 
> pathoc -c google.com:80 -p 8080 localhost get:/
- -

- Note that pathoc does not 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 -s flag: -

- - 
> pathoc -sc google.com:443 -p 8080 localhost get:/
-
- - -
-
-

Embedded response specification

-
- -

- 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: -

- - 
> pathoc localhost:9999 "get:/p/:s'401:ir,@1'"
- -

- 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 -e flag to show the expanded request: -

- - 
-        > > pathoc -e localhost:9999 "get:/p/:s'401:ir,@1'" >> Spec: get:/p/:s'401:i15,\'o\':h\'Content-Length\'=\'0\'':h'Content-Length'='0'
-        << 401 Unoauthorized: 0 bytes
- -

- Note that the embedded response has been resolved before 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. -

-
-{% endblock %} -- cgit v1.2.3