Bug 85386 - Redhat 8.0's apache has post irregularities
Redhat 8.0's apache has post irregularities
Status: CLOSED DUPLICATE of bug 82967
Product: Red Hat Linux
Classification: Retired
Component: php (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2003-02-28 17:43 EST by Jesse Thompson
Modified: 2007-04-18 12:51 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 13:52:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
This is the http.conf on my machine, sensitive info [snip]ped out (35.41 KB, text/plain)
2003-04-23 10:33 EDT, Jesse Thompson
no flags Details
php.ini from my system (36.92 KB, text/plain)
2003-04-23 10:34 EDT, Jesse Thompson
no flags Details

  None (edit)
Description Jesse Thompson 2003-02-28 17:43:38 EST
Description of problem:
Red hat distributes Apache Webserver 2.0.40 with Redhat 8.0, and has not 
released a newer version in it's updates. This version of apache (perhaps in 
concert with PHP 4.2.2, also distributed in RH8.0 updates) appears to have a 
bug in how it handles POST requests. In particular, the content of the post 
request (which takes the form "key1=val1&key2=val2..", I believe) appears to 
be chopped up randomly and rearranged before PHP parses the values out. Thus, 
incoming variables take on values like:

echo "text= '$text'";
'Here is somtext=Here is some example text'

(in real examples, this may take several hundred characters to replicate)

This was discussed in PHP's bug list, (PHP BUG #18648, 
http://bugs.php.net/bug.php?id=18648 ) appears to be an apache bug, and they 
report that the latest build of apache (2.0.44) seems to fix the problem. The 
last comment confirms that RH8.0 ships with 2.0.40, and that someone should 
notify RedHat. (I venture this is the appropriate place :)
I've searched apache's bug list and found no substantial counterpart, but 
apache doesn't recommend posting bugs on software versions they do not 
consider "up to date". See apache bug #15808, 
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15808 for an example of this 

I'd recommend either releasing a newer version of apache in updates, or a new 
patchlevel for 2.0.40 addressing this issue. (I'm not really a packager, but I 
play one on tv :)

Version-Release number of selected component (if applicable):
httpd 2.0.40-11, tested against php 4.2.2-8.0.7

How reproducible:

Steps to Reproduce:
1. build a simple web form with a textarea element (lets say it's named "foo") 
and a submit button, that submits using POST method.
1a. To aid reproduceability, make sure the textarea is the only named form 
element, no name for the submit button.
1b. Some people have suggested that multiple named form elements either make 
the bug go away or else make it harder to spot (corrupting variables you don't 
use), either way diminishing reproduceability
2. in response page, using php, <? print_r($_POST) ?>
2a. Some have reported php_info() confirms the error when it dumps incoming 
POST values, I haven't tried that.
3. Enter several kilobytes of data, just to be sure, into the text area and 
submit the form.
Actual results:
PHP will report that $_POST['foo'] contains a value with portions copied and 
spliced around, perhaps delimited by "foo=".

Expected results:
PHP should report that $_POST['foo'] matches your input text, give or take the 
effects of magic quotes and the like.

Additional info:
Fair discussion of the problem:
PHP BUG #18648, http://bugs.php.net/bug.php?id=18648
I've added a bug note in apache's bugzilla just in case:
Apache bug #17549
Comment 1 Joe Orton 2003-04-02 11:13:39 EST
Can you attach your httpd.conf and php.conf?  Previous reports of this have been
due to a configuration error: adding an AddType for PHP, alonside the <Files
*.php> section in php.conf
Comment 2 Jesse Thompson 2003-04-23 10:33:12 EDT
Created attachment 91245 [details]
This is the http.conf on my machine, sensitive info [snip]ped out
Comment 3 Jesse Thompson 2003-04-23 10:34:06 EDT
Created attachment 91246 [details]
php.ini from my system
Comment 4 Jesse Thompson 2003-04-23 10:51:39 EDT
$%&@, I'm sorry. I attached the http.conf and php.ini from the machine we were 
having troubles with, but we've already reinstalled that machine with FreeBSD 
so those files won't directly apply :(

They might be of some help, all of our unconventional settings are in them at 
least. Actually, if you can adapt those configuration files to work on an out-
of-the-box copy of Redhat 8.0 (and probably 9.0 if you haven't 
upgraded/patched php or apache) then you should be running a nearly perfect 
functional replica of our affected machine at the time.

As you can see, we don't have a <Files *.php> section, and we AddType for some 
file masks other than *.php, but all of my test files were simple php files.

Adtly, of course, <Files..> and Addtype are directives in httpd.conf, not 
php.ini :)

Moving our stuff to a FreeBSD machine with Apache 2.0.44 and php 4.3.1 
resolved the issue for us.

In the meantime, I remain curious why Redhat always sees fit to package 
software so old that the makers of the software generally refuse to support 
it? As the packager, you shouldn't have to try and track down software bugs 
like this (quite slowly mind you, while your customers all switch 
distributions ;) when you can simply keep up to date instead and let the 
software developers field the bug reports.

It's one thing if you'll hang back a major revision to avoid experimental 
code, but the third digit in a version number (2.0.40 vs 2.0.44) represents 
bug *fixes* for crying out loud :P
Comment 5 Simon Ilyushchenko 2003-05-12 13:32:58 EDT
Similar problem exists with apache and mod_perl in 9.0. Specifically, if the
POST data is sent in more than one TCP packet, only the contents of the first
packet is read from STDIN. I verified that if I read STDIN manually, all the
data are there. However, if I use CGI.pm to read STDIN, it eventually calls the
perl read() functions, which apparently misbehaves.

After installing from source mod_perl-1_99-09 and httpd 2.0.45 the problem went
away, which suggests that perl itself is not to blame, because the same Redhat
version of perl was used.

I think this is a very serious problem and should be solved asap.
Comment 6 Bostjan Lah 2003-05-25 11:08:10 EDT
Same problem here: mod_perl + httpd on both Red Hat Linux 8.0 and 9. Any
workaround (apart from using GET instead of POST)?
Comment 7 Joe Orton 2003-06-19 06:41:50 EDT
There can be problems using POST if configured using an "AddType" *and*
SetOutputFilter - this is covered in bug 82967.  If mod_perl suffers from
similar problems, please file bugs against mod_perl.

*** This bug has been marked as a duplicate of 82967 ***
Comment 8 Red Hat Bugzilla 2006-02-21 13:52:02 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.