php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #66436 CURLOPT_POSTFIELDS duplicate field names
Submitted: 2014-01-07 16:50 UTC Modified: 2014-04-25 08:56 UTC
From: julian at julianrhindconsulting dot com Assigned:
Status: Duplicate Package: cURL related
PHP Version: 5.5.7 OS: any
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: julian at julianrhindconsulting dot com
New email:
PHP Version: OS:

 

 [2014-01-07 16:50 UTC] julian at julianrhindconsulting dot com
Description:
------------
Hi

There appears to be a problem with the current curl implementation in regard to duplicate post fields - especially when also wanting to post files

In order to call curl_setopt option CURLOPT_POSTFIELDS with the following data

name=Bob
name=Mary

this can be done using the string form passing

'name=Bob&name=Mary'

however it can't be done using the array form

['name'=>'Bob', 'name'=>'Mary']

for obvious reasons

When posting files it appears to be a requirement to use the array form

So what is one to do - if one wants to post duplicate field names and files?

This bug/design problem appears to be long standing and is inquired widely on the internet - however no one appears to be trying to resolve it

Is it possible this could be resolved?

The simplest solution would appear to be to handle a field name pointing to an array as a duplicate field name - so one would specify

[name=>['Bob','Mary']]

and curl_setopt would generate

name=Bob&name=Mary

I also note that this exact problem occurs when receiving posted data via $_POST - again the same solution could be used - duplicate posted fields would return an array rather than a single value

I'm also aware of a workaround - using

['name[0]'=>'Bob','name[1]'=>'Mary']

however this does not generate the correct post data - but may be understood by the server if it happens to be running PHP

Regards

Julian

Julian Rhind


Expected result:
----------------
name=Bob&name=Mary

Actual result:
--------------
name=Mary

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-01-08 23:41 UTC] cmbecker69 at gmx dot de
duplicate of #51634
 [2014-01-09 05:58 UTC] julian at julianrhindconsulting dot com
Hi Christoph

Thanks - I see it has been reported - nearly four years ago - the problem is that a patch has been added to that bug claiming to fix the problem - however the problem remains - presumably that's why the bug has not been fixed - it's got trapped in the system - apparently fixed - but not - is it possible that the bug could get fixed?

Regards

Julian
 [2014-04-25 08:56 UTC] mike@php.net
-Status: Open +Status: Duplicate
 [2014-04-25 08:56 UTC] mike@php.net
Duplicate of bug #51634
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Nov 22 05:01:29 2024 UTC