Page 1 of 1
Can't access $_POST variables
Posted: Mon Feb 16, 2004 7:46 pm
by Russ Dirks
Hi,
I've got an order form on my web site which posts data to a .php script, which stuffs it into a mySql database. Last week it stopped working. I get nothing but blank entries in my database. In trying to debug the problem, I added code to my php script to output all the $_POST variables, and there are none. This happens about 80% of the time. About 20% of the time it works fine. Either the browser is not sending data, or the php engine on the server is not putting the data into $_POST variables properly. I've contacted tech support at my web host provider, but so far they have not been much help. Anybody have a clue what might be happening?
Thanks,
Russ
Posted: Mon Feb 16, 2004 8:02 pm
by DuFF
What version of PHP? Also, is register_globals on or off (you will probably have to ask you web host provider)?
Posted: Mon Feb 16, 2004 8:23 pm
by Russ Dirks
PHP Ver 4.1.0
register_globals = On
Posted: Mon Feb 16, 2004 8:48 pm
by DuFF

I think register_globals have to be turned off to support $_POST . . .
If I'm wrong someone please correct me
Edit
Yep, I was wrong

Posted: Mon Feb 16, 2004 8:54 pm
by markl999
$_POST is independent of register_globals

Posted: Mon Feb 16, 2004 8:55 pm
by Russ Dirks
This is from the PHP documentation:
HTTP POST variables: $_POST
Note: Introduced in 4.1.0. In earlier versions, use $HTTP_POST_VARS.
An associative array of variables passed to the current script via the HTTP POST method. Automatically global in any scope.
This is a 'superglobal', or automatic global, variable. This simply means that it is available in all scopes throughout a script. You don't need to do a global $_POST; to access it within functions or methods, as you do with $HTTP_POST_VARS.
$HTTP_POST_VARS contains the same initial information, but is not an autoglobal. (Note that HTTP_POST_VARS and $_POST are different variables and that PHP handles them as such)
If the register_globals directive is set, then these variables will also be made available in the global scope of the script; i.e., separate from the $_POST and $HTTP_POST_VARS arrays. For related information, see the security chapter titled Using Register Globals. These individual globals are not autoglobals.
Further info
Posted: Mon Feb 16, 2004 8:59 pm
by Russ Dirks
Further info :
I used this statement to ouput the POST variables :
print_r(array_keys($_POST));
When it works, I nicely see all the names of the fields that are being sent from the form, but 80% of the time, I see nothing but an empty array ( ).
Is there some way to see what is coming from the browser, before PHP starts parsing it?
Russ
Posted: Mon Feb 16, 2004 9:03 pm
by markl999
If it works only 20% of the time then you might have the 'pressing enter to submit' problem. Are you always using the submit button to post the form, or pressing the enter key? Sometimes a submit isn't sent went you use the enter key...in a certain well know browser.
Posted: Mon Feb 16, 2004 9:39 pm
by kanshou
Mark, are you serious? That would explain a few issues I was having... Is there a work around for it?
Posted: Mon Feb 16, 2004 9:44 pm
by markl999
Don't use if(isset($_POST['submit'])) , use another element. Either use an existing one or create a hidden form element and check for that. Checking for the submit button being pressed as a sign that the form has been posted isn't reliable
I think the 'pressing enter not working' thing is limited to IE 5.5, bit i'm not 100% sure.
Posted: Mon Feb 16, 2004 9:49 pm
by DuFF
Thanks for the tip Mark. I've been using Firebird (errr, Firefox I guess now) for debugging my forms so I guess I'll have to go back and fix a few *sigh*
M$, they really know how to screw everything up.
Posted: Mon Feb 16, 2004 11:00 pm
by Russ Dirks
I found the the problem. It has to do with security
update 832894 which I installed last week. Unfortunately, it has a caveat,
something to do with problems connecting to a server that resets the http
connection for a POST operation.
The security bulletin is here ...
http://www.microsoft.com/technet/treevi ... 04-004.asp
They have issued an update to fix the problem here ...
http://support.microsoft.com/default.aspx?kbid=831167
and here ...
http://www.microsoft.com/downloads/deta ... laylang=en
When I installed this update, the problem went away.
My question to you guys is, is there something that can be done to the server (Apache/1.3.26) so it doesn't exhibit this problem (something about reseting a POST operation, which is way above my head) or do I have to put a notice on my order page to warn people about this and get them to install the fix to the update. That would be a pain!
Thanks!