Feature request: x-www-form-urlencoded POSTs should be easier to do

[nickretallack]

It shouldn't require a work-around to get the behavior that nearly every web service on the internet expects. Angular already depends on (a subset of?) jQuery, and jQuery does this behavior by default, which means using the $http service is a bit of a downgrade. I expect most users will get frustrated and ditch it before they stumble across this post on the mailing list. At the very least, the content of this post should be included in the documentation.

There was an issue for this before, but it got closed when $xhr was renamed to $http. That didn't resolve the issue.

[pkozlowski-opensource]

From #1886

I have to work with a backend (PHP) which does not automatically parse JSON, and which I cannot change. I would like angular to automatically urlencode my POST data when the Content-Type is application/x-www-form-urlencoded. See this SO thread where the recommended solution is to use jQuery's $.param.

[davidchang]

Volunteer.

I am wondering, though, as to whether I should just copy $.param into ng/http.js or perhaps jqLite.js (if jqLite.js should be used for any subset of jQuery code), or if there is some wiser way to url encode an object (like the solution proposed here: http://stackoverflow.com/questions/1714786/querystring-encoding-of-a-javascript-object).

[davidchang]

Retracting.

[joshuawoodward]

@nickretallack this is not a problem with AngularJS, I don't know what backend you are using but in PHP you can simply
$data = json_decode(file_get_contents("php://input"));

$data becomes an object and you can access values with $data->key

http://stackoverflow.com/questions/15707431/http-post-using-angular-js

[Dashue]

+1 def a pain in the back end!

[nickretallack]

@joshuawoodward

When you POST a form, your browser makes a form-encoded POST payload. This is the default behavior, and accordingly every web framework I've ever encountered expects this. You can also construct form encoded payloads with jQuery, or even with the FormData API in javascript. Because this method of POST requests is so ubiquitous, most application servers I've seem implement it for all requests. It doesn't make a lot of sense to implement views differently just because they are going to be accessed by JavaScript, and besides, that precludes the ability to interact with them via forms. Allowing these two methods of access at once is convenient. Also, what if you're trying to access a third party server? Then you don't have the choice to change the POST encoding method.

You asked what framework I'm using. I'm using Pyramid. In Pyramid, the url router can actually decide which view to select based on form-encoded fields in the POST data -- see request_params for add_view. Unless I form-encode my POST, I can't use this helpful feature.

[James-Dunn]

+1 I don't know why Angular would break from the standard here.

[joshuawoodward]

@James-Dunn I don't think it is a standard as much as a convention

Conventionally, by default, when preforming an AJAX request the data is sent form encoded. AngularJS is different, in more ways then this, in it's design and patterns.

[Dashue]

On M$ you need to jump through a few hoops to get it to decode properly using Mvc/Nancy/Webapi. I feel this is more of a problem with the server than the client. Because the body is represented as a stream, I end up just reading that string to a dynamic of some sorts or a strong type would even work.

That being said, providing a simple switch on the client would avoid having people spend time learning about deserialization, headers / etc. Disregarding what is standard and what is not, if it´s a simple implementation and the user just have to toggle a bool to opt in or opt out that would be ideal i think.

[pkozlowski-opensource]

Going to close this one as a duplicate of #6039 to centralise the whole discussion in one place.

[joshuawoodward]

Why close the thread that was opened first and has more discussion?

[pkozlowski-opensource]

@joshuawoodward oh, sorry, actually both issues have some discussion and I wanted to centralise it one place so we can act on this. I've closed this one since #6039 started to have discussion on the actual discussion. But I don't mind it either way, we can re-open this once and close the other. For me the most important part is to draft a solution and act on it.