99% of people misunderstand the difference between GET and POST in HTTP (reprinted-HTML Tutorial-php.cn

GET and POST are the two basic methods of HTTP requests. Anyone who has been exposed to WEB development can tell their differences.

The most intuitive difference is that GET includes parameters in the URL, and POST passes parameters through the request body.

You may have written countless GET and POST requests yourself, or you have read many authoritative websites summarizing their differences. You know exactly when to use which one.

When you are asked this question in the interview, your heart is filled with confidence and joy.

You easily gave a "standard answer":

GET is harmless when the browser rolls back, while POST submits the request again.
The URL address generated by GET can be Bookmarked, but POST cannot.
GET requests will be actively cached by the browser, but POST will not unless manually set.
GET requests can only be URL encoded, while POST supports multiple encoding methods.
GET request parameters will be completely retained in the browser history, while parameters in POST will not be retained.
There is a length limit on the parameters transmitted in the URL for the GET request, but there is no length limit for POST.
Regarding the data type of parameters, GET only accepts ASCII characters, while POST has no restrictions.
GET is less secure than POST because the parameters are directly exposed on the URL, so it cannot be used to pass sensitive information.
GET parameters are passed through the URL, and POST is placed in the Request body.

(This standard answer is referenced from w3schools)

"Unfortunately, this is not the answer we are looking for!"

Please tell me the truth. . .

If I told you that there is essentially no difference between GET and POST, would you believe it?

Let us take off the cloak of GET and POST and be honest with each other!

What are GET and POST? Two methods of sending requests in the HTTP protocol.

What is HTTP? HTTP is a protocol based on TCP/IP about how data is communicated on the World Wide Web.

The bottom layer of HTTP is TCP/IP. So the bottom layer of GET and POST is also TCP/IP, that is to say, GET/POST are both TCP links. GET and POST can do the same thing. You need to add request body to GET and url parameters to POST. Technically, it is completely feasible.

So, what are the differences in the "standard answers"?

In our world of the World Wide Web, TCP is like a car. We use TCP to transport data. It is very reliable and there will never be any missing items. But if all the cars on the road look exactly the same, the world will look like a mess. Cars delivering urgent messages may be blocked by cars laden with goods in front of them, and the entire transportation system will definitely be paralyzed. To prevent this from happening, Traffic Rules HTTP was born. HTTP has set several service categories for car transportation, including GET, POST, PUT, DELETE, etc. HTTP stipulates that when executing a GET request, the car must be labeled with a GET (set the method to GET), and require Put the transmitted data on the roof of the car (in the url) for easy recording. If it is a POST request, a POST label must be attached to the car and the goods must be placed in the carriage. Of course, you can also secretly hide some goods in the car during GET, but this is very disgraceful; you can also put some data on the roof during POST, which makes people feel silly. HTTP is just a code of conduct, and TCP is the basis for how GET and POST are implemented.

However, we only see that HTTP imposes requirements on the transmission channel of GET and POST parameters (url or request body). Where does the limit on parameter size in the "standard answer" come from?

In my big world of the World Wide Web, there is another important role: transportation companies. Different browsers (initiating http requests) and servers (accepting http requests) are different transportation companies. Although in theory, you can pile unlimited goods on the roof of the car (unlimited parameters can be added to the URL). But transportation companies are not stupid. Loading and unloading are also very costly. They will limit the volume of a single shipment to control risks. Too much data will put a great burden on the browser and server. The unwritten rule in the industry is that (most) browsers usually limit URL length to 2K bytes, and (most) servers can handle URLs up to 64K in size. Any excess will not be processed. If you use the GET service and secretly hide data in the request body, different servers handle it differently. Some servers will help you unload and read the data, while some servers ignore it directly. Therefore, although GET can bring the request body, it cannot Guaranteed to be received.

Okay, now you know that GET and POST are essentially TCP links, there is no difference. However, due to HTTP regulations and browser/server limitations, they show some differences in the application process.

You thought this article ended like this?

Our big BOSS is still waiting to appear. . .

How mysterious is this BOSS? When you try to find "the difference between GET and POST" on the Internet, it is never mentioned in the search results you will see. What exactly is he? . .

There is another important difference between GET and POST. Simply put:

GET generates one TCP packet; POST generates two TCP packets.

The long one said:

For GET request, the browser will send the http header and data together, and the server will respond with 200 (return data);

For POST, the browser sends the header first, the server responds with 100 continue, the browser then sends data, and the server responds with 200 ok (return data).

In other words, GET only requires one trip by car to deliver the goods, while POST requires two trips. On the first trip, go and say hello to the server, "Hey, I'm going to deliver a batch of goods later. You guys?" Open the door to greet me" and then turn back to deliver the goods.

Because POST requires two steps and takes a little more time, it seems that GET is more efficient than POST. Therefore, the Yahoo team recommends replacing POST with GET to optimize website performance. But this is a trap! Jump in with caution. Why?

1. GET and POST have their own semantics and cannot be mixed casually.

2. According to research, when the network environment is good, the difference between the time of sending one package and the time of sending two packages can be basically ignored. In the case of poor network environment, TCP with two packets has great advantages in verifying the integrity of data packets.

3. Not all browsers will send the package twice in POST, Firefox only sends it once.

Now, when the interviewer asks you "the difference between GET and POST" again, is this what you feel in your heart?