Re^2: Embedding "user" CGI output into a mod

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.	[reply]
Re^4: Embedding "user" CGI output into a mod_perl response by bmcatt (Friar) on May 10, 2006 at 04:19 UTC
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.	[reply]