php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #2996 mime.c not parsing MIME headers properly
Submitted: 1999-12-18 04:48 UTC Modified: 2005-03-30 09:01 UTC
From: jeddings at jeddings dot com Assigned: hholzgra (profile)
Status: Wont fix Package: Parser error
PHP Version: 3.0.12 OS: Linux 2.2.5-15
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: jeddings at jeddings dot com
New email:
PHP Version: OS:

 

 [1999-12-18 04:48 UTC] jeddings at jeddings dot com
I'm using Perl's LWP and HTTP::Request::Common modules to POST a multipart/form-data form to upload a file to an Apache 1.3.6/PHP 3.0.12 web server.

The problem comes when PHP goes to MIME unencode the POST.  mime.c's php3_mime_split function looks for one of four things to be in the POST:  the boundary, the Content-Disposition header, a plain form-data field, or the uploaded file field (with a Content-Type header).  But Perl's HTTP::Request::Common puts in an additional header: Content-Length.

According to the RFC (RFC 1867), this seems legal.  So when Perl sends:

Content-type: multipart/form-data, boundary=AaB03x
--AaB03x
Content-Disposition: form-data; name="field1"

Joe Perl
--AaB03x
Content-Disposition: form-data; name="uploadfile"; filename="file1.txt"
Content-Length: 5660
Content-Type: text/plain

         ... contents of file1.txt ...
--AaB03x--


php3_mime_split saves the $uploadfile starting with "ntent-type: text/plain..." rather than the correct spot, which would be after the single \n by itself.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [1999-12-21 08:55 UTC] jeddings at jeddings dot com
There is some question as to whether Content-Length is a valid header, since the RFC is not clear.  There needs to be clarification on this.
 [2005-03-30 09:01 UTC] sniper@php.net
We are sorry, but we can not support PHP 3 related problems anymore.
Momentum is gathering for PHP 5, and we think supporting PHP 3 will
lead to a waste of resources which we want to put into getting PHP 5
ready. Of course PHP 4 will continue to be supported for the
forseeable future.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Dec 30 14:01:28 2024 UTC