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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
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: Sat Dec 21 17:01:58 2024 UTC