| Subject: | args_to_new object is instantiated with parameters from first request if dispatch.psgi script is not setup properly |
| Date: | Fri, 21 Aug 2020 10:09:45 -0500 |
| To: | bug-CGI-Application-Dispatch [...] rt.cpan.org |
| From: | Michael McNeil <waverly360 [...] gmail.com> |
First off, the specs:
CGI::Application::Dispatch - version 3.12
CGI::Application - version 4.61
Starman 0.4015
perl 5, version 30, subversion 2 (v5.30.2) built for
x86_64-linux-thread-multi (Using PerlBrew)
CentOS Linux 4.18.0-193.14.2.el8_2.x86_64 #1 SMP Sun Jul 26 03:54:29 UTC
2020 x86_64 x86_64 x86_64 GNU/Linux
I don't know whether to consider this a weird bug, or maybe documentation
confusion, but I've spent a long time digging through perl modules to
discover that the args_to_new object in the
CGI::Application::Dispatch::PSGI module gets instantiated with a copy of
the current environment *including* parameters passed in on the first
attempt when using a PSGI server (such as Starman, Starwoman, Starlet, and
Gazelle...I tried all of them.)
I tracked it to this section of code, which led to me eventually solving
the problem:
if (ref($args) eq 'HASH' and not defined $args->{QUERY}) {
require CGI::PSGI;
$args->{QUERY} = CGI::PSGI->new($env);
$module->new($args);
}
elsif (ref($args) eq 'HASH') {
$module->new($args);
}
else {
$module->new();
}
My plan to work around the problem was to just instantiate my own PSGI
object and pass it in per the examples on
https://metacpan.org/pod/CGI::Application::Dispatch::PSGI but I realized my
dispatch script had to be modified a bit to make that work. Originally, it
was setup like this, per the example on the above page under the "as_psgi"
function:
#!/opt/lsi/project/bin/perl
use strict;
use warnings;
use IO::Handle;
use Plack::App::CGIBin;
use Plack::Builder;
use CGI::Application::Dispatch::PSGI;
my $cgi_bin = Plack::App::CGIBin->new(
root => "/opt/project/web/cgi-bin"
)->to_app;
my $app = CGI::Application::Dispatch::PSGI->as_psgi(
prefix => 'Project::Web',
);
builder {
mount "/project" => $cgi_app;
mount "/project_cgi" => $cgi_bin;
};
In order to pass in a custom CGI::PSGI object however, I had to modify it
like this first:
#!/opt/lsi/project/bin/perl
use strict;
use warnings;
use IO::Handle;
use Plack::App::CGIBin;
use Plack::Builder;
use CGI::Application::Dispatch::PSGI;
use CGI::PSGI;
my $cgi_bin = Plack::App::CGIBin->new(
root => "/opt/project/web/cgi-bin"
)->to_app;
my $cgi_app = sub {
my $env = shift;
my $app = CGI::Application::Dispatch::PSGI->as_psgi(
prefix => 'Project::Web',
);
return $app->($env);
};
builder {
mount "/project" => $cgi_app;
mount "/project_cgi" => $cgi_bin;
};
Note here I'm not actually passing in the CGI::PSGI object...as it turns
out, simply reforming my dispatch script like this solved my problem. I
think the major difference here is that I'm properly passing in the current
perl environment to the as_psgi function, where I was not before.
Whether it's a bug or not, I have a few reasons for posting this as an
issue, and I'd appreciate guidance if I've done so in error:
1) If my original dispatch script was wrong, I think the documentation
should be updated to reflect that on the module page, specifically under
the "as_psgi" method description.
2) If my original dispatch script should have worked fine, then...clearly
there is some bug in how the environment is being handled (I had hoped to
fully get to the bottom of it and even provide a patch, but I've spent more
time than I care to admit tracing through perl libraries just to get this
far, and I can't be certain why some things are being done the way they
are. (For example, "$local_args_to_new" seems as though it was meant to be
a local copy of the "args_to_new" object, but it appears to be a reference
to the original args_to_new object, so any manipulation done to it ends up
actually setting args_to_new, which seems like the wrong thing?)
3) I have seen another bug report where folks have talked about how
args_to_new gets set with the query object initially, and then caches that
each time, and claim a new object should get created each time. (
https://rt.cpan.org/Public/Bug/Display.html?id=88506) Others in that list
were unable to reproduce. I thought *maybe* they were having the same
issue I was..and wanted to at least get this out there where others could
potentially try this solution instead. Maybe it's as simple as the
dispatch.psgi script being setup wrong in the first place.
4) Maybe I'm just missing something dumb overall, and someone can point me
in the right direction. I'm curious why I've not seen much further mention
of this even though it's very reproducible for me.
5)I have spent so much time on this..it felt wrong to just leave it as "ok,
it's working now..glad I wasted all that time for a simple admin interface
because I was stubborn.
At any rate, sorry for the long winded rant. Thanks for any time spent
reading over this, and if it's to be "not fixed" I'm fine with that...this
at least would give others something to google search for...hopefully.
Michael
Message body is not shown because it is too large.