http1.1 protocol specified way http requests are OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT in several ways. POST which is one of the most commonly used method to submit data to the server, this article focuses on four ways to submit POST data.
application/x-www-form-urlencoded
This should be the most common way to POST submit the data. Native browser <form> form, if not set enctype attribute, then the final data will be submitted to application / x-www-form-urlencoded manner. Request similar to the following (independent of the request header are herein omitted):
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, Content-Type is designated as application / x-www-form-urlencoded; secondly, the data is encoded in accordance with the submitted val1 manner key1 = & key2 = val2 of, key, and have carried out a URL val transcoding. Most server-side languages have very good support for this approach. For example in PHP, $ _ POST [ 'title'] can be obtained the value of title, $ _ POST [ 'sub'] can be sub array.
Many times, when we submit data using Ajax, also use this approach. For example Ajax, Content-Type defaults JQuery and QWrap are "application / x-www-form-urlencoded; charset = utf-8."
multipart/form-data
This is a common way of POST data submitted. When we use the form to upload files, you must let the <form> Form enctype equal multipart / form-data. A direct view of exemplary request:
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 slightly more complex. First generates a boundary for dividing the different fields, and the body in order to avoid duplicate content, very long and complicated boundary. Then in the Content-Type indicates the data is multipart / form-data is encoded, boundary this request is what. According to the number of fields in the message body is divided into a plurality of similar structural parts, each part are based --boundary begins, followed by the content description information, then the transport, the last field is the specific content (text or binary). If the file is transmitted, but also contains the file name and file type information. The message body and end with --boundary-- marked. Detailed definition of multipart / form-data, go to rfc1867 view.
This approach is generally used to upload files, the major server-side language it also has a good support.
Both the above-mentioned embodiment POST data are natively supported by the browser, and the stage standard natively <form> form only supports both ways (by <form> element specifies the enctype attributes, default application / x-www-form-urlencoded. In fact enctype also supports text / plain, but with very little).
As more and more Web sites, especially WebApp, after all use Ajax data exchange, we can define new data is presented in a way, to the developers bring more convenience.
application/json
application / json this Content-Type response header as I am sure you are not familiar with. In fact, now more and more people regard it as a request header that tells the server the message body is serialized JSON string. Due to popular JSON specification, in addition to the low of the major versions of IE browsers native support JSON.stringify, server-side languages have handlers JSON using JSON will not encounter any trouble.
JSON format support structured data much more complex than the keys, it is also useful. I remember doing a hierarchical data project a few years ago, you need to submit a very deep, and I'm JSON serialization of the data submitted later. But at the time I was put as a JSON string val, remains on the key-value pairs in order to x-www-form-urlencoded submission.
Ajax functionality in Google's AngularJS, the 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) {
...
});
Final request is sent:
POST http://www.example.com HTTP/1.1
Content-Type: application/json;charset=utf-8
{"title":"test","sub":[1,2,3]}
This embodiment may be conveniently submitted to complex data structures, especially for RESTful interface. Major capture tool comes as Chrome Developer Tools, Firebug, Fiddler, will demonstrate JSON data in a tree structure, very friendly. But some server-side language is not yet supported in this way, for example php can not get content from the above request by $ _POST object. At this time, you need to handle yourself: when the request header Content-Type is application / json, from php: // input to obtain the original input stream in, and then json_decode to objects. Some php framework has begun to do.
AngularJS course can also be configured to submit data using x-www-form-urlencoded manner. If necessary, you can refer to this article.
text/xml
Mentioned XML-RPC (XML Remote Procedure Call) before I blog. It is using HTTP as the transport protocol, XML as the encoding of the remote calling convention. A typical XML-RPC request is such that:
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>
</param>
</params>
</methodCall>
XML-RPC protocol is simple, functional enough to achieve a variety of languages are. Its use is very broad, such as the WordPress XML-RPC Api, search engines ping services. JavaScript, there are ready-made library supports data exchange in this way, can well support existing XML-RPC service. However, I personally feel that XML structure is still too bloated, general scene in JSON would be more flexible and convenient.
This link: https://imququ.com/post/four-ways-to-post-data-in-http.html
Reproduced in: https: //my.oschina.net/u/3655450/blog/1607678