Skip Menu |
 

This queue is for tickets about the CGI-Application CPAN distribution.

Report information
The Basics
Id: 72909
Status: open
Priority: 0/
Queue: CGI-Application

People
Owner: MARKSTOS [...] cpan.org
Requestors: FANY [...] cpan.org
bitcard [...] mfedv.net
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 4.50
Fixed in: (no value)



Subject: persistence issues
Download (untitled) / with headers
text/plain 1.1k
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
Download (untitled) / with headers
text/plain 697b
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
Download prerun.patch
text/x-diff 926b
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 ); }
RT-Send-CC: cgiapp [...] lists.erlbaum.net
Download (untitled) / with headers
text/plain 724b
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
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
Download (untitled) / with headers
text/plain 229b
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>
Download (untitled) / with headers
text/plain 783b
<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
Download (untitled) / with headers
text/plain 983b
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


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.