Bug 25476 - Form data altered with multipart/form-data uploads
Summary: Form data altered with multipart/form-data uploads
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: AfterStep   
(Show other bugs)
Version: 7.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-02-01 14:47 UTC by tyler
Modified: 2007-04-18 16:31 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-02-02 06:09:55 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
SquirrelMail 1.0 (in case the web site doesn't have it) (410.42 KB, application/octet-stream)
2001-02-01 14:49 UTC, tyler
no flags Details

Description tyler 2001-02-01 14:47:26 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.08 [en] (Win98; I ;Nav)

When submitting form data in a [multipart/form-data] form from some browsers (not all?  Konqueror 2.1beta2, Netscape 4.76 will do 
it for sure), an extra newline is placed before all incoming data.  So, if your php script is called with <input type=text name=test 
value="123">, the php script will be handed $test = "\r\n123".  (not sure if it is \r\n or \n\r -- I know the hex is 0x0D then 0x0A.

You can probably test this with a smaller example than the one I will illustrate below (like a simple php script that takes a couple 
parameters and a file, and is set to multipart/form-data).  However, I am sure the one below will produce errors.

To illustrate the problem on your own machine, simply install PHP 4.04pl1-3, then go to http://www.squirrelmail.org and download 
version 1.0.  Install it, set it up, and try to send a message.  If only 1.0.1 is out, you can use that too.  Just install 1.0.1, set it up, 
then edit compose.php and look for a section labeled "Workaround for RedHat PHP 4.0.4pl1-3" and just comment it out.  That 
should make the error appear again.

The compose form will try to send itself data (because the compose form shows the form and also has the sending functionality 
in), then forward to the message list.  Somewhere in there, the $mailbox you are viewing get changed to have the "\r\n" in front.

Here is a report from someone else that might provide more insight:
Once again, I get this WEIRD "SELECT" error for SquirrelMail 1.0pre1, 1.0pre2, and 1.0 (I skipped 1.0pre3 and do not get the 
CVS) only if and only if I use Red Hat's RPM of PHP 4.0.4pl1-3. When I uninstall the PHP RPM and install it straight from the PHP 
source for 4.0.4pl1, the problem goes away.  Just to be sure, I then installed the RPM
again and saw the problem return.  I am not sure which part of PHP could be causing this, so I am not sure where to look for 
differences. I am running Red Hat 7.0 w/all updates (except for PHP), just like Gary MacKay was.  This problem is not browser 

And another message:
I spent the past few hours debugging the weird errors some people are recieving when sending messages.  Luckily my roommate is 
getting these errors (Konq 2.1beta2), so I have a good test platform to fix this.  Below is what I found.

The problem lies in our form tag friend: ENCTYPE="multipart/form-data".  If you remember, this past summer I had all kinds of 
trouble with Netscape and this form parameter.  Anyway, when I sniffed the traffic from my browser (which sends correctly) and my 
roommate's (doesn't send), the exact same form data is being sent, so that part is fine.

However, directly after the form is submitted, the variables as rendered by PHP are different (even though the form data is the 
same).  From Konq, every entry has extra whitespace (new lines) at the end.  Through Netscape, it doesn't. I have narrowed the 
problem down as far as I know how, and the only layer between them now is PHP.  The only thing I can think of is that PHP 
doesn't like Konq's response and adds newlines to the variable.

As a fix, I took those variables and am trimming them.  There are 6 or 7 of them, so it isn't all that bad.  There is nothing else I know 
to do.  It's not too bad, really, and at least we don't have to make special cases for browsers (which I am adamently against).

So, please check out CVS and see if this fixes your problems.  Thanks for bearing with us.   Sorry for all the problems!!  Let me 
know if this fixes the problem so we can release 1.0.1 ASAP.

Reproducible: Always
Steps to Reproduce:
1.  Install RedHat 7 with PHP 4.0.4pl1-3
2.  Install SquirrelMail 1.0 (see above if you need 1.0.1)
3.  Use (unsure about which) a browser to try to send a message.
4.  When you hit send, the data from the compose form is fed back into compose.php.
5.  Compose.php sees the data all with a newline at the beginning.  It might be \n, or \r\n (not sure about which -- might be platform 
6.  When Compose.php is done sending the message, it tries to redirect you automatically to the message list.  At this time, 
$mailbox is already corrupted.

Actual Results:  Going into PHP:
<input type=text name="mailbox" value="INBOX">
Coming out of PHP and going into the script:
$mailbox == "
INBOX"; // note the newline

Expected Results:  Uh, no newline at the beginning of form entries.

Allegedly some browsers work and some don't.  That is the part that really gets me.  Konqueror and Netscape (versions above) 
seem to report the error.

My system doesn't show the error (not running RedHat), but this seems to be a pretty nasty bug if it is PHP's fault.

Comment 1 tyler 2001-02-01 14:49:53 UTC
Created attachment 8641 [details]
SquirrelMail 1.0 (in case the web site doesn't have it)

Comment 2 Nalin Dahyabhai 2001-02-02 06:09:50 UTC
We've seen some problems with 4.0.4pl1-3, and currently have another errata
candidate in http://people.redhat.com/nalin/test/ that will probably fix it. 
Please try it out and let me know if it fixes this either in this bug ID or
under #24933, which is where I'm tracking this particular bug.


Comment 3 tyler 2001-02-02 23:21:20 UTC
The new PHP 4.0.4pl1-5 candidate seems to work.  Not positive, but will post to other bug report if more errors occur.

Thanks for the quick reply!

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