GET/POST array handling (was [PATCH] Deprecate use of stdio)
| From: | Rasmus Lerdorf | Date: | Sun, 04 May 2003 17:27:08 +0000 |
| Subject: | GET/POST array handling (was [PATCH] Deprecate use of stdio) | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-1219@lists.php.net to get a copy of this message | ||
On Sun, 4 May 2003, Rasmus Lerdorf wrote:
> On Sun, 4 May 2003, Jani Taskinen wrote:
> > Anyway, after testing 4.2.3, it might be better to revert the 20796 fix
> > after all. It's less of PITA having them all in both POST/GET than
> > not having some at all in REQUEST nor in the global variable.
> >
> > Best of course would be if this was fixed properly.. :I
>
> I think Ilia's fix needs to stay in. It looks to me like the correct fix
> is to do an is_array() check on the symboltable2 assignment. If it is an
> array, then do a hash_find to see if it is already there. If it is, we
> add to that array, otherwise we just use the given zval as it is the first
> array element in that case.
>
> Ok, now to code my pseudo-code...
Looking at this in detail instead of just skimming it. I am not sure this
can be fixed while maintaining the concept of $_GET[foo][a] being a
reference to the global $foo[a] and $_REQUEST[foo][a].
Right now the way it works is that if we have foo array elements in both
GET and POST as per 23454 we basically create the array $_GET[foo] and
then do the API equivalent of $foo =& $_GET[foo]. Then when we parse the
POST data we create a new foo array in $_POST[foo] and once again do $foo
=& $_POST[foo] thereby losing the element we go from the GET data.
Now, if we reverse Ilia's patch and do all our work in the global symbol
table first, we have sort of the opposite problem. We end up creating the
global $foo array with both the GET element and the POST element in there
correctly. But then we do $_GET[foo] =& $foo and $_POST[foo] =& $foo so
both the GET and POST method arrays end up with the same elements even
though 1 element came from GET data and the other element came from POST
data. Hence the overwriting behaviour described in 20796.
Given how arrays don't have a distinct container that we can allocate and
assign a set of referenced elements to, I don't see a clean fix for this.
Right now we'd have to choose between the lesser of the two evils between
bug 20796 and 23454.
-Rasmus