You are here: Foswiki>Tasks Web>Item11707 (07 Sep 2015, GeorgeClark)Edit Attach

Item11707: Foswiki behaves differently between CGI and mod_perl when mixing GET and POST parameters

Priority: Normal
Current State: Confirmed
Released In: n/a
Target Release: n/a
Applies To: Engine
Component: FoswikiRequest, ModPerlEngineContrib
Branches: trunk
Reported By: FlorianSchlichting
Waiting For:
Last Change By: GeorgeClark
19:08 < fsfs> soooo, Foswiki behaves differently between CGI and mod_perl when a form is POSTed to a url that contains GET parameters: under CGI, the
              GET-params are explicitly ignored (queryParam() in F::Request), whereas under mod_perl, they re-surface among POST parameters through a detour
              via Apache2::Request::param()
19:08 < fsfs> is that a bug?
19:09 < fsfs> I have a feeling that it's not correct to just ignore the GET params. makes both available, but in case of a POST they need to be
              treated separately
19:09 < fsfs>
19:11 < fsfs> (and in case you were wondering, redirecting go ...?foswiki_redirect_cache=8065b244210cea9d96a5f870e90a7730 with a 307 does just that: sending
              both GET and POST params)
19:17 < fsfs> git says it dates back to the original TWiki import...

Found while working on Item11690

-- FlorianSchlichting - 30 Mar 2012

Thought I should perhaps add that I'm using Foswiki 1.1.4 and Apache2::Request 2.12 (Debian squeeze package).

And just to clarify: I'm unsure about the correct behaviour (whether Foswiki should consider GETvars in a POST request, or Apache2::Request should not make GETvars available as part of its param() method), but I think it is a bug and a road to tears that Foswiki should behave differently depending on webserver environment.

-- FlorianSchlichting - 03 Apr 2012

I would say it's a bug, but it's one that has to be resolved between CGI and fcgi i.e. reported upstream. It's not anything Foswiki cab do anything about.

-- CrawfordCurrie - 04 Apr 2012

well, Foswiki could do
--- a/lib/Foswiki/
+++ b/lib/Foswiki/
@@ -361,7 +361,6 @@ future, so it could be possible to get query and body parameters independently.
 sub queryParam {
     my $this = shift;
-    return if $this->method && $this->method eq 'POST';
     return $this->param(@_);
which I think would fix things. Haven't tested though, and there likely was a reason for excluding GET-params on POST and the whole split between queryParam, bodyParam and param in F::Request

-- FlorianSchlichting - 04 Apr 2012

The standards seem to allow mixing of querystring and post parameters, though I'm not sure that it's really a good / recommended practice.

The fact that there is a difference whe mod_perl says there is something wrong here, but I'd prefer that we fix something on the mod_perl side to prevent the mixing, rather than opening up foswiki cgi to mixed parameters.

Anyway, setting this to confirmed.

-- GeorgeClark - 06 Jan 2015

Note that the suggested fix above is already applied, but is ineffective. See Item13672.

-- GeorgeClark - 05 Sep 2015

The following patch would catch issues caused by providing both form data and query parameters:
diff --git a/core/lib/Foswiki/ b/core/lib/Foswiki/
index effcfc7..a2c4541 100644
--- a/core/lib/Foswiki/
+++ b/core/lib/Foswiki/
@@ -191,6 +191,11 @@ Main coordinator of request-process-response cycle.
 sub handleRequest {
     my $req = shift;
+    if ( DEBUG && $req->method() eq 'POST' ) {
+       $req->uri() =~ m/.*\?(.*)$/;
+       ASSERT( "querystring ($1) provided to POST" ) if ($1);
+    }
     my $res;
     my $dispatcher = $Foswiki::cfg{SwitchBoard}{ $req->action() };

-- GeorgeClark - 07 Sep 2015

ItemTemplate edit

Summary Foswiki behaves differently between CGI and mod_perl when mixing GET and POST parameters
ReportedBy FlorianSchlichting
Codebase 1.1.5 RC1, trunk
SVN Range
AppliesTo Engine
Component FoswikiRequest, ModPerlEngineContrib
Priority Normal
CurrentState Confirmed
Checkins FormPlugin:6efa65a415cd
TargetRelease n/a
ReleasedIn n/a
CheckinsOnBranches trunk
trunkCheckins FormPlugin:6efa65a415cd
Topic revision: r9 - 07 Sep 2015, GeorgeClark
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy