introduce:
Prior to this, the understanding of content-type was superficial, so the current understanding must be recorded for review
Content-Type can be understood as the content type from the name, but the professional term on the Internet is called "media type", that is, MediaType, also called MIME type, which is mainly used to indicate the type of the content of the main part of the message, such as html , json or xml and so on.
But content-type generally only exists in the Post method, because the Get method does not contain "body", and its request parameters will be encoded behind the url, so it is useless to add Content-type in the Get method.
Four common POST data submission methods
We know that the HTTP protocol is transmitted in ASCII code and is an application layer specification based on the TCP/IP protocol. The specification divides HTTP requests into three parts: status line, request header, and message 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 method the data must use. In fact, developers can completely decide the format of the message body, as long as the last sent HTTP request satisfies the above format.
However, it only makes sense for the data to be sent out only if the server-side parsing is successful. General server-side languages such as php, python, etc., as well as their frameworks, have built-in functions for automatically parsing common data formats. The server usually learns the encoding method of the message body in the request according to the Content-Type field in the request header (headers), 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. Let's start to introduce them officially.
application/x-www-form-urlencoded
This should be the most common way to submit data through POST. For 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 is similar to the following (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 according to 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, when we use Ajax to submit data, we also use this method. For example, in 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 another common way to submit POST data. When we use the form to upload files, we must make the enctyped of the form equal to this value. Just look at an example 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 The example is a little more complicated. First, a boundary is generated to split different fields. In order to avoid duplication with the content of the text, the boundary is very long and complicated. Then Content-Type indicates that the data is encoded in mutipart/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 starts with --boundary, followed by content description information, followed by carriage return, and finally the specific content of the field (text or binary). If the transfer is a file, also include the file name and file type information. The message body ends with the --boundary-- flag. For the detailed definition of mutipart/form-data, please check the protocol 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 the browser, and the native form form only supports these two methods at this stage. But as more and more Web sites, especially WebApps, all use Ajax for data interaction, we can completely define new data submission methods to bring more convenience to development.
application/json
The Content-Type of application/json is a response header that everyone is familiar with. 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-version IE all natively support JSON.stringify, and the server-side language also has functions for processing JSON, so you will not encounter any trouble when using JSON.
It is also useful that the JSON format supports much more complex structured data than key-value pairs. I remember that when I was working on a project a few years ago, the level of data that needed to be submitted was very deep. I submitted the data after JSON serialization. But at that time, I used the JSON string as val, still put it in the key-value pair, and submitted it in x-www-form-urlencoded way.
The Ajax function in Google's AngularJS is to submit 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 especially 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 friendly. However, some server-side languages do not yet support this method. For example, PHP cannot obtain 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 php frameworks already 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
XML-RPC (XML Remote Procedure Call). It is a remote invocation specification that uses HTTP as the transport protocol and XML as the encoding. 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>
</methodcall>
The XML-RPC protocol is simple, functional, and available in various languages. It is also widely used, such as the XML-RPC Api of WordPress, the ping service of search engines, 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 it is more flexible and convenient to use JSON in general scenarios.
Additional types:
Setting the transfer data to the specified data format is to tell the receiver of the request that the data format of the body is in the specified format. After receiving the data, the receiver can directly use the corresponding formatting method to convert it into a data object or framework for processing language recognition The interceptor automatically converts and can detect errors in data transmission earlier.
If it is passed directly through text/plain, the receiver needs to perform its own judgment on how to process the data. This is more of a normative requirement for front-end and back-end API interfaces
text/plain: It is an unformatted text, and the data exists in plain text, including ( text/html, text/json, text/xml ) format encoding, which does not contain any control or format characters.
Thanks to the blogger: https://blog.csdn.net/jam_yin/article/details/51837204
Reprinted in: https://www.cnblogs.com/unknows/p/8724729.html