The config file specifies exactly how the HTTP tunneling library should operate
and allows the user to control such things as the types of tunnel to be used,
the addresses of either end of the tunnels, whether to go via a proxy server,
and more besides.

The config file is split into sections, the start of which is denoted by
the section name (in capital letters) within square brackets. At a minimum,
a complete config file must contain exactly one [GLOBAL] section and at least
one [CLIENT] or [SERVER] section. If so desired you may configure multiple
clients and/or servers by including additional [CLIENT] or [SERVER] sections.

Any lines in the config file after the start of the current section and
before the start of a subsequent section are considered to be within that 
labelled section. A line may then either contain a configuration option for
that section, be a comment, or be blank.

A configuration option line must not contain any whitespace at the start or
end of the line, it must begin with the name of the option being specified
(in lowercase), and any arguments for the option must be listed on the same
line separated by single spaces.

A comment line must begin with a '#', and everything else on that line is
ignored.

A blank line must contain no other characters.


The first section within the config file must be the [GLOBAL] section. This
section may contain the following options:

debug <level>
  This option controls the level of logging performed by the HTTP tunneling
  library. The debug level can be between 0 (minimal logging) and 5 (verbose
  logging).

dotest
  This option instructs the HTTP tunneling library to perform periodic tests on
  the connection to the other end of the tunnels so as to try and determine the
  best tunneling parameters to use. The testing enabled by this option is
  currently very experimental, and while it may help in some situations it is
  disabled by default.


A [CLIENT] config file section specifies the behaviour of a client side
tunneler. This section may contain the following options:

fixed <host> <port> [udp]
  This option tells the client tunneler to configure a fixed (as opposed to
  SOCKS) client tunnel. A fixed tunnel is one where the ultimate destination
  for tunnelled traffic is fixed for all time. The address and port for the
  ultimate tunnelled traffic destination is given by the <host> and <port>
  arguments. If a third argument of 'udp' is specified, then it will tunnel
  UDP data instead of the normal TCP connections. A [CLIENT] section
  must contain either a 'fixed' config option or a 'socks' config option.

socks
  This option tells the client tunneler to run a SOCKS server tunnel for client
  applications to connect to. A SOCKS server allows connecting client
  applications to control where the ultimate destination for tunnelled traffic
  is on a connection by connection basis. SOCKS tunnels are therefore more
  flexible than fixed tunnels and generally easier to configure and use.
  A [CLIENT] section must contain either a 'socks' config option or a 'fixed'
  config option.

listen {<ip> <port>} | {<port> [IPv4 | IPv6]}
  This option tells the client tunneler what IP address and port it should
  listen for incoming connections from client applications on. There are 2
  formats for the arguments; you must either specify both the port and the
  address of a local interface to listen on, or alternatively you can just
  specify a port to listen on (in which case the client tunneler will listen
  for incoming connections on any interface) and optionally specify whether to
  create an IPv4 or an IPv6 socket. If your are configuring a SOCKS tunnelling
  client you will probably want to specify the standard SOCKS port 1080 here.

tunsvr <host> [<port>]
  This option tells the client tunneler the address of the corresponding tunnel
  server it should connect to. If you do not specify a port it will assume it
  should connect on the standard HTTP port 80.

proxy <host> <port>
  This option tells the client tunneler the address of an explicit proxy server
  it should route all traffic for this tunnel via.

proxyauth <user> <passwd>
  This option tells the client tunneler what username and password to use if
  the proxy it is routing via requires authentication. The same username and
  password is used for basic, digest or NTLM authentication. If you need to
  also specify a domain to which the user belongs (sometimes necessary if you
  are going via a Windows proxy requiring NTLM authentication), you can combine
  the domain name with the username using a '\'. For example;
  DomainName\UserName.

cliauth <user> <passwd>
  This option tells the client tunneler what username and password to use to
  authenticate itself at the server tunneler.

ssl
  This option tells the client tunneler to create a secure encrypted (SSL)
  tunnel between itself and the server tunneler.


A [SERVER] config file section specifies the behaviour of a server side
tunneler. This section may contain the following options:

listen {<ip> <port>} | {<port> [IPv4 | IPv6]}
  This option tells the server tunneler what IP address and port it should
  listen for incoming connections from client tunnels on. There are 2 formats
  for the arguments; you must either specify both the port and the address of a
  local interface to listen on, or alternatively you can just specify a port to
  listen on (in which case the server tunneler will listen for incoming
  connections on any interface) and optionally specify whether to create an
  IPv4 or an IPv6 socket. Typically you will probably want to specify a
  standard HTTP port here, such as 80 or 8080.

svrauth
  This option tells the server tunneler that it should only accept connections
  from clients who successfully authenticate themselves.

user <user> <passwd> <max tunnels> <max bandwidth>
  This option allows you to specify the authentication details for connecting
  clients. The <user> and <passwd> fields are the username and password for the
  connecting client and correspond to the <user> and <passwd> arguments to the
  cliauth option in the [CLIENT] configuration. The <max tunnels> field
  specifies the maximum number of active tunnels that user will be permitted
  to have running at once. The <max bandwidth> field specifies the total
  maximum bandwidth (in Kb/s) that user will be permitted to use over all their
  currently active tunnels. A value of 0 for either <max tunnels> or
  <max bandwidth> means there is no limit imposed for that user. Multiple users
  can be configured simply by including multiple user configuration lines.

denyips <ip>[,<ip>...]
  This option tells the server tunnelerto block any attempts to create tunnels
  to the specified IP address(es). A limited form of wildcard is supported for
  addresses ending in .* (for example; 127.*).

denyports <port>[,<port>...]
  This option tells the server tunneler to block any attempts to create tunnels
  to the specified port(s).

ssl <certificate file> <private key file>
  This option tells the server tunneler to create a secure encrypted (SSL)
  tunnel between itself and any connecting HTTPTunnel clients, and specifies
  the location of the SSL certificate file and private key file to use in
  negotiating the secure connection.

