Re: GET/POST array handling (was [PATCH] Deprecate use of stdio)
| From: | Ilia A. | Date: | Sun, 04 May 2003 17:55:12 +0000 |
| Subject: | Re: GET/POST array handling (was [PATCH] Deprecate use of stdio) | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-1221@lists.php.net to get a copy of this message | ||
On May 4, 2003 01:27 pm, Rasmus Lerdorf wrote:
> 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.
IMO when the same variable is passed via GPC methods we should follow the GPC
order specified in the config and overwrite variables even if they are arrays
that if merged could potentially have stored both GET & POST data. The reason
is that when merged, it is impossible to tell where the data had come from,
unless the user begins to use the $_GET & $_POST auto-globals, which they
should have been using in the 1st place.
Ilia