Common for both cases seems to be Apache2..please try with Apache 1.3.26 (and the latest snapshot from today, url above). Apache2 support is experimental btw.

Tested this with latest snapshot and Apache 1.3.26 on Tru64, seems to work fine. So Jani might be right with his Apache2-Guess.

I can't reproduce this problem using identical RPMs on Red Hat Linux 8.0 - this bug seems hard to trigger. 

hholzgra@php.net - any further insight would be appreciated. I can't find anything on the CVS logs about fixes for Tru64.  There is one fix to main/php_variables.c: 

2002-09-07  Yasuo Ohgaki  <yohgaki@ohgaki.net>
...
    * main/php_variables.c: Fixed POST/GET/COOKIE var handling

but this seems to concern NUL-terminated strings in field values, unles I'm mistaken.

jorton@redhat.com: IMO the change you pointed out has nothing to do with this problem because the leading php_strtok_r() replaces delimiter "=" by " ".

By the way I suspect this problem is an apache2 bug, not a php one though I wasn't able to reproduce this problem. I have received two similar PR, of which both reporters use Apache2.

[Report #1: RHLinux 8.0 / Apache 2.0.43 / PHP-4.3.0RC1]
This was reported in the Japanese PHP users' list. Please refer to http://ns1.php.gr.jp/pipermail/php-users/2002-November/011656.html if you can read Japanese.

[Report #2: RHLinux 7.2 / Apache 2.0.43 / PHP-4.3.0RC2]
"form post results in duplicitous $_REQUEST"
http://bugs.php.net/20823

Oops, I should have meant php_strtok_r() replaces the delimiter "=" by
"\0".

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

Small note for win32 users, the snapshot containing this patch will not be avaliable for a few hours (1 hour for latest CVS, 7 hours for STABLE).

Related bug: http://bugs.php.net/21441

It works fine with 

<form ... enctype="multipart/form-data">

Same problem with the latest version of PHP (4.3.1-dev). The hidden variable helps, but sometimes the variables get corrupted this way, too. So this is not a reliable solution at all.

apache 2.

when you post raw data it gets duplicated too, but it's not constant: on two hosts with rh8/4.2.2 (and 4.3.0 tested as well) only one seems to do the duplication.
The one that duplicates has an up2dated httpd, so apache version might have something to do with it.

I'm not sure, but I guess this problem is caused by the bug gy Apache2 filter code. Is there anyone who found some strange entries that begin with "* BUG *" in the error logs when running the server with the latest snapshot of PHP?

Tested today with snapshot 5-200301291430: post duplication bug continues.
I believe the bug is really a matter of duplication of the post: simple vars are overriden, arrays get duplicated, raw data gets duplicated.

Not a single 'BUG' entry on the logs, grep'ed all of them.

rep@devdomain.com, Thank you for the info!

Okay, updating version.

Have Apache/2.0.44 (RedHat8.0 (LastUpdates) mod_ssl/2.0.44 OpenSSL/0.9.6b PHP/4.3.0

Starting Apache answers - 
[root@delta bin]# httpd -DSSL
httpd: module "/usr/src/php-4.3.0/sapi/apache2filter/sapi_apache2.c" is not comp
atible with this version of Apache.
Please contact the vendor for the correct version.

Where troubles ?

array(4) {
  [0]=>
  string(1) "1"
  [1]=>
  string(1) "2"
  [2]=>
  string(1) "1"
  [3]=>
  string(1) "2"
}

From the latest snap's (php4-STABLE, php5). cvs commit (?) :)

I can _NOT_ reproduce this with Apache 2.0.44 and PHP 4.3.1-dev..

Tested in RH8.0 + PHP 4.2.2 + Apache 2.

- Is ok when you add the 'enctype="multipart/form-data"' propety to the form tag.
- Is ok when you send using GET method instead POST.
- Is ok when you send more than one field: if you have a text and a button, if you send it pressing enter only the text send and the problem occurs. When you press the button, text and button are send and the problem not occur.
ciao.

[To anyone who experiences this trouble]

Are you sure that your httpd.conf has just A SINGLE KIND OF PHP RELATED DIRECTIVE?

Then try grep "\(OutputFilter\|InputFilter\|AddType\)" < httpd.conf or whatsoever.

# bad example (a)
AddInputFilter PHP php
AddOutputFilter PHP php

...

AddType x-httpd-php .php

# bad example (b)
SetInputFilter PHP
SetOutputFilter PHP

...

AddType x-httpd-php .php

# not bad (c)
AddInputFilter PHP php
AddOutputFilter PHP php

# good (d)
AddType x-httpd-php .php

Thanks... It works ok.

First I made a typo in my previous comment.

I mean "application/x-httpd-php" everywhere I wrote "x-http-php".

Anyway let me mark this as bogus...
(The problem turned out to be a user fault.)

The default httpd configuration on RH8.0 use

<Files *.php>
    SetOutputFilter PHP
    SetInputFilter PHP
    LimitRequestBody 524288
</Files>

so is this RedHat fault? I replace above lines with

AddType application/x-httpd-php .php

and it works!!!

should tell redhat about this

The default configuration in Red Hat Linux has only the <Files *.php*> section.  This bug appears to occur if the "AddType x-httpd-php .php" is added *as well* as the <files  *.php> section.

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=76559

Thanx to moriyoshi@php.net
/me stupid...

AddInputFilter PHP .php

solves all problems.

For completeness, I'd like to mention that
the setting suggested

> [4 Feb 3:05pm CST] moriyoshi@php.net wrote
>
> # good (d)
> AddType application/x-httpd-php .php

works owlright except that if a request for xxx.php
arrives w/o extension like

   GET /xxx HTTP/1.1
   Accept: text/*

Apache responds "406 Not Acceptable" and lists
xxx.php as a possible alternative of MIME type
application/x-httpd-php. If the "Options MultiViews"
is in effect, Apache serves xxx.php when that is
the shortest (or only) choice.

Adding a "MultiViewsMatch Handlers Filter" or
renaming to xxx.html.php don't help. I think we need
to use PHP as a filter; 4.3.2 mentions having set a
new handler but doesn't say this bug is closed.

BTW, what's the reason why we "Do not use Apache 2.0
and PHP in a production environment neither on Unix
nor on Windows."? (That warning comes from
http://www.php.net/manual/en/install.apache2.php)