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 :roll:

Edit
Yep, I was wrong :P

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 :o

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!