Bug #14321 Updated: multipart/form-data doesn't accept a NULL character

ID: 14321 Updated by: yohgaki Reported By: kranzhoff@neptunelabs.de Status: Bogus Bug Type: Variables related Operating System: i686-gnu-linux PHP Version: 4.1.0 Assigned To: sterling New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2001-12-13 05:31:15] kranzhoff@neptunelabs.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-03 09:36:46] 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-03 06:23:56] derick@php.net Assigning to sterling, the cURL master. Derick ------------------------------------------------------------------------ [2001-12-03 06:22:04] kranzhoff@neptunelabs.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 ------------------------------------------------------------------------ Edit this bug report at http://bugs.php.net/?id=14321&edit=1