view release on metacpan or  search on metacpan

lib/Apache2/Translation.pod  view on Meta::CPAN

 <Location />
   ProxyPassReverse http://my.backend.org
 </Location>

Note, the location container uri differs.

The first one of them is also the only form of C<Config> available with
mod_perl before 2.0.3.

The next one:

 Config: ['ProxyPassReverse http://my.backend.org', '/path']

is equivalent to

 <Location /path>
   ProxyPassReverse http://my.backend.org
 </Location>

I have chosen C<ProxyPassReverse> for this example because the C<Location>
container uri matters for this directive, see httpd docs. The following
form of applying C<ProxyPassReverse> outside of any container is not
possible with C<Apache2::Translation>:

 ProxyPassReverse /path http://my.backend.org

Now let's look at another example to see how C<Directory> containers and
C<.htaccess> files are applied. C<AllowOverride> controls which directives
are allowed in C<.htaccess> files. As said before Apache applies C<Directory>
containers and C<.htaccess> files after our C<Config> directives.
Unfortunately, they are both applied in the same step. That means we can
say:

 Config: 'AllowOverride Options'

But if at least one C<Directory> container from our C<httpd.conf> is applied
that says for example C<AllowOverride AuthConfig> it will override our
C<Config> statement. So, if you want to control which directives are allowed
in C<.htaccess> files with C<Apache2::Translation> then avoid C<AllowOverride>
in your C<httpd.conf>, especially the often seen:

 <Directory />
   AllowOverride None
 </Directory>

Put it instead in a I<PREPROC> rule:

 #uri     blk ord action
 :PRE:    0   0   Config: 'AllowOverride None'

So subsequent rules can override it.

A similar problem exists with C<Options FollowSymlinks>. This option affects
directly the phase when C<Directory> containers are applied. Hence, any
such option from the C<httpd.conf> cannot be overridden by a C<Config> rule.

In Apache 2.2 at least up to 2.2.4 there is a bug that prevents
C<Config: AllowOverride Options> from working properly. The reason is an
uninitialized variable that is by cause 0, see
L<http://www.gossamer-threads.com/lists/apache/dev/327770#327770>

=item B<Call: string, ?@params?>

Well, the name suggests it is calling a subroutine. Assume you have several
WEB applications running on the same server, say one application for each
department. Each department needs of course some kind of authorization:

 #uri      blk ord action
 AUTH      0   0   Config: "AuthName \"$ARGV[0]\""
 AUTH      0   1   Config: 'AuthType Basic'
 AUTH      0   2   Config: 'AuthUserFile /etc/htaccess/user/'.$ARGV[1]
 /dep1     0   0   Call: qw/AUTH Department_1 dep1/
 /dep2     0   0   Call: qw/AUTH Department_2 dep2/

The C<AUTH> in the C<Call> actions refer to the C<AUTH> block list in the
C<uri> column. An optional parameter list is passed via C<@ARGV>.

C<Call> fetches the block list for a given uri and processes it. If a
C<Last> action is executed the processing of that block list is finished.

=item B<Redirect: url, ?http_code?>

The C<Redirect> action sends a HTTP redirect response to the client and
abort the current request. The optional C<http_code> specifies the
HTTP response code. Default is 302 (MOVED TEMPORARILY).

C<Redirect> tries to make the outgoing C<Location> header RFC2616 conform.
That means if the schema part is ommitted it figures out if it has to be
C<http> or C<https>. If a relative url is given an appropriate url is
computed based on the current value of C<$URI>.

If the current request is the result of an internal redirect the
redirecting request's status is changed to C<http_code>. Thus,
C<Redirect> works also for C<ErrorDocument>s.

=item B<Error: ?http_code?, ?message?>

C<Error> aborts the entire request. A HTTP response is sent to the client.
The optional C<http_code> specifies the HTTP response code. The optional
C<message> is logged as reason to the C<error_log>.

C<http_code> defaults to 500 (INTERNAL SERVER ERROR), C<message> to
C<unspecified error>.

=item B<Uri: string>

This action sets C<$r-E<gt>uri> to string. It is equivalent to

 Do: $URI=do{ string }

=item B<Key: string>

C<string> is evaluated in scalar context. The result is assigned to the
current key. The new key takes effect if the list of blocks matching the
current uri is finished.

For example:

 id  key    uri      blk ord action
  1  dflt   :PRE:    0   0   Cond: $CLIENTIP eq '192.168.0.1'