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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
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