The first time I write on the nuggets, I’m shaking now, and I hope that bill (´∀ ‘) righted myself

The most obvious difference is semantic

  • Get is used to get data, and POST is used to submit data
  • The GET argument is limited in length (by url length, depending on the browser and server, up to 2048 bytes), while the POST argument is unlimited.
  • The data of the GET request is appended to the URL, starting with “? “Split url and transfer data, multiple parameters are concatenated with ampersand, whereas A POST request puts the requested data in the HTTP request body.
  • Get is in plaintext, post is in the body of the request, but the developer can see it through the packet capture tool, and it is also in plaintext.
  • Get requests are saved in the browser history and possibly in the Logs of the Web server

From the current perspective, POST is more secure than GET, at least the requested data is not visible at the URL. But is that really all??

Wrong, wrong ？？？？？

  • That is safe after all or not safe ？？？？？

The first thing you need to decide is what defines security (for example).

  • Do you feel safe sending my mom, dad, uncle and aunt to look at this URL?
  • You let a junior test engineer test the interface, do you feel safe?
  • Why don’t you ask the security test engineer to look at the GET request? So the definition of safety is different depending on the crowd
  • The truth

First of all, get and POST are both TCP links in nature, but due to HTTP protocol and browser or server restrictions, they are different in application process, but there is a major difference between them: Get sends a packet during the request, sending the header and data together, while POST generates two packets. The server sends the header first, and returns 100. The server returns 200 after sending data

So when you break down get and POST layer by layer, you will find that they are essentially TCP connections. There is no difference between them, but they are represented differently in the application process due to HTTP protocol regulations and browser or server restrictions.

What the hell is RFC?

Some time ago when I saw someone talking about this issue someone pulled out the RFC, so what is the RFC?

  • Request For Comments (RFC) is a series of numbered files. The file collects information about the Internet, as well as software files for the UNIX and Internet communities. (From Baidu Encyclopedia)

Put it this way! RFC is the specification of the Internet, and the protocol commonly referred to is the existence of RFC. RFC7231 in THE HTTP /1.1 specification involves several HTTP methods, which define several properties:

1. [‘ t? : n]

Security doesn’t mean security in the usual sense, just as a request is secure if its semantics are essentially to get data (read only). A request from a client to the server is safe if it does not cause any state change on the server, and a POST request to submit data must cause the server to change accordingly. From this perspective, GET requests are secure relative to the server, while POST is not.

Ldempotend

Idempotent means, in plain English, that the same request executed multiple times has exactly the same effect as executing it only once. If the connection is lost before the request responds, then the request can be safely reissued if the request is idempotent. Therefore, it can be concluded that when GET request is idempotent, the request can be repeated, while when POST request is not idempotent, repeated request may have unpredictable consequences.

Cacheable

For the most part, POST is not cacheable (some browsers may support POST caching), but GET is cacheable.

To put it mildly:

Get requests to obtain specified resources. It is secure, idempotent, and cacheable. The packet body of GET does not have any semantics.

Post processes a specified resource based on the packet body. Post is not secure, idempotent, or cacheable (in most cases).

Good, today pull so much first, have big guy discovery wrong please help me correct correct, crab crab crab crab! Slip first!