99% of people understand the wrong difference between get and post in HTTP (go)

Get and post are the two basic methods of HTTP requests, and the difference between them is that people who have been exposed to web development can say one or two.

The most intuitive difference is that the get parameter is included in the URL, and the post passes the parameters through the request body.

You may have written numerous get and post requests yourself, or have seen the differences that many authoritative websites have summed up, and you know exactly when to use them.

When you are asked this question in an interview, your heart is full of confidence and joy.

You give a "standard answer" in a very loose light:

Get is harmless when the browser is rolled back, and post submits the request again. Get generated URL address can be bookmark, and post is not available. The GET request will be active by the browser cache, and post will not, unless manually set. A GET request can only be URL-encoded, while post supports multiple encoding methods. The GET request parameters are kept intact in the browser history, and the parameters in the post are not retained. A GET request has a length limit for the parameters that are passed in the URL, and post does. For data types of parameters, get accepts only ASCII characters, while Post has no restrictions. Get is less secure than post, because parameters are directly exposed to URLs, so they cannot be used to pass sensitive information. The get parameter is passed through the URL and the post is placed in the request body.

"Unfortunately, this is not the answer we want!"

Please tell me the truth ...

If I told you get and post are essentially no difference do you believe?

Let's take off the coat of Get and post, and be frank!

What is get and post? Two methods of sending requests in the HTTP protocol.

What is HTTP? HTTP is a TCP/IP-based protocol about how data communicates in the World Wide Web.

The underlying HTTP is TCP/IP. So the bottom of GET and post is TCP/IP, which means that get/post are TCP links. Get and post can do the same thing. You have to add the request body to the GET, and the URL parameter to the post, technically it's all in line.

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

In my big World Wide Web, TCP is like a car, we use TCP to transport data, it is very reliable, never happen missing pieces of the phenomenon. But if the road is full of seemingly identical cars, then the world looks like a mess, the dispatch of the car may be in front of the full load of cars blocked on the road, the entire transport system will be paralyzed. In order to avoid this happening, traffic rules HTTP was born. HTTP has set up several service categories for car transport, get, POST, PUT, delete, and so on, HTTP rules, when executing a GET request, the car is labeled with a get (set method is get), and requires the transfer of data placed on the roof (URL) for easy recording. If it is a POST request, attach the post label to the car and put the goods in the compartment. Of course, you can secretly hide the goods in the car when get, but it is very disgraceful, you can also put some data on the roof at the post, it makes people feel silly. HTTP is just a code of conduct, and TCP is the basic of how get and post are implemented.

However, we only see that HTTP is asking for the delivery channel (URL or requrest body) of the Get and post parameters. In the "standard answer" about the size of the limits of the parameters from where?

In My big web world, there is another important role: transport companies. Different browsers (initiating HTTP requests) and servers (accepting HTTP requests) are different shipping companies. Although theoretically, you can load unlimited loads on the roof (unlimited parameters in the URL). But transport companies are not stupid, loading and unloading is also a big cost, they will limit the single traffic to control the risk, the volume of data is too large for the browser and server is a big burden. The industry's unwritten rule is that (most) browsers typically limit URLs that are 2K bytes long, while (most) servers handle up to a 64K-size URL. Over the part that is not processed. If you use Get service, in the request body secretly HID data, different server processing way is also different, some servers will help you unload, read out data, some servers directly ignore, so, although get can take request body, there is no guarantee will be received OH.

Well, now you know that get and post are essentially TCP links, and there's no difference. However, due to the HTTP rules and browser/server restrictions, they have shown some differences in the application process.

You think this is the end of this article?

Our big Boss is waiting for the appearance ...

How mysterious is this boss? When you try to find the "get and post differences" on the Internet, the search results that you will see never mention him. What the hell is he?

There is also a significant difference between get and post, which simply says:

Get generates a TCP packet; Post generates two TCP packets.

The long said:

For the Get mode request, the browser will send the HTTP header and data in a concurrent delivery, the server response 200 (return data);

For post, the browser first sends the header, the server responds to the continue, the browser sends the data, and the server responds with a $ OK (return data).

In other words, get only need a car to run a trip to the goods sent to, and post to run two times, the first trip, first go and the server to say hello "Hi, I will send a batch of goods, you open the door to greet me", and then back to the goods sent to the past.

Because post takes two steps, it consumes a bit more time and looks like get is more efficient than post. So the Yahoo team recommends using get to replace post to optimize site performance. But this is a pit! Jumping in requires caution. Why?

1. Both get and post have their own semantics and cannot be mixed.

2. According to research, in a good network environment, the time to send a packet and two times the time difference between packets can be ignored. In the case of poor network environment, two packets TCP has a great advantage in verifying the integrity of packets.

3. Not all browsers will send two packets in post, and Firefox will send them only once.

Now, when the interviewer asks you the difference between get and post, is your heart like this?

99% of people understand the wrong difference between get and post in HTTP (go)