Bug #16305 Updated: curl post doesn't behave as per the manual
| From: | sniper@php.net | Date: | Thu, 04 Apr 2002 12:34:53 +0000 |
| Subject: | Bug #16305 Updated: curl post doesn't behave as per the manual | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-4033@lists.php.net to get a copy of this message | ||
ID: 16305
Updated by: sniper@php.net
Reported By: reywob@f2s.com
-Status: Open
+Status: Feedback
Bug Type: cURL related
Operating System: Any
PHP Version: 4.1.2
New Comment:
PHP 4.2.0-dev does not use curl_formparse..please try
the RC2 from http://www.php.net/~derick/
Previous Comments:
------------------------------------------------------------------------
[2002-03-27 03:49:03] reywob@f2s.com
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.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=16305&edit=1