What is the fundamental difference between post and get?

1. What is the fundamental difference between post and get? (Please do not answer post security or post-delivery information with large capacity)
2. Please analyze the difference between post and get from the point of view of packet packets

Thank you

Reply content:

1. What is the fundamental difference between post and get? (Please do not answer post security or post-delivery information with large capacity)
2. Please analyze the difference between post and get from the point of view of packet packets

Thank you

From a restful perspective:
1. Get is a query resource, post is an increase in resources
2. Power and other characteristics.
Get,put,delete are idempotent operations.
Post is not.
Specifically you can Google a restful related article. Nanyi This can also be seen: http://www.ruanyifeng.com/blog/2011/09/restful.html

In terms of protocol, post and get are different from the first line of the message, and get can also carry Content-body

Add, post can also receive query string, the simplest chestnut is

Get can also have the body, the protocol only said that the server does not care about get the body (tacitly allowed to take), but not expressly prohibited to carry, comments are also referred to the Elasticsearch chestnut

Get post semantics, idempotent differences, I think it's out of the protocol or the scope of the capture that the Lord wants.

Before facing the concept of restful is very clear, I add here, here is a GET request, I am not lazy here to grab the bag, directly in the Chrome console copy, you say from the message of the way analysis, I can directly tell you the essential difference
I think the essential difference between get and post is the difference in where the parameters are placed,

Get is placed in the header (so there is a limit to the length of the browser, the URL length limit), post is placed in the body (length unlimited),

If you ask me what is the difference between the header and body, I can only hehe (recommended to grab a packet to see), are TCP data stream, header and body is two/r/n separate

Get Remote address:222.186.132.183:80request url:http://qiniu-plupload.qiniudn.com/bb.png?imageview2/1/w/100/h/ 100Request method:getstatus code:200 okresponse headersview sourceaccept-ranges:bytesaccess-control-allow-origin:* Access-control-max-age:2592000cache-control:public, Max-age=31536000connection:keep-alivecontent-length : 15509content-type:image/pngdate:wed, APR 07:01:08 gmtetag: "Alcdknr1wgnfuximbrweuxoe76oq" Server:nginx/ 1.4.4x-log:mc.g/404;mc.g:2; rs:2;mc.s;dc/404; fopdc/404; fopagent;image:239; fopagent:240; fopagent;image:239; fopagent:240; fopg:241; fopagent;io:249x-qiniu-zone:0x-reqid:yvqaabbhtnn3adktx-via:1.1 tzh57:8110 (Cdn Cache Server V2.0), 1.1 zhenjiang157 : Ten (Cdn Cache Server V2.0) x-whom:nb263request Headersview Sourceaccept:image/webp,*/*;q=0.8accept-encoding:gzip, Deflate, Sdchaccept-language:zh-cn,zh;q=0.8cache-control:no-cacheconnection:keep-alivehost: Qiniu-plupload.qiniudn.compragma:no-cachera-sid:de49cae2-20141215-034718-ab4eeb-10884dra-ver:2.10.0referer: /HTTPjssdk.demo.qiniu.io/user-agent:mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) applewebkit/537.36 (khtml, like Gecko) chrome/42.0.2311.90 safari/537.36query String Parametersvie W sourceview URL encodedimageview2/1/w/100/h/100:

Remote address:183.136.139.10:80request url:http://up.qiniu.com/request method:poststatus Code:200 OKResponse Headersview Sourceaccess-control-allow-headers:x-file-name, X-file-type, X-file-sizeaccess-control-allow-methods : OPTIONS, HEAD, Postaccess-control-allow-origin:*access-control-max-age:2592000cache-control:no-store, No-cache, Must-revalidateconnection:keep-alivecontent-length:54content-type:application/jsondate:wed, APR 2015 07:01:08 Gmtpragma:no-cacheserver:nginx/1.4.4x-content-type-options:nosniffx-log:s.ph;s.put.tw;s.put.tr:5;s.put.tw:1; s.put.tr:4;s.ph;s.put.tw:1;s.put.tr:5;s.ph; Pfds:12; Pfds:13; Pfds:14;rdb.g/no such key;dbd/404;dbg/404;v4.exist:1/document not found;rs12_9.ins;qtbl.ins:2;mc.s; rs:3;rs.put:4;rs-upload.putfile:20; Up:27x-reqid:-zwaabhcpxl3adktrequest Headersview Sourceaccept:*/*accept-encoding:gzip, DeflateAccept-Language: Zh-cn,zh;q=0.8cache-control:no-cacheconnection:keep-alivecontent-length:620773content-type:multipart/form-data ; boundary=----WebkitformboundaRyb5pfxdf4m1ocl5qmhost:up.qiniu.comorigin:http://jssdk.demo.qiniu.iopragma:no-cachera-sid:d e49cae2-20141215-034718-ab4eeb-10884dra-ver:2.10.0referer:http://jssdk.demo.qiniu.io/user-agent:mozilla/5.0 ( Macintosh; Intel Mac OS X 10_10_1) applewebkit/537.36 (khtml, like Gecko) chrome/42.0.2311.90 safari/537.36request Payload------WEBK Itformboundaryb5pfxdf4m1ocl5qmcontent-disposition:form-data; Name= "name" bb.png------webkitformboundaryb5pfxdf4m1ocl5qmcontent-disposition:form-data; Name= "Chunk" 0------webkitformboundaryb5pfxdf4m1ocl5qmcontent-disposition:form-data; Name= "chunks" 1------webkitformboundaryb5pfxdf4m1ocl5qmcontent-disposition:form-data; Name= "key" bb.png------webkitformboundaryb5pfxdf4m1ocl5qmcontent-disposition:form-data; Name= "token" 0mlvwpnyya1wtpnxfy9klyghyfpndzceomlvk0c9:d5m0tc6iyvvxmsweqxn-_cjhed0=: EYJZY29WZSI6INFPBML1LXBSDXBSB2FKIIWIZGVHZGXPBMUIOJE0MZAYOTQ0NDD9------Webkitformboundaryb5pfxdf4m1ocl5qmcontent-dispositi On:form-data; Name= "File"; Filename= "Bb.png" Content-type:image/png------webkitformboundaryb5pfxdf4m1ocl5qm-- 

I think the essential difference between get and post is the difference in where the parameters are placed,

Get is placed in the header (so there is a limit to the length of the browser, the URL length limit), post is placed in the body (length unlimited),

The post I posted here is in form-data format,

There are a lot of people who confuse the x-www-form-urlencoded in post with get requests because, on the server side, many language frameworks have the same way of getting parameters for both requests.

Below you can see the x-www-form-urlencoded way

POST http://www.example.com HTTP/1.1Content-Type: application/x-www-form-urlencoded;charset=utf-8title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3

This article is very clear.

The main problem is that many people now use get to submit data. This is a trickery (or lazy) approach to protocol specification. Because get is originally designed to fetch data (the HTTP protocol states that the Get and head methods should only fetch resources rather than perform actions). But the use of get is relatively simple, the use of post need to create a form on the Web page, relatively troublesome, so we have to do so.
One of the less appropriate examples is that the post is a pen and is designed to write. Get is a lipstick, not designed to write, but sometimes used to write.
However, it is still necessary to point out that using get instead of post is not a good habit. Because a get operation may be incorrectly cached by some poorly designed systems, this can cause the corresponding request to not be executed. At the same time, using get instead of post is also prone to XSS problems.

From the HTTP protocol specification, Xelz has already answered. The HTTP protocol does not explicitly state that get does not allow the body of the message (I simply looked at it as if it was not, if there was an error), but also did not define any function of the get message body. So now the Web server receives a GET request with the message body can also be handled correctly, but the message experience is ignored.

This may be more or less restful credit, post/delete/put/get and data manipulation, online data many.

POST /uri 创建DELETE /uri/xxx 删除PUT /uri/xxx 更新或创建GET /uri/xxx 查看

In addition, the URL has a length limit, (although it is long, but sometimes not necessarily enough)

Can see this article link description

Recommend you look at 2 articles, the first is more popular than the second one, the second one in the back of some of the HTTP protocol things, in fact, they are the difference.
What is the difference between get and post?
HTTP POST Get detailed

Get 10,000 times get the same thing post is different. This is the idempotent and non-idempotent

Get gets the relationship to the post given

The essential difference is where the data is placed.

The difference of nature is idempotent.

My understanding:
The post submission is implicit. (The submitted parameters are hidden for the traffic person)
Get commits are explicit. (The submitted parameters are included in the URL and are visible)

If you have to say something different, that is, the browser processing the two protocols, get to refresh a few times, the post refresh will prompt "repeating the form", not to give the two hats, it should be based on the habit passed down, these two things "idempotent" different.

As for the background processing post and get there is no difference, it is not good to say.
Previously seemingly tried, JSP Servlet.getparameter not take the post placed in the URL parameters. I'm not sure.

1. There is no body part, that is, except the URL and the head, there is no information body is the fundamental difference. So get cannot be used to transfer large amounts of data from the client to the server side. Because get all parameters are in the URL (browser address bar).
2. HTTP is the application-layer protocol, which is generally based on the TCP protocol's reliable data flow. So parsing HTTP does not have to parse packets and packets.

Example:
Get method:
Get/index.html?name=leo http/1.1
Accept: / <这是头部>
<空行>
End

Post method:
Post/index.html http/1.1
Acept: /
Content-length:10
<空行>
1234567890
<空行>
End

When grasping the bag, you can find:
Get generally 1 to 2 TCP packets (information header and data together, if the information header content will produce 2 or more packets), and post at least 2 packets (the first packet is the information header, the second is the data).

Hey, you really do not have to do every day, this kind of problem is clear to the development of what help? Program is used to solve the problem, you are purely theoretical research, anyway, I am ignorant fearless, it knowledge is not learning, can use some are good, die pick this you can pick up 10 years, and finally pull out there is no application scenario of the year

