HTML data submission post_PowerNode Java Academy

The HTTP request methods specified by the HTTP/1.1 protocol include OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, and CONNECT. POST is generally used to submit data to the server. This article mainly discusses several ways to submit data using POST.

We know that the HTTP protocol is transmitted in ASCII code and is an application layer specification built on the TCP/IP protocol. The specification divides HTTP requests into three parts: status line, request header, and message body. It looks like this:

<method> <request-url> <version>
<headers>
<entity-body></entity-body></headers></version></request-url></method>

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 method must be used for the data. In fact, developers can completely decide the format of the message body by themselves, as long as the final HTTP request sent meets the above format.

However, the data is only meaningful if it is successfully parsed by the server. General server-side languages ​​such as Java and their frameworks have built-in functions for automatically parsing common data formats. The server usually learns how the message body in the request is encoded based on the Content-Type field in the request header, and then parses the body. So when it comes to the POST data submission scheme, it includes two parts: Content-Type and message body encoding method. Now let’s start introducing them formally.

application/x-www-form-urlencoded

This should be the most common way to submit data via POST. If the enctype attribute is not set for the browser's native form, the data will eventually be submitted in application/x-www-form-urlencoded format. The request looks like this (irrelevant request headers are omitted in 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 specified as application/x-www-form-urlencoded; second, the submitted data is encoded in the form of key1=val1&key2=val2, and both key and val are URL-encoded. Most server-side languages ​​have good support for this approach. For example, in PHP, POST['title'] can get the value of title, POST['title'] can get the value of title, and _POST['sub'] can get the sub array.

Many times, we also use this method when submitting data with Ajax. For example, for JQuery's Ajax, the default value of Content-Type is "application/x-www-form-urlencoded; charset=utf-8".

multipart/form-data

This is another common way of submitting POST data. When we use a form to upload a file, we must set the enctyped of the form to be equal to this value. Let's take a look 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 a little more complicated. First, a boundary is generated to separate different fields. In order to avoid duplication with the main text content, the boundary is very long and complex. Then Content-Type indicates that the data is encoded in mutipart/form-data and what the boundary of this request is. The message body is divided into multiple similarly structured parts according to the number of fields. Each part starts with --boundary, followed by content description information, then a carriage return, and finally the specific content of the field (text or binary). If the file is being transferred, the file name and file type information must also be included. The message body ends with the --boundary-- tag. For the detailed definition of mutipart/form-data, please refer to rfc1867.

This method is generally used to upload files, and major server-side languages ​​also have good support for it.

The two methods of POSTing data mentioned above are both natively supported by browsers, and at this stage native forms only support these two methods. However, 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 Content-Type application/json as a response header. 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. Due to the popularity of the JSON specification, all major browsers except lower versions of IE natively support JSON.stringify, and server-side languages ​​also have functions for processing JSON, so there will be no trouble using JSON.

It's also useful that the JSON format supports structured data that is much more complex than just key-value pairs. I remember when I was working on a project a few years ago, the data level that needed to be submitted was very deep, so I serialized the data into JSON before submitting it. However, I used the JSON string as val, still put it in the key-value pair, and submitted it in x-www-form-urlencoded format.

The Ajax function in Google's AngularJS submits a JSON string by default. For example, the following code:

var data = {'title':'test', 'sub' : [1,2,3]};
$http.post(url, data).success(function(result) {
...
});

The final request sent is:

POST 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 particularly suitable for RESTful interfaces. Major packet capture tools, such as Chrome's built-in developer tools, Firebug, and Fiddler, will display JSON data in a tree structure, which is very user-friendly. However, some server-side languages ​​do not support this method yet. For example, PHP cannot obtain the content from the above request through the $_POST object. At this time, you need to do it yourself: when the Content-Type in the request header is application/json, get the original input stream from php://input, and then json_decode it into an object. Some Java frameworks have already started doing this.

Of course, AngularJS can also be configured to submit data using x-www-form-urlencoded.

text/xml

XML-RPC (XML Remote Procedure Call). It is a remote calling specification that uses HTTP as the transmission protocol and XML as the encoding method. A typical XML-RPC request looks like 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>

The XML-RPC protocol is simple, functional, and has implementations in various languages. It is also widely used, such as WordPress's XML-RPC Api, search engine's ping service, and so on. In JavaScript, there are also ready-made libraries that support data interaction in this way, which can well support existing XML-RPC services. However, I personally think that the XML structure is still too bloated, and JSON is more flexible and convenient for general scenarios.