* Global "Backend" definitions

A "Backend" statement is allowed to appear in global scope.  In this
case it must be followed by a symbolic name, as in:

  Backend "name"
    ...
  End

The "name" must uniquely identify this backend among other backends
defined in global scope.

Global backend definitions can be used in services using the
"UseBackend" statement:

  UseBackend "name"

A single globally defined backend can be used in multiple services.
Its actual global definition may appear before as well as after the
service or services it is used in.

A named form of Backend statement is also allowed for use in
Service sections.  In this case it acts as "UseBackend" statement,
except that statements between "Backend" and "End" modify the
parameters of the backend for use in this particular service.  Only
two statements are allowed in such named form: "Priority" and
"Disabled".  The following example attaches the globally defined
backend "assets" to the service and modifies its priority:

  Backend "assets"
    Priority 8
  End

* Response header modification

The "Rewrite" statement accepts optional argument specifying whether
it applies to the incoming request, or to the response.  The following
statement applies to requests and is exactly equivalent to "Rewrite"
without argument:

  Rewrite request
    ...
  End

In contrast, the following statement:

  Rewrite response
    ...
  End

applies to the response (received from the regular backend or generated
by error backend).  In this form, the set of statements that can
appear inside the section (denoted by ellipsis above) is limited to
the following: "Not", "Match", "Header", "StringMatch",
"SetHeader", and "DeleteHeader".  For example:

  Rewrite response
    Match
      Header "Content-Type: text/(.*)"
    End
    SetHeader "X-Text-Type: $1"
  End

The same applies to "Else" branches.

* Basic authentication

New request matching statement "BasicAuth" is implemented.  Its
syntax is:

  BasicAuth "FILE"

It evaluates to true, if the incoming request contains Authorization
header with scheme "Basic", such that user name and password obtained
from it match a line in the given disk file.  FILE must be a
plain-text file created with htpasswd(1) or similar utility, i.e. each
non-empty line of it must contain username and password hash separated
by a colon.  Password hash can be one of:

  . Password in plain text.
  . Hash created by the system crypt(3) function.
  . Password hashed using SHA1 algorithm and encoded in base64.
    This hash must be prefixed by {SHA}
  . Apache-style "APR1" hash.

Combined with the response rewriting described above, this can be
used to implement basic HTTP authentication in Pound as shown in
the following example:

  Service "auth"
      Not BasicAuth "/etc/pound/htpass"
      Rewrite response
          SetHeader "WWW-Authenticate: Basic realm=\"Restricted access\""
      End
      Error 401
  End

Unless the file name starts with a slash, it is taken relative to the
"IncludeDir" directory.  The file is cached in the memory on the first
authorization attempt, so that further authorizations do not result in
disk i/o operations.  It will be rescanned if Pound notices that the
file's modification time has changed.

* Bugfixes

** The Host statement assumes exact match by default.
** Fix detection of duplicate Transfer-Encoding headers.