If you're using mod_perl 2, you can customize the output using an output filter written in perl. This is also in the mod_perl docs.

Good ideas, but coming from the wrong side. I've already got the access and authentication pieces. While I might be able to tackle this with an output filter, that doesn't give me a good way to pre-empt the access and authentication aspects.

I'm still pretty sure that there should be a way to, from a mod_perl2 handler, "pretend" to be Apache starting up a cgi script and then have the output available for further processing.

I'm not following. Why can't you "pre-empt" the access and authentication? A mod_perl access handler can run for static files, CGI scripts, PHP, etc. It's a standard phase provided by the web server.

I think you are overestimating how easy it is to do your own CGI. You can try copying some code from one of the perld HTTP daemons on CPAN, but there's a lot to deal with in terms of proper error handling and security. Better to let mod_cgi do it if you can.

perrin, I am forced to bow to your mastery here... with appreciation.

I haven't finished all the bits that I need, but it's definitely turning out to be significantly easier to do this as you suggested than I had originally feared. And, yes, this is mod_perl2, so I can do an output filter.

For anyone else who cares, relevant code (and otherwise) fragments: (Names have been changed to protect the guilty...)

httpd.conf

PerlModule Foo::FooAuth
PerlModule Foo::FooFilter
<Location /foo/cgi-bin/foo.cgi>
    PerlOutputFilterHandler Foo::FooFilter
    PerlAuthenHandler Foo::FooAuth

    require valid-user
</Location>
[download]

Foo::FooAuth

package Foo::FooAuth;

use strict;

use Apache2::Const qw(:common);

use Foo::AuthAux; # Provides whoami - uses a cookie set elsewhere

sub handler {
    my $r = shift;

    my $user = whoami($r);
    unless ($user) {
        $r->note_basic_auth_failure;
        return AUTH_REQUIRED;
    }
    $r->user($user);

    $r->subprocess_env(FOO => "bar+$user");

    return OK;
}

1;
[download]

Foo::FooFilter

package Foo::FooFilter;

use strict;


use Apache2::Filter;
use Apache2::Const qw(:common);
use Apache2::Request;

use HTML::Template;

use Foo::Config;  # Provides $TMPL_PATH below
use Foo::Auth;
use Foo::AuthAux;  # Provides whoami below

my $BUFF_LEN = 8192;

sub handler {
    my $f = shift;
    my $r = $f->r;

    my $fullbuf;

    while ($f->read(my $buf, $BUFF_LEN)) {
        $fullbuf .= $buf;
    }

    my $tmpl = HTML::Template->new(scalarref => \$fullbuf,
                                   path => $TMPL_PATH,
                                   die_on_bad_params => 0,
                                  );

    my $user = whoami($r);
    my $userinfo = ISPNET::Auth::userinfo($user);

    $tmpl->param(_user => $user,
                 _logo => $userinfo->{logo},
                 _logo_alt => $userinfo->{logo_alt},
# Set _home (would be $ENV{SCRIPT_NAME})...
                );

    $f->print($tmpl->output);

    return OK;
}

1;
[download]

I'm still debating where to put the .cgi scripts (in the filesystem) and have to figure out how to reference them from elsewhere (which will be used to adjust the $tmpl->param(_home => ...) bits, but otherwise, it seems to be working nicely.

There is no difficulty if you know the Apache API. Just ensure sure that all incoming and outgoing headers are copied, especially the HTTP headers that may appear twice, like Cookie -- you cannot use functions like $r->headers_in that return hash structures, thus suppressing the second Cookie header.

This is actually going to be for cgi scripts that are deployed (in the current "old" system) on the same system, so there's no need to act as a full proxy. Theoretically, I *should* be able to just use some aspect of the Apache interface(s) to fire off the CGI script "inline" and then extract the body of the response.

Thanks for the suggestion, though. I'd already thought of proxying it, but that then leaves me needing to have an exposed (in the sense of publicly-visible) cgi interface and I'm explicitly trying to avoid that.

Apache::Filter only allows you to do this with mod_perl handlers. IIRC you can do the same chaining natively in apache 2 without that restriction.

I've never done it but if I would attempt it, I would start by looking at Apache::PerlRun. Modelling from Apache::PerlRun, I would figure out how to capture the script's STDOUT (localizing STDOUT before the scripts run and re-opening STDOUT out on an IO::Scalar??). Once I have the scripts output in a scalar, then I would filter it. Sounds like a real pain ... I would give serious consideration to just using an iframe.