Item11690: FormPlugin: global variables, double Location HTTP headers a problem under mod_perl

There are a number of issues preventing FormPlugin to work properly when running under mod_perl, among them global (persisting) variables that do not get initialized (reset) in between requests and stuff that's output directly to stdout. I'll commit patches for those, but here's one bit that I currently use but which I don't consider a proper fix, and ask your advice on:

--- a/lib/Foswiki/Plugins/FormPlugin.pm
+++ b/lib/Foswiki/Plugins/FormPlugin.pm
@@ -476,9 +476,11 @@ sub _redirectToActionUrl {
     debug( "\t query=" . Dumper($query) );

     $redirecting = 1;
-    Foswiki::Func::redirectCgiQuery( undef, $url, 1 );
-
-    print "Status: 307\nLocation: $url\n\n";
+    $Foswiki::Plugins::SESSION->{response}->redirect(
+        -url => $url,
+        -cookies => $Foswiki::Plugins::SESSION->{response}->cookies(),
+        -status => 307,
+    );
        _sessionClearForm($formData->{options}->{name});

     return '';

The old code calls Foswiki::Func::redirectCgiQuery(), presumably in order to save (passthrough) the validated request data, and then outputs a Status and Location header to stdout. Unfortunately, redirectCgiQuery already outputs both headers (but with a Status: 302 instead of a 307), so this makes two Status and Location headers, which under CGI get cleaned up by Apache and the latter wins. Under mod_perl, headers cannot be output via stdout, and the whole thing breaks.

The above patch properly redirects the browser with a 307 status, but it violates the plugin API and I suspect that it throws out the validation previously done by FormPlugin (but there may be other issues with passthrough which I haven't properly identified yet). I believe what would be needed by FormPlugin is for Foswiki::Func::redirectCgiQuery() to gain an optional fourth parameter $status, which would default to 302.

Suggestions? Can I commit such an extention to the Plugin API to 1.1 at this point?

-- FlorianSchlichting - 23 Mar 2012

I vote for the latter: fix redirectCgiQuery. I have to admit I don't really understand why the browser must wait for the user's confirmation before getting the page, but I trust you on this.

Please, if you code the fix, add a basic check that the status is a 3XX, like: $status = $status ? $status =~ /^3[0-9][0-9]$/ ? $status : 302 : 302;

-- OlivierRaginel - 23 Mar 2012

Officially the browser should request a user confirmation on a 307, but only Firefox has implemented this, to the chagrin of users (doesn't make any sense, because the data has been sent already).

-- ArthurClemens - 24 Mar 2012

See also Item11702. This change exposes a bug in Foswiki::UI::Save. Cancel from edit results in "no response".

-- GeorgeClark - 29 Mar 2012

Commenting is disabled while not logged in