Cool... exactly the same thing happened to me, except that it wasn't when I switched
from mp1 to mp2 (which I haven't done), it was when I upgraded from Jaguar to
Panther, which comes with 5.8.1RC3 and a pre-built Apache/mod_perl.
eeck, a release candidate on a major os? unbelievable.
So I'm still
using mp1, yet the exact same thing happens to me; all the POST values are lost.
that's not good. mp1 and CGI.pm have been friends for a long time, so I wouldn't have expected this.
I sniffed around and it seems to be that something is funky with the way that CGI.pm is initialising itself under mod_perl;
any chance you can go back to 5.8.0 or the official 5.8.1, recompile, and see if that makes a difference?
remember that when a mod_perl process accesses $r->args, all future calls to that will return nothing.
well, not $r->args, since that's for the query string. but for POST data ($r->content) you're right.
It seems to me that this is happening too early in the case of a POST, but it's not in my code anywhere... so I suspect it's buried somewhere in the bowels of Apache and CGI and their interactions with each other.
mod_perl doesn't do it, neither does apache. so it must be CGI.pm. one way to try and debug this would be to read from STDIN directly (you know, the way we all used to do it way back when :) during a fixup handler and see if the POST data is there. then remove CGI.pm entirely and do the same thing from a registry script.
Seems I was luckier than Scott though since I had wrapped all calls to get parameters from CGI.pm with a few methods of my own. To get around the weirdness, I just replaced the instance of CGI.pm with an instance of Apache::Request, and everything started working again.
cool. Apache::Request is nice, isn't it :)
--Geoff
