The HTTP request methods specified by the HTTP/1.1 protocol include OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, and CONNECT. Among them, POST is generally used to submit data to the server. This article mainly discusses several ways to submit data through POST.
We know that the HTTP protocol is an application layer specification based on the TCP/IP protocol, which is transmitted in ASCII code. The specification divides the HTTP request into three parts: the status line, the request header, and the message body. Something like this:
BASH<method> <request-URL> <version>
<headers>
<entity-body>
The protocol stipulates that the data submitted by POST must be placed in the message body (entity-body), but the protocol does not stipulate what encoding the data must use. In fact, the developer can completely decide the format of the message body, as long as the final HTTP request satisfies the above format.
However, when the data is sent out, it only makes sense if the server parses it successfully. General server languages such as php, python, etc., as well as their frameworks, have built-in functions to automatically parse common data formats. The server usually learns how the message body in the request is encoded according to the Content-Type field in the request header, and then parses the body. So when it comes to the POST submission data scheme, it includes two parts: Content-Type and message body encoding method. The following is the official introduction to them.
application/x-www-form-urlencoded
This should be the most common way of POSTing data. The browser's native <form> form, if the enctype attribute is not set, the data will eventually be submitted in the form of application/x-www-form-urlencoded. The request looks like this (irrelevant request headers are omitted from this article):
BASHPOST 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 specified as application/x-www-form-urlencoded; secondly, the submitted data is encoded in the manner of key1=val1&key2=val2, and both key and val are URL-transcoded. Most server-side languages have good support for this approach. For example, in PHP, $_POST['title'] can get the value of title, and $_POST['sub'] can get the sub array.
Many times, we also use this method when we submit data with Ajax. For example , Ajax of JQuery and QWrap , the default value of Content-Type is "application/x-www-form-urlencoded; charset=utf-8".
multipart/form-data
This is again a common way of POST data submission. When we upload files using a form, we must make the <form> form enctype equal to multipart/form-data. Just look at an example request:
BASHPOST 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 a little more complicated. First, a boundary is generated to separate different fields. In order to avoid duplication with the body content, the boundary is very long and complicated. Then Content-Type indicates that the data is encoded in multipart/form-data, and what is the boundary of this request. The message body is divided into several parts with similar structures according to the number of fields. Each part --boundary starts with the content description information, then the carriage return, and finally the specific content of the field (text or binary). If transferring a file, also include file name and file type information. The message body ends with a --boundary-- flag. For the detailed definition of multipart/form-data, please go to rfc1867 .
This method is generally used to upload files, and major server languages also have good support for it.
The two methods of POST data mentioned above are natively supported by browsers, and the native <form> form in the current standard only supports these two methods (specified by the attributes of the <form> element enctype , the default is application/x-www-form-urlencoded. In fact, it is enctype still supported text/plain, but it is used very rarely).
As more and more Web sites, especially WebApps, all use Ajax for data interaction, we can define new data submission methods to bring more convenience to development.
application/json
You must be familiar with the application/json Content-Type as a response header. In fact, more and more people now use it as a request header to tell the server that the message body is a serialized JSON string. Due to the popularity of the JSON specification, all major browsers except low-level IE natively support JSON.stringify, and the server-side languages also have functions for processing JSON, so you will not encounter any trouble when using JSON.
It is also useful that the JSON format supports structured data that is much more complex than key-value pairs. I remember that when I was working on a project a few years ago, the data that needed to be submitted was very deep, and I submitted the data after serializing it in JSON. But at that time, I used the JSON string as val, still put it in the key-value pair, and submitted it in the form of x-www-form-urlencoded.
The Ajax function in Google's AngularJS , the default is to submit a JSON string. For example the following code:
JSvar data = {'title':'test', 'sub' : [1,2,3]};
$http.post(url, data).success(function(result) {
...
});
The final request sent is:
BASHPOST http://www.example.com HTTP/1.1
Content-Type: application/json;charset=utf-8
{"title":"test","sub":[1,2,3]}
This solution can easily submit complex structured data, and is especially suitable for RESTful interfaces. Major package capture tools, such as Chrome's own developer tools, Firebug, and Fiddler, will display JSON data in a tree structure, which is very friendly. But some server-side languages do not yet support this method. For example, php cannot get the content from the above request through the $_POST object. At this time, you need to handle it yourself: when the Content-Type in the request header is application/json, php://input get the original input stream from it, and then turn it json_decode into an object. Some php frameworks have started to do this.
Of course, AngularJS can also be configured to submit data using x-www-form-urlencoded. If necessary, you can refer to this article .
text/xml
My blog previously mentioned XML-RPC (XML Remote Procedure Call). It is a remote invocation specification that uses HTTP as the transport protocol and XML as the encoding method. A typical XML-RPC request looks like this:
HTMLPOST 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 协议简单、功能够用，各种语言的实现都有。它的使用也很广泛，如 WordPress 的 XML-RPC Api，搜索引擎的 ping 服务等等。JavaScript 中，也有现成的库支持以这种方式进行数据交互，能很好的支持已有的 XML-RPC 服务。不过，我个人觉得 XML 结构还是过于臃肿，一般场景用 JSON 会更灵活方便。
https://imququ.com/post/four-ways-to-post-data-in-http.html