The curl extension is not behaving as described in the manual.

If you set CURLOPT_POST to 1, and then pass an array to CURLOPT_POSTFIELDS, it sets Content-type to multipart/form-data instead of application/x-www-form-urlencoded.  This is wrong: the multipart header should only be used when CURLOPT_PUT is set.  To quote the PHP manual:

{{{CURLOPT_POST: Set this option to a non-zero value if you want PHP to do a regular HTTP POST. This POST is a normal application/x-www-form-urlencoded kind, most commonly used by HTML forms.}}}


Here is what the author of curl (Daniel Stenberg) says - full message at <http://curl.haxx.se/mail/curlphp-2001-11/0003.html>:

{{{I took a tour into the inner workings of the php curl wrapper code and I've now returned to tell about my findings! ;-)

When you pass an array to CURLOPT_POSTFIELDS, it is passed as a multipart/form-data post exactly as you describe. The problem with this is that it uses the libcurl function curl_formparse() to accomplish this, and that is a lame function(*).

It does not support newlines in the contents like you tried here.

The wrapper should instead use the new (and much better) curl_formadd() function for this purpose. It does not have this newline problem.

(*) = yet it was the only available one for a very long time.}}}

I think there is enough evidence here to change the behaviour of the extension - I think it can be done without breaking backwards compatibility.  The extension was never meant to behave like this, as the manual testifies.

Regards,
Peter Bowyer.