Bug 72752 - URL parameters disappear if = is missing after parameter name
URL parameters disappear if = is missing after parameter name
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: php (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
David Lawrence
:
: 72551 72921 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-08-27 07:38 EDT by Steffen Furholm
Modified: 2007-04-18 12:46 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-25 11:47:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Steffen Furholm 2002-08-27 07:38:49 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; Crazy Browser 
1.0.5)

Description of problem:
Example:

  index.php?OpenDocument&ID=5

Then var_dump($_GET) or var_dump($HTTP_GET_VARS) shows that OpenDocument exists 
in the array, but ID does not. And $ID, $_GET["ID"] and $HTTP_GET_VARS["ID"] 
all return an empty string.

If you use the following it'll work:

  index.php?OpenDocument=&ID=5

(Adding = to the OpenDocument parameter)


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.index.php?OpenDocument&ID=5
2.var_dump($_GET);

3.index.php?OpenDocument=&ID=5
4.var_dump($_GET);


Actual Results:  All parameters after the one with the "missing" '=' disappears 
from the $_GET, $HTTP_GET_VARS arrays and from $ID (if register globals is on).

Expected Results:  $_GET["OpenDocument"] should be an empty string.
$_GET["ID"] should be the value "5".

Additional info:
Comment 1 Phil Copeland 2002-08-27 14:56:53 EDT

*** This bug has been marked as a duplicate of 72551 ***
Comment 2 Phil Copeland 2002-08-27 15:12:01 EDT
Argh wait this is for 7.2 not current beta.. sorry

Looking at this again
Comment 3 Phil Copeland 2002-08-27 16:01:45 EDT
Ok, lets have a look at the following screen cuts.

First off what level of php are we using...
[root@alpha root]# rpm -q php
php-4.1.2-7.2.4

Current errata for 7.2 good...
And we'll be using the following to dump out variables.

[root@alpha root]# cat /var/www/html/test.php 
<?php
reset($_GET);
var_dump($_GET);
?>

The test is to toggle register_globals=On/Off and note if there are any
differances when passing in a NULL variable 
ie
1 - http://localhost/test.php?a=1&b=2&c
2 - http://localhost/test.php?a=1&b=2&c=
3 - http://localhost/test.php?c&b=2&a=1
4 - http://localhost/test.php?c=&b=2&a=1

Results when register_globals=On (line 302 /etc/php.ini)
1 array(2) { ["a"]=>  string(1) "1" ["b"]=>  string(1) "2" }
2 array(3) { ["a"]=>  string(1) "1" ["b"]=>  string(1) "2" ["c"]=>  string(0) "" } 
3 array(2) { ["c"]=>  string(0) "" ["b"]=>  string(1) "2" }
4 array(3) { ["c"]=>  string(0) "" ["b"]=>  string(1) "2" ["a"]=>  string(1) "1" }

Results when register_globals=Off
1 array(2) { ["a"]=>  string(1) "1" ["b"]=>  string(1) "2" }
2 array(3) { ["a"]=>  string(1) "1" ["b"]=>  string(1) "2" ["c"]=>  string(0) "" }
3 array(2) { ["c"]=>  string(0) "" ["b"]=>  string(1) "2" } 
4 array(3) { ["c"]=>  string(0) "" ["b"]=>  string(1) "2" ["a"]=>  string(1) "1" } 

Thers actually no differance between register_globals=On/Off so thats a red
herring. On the more annoying side, though probably more sensible, variable
count is being calculated on the number of ='s (Note how a=1 drops off the
argument list when the first param has no '=' associated with it.)

Lemme see if ?var without an = is valid html


Comment 4 Phil Copeland 2002-08-27 16:11:32 EDT
Ok, so having asked around,
http://localhost/test.php?a
IS legal, however, HTML forms NEVER write ?a but rather ?a=

Strictly speaking, yes, this is a bug but it's not one thats likely to
obliterate php scripts from working as in normal operation html forms pass in
the '=' appended to undefined variables. I'm passing this upstream to the php folk.
Comment 5 Phil Copeland 2002-08-27 16:34:07 EDT
Kicked upstream as

http://bugs.php.net/bug.php?id=19131
Comment 6 Phil Copeland 2002-08-27 20:27:43 EDT
Reopening

Seems we need this little gem:
http://cvs.php.net/diff.php/php4/main/php_variables.c?r1=1.35.2.1&r2=1.38&ty=u&Horde=f49512db3e843ec2d787d53cd6ffa5a2

Phil
=--=
Comment 7 Phil Copeland 2002-08-27 21:31:19 EDT
... and some testing shows that this doesn't help things.. doh...
Comment 8 Phil Copeland 2002-08-27 22:07:52 EDT
..except their fix is buggy,.. NULL should be "" ...

fixing,..
compiling,..
testing,..

still craps out.
Humm, something else is amiss.

Phil
=--=
Comment 9 Phil Copeland 2002-08-28 17:16:33 EDT
.. and I see upstream has now said 'use latest cvs'...
bah...

Comment 10 Phil Copeland 2002-08-29 16:13:28 EDT
*** Bug 72921 has been marked as a duplicate of this bug. ***
Comment 11 Phil Copeland 2002-08-29 16:55:52 EDT
Latest cvs dies during compile...
waiting for next snapshot

Phil
=--=
Comment 12 Phil Copeland 2002-08-29 21:17:56 EDT
Ok so 4.3.0-dev (200208291500 cvs snapshot) seems to come through without too
much problems.

[root@alpha root]# ./test.php "&valueone=testone&valuetwo=testtwo&fred="
Status: 200
Content-type: text/html
X-Powered-By: PHP/4.3.0-dev

test1 = [testone]
test2 = [testtwo]
array(4) {
  ["_/test_php+"]=>
  string(0) ""
  ["valueone"]=>
  string(7) "testone"
  ["valuetwo"]=>
  string(7) "testtwo"
  ["fred"]=>
  string(0) ""
}

Now then,.. thers no way I'm going to ship 4.3.0-dev cvs snapshots in the dist.
Just ain't going to happen. So the question becomes what the heck changed that
makes it work, makes the diffs and shove it in an errata/upcoming release
(present in 4.2.2)

Phil
=--=


Comment 13 Phil Copeland 2002-08-30 14:38:28 EDT
Ok,.. after a lot of tinkering around, this looks related to --enable-mbstring
and --enable-mbstr-enc-trans being enabled during the build.

These were enabled to help support multibyte language entry but as it appears to
be broken, I think the correct action should be to remove them. By itself this
isn't actually enough. You also need this small patch to
php-4.1.2/main/php_variables.c


[root@alpha main]# diff -u php_variables.c.orig php_variables.c
--- php_variables.c.orig        Fri Aug 30 13:01:40 2002
+++ php_variables.c     Fri Aug 30 13:02:53 2002
@@ -297,6 +297,8 @@
                        php_url_decode(var, strlen(var));
                        val_len = php_url_decode(val, strlen(val));
                        php_register_variable_safe(var, val, val_len, array_ptr
TSRMLS_CC);
+               } else {
+                       php_register_variable_safe(var, "", 0, array_ptr TSRMLS_CC);
                }
                var = php_strtok_r(NULL, separator, &strtok_buf);
        }



All those in favor of removing the two compile options, and getting back to php
acknowledging all the variables passed to it, say 'aieee'

aieee!

Removed. Errata built, passed to QA for testing.

[root@alpha main]# ../php /root/test.php "&a=1&b=2&c"
X-Powered-By: PHP/4.1.2
Content-type: text/html

test1 = []
test2 = []
array(4) {
  ["/root/test_php+"]=>
  string(0) ""
  ["a"]=>
  string(1) "1"
  ["b"]=>
  string(1) "2"
  ["c"]=>
  string(0) ""
}
Comment 14 Phil Copeland 2002-08-30 16:16:39 EDT
Ah, forgot, and you'll need this as well for main/main.c

@@ -779,7 +779,9 @@
                int i;
 
                for (i=0; i<NUM_TRACK_VARS; i++) {
-                       zval_ptr_dtor(&PG(http_globals)[i]);
+                       if (PG(http_globals)[i]) {
+                               zval_ptr_dtor(&PG(http_globals)[i]);
+                       }
                }
        } zend_end_try();
Comment 15 Phil Copeland 2002-08-31 02:36:37 EDT
Queued up for errata

4.1.2-2.1.5 - Advanced Server
4.1.2-7.0.5 - 7.0
4.1.2-7.1.5 - 7.1
4.1.2-7.2.5 - 7.2
4.1.2-7.3.5 - 7.3

Rawhide
4.2.2-8.0.1 - 8.0
Comment 16 Phil Copeland 2002-08-31 02:39:43 EDT
*** Bug 72551 has been marked as a duplicate of this bug. ***
Comment 17 Joe Orton 2002-09-26 04:49:23 EDT
Leaving this open whilst an errata is still pending.
Comment 18 P Fudd 2004-01-16 17:00:35 EST
Was this ever fixed?
Comment 19 Joe Orton 2005-01-25 11:47:18 EST
Thanks for the report.  This is a mass bug update; since this release
of Red Hat Linux is no longer supported, please either:

a) try and reproduce the bug with a supported version of Red Hat
Enterprise Linux or Fedora Core, and re-open this bug as appropriate
after changing the Product field, or,

b) if relevant, try and reproduce this bug using the current version
of the upstream package, and report the bug upstream.

c) report the bug to the Fedora Legacy project who may wish to
continue maintenance of this package.

Note You need to log in before you can comment on or make changes to this bug.