Reference: Http://stackoverflow.com/questions/4007969/application-x-www-form-urlencoded-or-multipart-form-data
Four common ways of POST submission data
We know that the HTTP protocol is based on the ASCII code transmission, based on the TCP/IP Protocol Application layer specification. The specification divides the HTTP request into three parts: a status line, a request header, and a message body. This is similar to the following:
<method> <request-url> <version>
<entity-body></entity-body>The agreement stipulates that the data submitted by POST must be placed in the message body (entity-body), but the agreement does not specify what encoding the data must use. In fact, the developer can completely determine the format of the message body, as long as the last HTTP request is sent to meet the above format.
However, the data sent out, but also the server to resolve the success of the meaning. General Service-side languages such as PHP, Python, and their frameworks are built with the ability to automatically parse common data formats. The server side usually learns from the Content-type field in the request header (headers) How the message body in the request is encoded and then parses the body. So when it comes to the POST submission data scheme, it includes two parts, Content-type and the message body encoding method. Here's a formal introduction to them.
application/x-www-form-urlencoded
This should be the most common way to POST-submit data. The native form form of the browser, if you do not set the Enctype property, the data will eventually be submitted in application/x-www-form-urlencoded mode. The request is similar to the following (the irrelevant request headers are omitted from this article):
POST http://www.example.com http/1.1
Content-type:application/x-www-form-urlencoded;charset=utf-8
Title=test&sub%5b%5d=1&sub%5b%5d=2&sub%5b%5d=3
First, the Content-type is designated as application/x-www-form-urlencoded; second, the submitted data is encoded in a key1=val1&key2=val2 manner, and key and Val are both URL-transcoding. Most service-side languages have a good support for this approach. For example, in PHP, $_post[' title ' can get the value of title, $_post[' Sub ' can get a sub array.
Most of the time, we use Ajax to submit data, which is also used in this way. For example, the Ajax,content-type default values for JQuery and Qwrap are "application/x-www-form-urlencoded;charset=utf-8".
Multipart/form-data
This is another common way to POST data submissions. When we use a form to upload a file, we must have the enctyped of the form equal to this value. Look directly at a request example:
POST http://www.example.com http/1.1
Content-type:multipart/form-data; boundary=----Webkitformboundaryrgkcby7qhfd3trwa
------Webkitformboundaryrgkcby7qhfd3trwa
Content-disposition:form-data; Name= "Text"
Title
------Webkitformboundaryrgkcby7qhfd3trwa
Content-disposition:form-data; Name= "File"; Filename= "Chrome.png"
Content-type:image/png
PNG ... content of chrome.png ...
------webkitformboundaryrgkcby7qhfd3trwa--
This example is slightly more complicated. First, a boundary is generated to segment different fields, and boundary is long and complex to avoid duplication with the body content. The Content-type then indicates that the data is encoded in Mutipart/form-data, and what the boundary of this request is. The number of fields in the message body is divided into a number of similar parts of the structure, each part is started with--boundary, followed by the content description information, then enter, and finally the specific content of the field (text or binary). If you are transferring files, also include file name and file type information. The message body finally ends with a--boundary--mark. For a detailed definition of mutipart/form-data, please go to rfc1867 view.
This way is generally used to upload files, the major service-side language for it also has good support.
The two types of POST data mentioned above are natively supported by browsers and are supported only by the native form form at this stage. But with more and more Web sites, especially WebApp, all using Ajax for data interaction, we can completely define new data submission methods and bring more convenience to development.
Application/json
Application/json this content-type as a response to the head everyone is certainly not unfamiliar. In fact, more and more people are using it as a request header to tell the server that the message body is a serialized JSON string. Because of the popularity of the JSON specification, the server-side language also has functions that handle JSON, except for the large browsers that are not in the lower version of IE, and there is no trouble using JSON.
The JSON format is also useful for supporting structured data that is much more complex than the key value pair. Remember when I was working on a project a few years ago, I needed to submit a very deep level of data, and I was submitting the data JSON serialization later. But at the time I was putting the JSON string as Val, still in the key-value pair, and submitting it in a x-www-form-urlencoded way.
The Ajax feature in Google's Angularjs, by default, is to submit a JSON string. For example, the following code:
var data = {' title ': ' Test ', ' Sub ': [1,2,3]};
$http. Post (URL, data). Success (function (result) {
...
});
The final request to send is:
POST http://www.example.com http/1.1
Content-type:application/json;charset=utf-8
{"title": "Test", "sub": [1,2,3]}
This scheme makes it easy to submit complex structured data, especially for RESTful interfaces. The big grab kits, such as Chrome's own developer tools, Firebug, and Fiddler, will display JSON data in a tree-like structure, very friendly. But there are also service-side languages that do not support this approach, such as PHP's inability to get content from the above request through the $_post object. At this time, need to deal with their own hands: in the request header Content-type as Application/json, from the Php://input to obtain the original input stream, and then json_decode into objects. Some PHP frameworks are already starting to do this.
Of course Angularjs can also be configured to submit data using the X-www-form-urlencoded method. If necessary, you can refer to this article.
Text/xml
My blog has mentioned XML-RPC (Procedure call) before. It is a remote invocation specification that uses HTTP as a transport protocol and XML as a coding method. The typical XML-RPC request is this:
POST http://www.example.com http/1.1
Content-type:text/xml
<!--? XML version= "1.0"?-->
<methodcall>
<methodname>examples.getStateName</methodname>
<params>
<param>
<value><i4>41</i4></value>
</params>
</methodcall>
XML-RPC protocol is simple, the function is sufficient, each kind of language realization has. Its use is also very extensive, such as WordPress XML-RPC Api, search engine ping service and so on. JavaScript, there are ready-made libraries that support data interaction in this way, and can support existing XML-RPC services well. However, I personally feel that the XML structure is still too bloated, the general scenario with JSON will be more flexible and convenient.
