-
Notifications
You must be signed in to change notification settings - Fork 494
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cURL POST fields are added via CURLOPT_POSTFIELDS as an array, setting form to multipart/form-data #33
Comments
Sorry for taking so long to respond. Does passing the 'Content-Type' header in not set this for you? |
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. |
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 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 |
Marking this as a documentation problem, as this should be documented as required internal behaviour. |
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. |
@Ninegears Sorry for missing your comment previously, is it the same behaviour as #35? This issue is more about the content-type being set. |
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 headerContent-Type
to a value ofmultipart/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 theContent-Type
header. The multipart form header causes problems in certain cases, and my workaround of converting POST array data into a string prior to callingRequests::request()
is a bit sloppy.Thanks.
The text was updated successfully, but these errors were encountered: