Shulou(Shulou.com)06/02 Report--

1. General views on the difference between GET and POST:

HTTP defines different ways to interact with the server. The four most commonly used methods are Get, Post, Put and Delete. If I change the order, it will be easy to remember, Put (add), Delete (delete), Post (delete), Get (check), that is, add, delete, change and query. The following is a brief description:

1) Get, which is used to obtain information, note that it only acquires and queries data, that is to say, it will not modify the data on the server. From this point, it is data security, while Post, which will be mentioned later, can modify data, so this is one of the differences between the two.

2) Post, which can send a modification request to the server to modify the server, for example, we have to post on the forum and comment on the blog, which will use Post, of course, it can only get the data.

3) Delete deletes data. It can be achieved through Get/Post.

4) Put, adding and placing data can be realized through Get/Post. Do not use much, do not write more for the time being, expand in the future.

Here's a brief description of the difference between Get and Post:

1) the data requested by GET is placed in the HTTP header, that is, after URL, and the format is usually defined as follows (while Post puts the submitted data in the HTTP body).

Login.action?name=hyddd&password=idontknow&verify=%E4%BD%E5%A5%BD

A, to? To separate URL from data

B, delimiting parameters with &

C, if the data is in English or numbers, send it as is

D, if the data is Chinese or other characters, then BASE64 encoding.

2) GET submits less data, up to 1024B, because GET data is attached to URL, while URL is limited by different environments. For example, IE limits it to 2K+35, while POST can transfer more data. (in theory, there is no limit, but it is generally subject to different environments, such as browser, operating system, server processing capacity, etc. IIS4 can support 80KB IIS5 and 100KB).

3) the security of Post is higher than that of Get, because when Get, the parameter data is transmitted in clear text, and if you use GET, it may cause Cross-site request forgery***. POST data can be encrypted, but GET may be faster.

The above is transferred from: http://blog.csdn.net/wangzhilife/article/details/12440089

The above statement is generally known to those who have developed web; there may be some misunderstandings:

Many people may have guessed that the answer he wants is:

1. GET uses URL or Cookie to pass parameters. POST puts the data in BODY.

2. If the URL of GET is limited in length, the data of POST can be very large.

3. POST is more secure than GET because the data is not visible on the address bar.

But unfortunately, these differences are all wrong, and unfortunately, the answer is still on the front page of Google search, but I didn't think these were answers at all, because in my opinion, they are all wrong. Let me explain one by one.

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

GET and POST are defined by the HTTP protocol. In HTTP protocol, Method and Data (URL, Body, Header) are two orthogonal concepts, that is to say, which Method is used has nothing to do with how the data in the application layer is transmitted.

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

So, where does this saying come from, which is widely spread on the Internet? I found a similar description in the HTML standard. This is consistent with the story circulated on the Internet. But this is only the HTML standard's agreement on the use of the HTTP protocol. How can it be regarded as the difference between GET and POST?

Moreover, modern Web Server supports requests such as BODY in GET. Although this kind of request cannot be made from the browser, the current Web Server is not just for browsers and is completely beyond the scope of the HTML server.

What's the use of knowing this? I don't want to explain, sometimes I have to hurt myself to remember.

HTTP protocol has no restrictions on the length of GET and POST.

The HTTP protocol clearly states that there is no length requirement for HTTP headers and Body. There are two reasons for the restriction on the length of URL:

1. browser. It is said that early browsers would limit the length of URL. It is said that IE limits the length of URL to 2048 characters (widely circulated and agreed by countless colleagues). But I tried it myself, and I constructed a 90K URL to access live.com through IE9, which is normal. Things on the Internet, even on Wikipedia, can't be trusted.

two。 Server. URL has grown up, and it is also a burden on the server. Originally, there was not much data in a session, but now if someone maliciously constructs several megabytes of URL and keeps accessing your server. The maximum number of concurrency of the server will obviously decrease. Another way is to tell the server that Content-Length is a large number, and then send only a little data to the server. Hey, you just wait for the server to go. Even if you have a timeout setting, this deliberate timeout can be too much for the server. In view of this, for the sake of security and stability, most servers impose restrictions on the length of URL. But this restriction applies to all HTTP requests and has nothing to do with GET or POST.

Security has nothing to do with GET and POST.

The above comes from another blog post: http://kb.cnblogs.com/page/188928/

Here are two well-written blogs:

The first explanation is more detailed than the previous one: http://blog.csdn.net/yaojianyou/article/details/1720913/

The second article is pretentious from the perspective of tcp/ip, and the blog has a domineering name: http://www.techweb.com.cn/network/system/2016-10-11/2407736.shtml.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.