Bug #72909 for CGI-Application: persistence issues

Fri Dec 02 18:06:49 2011 bitcard [...] mfedv.net - Ticket created

Subject:

persistence issues

Hello, the documentation does not say much about object persistence (as opposed to just perl interpreter persistence) in persistent environments (e.g. FastCGI, CGI::Application::Server). * Feature Request: Documentation should cover persistence. It would be nice if there was a small howto regarding CGI::Application object persistence. - should it be done at all? - what cleanup is an application supposed to do? - are plugins supposed to work in persistent environments? * Bug Report (maybe): CGI::Application does not cleanup per-request data I stumbled across 2 issues that I believe should be handled (cleaned up) by CGI::Application itself (if persistence is to be supported at all): - header settings ($self->{__HEADER_PROPS}) => redirect loop - prerun_mode settings ($self->{__PRERUN_MODE}) => locked in given runmode after first use (see also http://www.mail-archive.com/cgiapp@lists.erlbaum.net/msg08997.html) I am not sure if this classifies as a bug, since the documentation does not say if persistence is to be used or not. See also https://rt.cpan.org/Ticket/Display.html?id=72906 about CGI::Application::Server Regards Matthias

Mon May 28 05:06:43 2012 FANY [...] cpan.org - Requestor FANY added

Mon May 28 05:24:14 2012 FANY [...] cpan.org - Correspondence added

Dear Mark, I think it would be great if CGI::Application would clean up things like prerun_mode and headers after each request with regard to persistent environments like CGI::Application::FastCGI. What do you think? If you share this opinion, I could try to write appropriate patches for CGI::Application, and I would also submit some for CGI::Application::Plugin::Authentication. If not, I can alternatively amend the documentation, as Matthias already suggested, and maybe should think about an addition for CGI::Application::FastCGI. As a start, a patch for cleaning up the prerun mode after each request is attached. Kind regards, Martin PS: Ticket #46258 is still on my TODO list. ☺

Subject:

prerun.patch

diff --git a/lib/CGI/Application.pm b/lib/CGI/Application.pm index f715b4e..3ec2d3d 100644 --- a/lib/CGI/Application.pm +++ b/lib/CGI/Application.pm @@ -212,6 +212,7 @@ sub run { # clean up operations $self->call_hook('teardown'); + $self->{__PRERUN_MODE} = '' if length $prerun_mode; return $return_value; } diff --git a/t/prerun.t b/t/prerun.t index 115c4b1..25b9b7e 100644 --- a/t/prerun.t +++ b/t/prerun.t @@ -1,4 +1,4 @@ -use Test::More tests => 10; +use Test::More tests => 13; # Need CGI.pm for tests use CGI; @@ -44,6 +44,13 @@ $ENV{CGI_APP_RETURN_ONLY} = 1; # get_current_runmode() working? is($ta_obj->get_current_runmode(), 'new_prerun_mode_test'); + + my $rm = 'prerun_test'; + $ta_obj->query( CGI->new("rm=$rm") ); + $output = $ta_obj->run; + like( $output, qr!^Content-Type: text/html\b! ); + like( $output, qr/Hello World: \Q$rm\E OK\b/ ); + is( $ta_obj->get_current_runmode, $rm ); }

Mon May 28 05:24:16 2012 FANY [...] cpan.org - Status changed from 'new' to 'open'

Fri Jun 15 09:49:16 2012 FANY [...] cpan.org - Correspondence added

RT-Send-CC:

cgiapp [...] lists.erlbaum.net

I wrote on May 28th: Show quoted text

> I think it would be great if CGI::Application would clean up things > like prerun_mode and headers after each request with regard to > persistent environments like CGI::Application::FastCGI.

Second thought: In order not to risk breaking any existing code – maybe someone with a persistent environment sets ->header_props in ->cgiapp_init and relies on them being sticky – maybe it would be preferable not to change the default behaviour of CGI::Application, but to provide a ->reset or ->cleanup method which would do the job. Any opinions on that? I am planning to have a look at which things exactly should probably be reset between requests and provide a patch for that sometime soon. fany

Fri Jun 15 09:49:39 2012 cgiapp-owner [...] lists.erlbaum.net - Correspondence added

Subject:	[rt.cpan.org #72909] persistence issues
Date:	Fri, 15 Jun 2012 09:49:19 -0400
To:	bug-cgi-application [...] rt.cpan.org
From:	cgiapp-owner [...] lists.erlbaum.net

You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at cgiapp-owner@lists.erlbaum.net.

CC:	cgiapp [...] lists.erlbaum.net
Subject:	[rt.cpan.org #72909] persistence issues
Date:	Fri, 15 Jun 2012 09:49:17 -0400
From:	"FANY via RT" <bug-CGI-Application [...] rt.cpan.org>

<URL: https://rt.cpan.org/Ticket/Display.html?id=72909 > I wrote on May 28th: Show quoted text

> I think it would be great if CGI::Application would clean up things > like prerun_mode and headers after each request with regard to > persistent environments like CGI::Application::FastCGI.

Second thought: In order not to risk breaking any existing code – maybe someone with a persistent environment sets ->header_props in ->cgiapp_init and relies on them being sticky – maybe it would be preferable not to change the default behaviour of CGI::Application, but to provide a ->reset or ->cleanup method which would do the job. Any opinions on that? I am planning to have a look at which things exactly should probably be reset between requests and provide a patch for that sometime soon. fany

Mon Mar 25 12:19:39 2013 MARKSTOS [...] cpan.org - Taken

Mon Mar 25 12:25:14 2013 MARKSTOS [...] cpan.org - Correspondence added

CGI::Application works fine in persistent environments. A number of users deploy it with mod_perl-- I use it with mod_perl every day. People also use it in FastCGI as well. The CGI::Application::FastCGI approach is broken though, as noted in the one review left for it: http://cpanratings.perl.org/dist/CGI-Application-FastCGI That review points to this wiki page, which documents a solution that I think should work (although I don't use FastCGI): http://www.cgi-app.org/index.cgi?FastCGI As people have been using both FastCGI and mod_perl for years, I don't think patches should be necessary. CGI::Application is designed to have a new object created on each request. The environment is pesistent in that classes and modules stay loaded in memory, but the CGI::Application object itself is not intended to persist. If you want something to persistent, I suggest storing it in a class/global variable instead of the object. Some plugins take that approach. Mark