Assigning to sterling, the cURL master.

Derick

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.

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 

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.

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

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