diff --git a/libpathod/templates/docs_pathoc.html b/libpathod/templates/docs_pathoc.html index b9338c87e..eff4920c6 100644 --- a/libpathod/templates/docs_pathoc.html +++ b/libpathod/templates/docs_pathoc.html @@ -126,15 +126,25 @@ the command-line help:

Interacting with Proxies

-

At the moment, pathoc has no explicit support for proxies, but there's a - workaround that serves many use cases. Instead of specifying just a path, - specify an entire URL to the GET request, like so (assuming there's a proxy - running on port 8080 of localhost):

+

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

Proxy support is going to be a major focus of development for the next - version of pathoc, so keep an eye on the repo.

+

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:/
diff --git a/libpathod/templates/docs_pathod.html b/libpathod/templates/docs_pathod.html index 424593522..d9897245b 100644 --- a/libpathod/templates/docs_pathod.html +++ b/libpathod/templates/docs_pathod.html @@ -55,9 +55,11 @@ 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.

-

Proxy mode operates even when Pathod is run in SSL mode, but we do not -support nested SSL connections. This means that CONNECT requests will cause an -error response.

+

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.