release 175 incorrectly encode parameters that are multi-dimensional arrays

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Try to send a multi-dimensional array as a POST parameter

What is the expected output? What do you see instead?
The multidimensional array should be created and encoded appropriately:
my_array[0][name]=value

instead I get
my_array=Array

What version of the product are you using? On what operating system?
release-175 on Mac OS 10.5.8

Please provide any additional information below.
It appears that you are not using http_build_query() and parse_str() to build 
and parse the parameters. Is this because they only work in PHP 5+? In 
searching for the source of the problem, I discovered that 
OAuthRequest::setParam, OAuthRequestSigner::getQueryString, 
OAuthRequest::parseUri(), and OAuthRequest::transcodeParams all assume that 
values that are arrays are at most only one level deep.

To fix the situation, I have added 3 extra recursive functions to 
systematically encode each dimension of the array. However, I suggest looking 
at this link to see if this is a simpler way to remain PHP 4 compatible: 
http://www.php.net/manual/en/function.http-build-query.php#90438

Alternatively, I would recommend not having OAuthRequest::param always be url 
encoded and instead just be a multi-dimensional array that is encoded 
appropriately inside getQueryString and decoded in parseURI.

Original issue reported on code.google.com by archul...@seqcentral.com on 17 Mar 2011 at 6:05

[GoogleCodeExporter]

I also ran into this problem. Essentially, the library doesn't handle 
multidimensional parameter arrays at all. I assume this might be because 
different frameworks handle it differently (see 
http://stackoverflow.com/questions/7578269/where-did-this-ruby-parameter-convent
ion-come-from). PHP and Rails expect data in this format:

foo[]=bar&foo[]=baz

whereas other frameworks expect to see

foo=bar&foo=baz

So if the library uses http_build_query, it'll output multidimensional arrays 
in the PHP-style format. That will work for PHP and Rails endpoints, but others 
(Java, say) will choke on it.

Probably the best way to handle it is a switch of some kind 
(::setPostEncodingMethod() or some such) that lets you use 
http_build_query()-style parameters if you know you're dealing with a PHP or 
Rails endpoint.

Original comment by katherin...@acquia.com on 16 Nov 2011 at 8:51