>  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