Bug 25831 - Content type added to uploaded file in php-4.0.4pl1
Content type added to uploaded file in php-4.0.4pl1
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: php (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Phil Copeland
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-02 21:14 EST by Need Real Name
Modified: 2007-04-18 12:31 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-02-28 14:18:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2001-02-02 21:14:27 EST
When uploading a file from the web-browser, the destination file is longer 
than the source file and contains 2 extra lines at the top. The first line 
looks something like "Content-Type: image/pjpeg". The second line is 
blank. The _type variable is empty.

Reproducible: Always

Steps to Reproduce:

The following script (upload.php) illustrates the problem:

<HTLM><BODY>
<FORM ENCTYPE="multipart/form-data" ACTION="upload.php"
METHOD=POST>
<INPUT TYPE="hidden" name="MAX_FILE_SIZE"
value="100000">
Send this file: <INPUT NAME="userfile" TYPE="file">
<INPUT TYPE="submit" VALUE="Send File">
</FORM>
<?
echo "\$userfile=".$userfile."<br>";
echo "\$userfile_name=".$userfile_name."<br>";
echo "\$userfile_size=".$userfile_size."<br>";
echo "\$userfile_type=".$userfile_type."<br>";
echo "is_uploaded_file=".is_uploaded_file($userfile)."<br>";
copy($userfile, "testfile");
?>
</BODY></HTML>


Actual Results:  

Here is the output produced for a sample jpeg of 41052 bytes:

$userfile=/tmp/phpHaOmjN
$userfile_name=J0144216.JPG
$userfile_size=41081
$userfile_type=
is_uploaded_file=1

As you can see, the file is 29 bytes longer than it should be...

Here is what I get when pressing the "send file" button without specifying 
a filename:

$userfile=/tmp/phpJryFlz
$userfile_name=
$userfile_size=42
$userfile_type=
is_uploaded_file=1

The file "uploaded" looks like this:
*** cut here ***
Content-Type: application/octet-stream

*** cut here ***


Expected Results:  A shorter file in the first example. "none" in the 
second example.

Using RedHat 7 with all the latest updates available from "up2date -u". 
php.ini as installed with the package. Upload worked before I updated to 
php-4.0.4pl1-3.rpm. 

(As you can probably guess, I am no PHP expert. But as far as I can see, 
it should not behave like this?)

Svein Roar
Comment 1 Nalin Dahyabhai 2001-02-02 21:49:42 EST
We're currently tracking form-parsing bugs in bug #24933.  There is an errata
candidate in http://people.redhat.com/nalin/test/ which fixes the problems that
I can verify and reproduce.  Please try them and either follow up under this bug
ID or under #24933.  Thanks!
Comment 2 Need Real Name 2001-02-03 08:13:57 EST
I'm sorry! I tried searching for my bug, but did not find it.

And yes, the version found under /nalin/test solved my problem! So I guess you 
can close this one. 
Comment 3 Nalin Dahyabhai 2001-02-06 13:38:12 EST
Okay then.  I'll resolve it as an ERRATA when we actually push it out.

Thanks!
Comment 4 Gabriele Turchi 2001-02-22 05:32:16 EST
In php bug list (bugs.php.net, bug 9298) is reported the same bug, and the
poster report that the last CVS snapshot fixes the problem. I've tryed the
php-4.0.4pl1-5 rpm: now the file is uploaded correctly, but the content-type
variable is still empty.

Gabriele Turchi

P.S.: my english is alpha version...
Comment 5 Need Real Name 2001-03-08 13:25:33 EST
We're having hte same problems here.  Has anybody tried to strip the extra 
information from the file???

<a href="mailto:tporter@creativenet.net">tporter@creativenet.net</a>
Comment 6 Daniel Senie 2002-01-06 10:08:45 EST
Any news or action? We're in a holding pattern waiting for this fix before we 
can deploy some services. At this point, we're trying to decide whether to 
scrap use of PHP for new development and implement in Perl. While PHP 
simplifies things, it's useless to us due to this bug.

PLEASE provide some clue as to whether RedHat will be releasing a fix to this 
issue, and provide some sort of timeline. If there's no interest in fixing 
this, let us know that too. We'd just like to move forward one way or another.

For us, at least, this is a VERY HIGH priority issue, not merely an annoyance.
Comment 7 Daniel Senie 2002-02-28 14:18:29 EST
This bug, which languished for a year without being addressed, has now been 
cured by the errata fix RHSA-2002:035-13. Luckily someone found a bug requiring 
a security patch, and RedHat fixed the security problem by building versions of 
PHP for supported releases which is from a newer code base, and does not have 
this file upload bug in it.

Whomever is able to close this bug out, may want to do so, pointing at the new 
version now available.

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