|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #18648 Single entry form POST gives incorrect variable content
Submitted: 2002-07-30 09:37 UTC Modified: 2003-02-07 21:50 UTC
Avg. Score:4.9 ± 0.2
Reproduced:16 of 16 (100.0%)
Same Version:12 (75.0%)
Same OS:12 (75.0%)
From: ms at ecs dot soton dot ac dot uk Assigned:
Status: Not a bug Package: Apache2 related
PHP Version: 5CVS-2003-01-29 (dev) / 4CVS-20020121 (stable) OS: All
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
47 - 27 = ?
Subscribe to this entry?

 [2002-07-30 09:37 UTC] ms at ecs dot soton dot ac dot uk
When submitting a form with one field via post the variable contents gets mangled...

*** foo.html ***
<form action="test.php" method="post">
        Test: <input type="text" name="id" value="bar">
        <input type="submit">

*** test.php ***
<?php print_r($_POST); ?> 

*** output ***
    [id] => barid=bar

This bug can also be detected up by submitting the page
to a phpinfo().

Compiled under Tru64 5.1 using both Compaq and Gnu cc & make.   Have tested using PHP 4.2.2 / Apache 2.0.39 and Apache 2.0.40 / PHP 4.3.0-Dev (200207100600 snapshot).

Configure Line:
./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql

Bug appears to be limited to Tru64, as if I POST the data to a separate linux machine running 4.2.2/2.0.39 then it works fine.

If I have more than one field in the form then everything is fine, or if I use GET instead of POST then it also works.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2002-08-15 07:15 UTC]
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.

 [2002-08-15 23:09 UTC]
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.
 [2002-12-02 07:51 UTC] jorton at redhat dot com
I can't reproduce this problem using identical RPMs on Red Hat Linux 8.0 - this bug seems hard to trigger. - 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  <>
    * 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.
 [2002-12-06 11:26 UTC] 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 if you can read Japanese.

[Report #2: RHLinux 7.2 / Apache 2.0.43 / PHP-4.3.0RC2]
"form post results in duplicitous $_REQUEST"

 [2002-12-06 11:30 UTC]
Oops, I should have meant php_strtok_r() replaces the delimiter "=" by
 [2002-12-09 12:48 UTC]
Please try using this CVS snapshot:
For Windows:

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).
 [2003-01-05 16:48 UTC]
Related bug:

 [2003-01-20 20:24 UTC] laday at chollian dot net
It works fine with 

<form ... enctype="multipart/form-data">
 [2003-01-21 04:20 UTC] szabo_a at interware dot hu
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.
 [2003-01-29 10:01 UTC] rep at devdomain dot com
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.
 [2003-01-30 03:25 UTC]
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?

 [2003-01-30 03:45 UTC] rep at devdomain dot com
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.
 [2003-01-30 03:46 UTC] rep at devdomain dot com
Not a single 'BUG' entry on the logs, grep'ed all of them.
 [2003-01-30 03:52 UTC], Thank you for the info!

Okay, updating version.

 [2003-01-31 19:52 UTC] marvel at herzen dot spb dot ru
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 ?
 [2003-02-03 11:55 UTC] rep at devdomain dot com
array(4) {
  string(1) "1"
  string(1) "2"
  string(1) "1"
  string(1) "2"

From the latest snap's (php4-STABLE, php5). cvs commit (?) :)
 [2003-02-03 12:36 UTC]
I can _NOT_ reproduce this with Apache 2.0.44 and PHP 4.3.1-dev..

 [2003-02-04 09:16 UTC] r dot cruces at alcorce dot com
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.
 [2003-02-04 15:05 UTC]
[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

 [2003-02-04 20:49 UTC] laday at chollian dot net
Thanks... It works ok.
 [2003-02-07 21:50 UTC]
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.)

 [2003-02-20 09:43 UTC] apiset at hotmail dot com
The default httpd configuration on RH8.0 use

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

so is this RedHat fault? I replace above lines with

AddType application/x-httpd-php .php

and it works!!!

should tell redhat about this
 [2003-03-05 07:32 UTC] jorton at redhat dot com
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.
 [2003-05-04 08:36 UTC] anrdaemon at mtu-net dot ru
Thanx to
/me stupid...

AddInputFilter PHP .php

solves all problems.
 [2003-07-20 12:57 UTC] vesely at tana dot it
For completeness, I'd like to mention that
the setting suggested

> [4 Feb 3:05pm CST] 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
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Thu Mar 30 06:03:41 2023 UTC