Topic awaiting preservation: Missing data in $_REQUEST

(also at the GN)
Now it's my turn with a really absurd problem in PHP (or my mind)...

I'm recieving a querystring from a paymentservice (no control over the format).

looks something like this:
?Param_1=12345&Param_2=23456... and so on, totally standard, only it might come as a POST in the future, same format though.

What I need to do before I can process it, is to extract the variables (not all), validate that they contain a value, and place them in internal variables for further processing.

Piece of cake!
So I grab them through
if(!empty($_REQUEST['Param_1'])){
$param_1 = $_REQUEST['Param_1'];
}
For each one that I need.

Then I do a datatype check:
if(!is_string($param_1)){
$param_1 = "";
}
To kill all that's not strings.

Now, out of 6 parameters only three can be retrieved this way...
If I print_r($_REQUEST)
It's all there, it's in the actual url
But if I access any of the three missing parameters directly they are gone ?!?!?!? It's the same ones all the time.

First thought: I must unintentionally kill the internal variable...
Removed that validation. Same thing...
No matter what I do I cannot transfer three specific indexes value from $_REQUEST to internal variables...
And no, $_GET doesn't work either...

No error messages, the data simply isn't there...

I'm going to strip this down to it's bare bones tomorrow to find any stupid spelling mistakes and similar, I'm just wondering if anyone has experienced something similar before?
/Dan



{cell 260}
-{ a vibration is a movement that doesn't know which way to go }-

Some quick thoughts:
http://development.gurusnetwork.com/discussion/showthread.php?s=&postid=19398#post19398

___________________
Emps

FAQs: Emperor

DmS, experienced a similar problem awhile back and found a plausible solution.

<?php

    foreach($_REQUEST as $request_key => $request_value) {

        $eval_string = "\$$request_key = '$request_value';";

        eval($eval_string);

?>

__________________

Kriek says '[SYSTEMWIDE_MESSAGE] PHP Meetup'
What we do is never understood; only praised and blamed

that's one awesomely large security hole you got their, kriek.
Either use variable variables for this, or don't do it at all, but I could easly drive a dead-star through an eval hole that size.

so, you're sure your $_REQUEST['Param_1'] is actually a string, and doesn't get set to '', DmS?

now, the param_1 is a valid variable name, isn't it? it's not like you're setting 342=3248 in your url, or something?

Are you using any external scripts that may be using the same variable?

Last not but least, are you possibly inside of a function and forgot to declare something global?

if all fails, put in debug statementes ever second line ;-)


so long,
TP

Thanx.
TP, did all that, I'm getting the querystring from an external place that I have no control over,
however, I did find the errors. Two of them was simple spelling errors as it usually is.

The other one wasn't that usual, and as long as no one can explain it to med I'll treat it as a bug in PHP/HTML.

I tested all the values like this
if(!empty($_REQUEST['Param_1'])){
$param_1 = $_REQUEST['Param_1'];
}

Here's the problem, if "$_REQUEST['Param_1']" holds a valid value of zero (0) the above will evaluate it as empty...

If you test it like this: if($_REQUEST['Param_1'] == "0") you will be ok.

How is that for interesting behaviour!

My problem is solved and something is learned, but I'd really like to know if this is normal behaviour for empty()

/Dan


{cell 260}
-{ a vibration is a movement that doesn't know which way to go }-

This is taken from PHP manual:

empty("0")

The perhaps most controversial change in behavior has happened to the behavior of the empty(). A String containing only the character '0' (zero) is now considered empty while it wasn't in PHP 3.

This new behavior makes sense in web applications, with all input fields returning strings even if numeric input is requested, and with PHP's capabilities of automatic type conversion. But on the other hand it might break your code in a rather subtle way, leading to misbehavior that is hard to track down if you do not know about what to look for.

Link: http://www.php.net/manual/en/migration4.empty.php

So, this behavior is not a bug, it's a feature...

Thanx mr.Max, I got that from the GN as well.
Personally I think that this little snip:

quote:

---

This new behavior makes sense in web applications, with all input fields returning strings even if numeric input is requested, and with PHP's capabilities of automatic type conversion...

---

doesn't agree with me, at all...
A string with the value of "0" is not empty, its just 0 no more no less.
So if I know that everything from $_POST, $_GET, $_REQUEST is strings and 0 is a valid string and I choose to set the types manually for control, this really fucks up my day...

Ah well, lesson learned and will not be forgotten.
Thanx/Dan

{cell 260}
-{ a vibration is a movement that doesn't know which way to go }-

if (isset($variableName)) {
perform;
} else {
dont;
}

Isn't it ???


Bug-free software only exisits in two places
A programmer's mind and a salesman's lips

Trib, Unfortunatley that wasn't enough for us, we had to validate/set the type of the value as well (lot's of different logic that uses it further "down") in order for every thing to work.
/Dan


{cell 260}
-{ a vibration is a movement that doesn't know which way to go }-

Dan .. I guessed your problem was a little less trivial than my reply indicated, but isset() as a replacement for !empty() was what I was trying to indicate ... actually I can't ever remember using empty() to test a variable, and isset() always comes up with the goods for me ...


Bug-free software only exisits in two places
A programmer's mind and a salesman's lips

yeah, isset() && is_numeric() for numbers, isset() && is_numeric() && intval() for integers,
trim() != '' for strings... that's what I usually use.