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

go to bug id or search bugs for

Bug #17088 GET/POST variables not registered
Submitted: 2002-05-08 05:26 UTC Modified: 2002-12-22 01:00 UTC
Votes:6
Avg. Score:4.0 ± 1.5
Reproduced:6 of 6 (100.0%)
Same Version:1 (16.7%)
Same OS:1 (16.7%)
From: oliver dot drexler at gmx dot net Assigned:
Status: No Feedback Package: Scripting Engine problem
PHP Version: 4.2.0 OS: WindowsXP Pro
Private report: No CVE-ID: None
View Developer Edit
 [2002-05-08 05:26 UTC] oliver dot drexler at gmx dot net 
Since upgrading to 4.2.0 the variables from forms/URLs are not registered anymore.

for example URL: http://somehost/test.php?xy=12345&xyz=abc

Result: The $_GET, $_POST, $_REQUEST, $HTTP_*_VARS arrays are all empty.

When switching back to 4.1.1 WITH THE SAME PHP.INI FILE (the one that came with 4.2.0) all works fine. Switching back to 4.2.0, arrays are empty.

System:
WinXP Pro
Xitami v2.5b5
PHP 4.2.0, precompiled version from PHP.NET
register_globals OFF (need it that way for security reasons)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-05-08 05:27 UTC] derick@php.net 
In PHP 4.2.0, the 'register_globals' setting default changed to
be off. See http://www.php.net/release_4_2_0.php for more info.
 [2002-05-08 05:28 UTC] derick@php.net 
Oops... I should read the report before replying :)
 [2002-05-08 05:30 UTC] imajes@php.net 
this is the second such xitami bug report.

Oliver: is there a reason for using Xitami?
 [2002-05-08 05:30 UTC] mfischer@php.net 
You are using the CGI version, right?
 [2002-05-08 09:01 UTC] mfischer@php.net 
oliver.drexler@gmx.net: Yes, I'm using the CGI version

My comment: It seems Xitami has server problems adhering to the CGI standard. I suggest either consulting some Xitami related Newsgroups or change the Webserver.

Suspending for now.
 [2002-05-08 09:50 UTC] oliver dot drexler at gmx dot net 
If that problem is a Xitami problem I wonder why it worked fine with PHP4.1.1 ...
 [2002-05-08 10:06 UTC] mfischer@php.net 
Good point.

Whatever it is, it seems no one with enough knowledge cares about it and steps forward and starts digging where the problem is.
 [2002-05-09 20:14 UTC] php at littauer dot com 
Please see also bug # 16848 with similar difficulty running on Linux. Also note that I have this problem on OmniHTTPd on Windows 98 (which I tried after the above comment on Xitami).

With similar problems on 2 operating systems and 3 servers it looks to me like either a real PHP problem or a configuration error of some kind.
 [2002-05-10 08:09 UTC] php at littauer dot com 
... and the answer is: COnfiguration error.

While struggling with the cgi.force_redirect I had started using the command-line version to parse .php files. Obviously enough there were no entries in $_GET, $_POST et al.

Since there were at least 3 of us Bozos who did that, perhaps it's worth a mention in the documentation or FAQ.
 [2002-12-06 19:33 UTC] sniper@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip
 [2002-12-06 19:34 UTC] sniper@php.net 
Should have added that there were some fixes made for CGI just recently that might fix this too..
 [2002-12-22 01:00 UTC] php-bugs at lists dot php dot net 
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2003-01-22 06:44 UTC] Ken dot Coar at Golux dot Com 
Using 4.4.0-dev as a CGI, I am seeing this as well.  Dumping the various variables indicates this is a PHP bug:

From var_dump($GLOBALS):

  ["REQUEST_METHOD"]=>
  string(3) "GET"
  ["QUERY_STRING"]=>
  string(31) "url=foo&title=bar&blog_name=bag"
  ["REQUEST_URI"]=>
  string(53) "/blog/trackbackto.cgi?url=foo&title=bar&blog_name=bag"
  ["HTTP_POST_VARS"]=>
  array(0) {
  }
  ["_POST"]=>
  array(0) {
  }
  ["HTTP_GET_VARS"]=>
  array(0) {
  }
  ["_GET"]=>
  array(0) {
  }

I am using PHP built from CVS as of some time during 4.4.0-dev, on RedHat Linux 7.2, with Apache 1.3.27.  I am now rebuilding PHP from CVS HEAD to see if there's any change.
 [2003-01-22 06:57 UTC] Ken dot Coar at Golux dot Com 
Curiously enough, and I don't know if it's related, but my Header('content-type: text/xml') wasn't processed.  I had to explicitly 'print "content-type: text/xml\r\n\r\n"' to get the header emitted.  Right now CVS HEAD isn't building with a '/ext/standard/basic_functions.c:2827: `ZEND_INI_PARSER_POP_ENTRY' undeclared (first use in this function)' but I'm working on that.  (Last time this happened I had to re-checkout the source tree, which indicates that 'make clean' is missing something..)
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sat Oct 25 08:00:01 2025 UTC