php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
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 Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: oliver dot drexler at gmx dot net
New email:
PHP Version: OS:

 

 [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

Add a Patch

Pull Requests

Add a Pull Request

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-2017 The PHP Group
All rights reserved.
Last updated: Sun Nov 19 01:31:42 2017 UTC