cURL POST fields are added via CURLOPT_POSTFIELDS as an array, setting form to multipart/form-data

[ghost]

Requests_Transport_cURL::setup_handle() directly passes a PHP array to CURLOPT_POSTFIELDS when performing POST or PUT. According to http://php.net/manual/en/function.curl-setopt.php, this will implicitly set the request header Content-Type to a value of multipart/form-data. This is not always desired.

Would it be possible to add a feature whereby Requests encodes the POST array to a string when using cURL as the transport, perhaps via options? This would ensure that php-curl does not set the Content-Type header. The multipart form header causes problems in certain cases, and my workaround of converting POST array data into a string prior to calling Requests::request() is a bit sloppy.

Thanks.

[rmccue]

Sorry for taking so long to respond.

Does passing the 'Content-Type' header in not set this for you?

[ghost]

Setting the 'Content-Type' header manually should work, although I have not tested it.

The issue was that I was scratching my head trying to figure out why my requests were not working with certain remote servers.. figured this might be helpful for the end user to be aware of (and be able to configure perhaps through some explicit configuration option) and/or have a consistent/sensible default. Since cURL / passing POST to cURL is abstracted away and is exhibiting idiosyncratic behavior, perhaps it is prudent to expose these details in some form or fashion to the end user of Requests? I had to open the internals of Requests to see how POST data was passed to cURL to isolate the issue.

Long and short, doing the POST via cURL thru Requests changes the 'Content-Type' header, and this is not immediately apparent to the end user of Requests.

I have only tested this with cURL so not sure how the fallback method will behave in terms of passing POST data (I'd assume it should be consistent).

Thanks.

[rmccue]

Long and short, doing the POST via cURL thru Requests changes the 'Content-Type' header, and this is not immediately apparent to the end user of Requests.

It's not really changing the Content-Type header if you're not setting on. To be able to POST data, you have to have a content-type, so cURL sets this automatically when it passes this in (seeing as it's encoding it in multipart/form-data style).

I'm not sure what the desired behaviour here should be. Sending a body without a content-type header doesn't make sense, and anything except multipart/form-data will be encoded differently, so it should be passing a string in anyway.

[rmccue]

Marking this as a documentation problem, as this should be documented as required internal behaviour.

[Ninegears]

I'm not so sure this is actually a documentation issue. I've just had a lot of fun with a request being mangled when array data was passed, with the text/plain header manually added.

When I manually serialise the array into a string it's fine, and when I allow the implicit multipart, it's fine then too, but sent the data in the wrong way for the system I'm interacting with. I can provide some example code if required, but hopefully it's apparent how to test it.

[rmccue]

@Ninegears Sorry for missing your comment previously, is it the same behaviour as #35? This issue is more about the content-type being set.