in reply to upstream prematurely closed connection while reading response header from upstream

My guess is that your "global" variables in package Navi are not always initialized, maybe due to some mod_perl weirdness resp. how it wraps your code in a subroutine. You should see some warning like Variable will not stay shared in the webserver logs maybe.

My first approach would be to move the creation of the CGI object into a subroutine and always call that subroutine instead of hoping that the global variable is still available.

  • Comment on Re: upstream prematurely closed connection while reading response header from upstream
  • Select or Download Code

Replies are listed 'Best First'.
Re^2: upstream prematurely closed connection while reading response header from upstream
by Digioso (Sexton) on Feb 24, 2023 at 14:22 UTC

    Thanks a lot for this. And it seems that is indeed the solution. The scripts have been running for years without any issues, though. So I find it quite astonishing that this really is the case. oO I uploaded a test3.pl where I tried your suggestion and this one works without any issues. But urgh... That would mean I have to adjust that in dozens of scripts... My whole site is running on Perl... :(


    Link: https://digioso.tk/test3.pl

    Source code test3.pl
    #!/usr/bin/perl -w use strict; use CGI; use CGI::Carp qw(fatalsToBrowser warningsToBrowser); use lib "/home/digioso/web/digioso.tk/stuff"; use Navi2; my $cgi = Navi2::create_cgi(); Navi2::print_navi($cgi); print "test"; Navi2::end_navi($cgi);

    Source code Navi2.pm:
    #!/usr/bin/perl -w use strict; use warnings; use CGI; use CGI::Carp qw(fatalsToBrowser warningsToBrowser); package Navi2; binmode STDOUT, ":utf8"; sub create_cgi { return new CGI; } sub print_navi($) { my $cgi = shift; print $cgi->header (-type => 'text/html', -charset => 'UTF-8'); } sub end_navi($) { my $cgi = shift; print $cgi->end_html; }
      Now I started migrating stuff from my old webhoster to the new server

      This is why things changed, and why you have to edit your scripts.

      If you are interested, you could use this to migrate to (say) Mojolicious, which allows you to locally test your scripts and move some of your HTML generation into templates etc., but as a first step, instead of passing $cgi into print_navi(), you could create it within print_navi() if you don't need it elsewhere, especially if you're only using it for HTML generation.

      You also want to move the binmode STDOUT, ":utf8"; into your first call, likely create_cgi() so it gets called every time.

        Ah, understood. OK, that reduces the number of required changes a lot. :) Regarding Mojolicious (or other CGI.pm alternatives). Yes, I know it's bad to CGI.pm. But basically I really haven't found any alternative. I don't need frameworks to write applications and I don't need templates because I (as you've seen) I use Perl to write HTML. I only use CGI.pm to print out websites, so all the other neat features are totally wasted on me. And my main problem would be that I'd have to spend months to migrate everything I wrote over the past decades to the new system. At least CGI.pm isn't completely abandoned. The last update was beginning of January.

        Adjusted to this now: test3.pl:
        #!/usr/bin/perl -w use strict; use lib "/home/digioso/web/digioso.tk/stuff"; use Navi2; binmode STDOUT, ":utf8"; Navi2::print_navi(); print "test"; Navi2::end_navi();
        Navi2.pm:
        #!/usr/bin/perl -w use strict; use warnings; use CGI; use CGI::Carp qw(fatalsToBrowser warningsToBrowser); package Navi2; 1; sub create_cgi { binmode STDOUT, ":utf8"; return new CGI; } sub print_navi() { my $cgi = create_cgi(); print $cgi->header (-type => 'text/html', -charset => 'UTF-8'); } sub end_navi() { my $cgi = create_cgi(); print $cgi->end_html; }