php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #14321 multipart/form-data doesn't accept a NULL character
Submitted: 2001-12-03 06:22 UTC Modified: 2002-01-07 10:51 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: kranzhoff at neptunelabs dot de Assigned: sterling (profile)
Status: Not a bug Package: Variables related
PHP Version: 4.2.0dev OS: i686-gnu-linux
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: kranzhoff at neptunelabs dot de
New email:
PHP Version: OS:

 

 [2001-12-03 06:22 UTC] kranzhoff at neptunelabs dot de
This one is related to the report of jeroen@smartnet.dhs.org (Bug id #11516).
I talked to sniper about this problem a year ago, but I could not convince him that this behaviour of PHP to truncate post variables at the first occurrance of 0x00 exists and that it's incorrect (when used with multipart-formdata). Some days ago I used libCURL with C++ to post binary data with the "CURLFORM_PTRCONTENTS" option which lead to the same problem. Packet-sniffing revealed that the data is sent correctly, but PHP truncates the variable at the first occurance of 0x00. I had a discussion with Daniel Stenberg (Curl-developer) on that topic. He agreed that following RFC1867 it is allowed to send binary data in the way jeroen describes and he was pretty much suprised that PHP causes such problems. As the function curl_formadd() and "CURLOPT_POSTFIELDSIZE" is not implemented in PHP I can not give you a PHP script which produces the error but let me know if you're interested in an example written in C++. I would appriciate very much if this bug could be removed in future versions of PHP.
thanks in advance
Hanno



Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-12-03 06:23 UTC] derick@php.net
Assigning to sterling, the cURL master.

Derick
 [2001-12-03 09:36 UTC] sterling@php.net
a) not a cURL related bug report
b) bogus, when you print binary data, expect it to be truncated at the NULL, this is the same in every language.
 [2001-12-13 05:31 UTC] kranzhoff at neptunelabs dot de
Sorry, this is not a bogus.
I wish it was. Obviously Sterling got me completely wrong.
It's not a problem of printing binary data.
As I do not use curl with PHP this bug is NOT Curl related it's more in the receiving end.
What I'm doing is posting binary data using
libcurl with c++.
In this example it's a buffer containing A,chr(0) and B.
Network traces show the following:
########
POST /test.php HTTP/1.1.
Pragma: no-cache.
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*.
Content-Length: 130.
Content-Type: multipart/form-data; boundary=curl/49TVuznugm1TDG2p68EyKJrXOq.
.
--curl/49TVuznugm1TDG2p68EyKJrXOq.
Content-Disposition: form-data; name="BinaryData".
.
A.B.
--curl/49TVuznugm1TDG2p68EyKJrXOq--.
########
I hope everybody agrees that the post is ok and that
it's containing 3 byte of data (A,chr(0) and B). 
So I do not present the C++ code here, as it is obviously not relevant.
On the PHP side I check the received data with:
########
echo "POST: ";
print_r($_POST);
//and just to make sure print_r is binary safe...
$foo="X".chr(0)."Z"; 
print_r($foo);
########
the result is:
########
POST: Array
(
     [BinaryData] => A
)
X.Z
########
So everything following "A" including chr(0) has been truncated.
Again this problem has been mentioned on 2001-06-16 by jeroen@smartnet.dhs.org in bug report #11516.

Additionally if I change the name of the post variable to 
###
name="BinaryData" filename="foo"
###
to trick PHP into believing it's a ordinary file post
the received file contains all the 3 bytes.
This should prove that the post itself is ok.
Tell me if you want me to present the c source code or
do some different kind of testing.
Tests were done with PHP 4.1.0 and the latest CVS version.
Hanno 

 [2001-12-13 06:45 UTC] yohgaki@php.net
Try $HTTP_RAW_POST_DATA. Encode data with base64 or like when you print, if there is null char in data. Then you should be able to deal with.
 [2001-12-13 12:37 UTC] kranzhoff at neptunelabs dot de
Ok, I tried $HTTP_RAW_POST_DATA.
The result of "echo rawurlencode($HTTP_RAW_POST_DATA);" is :
#####
--curl0m0Kw3o0o1CufhI8a%2BHAFaguSrD%0D%0A
Content-Disposition%3A%20form-data%3B%20name%3D%22BinaryData%22%0D%0A%0D%0A
A%00B%0D%0A
--curl0m0Kw3o0o1CufhI8a%2BHAFaguSrD--%0D%0A
#####
So it seems that PHP receives the data (A%00B) correctly.
But why doesn't $_POST reveal the same data ?
Is there something wrong with reassembling the data
of the post in PHP (maybe in rfc1867.c) ?
Or is there another way of getting the data w/o the rfc1867 stuff (e.g. boundaries) besides "$_POST" ?

Hanno
 [2002-01-07 10:51 UTC] kranzhoff at neptunelabs dot de
yohgaki@php.net said (via email) "If PHP is not following RFC1867, someone will fix it.".
Actually it's hard to say, if binary data _has_ to be supported in post variables (multipart/form-data), as far as rfc1867 is concearned. I already discussed that with Daniel Stenberg (libcurl) [daniel@haxx.se] and he said, that PHP should support that from his point of view.
Anyway it would be very helpful, if it was possible to send binary data w/o writing the data to a file and reading it again and of course w/o encoding the data prior to sending it ( for performance reasons).
As far as I understand Sterling, PHP was expected to behave that way (not only with file-posts).
I just finished an example which demonstrates, that the data is beeing truncated by PHP, somewhere between $HTTP_RAW_POST_DATA and transferring it to $_POST.
You can download the sample from:
http://www.kranzhoff.de/php/bug14321.bz2
It contains a small C prog which sends the data and
a corresponding PHP-script which receives the data.

Hanno
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Dec 06 01:01:29 2024 UTC