|  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
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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
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.

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


Add a Patch

Pull Requests

Add a Pull Request


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

Oliver: is there a reason for using Xitami?
 [2002-05-08 05:30 UTC]
You are using the CGI version, right?
 [2002-05-08 09:01 UTC] 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]
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]
Please try using this CVS snapshot:
For Windows:

 [2002-12-06 19:34 UTC]
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):

  string(3) "GET"
  string(31) "url=foo&title=bar&blog_name=bag"
  string(53) "/blog/trackbackto.cgi?url=foo&title=bar&blog_name=bag"
  array(0) {
  array(0) {
  array(0) {
  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-2024 The PHP Group
All rights reserved.
Last updated: Mon Jul 15 01:01:27 2024 UTC