GET/POST array handling (was [PATCH] Deprecate use of stdio)

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

« previous php.internals (#1219) next »