[cgiapp] Strange behaviour using CGI::Application, Template Toolkit's exception handling and flow control and the redirect plugin

[David Williamson]

Hi,

I'm observing some puzzling (to me) behaviour using:

  * CGI Application;
  * Template Toolkit's exception handling and flow control;
  * The redirect plugin.

I wonder if anybody can understand what's happening and how to resolve 
it. Here's what I think is going on.

I am handling form input. The first step is to display the page 
containing the form. I'm using Template Toolkit via the 
CGI::Application::Plugin::AnyTemplate plugin, because I like its 
implementation of embedded components.

In my Template Toolkit setup, I have a common header that attempts an 
INCLUDE as follows:

[% TRY # INCLUDE page_header if it has been defined %]

[% INCLUDE page_header %]

[% CATCH file # Ignore the error if no page_header %]

[% END # TRY %]

What's going on here, is that all pages call the header. If the page 
sets a page_header block before calling the header, then that 
page_header block is displayed. However, if the page does not set a 
page_header block then that's fine and I don't want Template Toolkit to 
throw an error.

The page that I'm displaying that contains my form does not set the 
page_header block and this works fine. No error is thrown. The page is 
displayed. No error messages appear in my uwsgi log (more on that later).

Now, I input data in to the form and submit it. The run mode that is 
invoked processes the form data. If the form data passes validation and 
is processed successfully then that run mode ends with an external 
redirect to another run mode that displays a "You're input was 
successful" type page. I do an external redirect in this way so that if 
the user then does a page refresh they do not resubmit their form input.

Everything works okay except that when the run mode that processed the 
form data ends, suddenly a load of output appears in the uwsgi server 
log referring to failed attempt to find a page_header block. No actual 
error occurs and all is functionally fine but I'm the kind of guy who is 
bugged by all this spurious output appearing in the server log. I often 
refer to the server log to debug and/or reassure myself that all is 
well. The spurious output in there bothers me.

Any thoughts?

My instinct is that because the run mode that processes the form data 
doesn't output itself but instead performs a redirect, for some reason 
this is leading to a flushing of STDERR output to the uwsgi log.

Dave