From 01f098296870cf56f835fa1222607d8216f52811 Mon Sep 17 00:00:00 2001 From: Thomas Kriechbaumer Date: Mon, 22 Jun 2015 15:12:20 +0200 Subject: prettify html docs --- libpathod/templates/docs_pathoc.html | 268 +++++++++++++++++++---------------- 1 file changed, 143 insertions(+), 125 deletions(-) (limited to 'libpathod/templates/docs_pathoc.html') diff --git a/libpathod/templates/docs_pathoc.html b/libpathod/templates/docs_pathoc.html index 76018530..e4c12873 100644 --- a/libpathod/templates/docs_pathoc.html +++ b/libpathod/templates/docs_pathoc.html @@ -1,191 +1,209 @@ -{% extends "docframe.html" %} -{% block body %} +{% 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 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
+
pathoc --help
-

Getting Started

+

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

+ 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

+

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:

+

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

+

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

+

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

+

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

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

+

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:

+

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

+

+ 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

+

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

+

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

+

+ 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

+

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.

- +

+ 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 From 427e6d23ef76ab9f113bce1d17e6a7a8cddb275c Mon Sep 17 00:00:00 2001 From: Thomas Kriechbaumer Date: Fri, 26 Jun 2015 11:47:39 +0200 Subject: apply js-beautify changes selectivly --- libpathod/templates/docs_pathoc.html | 118 ++++++++++++++++++----------------- 1 file changed, 60 insertions(+), 58 deletions(-) (limited to 'libpathod/templates/docs_pathoc.html') diff --git a/libpathod/templates/docs_pathoc.html b/libpathod/templates/docs_pathoc.html index e4c12873..d38c3a77 100644 --- a/libpathod/templates/docs_pathoc.html +++ b/libpathod/templates/docs_pathoc.html @@ -7,12 +7,12 @@

- 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 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
@@ -27,8 +27,8 @@ 
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: + That is, we specify the hostname to connect to, followed by one or more requests. + Lets start with a simple example: 

@@ -36,10 +36,10 @@

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

@@ -64,8 +64,8 @@

- 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

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

@@ -76,8 +76,8 @@

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

@@ -96,8 +96,9 @@
     
 
     

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

 
     
@@ -105,18 +106,18 @@
     

 
     

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

 
     
    
         
  • 
-            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
-            -t 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
+            -t option comes in, which sets a timeout that causes pathoc to
+            disconnect after two seconds.
         
    • 
 
         
  • 
@@ -124,16 +125,16 @@
         
    • 
 
         
  • 
-            The -I 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 -I 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 -e 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 -e 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.
         
    • 
     

 
@@ -146,25 +147,26 @@
 
     

         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:
     

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

@@ -177,33 +179,33 @@
     
 
     

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

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

+    

+        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