The difference between the get and post methods in the HTTP protocol

Reproduced

The usual understanding

W3Schools answers to this question: HTTP method: GET vs. POST Lists general understanding:

Method	GET	POST
Back button/Refresh	Harmless	The data is resubmitted (the browser should tell the user that the data will be resubmitted).
Bookmark	Bookmark can be bookmarked	Bookmark not available for collection
Cache	can be cached	Cannot be cached
Encoding type	application/x-www-form-urlencoded	Application/x-www-form-urlencoded or Multipart/form-data. Use multiple encodings for binary data.
History	The parameters remain in the browser history.	Parameters are not saved in the browser history.
Limits on the length of data	Yes. When data is sent, the GET method adds data to the URL, and the length of the URL is limited (the maximum length of the URL is 2048 characters).	Unlimited.
Restrictions on data types	Only ASCII characters are allowed.	There is no limit. Binary data is also allowed.
Security	GET is less secure than POST because the data being sent is part of the URL. Never use GET when sending passwords or other sensitive information!	POST is more secure than GET because parameters are not saved in the browser history or Web server logs.
Visibility of	The data is visible to everyone in the URL.	The data is not displayed in the URL.

Later, the classmate pointed out that the length of the URL is limited this is not right, the HTTP protocol does not limit the length of the URI, the specific length of the browser and system constraints.

This comparison only gives some differences in the phenomena, but does not explain why the understanding of this problem cannot be stopped on this level.

Misunderstood?

There is an article 99% of the people understand the wrong HTTP in the difference between GET and POST, denied the above answer: "Unfortunately, this is not our answer!" , the author says:

Get and post are essentially TCP links, and there is no difference. However, due to the HTTP rules andBrowser/continue, the browser sends data, the server responds with a $ OK (return data).

All talk about TCP, feel very tall wood has, at least at that time saw this article I was believed.

Reverse??

But at the time of the visit and saw this article: I heard that "99% people understand the wrong HTTP GET and POST differences"?? , pointing out the two errors in the preceding article:

 - ContinueOnly in the request brought expect: --It 's only meaningful when Continueheader. When the request contains an Expect header field that includes a --ContinueExpectation, the -Response indicates that the server wishes to receive the request payload body, asDescribedinchSection5.1.1. The client ought toContinueSending the request and discard the -Response. If the request did not contain an Expect header field containing the --ContinueExpectation, the client can simply discard ThisInterim response.

We're usually talking about GET vs POST, actually talking about specification, not implementation. What is specification? To be blunt is the relevant RFC. Implementation is all the Code/library that implements the description in specification/continue-continue  Thecontinue 2.5 frequently exploded and said that there were problems with the national standards for industrial emissions.

It seems more reasonable to say, and also moved out of rfc,specification,implementation these high-end words, this I eat melon people can no longer sit, decided to personally study.

RFC Quest

First, what is RFC? The wiki above is defined as:

Request for Comments (English: Request for Comments, abbreviated as RFC), is a series of memos published by the Internet Engineering Task Force (IETF). The document collects information about the Internet, as well as software files for the UNIX and Internet communities, to be numbered. The current RFC file is sponsored by the Internet Association (ISOC).

A simple understanding of the RFC is the specification of the Internet, we often call the "agreement" is in the form of RFC, and the current http/1.1 specification of the RFC has the following: RFC7230 , RFC7231, RFC7232, RFC7233, RFC7234, RFC7235. One of the RFC7231 section 4. Request methods involves several HTTP methods, and then read this section carefully.

 is  for  and  is expected by the client as a successful result.

here is a very important word: semantic"semantics, so what is semantics? This article gives an explanation: the difference between syntax and semantics.

A language is a collection of legitimate sentences. What kind of sentence is legal? It can be judged in two ways: syntax and semantics. Grammar is related to grammatical structure, but semantics are related to the meaning of word symbols combined in this structure. A reasonable grammatical structure does not imply that semantics are legal. For example, we often say: "I am in college, this sentence is in line with the grammatical rules, and also conforms to the semantic rules." But in college I, though it's grammatical, doesn't make sense, so it's not semantically correct.

for HTTP requests, the syntax refers to the format of the request response, such as the request that the first line must be 方法名 URI 协议/版本 in this format, the content can be found in the previous written "Graphic http" Reading notes inside the contents, and all the requests in accordance with this format are legitimate.

Semantics defines what the nature of this type of request is. For example, the semantics of Get is "to get the",post of resources "is" processing resources ", then in the concrete implementation of these two methods, it is necessary to consider its semantics, to make the behavior that conforms to its semantics.

Of course, it is possible to implement a violation of semantics in accordance with the syntax, such as using the Get method to modify the user information, post to get a list of resources, so that the request can only be said to be "legitimate", but not "in line with the semantics". It suddenly reminds me of two concepts in XML: Well formed and valid, which seem to be the idea of grammar and semantics.

As mentioned above, the method is the main source of the request semantics, that is, there are secondary sources, some request header can further modify the semantics of the request, such as a header with a Range GET request becomes part of the request.

The RFC7231 immediately defines several features of the HTTP method:

 The concept of Safe-idempotent is exactly the same as if the same request method executes multiple times and executes only once. According to RFC specification, Put,delete and security methods are idempotent. Again, this is just the norm, and the server implementation is not guaranteed to be idempotent. The introduction of idempotent is mainly to deal with the same request repeatedly sent, such as the request to lose the connection before the response, if the method is idempotent, you can safely resend the request. This is also the browser in the back /-cacheable As the name implies is a method can be cached, this RfC get,head and in some cases post is cacheable, but most of the browser's implementation only support get and head. More about caching can go to see RFC7234.

In these three features have been emphasizing the same thing, that is, the agreement is not equal to the realization: the Protocol stipulates that security is not necessarily safe in the implementation, the Protocol is not necessarily idempotent in the implementation, the Protocol provides that the implementation of a slow existence may not be cached. This is actually the relationship between the specification and implementation mentioned by the author above.

The controversy of semantics

This step, in fact, understand the difference between the two methods, essentially "semantic" contrast rather than "grammatical" contrast, is "specification" contrast rather than "implementation" contrast.

As for the semantics of these two methods, the original text in RFC7231 has been well written:

 for  is  and The focus of almost all performance optimizations. Hence, when people speak of retrieving some identifiable information via HTTP, they is generally referring to making a GE T request. A payload within a GET request message has no defined semantics; Sending a payload body on a GET request might cause some existing implementations to reject the request.

 in the request according to the resource's own specific semantics.

Scrape the slag upside down, plus a bit of your own understanding:

The semantics of Get is the request to get the specified resource. The Get method is secure, idempotent, cacheable (unlessconstrained by the cache-Control header), and the message body of the Get method has no semantics. The semantics of post is to handle the specified resource according to the request load (the message body), depending on the resource type. Post is unsafe, not idempotent, and (most implementations) not cacheable. In order to be non-cacheable, there are a number of ways to optimize and later have the opportunity to study (flag has been set up). Or a popular chestnut bar, in this scenario, get semantics will be used to "look at my timeline on the latest 20 micro-blog" Such a scene, and the semantics of post will be used in "tweet, comment, like" the scene. 

Summarize

This article from the usual understanding, after a challenge and another counter-doubt, twists, finally through the reading of the RFC specification deepened the understanding of the HTTP method, it is a pleasant exploration of the journey ~ My greatest feeling is: do not conform, to insist on independent thinking, not content with second-hand knowledge, Try to keep your own.

The difference between the get and post methods in the HTTP protocol