Real difference between GET and POST-PHP source code

The real difference between GET and POST is no longer transmitted using uploads.

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

What is the difference between GET and POST? 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 it. I think that if we talk about the specific difference, we can only look at the RFC document, but also depend on the specific implementation of the server (Apache, 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.

However, unfortunately, these differences are all incorrect. Unfortunately, this answer is still the headlines of Google search. However, I didn't even think of these answers, in my opinion, they are all wrong. 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 to say, there is no relationship between which Method is used and how Data is transmitted at the application layer.

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, 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 didn't agree. "Why don't you say that URL parameters have been encoded, or Base64? I can't understand it either ."

The man retorted, "Encode is too simple. it's easy to Decode and modify it if you're a little smart ."

I smiled and said, "If you are a little more intelligent, you can cut packets and try again. Opera has this function ."

The man maliciously sacrificed the artifact-the right to final interpretation, and 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 have only one fundamental difference. to put it simply, 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 ."