in reply to Re: Embedding "user" CGI output into a mod_perl response
in thread Embedding "user" CGI output into a mod_perl response

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.

  • Comment on Re^2: Embedding "user" CGI output into a mod_perl response

Replies are listed 'Best First'.
Re^3: Embedding "user" CGI output into a mod_perl response
by perrin (Chancellor) on May 10, 2006 at 03:26 UTC
    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.

      Hmmm... I'll have to ponder that. My original plan had been to use my existing framework only, for the cgi bits, hand the processing off to a "CGI masquerade" module, rather than needing to also do a separate access / authentication that is also used for the CGI-ish bits.

      I was thinking that there should be a way for me to run through mod_cgi directly from inside my handler rather than needing to let Apache do the mod_cgi processing. Also, I'd prefer to keep from exposing the .cgi scripts to the outside world.

      What you suggest is definitely an interesting approach and I hadn't thought of doing it that way. I'll need to investigate a little bit in how to do the access/authentication as well as building an output filter.