What is the difference between get and post? And why most answers on the Internet are wrong.

ArticleDirectory

• Get and post are irrelevant to how data is transmitted.
• HTTP does not limit the length of get or post.
• Security and security are not related to get and post.

If someone asks you,GetAnd postWhat is the difference? How would you answer?

My experiences

Someone asked me this question a few days ago. In my opinion, get is used to obtain data, and post is generally used to send data to the server.

This answer does not seem to be what he wants. So he continued to ask if there were any other differences? I said this is just a name. If the server supports it, he can change "get" to "get2. He asked, What is the difference between simple names? I thought about the difference. I think I can only go to the RFC documentation.Depends on the serverApache, IIS).. However, I have to admit that I did not carefully read the RFC document of HTTP. So I said, I am not familiar with the HTTP protocol. This problem is over.

The most common answer

I have been thinking for a long time since I came back. What does he want to ask me? I have always felt that get and post have no difference except semantics. I started to learn web programming and understood it that way.

As many people may have guessed, the answer is:

1. Get uses URL or cookie to pass parameters. Post puts the data in the body.

2. Get URLs have length restrictions, so the post data can be very large.

3. Post is safer than get because the data is invisible in the address bar.

But unfortunately,These differences are all incorrect,Unfortunately, this answer is still the headlines of Google search, but I didn't even think about it because they are all wrong in my opinion. Let me explain it one by one.

Get and post are irrelevant to how data is transmitted.

Get and post are defined by the HTTP protocol. In HTTP, method and data (URL, body, header) are two orthogonal concepts, that is,Which method is used and how data is transmitted at the application layer is irrelevant..

HTTP is not required. If the method is post data, it must be placed in the body. There is no requirement either. If the method is get, the data (parameter) must be placed in the URL rather than in the body.

So where did the widely circulated online saying come from? I found a similar description in the HTML standard. This is consistent with the statement circulating on the Internet. However, this is only an HTML standard convention for HTTP protocol usage. How is the difference between get and post?

In addition, modern Web servers support requests such as get containing the body. Although such requests cannot be sent from the browser, the current web server is not only used by the browser, it is completely beyond the scope of the HTML server.

Do you know how to use this? I don't want to explain it. Sometimes I have to remember it after a pain.

HTTP does not limit the length of get or post.

The HTTP Protocol clearly states that neither the HTTP header nor the body has a length requirement. There are two reasons for the restriction on the URL Length:

1. browser. It is said that early browsers will limit the URL length. It is said that IE will limit the URL length to 2048 characters (widely spread, and many colleagues agree ). But I tried it myself. I constructed a 90 K URL and accessed live.com through ie9, which is normal. Online content, even on Wikipedia, cannot be sent.

2. server. The URL is too long to process the server. The original session does not have much data. Now, if someone maliciously constructs several M-sized URLs and keeps accessing your server. The maximum concurrency of the server is obviously decreased. Another attack method is to tell the server that Content-Length is a large number, and then send only a little data to the server. Hey hey, you can wait for the server. Even if you have time-out settings, this deliberate time-out for the second access can make the server fail to eat. In view of this, most servers impose restrictions on the URL Length for security and stability considerations. However, this restriction applies to all HTTP requests and has nothing to do with get and post.

Security and security are not related to get and post.

I think this is really a Chinese feature. Let me tell you a little bit about it. You should be able to understand how ridiculous it is.

People who think post data is safer than get data will say

"Anti-gentleman does not defend against villains; there are too many Chinese whites to defend against white users ."

"Hum ,"I disagree,"Why don't you say that,URLEncode for all parametersOver, or base64I can't understand it either ."

The man retorted,"EncodeIt's too simple. It's easy to decode a little bit of intelligence.And modify it ."

I smiled,"Fifty-fifty,OperaThis function is available ."

The man secretly sacrificesArtifact-right of final interpretation, Said,"This is not a small white ."

My day.

Last thought

I have been working on Windows desktop applications and have little knowledge about web development. I started to access HTTP more than a year ago when I switched to server-side development. (Note: I am talking about HTTP, not HTML. The server open interface is designed based on the concept of rest. The protocol used is HTTP, but the transmitted content is not HTML. This is not a Web server, but a Web Service)

Therefore, my understanding of get and post is purely from the HTTP protocol. They onlyOne pointThe fundamental difference is that one is used to obtain data and the other is used to modify data. For more information, see RFC.

If a person starts web development from the very beginning, he may regard the use of HTML for the HTTP protocol as the only reasonable use of the HTTP protocol. In this way, I made a false positive.

Some people may think that I have a point. I just don't like ambiguity, I don't like unclear boundaries, concepts, "tailism", and I don't like being overwhelmed by other people who like it.

"knowing is knowing, not knowing, or knowing ."