Article source: blog.sina.com.cn/s/blog_9f6d…

If someone asks you, what’s the difference between GET and POST? How would you answer that?

My story

I was asked this question the other day. I said GET is for getting data, POST is usually for sending data to the server.

That didn’t seem to be the answer he was looking for. So he goes on to ask is there any other difference? I said it was just a name, and if the server supported it, he could have changed the name of GET to GET2. ‘Is that just a name difference?’ he asked. I thought about it, I think if the specific difference is to see the RFC documentation, but also depends on the server (Apache, IIS) specific implementation. But I have to admit that I haven’t really looked closely at the HTTP RFC documentation. So I said, I’m not familiar with the HTTP protocol. That’s the end of the problem.

The most common answer

After coming back, I pondered for a long time. What does he want to ask me? I’ve always felt there was no difference between GET and POST other than semantics, ever since I started learning Web programming.

His answer, as many of you might have guessed, was:

  1. GET uses the URL or Cookie to send parameters. POST puts the data in the BODY.
  2. GET urls are limited in length, and POST data can be very large.
  3. POST is safer than GET because the data is not visible on the address bar.

Unfortunately, these differences are all wrong, and unfortunately, the answer is the top of a Google search, which I didn’t even think was the answer, because they were all wrong to me. Let me explain them all.

1. GET and POST have nothing to do with how data is passed

GET and POST are defined by the HTTP protocol. In HTTP protocol, Method and Data (URL, Body, Header) are orthogonal concepts, that is to say, there is no correlation between which Method is used and how Data is transmitted at the application layer.

HTTP does not require that if the Method is a POST the data should be placed in the BODY. There is no requirement that if Method is GET, the data must be in the URL and not in the BODY.

So where did this popular Internet meme come from? I found a similar description in the HTML standard. That’s consistent with what’s been circulating on the Internet. But this is just the HTML standard’s convention on how HTTP is used. How can that be the difference between GET and POST?

Furthermore, modern Web servers support requests that include a BODY in a GET. Although this request cannot be made from a browser, the Web Server is not just for browsers, but for HTML servers.

What’s the use of knowing that? I don’t want to explain. Sometimes you have to hurt yourself to remember.

2. HTTP does not limit the length of GET or POST

The HTTP protocol explicitly states that neither HTTP headers nor Body have a length requirement. There are two reasons for limiting URL length:

  1. The browser. It is said that early browsers put limits on URL length. Internet Explorer is said to limit URL length to 2048 characters (it’s widely circulated, and countless colleagues agree). But I tried it on my own, I constructed a 90K URL to access Live.com through IE9, it works fine. You can’t trust anything on the Internet, even Wikipedia.
  2. The server. Long urls are also a burden on server processing. A session used to have very little data, but now if someone maliciously constructs several MEgabytes of urls and accesses your server constantly. The maximum number of concurrent requests on the server will obviously go down. Another way to attack the server is to tell the server that content-Length is a large number, and then just send a little bit of data to the server. Even if you have a timeout set, this deliberate timeout can overwhelm the server. For this reason, most servers limit URL length for security and stability reasons. However, this restriction applies to all HTTP requests and has nothing to do with GET or POST.

Security And security GET and POST do not matter

I think it’s really Chinese. I’ll tell you a little joke, and you’ll get a sense of how ridiculous this is.

People who think POST data is safer than GET data would say

“Beware of gentlemen but not villains; China small white much, can prevent small white users on the line.”

“Hum,” I don’t think however, “that you how don’t say, URL parameter all Encode, or Base64 once, small white also don’t understand.”

That person countered way, “Encode is too simple, clever little white can Decode and modify very easily.”

“I laughed.” The pot calls the kettle black. Even a cleverer man will cut and redistribute packages.

The man, in a sinister gesture, offered up an artifact — the ultimate power of explanation — and said, “This is not a trifle.”

My day ah.

One last thought

I had been working on Windows desktop applications and didn’t know much about Web development until I switched to server-side development a little over a year ago, when I was introduced to HTTP. (Note that I said HTTP, not HTML. The Server Open interface is designed based on REST concepts, using HTTP as the protocol, but not HTML as the content to transport. This is not a Web Server, but a Web Service.

So my understanding of GET and POST comes purely from the HTTP protocol. There is only one fundamental difference between them. Simply put, one is used to fetch data and one is used to modify it. For details, see the RFC documentation.

If you’re starting out as a Web developer, you’re likely to see HTML’s use of HTTP as the only legitimate use of HTTP. Thus made the mistake of overgeneralization.

Some people might think I’m overreaching. I just don’t like ambiguity. I don’t like unclear boundaries and concepts, I don’t like “copyism”, and I don’t like being ridiculed by other pushy people.

“Know is know, noknow is not know, is also know.”

\