php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #30523 _GET bug with null last var persists
Submitted: 2004-10-21 23:19 UTC Modified: 2004-11-06 23:46 UTC
From: support at ruishi dot info Assigned:
Status: Not a bug Package: URL related
PHP Version: 4.3.9 OS: Linux SUSE
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: support at ruishi dot info
New email:
PHP Version: OS:

 

 [2004-10-21 23:19 UTC] support at ruishi dot info 
Description:
------------
The bug described earlier in http://bugs.php.net/bug.php?id=28221 by some sir else still persists in PHP-4.3.9, Suse Linux. The problem is:

The request "page.php?var1=a&var2=b&var3=c" sets the $_GET array correctly, but a slightly different request "page.php?var1=a&var2=b&var3=" with a null $var3 will make the whole $_GET array null!

A live demo can be found at:

Everything is fine with Link 1: http://www.ruishi.info/forum/testwindnumeric.php?tid=123&a=1&b=2&c=3

Then $_GET becomes null is the last variable $c is null in Link 2:
http://www.ruishi.info/forum/testwindnumeric.php?tid=123&a=1&b=2&c=




Reproduce code:
---------------
$tid=<?=$_GET['tid']?><br>
<?php
require_once('./testglobal.php');
echo "$tid<br>";
echo $_GET['tid'];
echo "\$_GET=";
print_r($_GET);
echo "<br>";
if(!is_numeric($_GET['tid'])) echo('invalid id number');
?>

In testglobal.php, the related sections:

print_r($_GET);
echo "<br>";

unset($GLOBALS,$_ENV,$HTTP_ENV_VARS,$_REQUEST,$HTTP_POST_VARS,$HTTP_GET_VARS,$HTTP_POST_FILES,$HTTP_COOKIE_VARS);
$Is_Gmqgg=get_magic_quotes_gpc();
if(!$Is_Gmqgg){
	Add_S($_POST);
	Add_S($_GET);
	Add_S($_COOKIE);
}
print_r($_GET);
echo "<br>";
......

Expected result:
----------------
For Link 1, the result is correct.
For Link 2, the correct result should be:

Array ( [tid] => 123 [a] => 1 [b] => 2 [c] => 3 )

Actual result:
--------------
For Link 2, the actual incorrect result is:

Array ( )

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-10-21 23:55 UTC] support at ruishi dot info 
A typo in the submission (in the section of Expected Result):

------
For Link 2, the correct result should be:

Array ( [tid] => 123 [a] => 1 [b] => 2 [c] => 3 )
------

should be:

Array ( [tid] => 123 [a] => 1 [b] => 2 [c] => NULL or ''?)
 [2004-10-22 00:57 UTC] scottm at spamcop dot net 
We've had customers with a similar issue but never found out the cause of it, we had null session paramaters in the query string if they were using cookies but for some reason or another some hosts just didn't work. We were never able to find out what caused this in the first place.

I've just searched through a few of the previous support tickets and they varied from PHP 4.3.1 to PHP 4.3.4. They all ran PHP as a CGI though.

Do you run PHP as a CGI?
 [2004-10-22 11:10 UTC] support at ruishi dot info 
in the output of phpinfo(), there does exist a line "Server API: CGI". I will check with our sysadmin to see if we can solve it by making it an Apache2 module. Stay tuned please. More comments and suggestions are welcome.
 [2004-10-28 22:28 UTC] support at ruishi dot info 
Hello, some investigation reveals that the hosting company has its reasons to run it using the CGI API, mainly because of the security related to multi hosting users. If PHP is run using the Apache API, then every hosting user can view other users' file (e.g. config files containing passwords).

This problem seems to have existed for extremely long time (several years), hope it wouldn't stay there forever... No guru could get rid of it?

Is there any way around? See, one normally has to host his files on an ISP's machine, but PHP is usually installed using the CGI API because of the security reason mentioned above. If $_GET does not work (probably other $_VARs as well), then most php scripts would be broken. How could the Web site survive?

Has anyone collected information about which OSes are free from this bug? SUSE seems to be problematic, how about debian and else?
 [2004-11-06 20:13 UTC] support at ruishi dot info 
It turned out to be a bug of suphp... After upgrading it to suphp-0.5.2, the problem is solved. Btw, I am running Apache2. No idea if it works for Apache1, however no wonder if it does.

This bug can be closed now. I suggest doing so, thanks.
 [2004-11-06 23:46 UTC] derick@php.net 
Not a bug in PHP -> bogus.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 12:01:31 2024 UTC