fix($http): support url format variant for arrays value #fixes 7363

[FGRibreau]

$http now supports both url format /foo?countries[]=US&countries[]=GB and /foo?countries=US&countries=GB
In order to activate the first format, config.useArrayParams must be set to true.

Fixes #7363

[mary-poppins]

Thanks for the PR! Please check the items below to help us merge this faster. See the contributing docs for more information.

• Uses the issue template (#7409)

If you need to make changes to your pull request, you can update the commit with git commit --amend.
Then, update the pull request with git push -f.

Thanks again for your help!

[FGRibreau]

PR for #7363

[mary-poppins]

I'm sorry, but I wasn't able to verify your Contributor License Agreement (CLA) signature. CLA signature is required for any code contributions to AngularJS.

Please sign our CLA and ensure that the CLA signature email address and the email address in this PR's commits match.

If you signed the CLA as a corporation, please let us know the company's name.

Thanks a bunch!

PS: If you signed the CLA in the past then most likely the email addresses don't match. Please sign the CLA again or update the email address in the commit of this PR.
PS2: If you are a Googler, please sign the CLA as well to simplify the CLA verification process.

[FGRibreau]

#up Just signed the CLA.

[lgalfaso]

I was working in a somehow more generic solution #7423

[FGRibreau]

@Igalfaso there is are lot of duplicated code between keyValueParametersSerializer and jsonParametersSerializer. I am not sure if jsonParametersSerialized should be already implemented inside AngularJS code. But indeed it may be a good idea to allow an implementation user-side even if the two forms "param=val1&param=val2" and "param[]=val1&param[]=val2" are the most widely used.

So my simple implementation + a allowing user-side overriding should be enough I think (everything other than that seems to be premature optimization IMHO).

[mary-poppins]

CLA signature verified! Thank you!

Someone from the team will now triage your PR and it will be processed based on the determined priority (doc updates and fixes with tests are prioritized over other changes).

[IgorMinar]

as mentioned in #7423 (comment)

I'm not keen on having multiple serialization strategies, but you are right that there are only two popular strategies.

can you provide a list of popular backends that would benefit from this serialization format?

I know of:

• play framework
• php

Rails, .net/asp, and many others don't use that format.

If there is some other noticeable backends then we should reconsider this PR. In order to get it in, we'll need tests though.

[pkozlowski-opensource]

So, this PR was stale for some months now and I don't think that we want to merge it in the current form as:

• based on discussion in feat(http): add multiple parameters serializers #7423 we don't want to have multiple serialization strategies in the core
• we are working on a more generic solution in the 1.4 time-frame (see: https://gist.github.com/pkozlowski-opensource/5a57d28ccfeacaba7661)

Based on the above and the fact that this PR doesn't merge cleanly any more, doesn't have tests etc. I'm going to close this one. @FGRibreau we do appreciate your effort and contribution so if you could review the proposal in https://gist.github.com/pkozlowski-opensource/5a57d28ccfeacaba7661 this would be much appreciated.