in reply to Re: httpd.conf configuration with mod_perl
in thread httpd.conf configuration with mod_perl

Works now! Set the first PerlResponseHandler to PerlAccessHandler...

Cheers!
  • Comment on Re^2: httpd.conf configuration with mod_perl

Replies are listed 'Best First'.
Re^3: httpd.conf configuration with mod_perl
by dariusj (Sexton) on Nov 12, 2007 at 17:36 UTC
    Having further complications with this issue - it doesn't seem to be working fully.
    Take this example:
    <Location ~ /StockControl/Inventory$> SetHandler perl-script PerlAccessHandler XTracker::Authenticate PerlResponseHandler XTracker::Stock::Inventory::SearchForm </Location>
    Authenticate is meant to redirect to /Home with the following code:
    $r->headers_out->set( Location => "/Home" ); return REDIRECT;
    This doesn't seem to be working at all - the redirect is being completely ignored, an error message is passed to the browser but then the browser displays the rest of the page as if an OK had been passed.
    Does anyone know how this can be changed to work in mod_perl 2?
    The docs mentioned in the previous post mention that PerlAccessHandler should return FORBIDDEN or OK, does this mean REDIRECT cannot be returned at all? Also, the page does not mention REDIRECT anywhere - has this been deprecated? How should it be replaced?
    Thanks!
      There is good documentation on porting code to mod_perl 2. Please read it.

      It should be fine to send a redirect. Your code may not be sending the right headers. The simplest way to check is to use Firefox with the LiveHTTPHeaders extension and see what is being sent to the browser.

      REDIRECT is not available unless you imported it from Apache2::Const. You can just use it directly: Apache2::Const::REDIRECT.

        I've read the documentation a few times (or at least the parts that were relevant - lot of stuff that I'm not using).

        The problem was not actually with REDIRECT, which works (apologies for misdiagnosing the problem) - the problem was that in the <Location> Apache2 configuration the actual location is followed by a Regexp, which altered the behaviour of the redirect.

        Though this was meant to be the case in Apache 1.3 too (at least according to the docs), the behaviour was different - basically another location was picked up in Apache 2 that wasn't in Apache 1.3.