This article introduces HTTP and TCP protocols, their differences and connections

The introduction

This article explores the differences between GET and POST from the following aspects:

• The standard answer given by W3School
• Start with what is HTTP and dive into GET and POST request methods, the essential differences between the two
• Common GET and POST misunderstandings
• Is POST more secure than GET?
• POST method produces two TCP packets?

The standard answer

GET and POST are two of the most common methods used in HTTP requests, and the distinction between GET and POST is a familiar one

	GET	POST
Back button/refresh	harmless	The data will be resubmitted (browsers should inform users that the data will be resubmitted).
bookmarks	Bookmark	Do not bookmark
The cache	Can be cached	Can’t cache
The encoding type	application/x-www-form-urlencoded	Application/x – WWW – form – urlencoded or multipart/form – the data. Use multiple encoding for binary data.
history	Parameters are retained in browser history.	Parameters are not saved in browser history.
A limit on the length of data	Yes. When sending data, the GET method adds data to the URL; URL length is limited (maximum LENGTH of URL is 2048 characters).	Unlimited.
Restrictions on data types	Only ASCII characters are allowed.	There is no limit. Binary data is also allowed.
security	GET is less secure than POST because the data sent is part of the URL. Never use GET! When sending passwords or other sensitive information.	POST is more secure than GET because parameters are not saved in browser history or Web server logs.
visibility	The data is visible to everyone in the URL.	The data is not displayed in the URL.

The above is the standard answer given by W3School

But do you really understand it? After all we have learned about HTTP, is that enough to answer? GET and POST are both HTTP request methods. How to understand request methods? What are the essential differences?

Let’s step through the GET and POST methods and the essential differences between them

Drill down into GET and POST request methods

1. What is HTTP?

HyperText Transfer Protocol (HTTP) is an application-layer Protocol based on TCP. Among them:

• Hypertext: images, audio, video, and even compressed packages
• Transmission: Two-way transmission of data between two points
• Agreement: A convention and specification of behavior

Therefore, HTTP protocol is more easily described as a computer world dedicated to the transfer of text, images, audio, video and other hypertext data between two points of the convention and specification

Although HTTP is a “transport protocol”, it does not care about the details of the transmission, such as addressing, routing, and data integrity. These details are handled by TCP/IP. For example, IP implements addressing and routing, and TCP implements reliable data transmission. In addition, DNS protocol to achieve domain name search, SSL/TLS protocol to achieve secure communication

What’s the main reason for the HTTP protocol?

2. HTTP message

The core part of THE HTTP protocol is the format of the packets that it defines, such as packet composition and resolution rules. In this way, TCP/IP can implement various and flexible functions, such as cache control, data coding, and content protocol

HTTP packets are divided into four parts:

• Start line: the request line in the request message and the status line in the response message (indicating the response status of the server)
• Head: the header
• Empty line: There is an empty line between header and body
• Entity: We usually say body

Note: This message ends with a blank line and no body.

The request method is specified in the start line:

• Request line: GET/URI HTTP/1.1, including request methods such as GET or POST

• Status line: HTTP/1.1 200 OK, contains only the status of the server’s response, not the request method

Request method

The client initiates an HTTP request, and the server responds to the request. The client can perform operations on the server, such as querying, adding, and deleting resources.

This is the significance of the request method. It specifies some operation instruction on the client side, which is used to tell the server side what operation I need to do. Common request methods are:

• GET: Obtains resources. It is used to read or download resources
• HEAD: Requests a response that is identical to the response to a GET request. Only the request header is returned, but no response body is generated, mostly by JavaScript
• POST: Used to submit an entity (body) to a specified resource, usually resulting in a change in status or side effects on the server
• PUT: Replaces all current representations of the target resource with the request payload.
• DELETE: deletes the specified resource.
• CONNECT: Establishes a tunnel to a server identified by the target resource, used mostly for HTTPS and Websockets.
• OPTIONS: pre-check, used to describe the communication OPTIONS of the target resource. This request is used to know whether the server allows cross-domain requests.
• TRACE: Performs a message loopback test along the path to the target resource, which is not supported by most online services
• PATCH: Used to apply partial changes to resources.

The GET request method is probably the first of all HTTP request methods, and it means to GET a resource from the server

The POST request method is the most commonly used request method of all HTTP protocols except GET. It means to submit data to a specified server resource. The submitted data is stored in the BODY of the HTTP message, usually resulting in a change of status or side effects on the server

3. Essential differences between GET and POST request methods

To sum up, there are two essential differences between GET and POST:

• Different request lines:
  • GET: GET /uri HTTP/1.1
  • POST: POST /uri HTTP/1.1
• Operations on server resources are different:
  • GET: obtains resources from the server
  • POST: Submit data to a specified server resource (usually resulting in changes in status or side effects on the server)

Advanced: Frequently asked Questions and answers

1. Is POST more secure than GET?

In THE HTTP protocol, the so-called “security” means that the request method does not modify the resources on the server, “damage” the resources on the server

By this definition, the GET request method is safe because it performs only read-only operations on the server resources and is idempotent

Idempotent means that the same operation is performed many times with the same result, i.e. the result is “equal” after many “powers”.

The POST request method is not secure because it modifs the resources on the server. In RFC semantics, POST means “add or submit data”. Multiple submissions create multiple resources, so it is not idempotent

Conclusion:

• GET: security, idempotent
• POST: Unsafe, not idempotent

For transmission, both GET and POST packets are insecure because HTTP is transmitted in plaintext on the network. To secure transmission, encryption, namely HTTPS, is required

2. Does the POST method generate two TCP packets?

As mentioned in part of the article, the POST request method will send the header and the body separately. The server will send the header and the 100 status code and then send the body 🤔️🤔️ port

The HTTP protocol does not explicitly state that POST produces two TCP packets, and actual testing (Chrome, Firefox) found that header and body are not sent separately.

But why do some writers write nan like this? I did some research and finally found that this was the case.

In search of performance – how we shaved 200ms off every POST request

Gocardless.com/blog/in-sea…

The main story is that the author found that POST is 200ms more than GET, and then dug deeper and found that Ruby’s NET ::HTTP library will split an HTTP request, sending the header part first. In addition, TCP_NODELY was not set up, so the first packet had to wait for ack before the next packet was sent, resulting in a 200ms delay for a request.

Also, about HTTP 100 Continue:

The purpose of 100 Continue is to optimize situations where an HTTP client application has a body part of an entity to send to the server, but wants to see if the server will accept the entity before sending

—- The Definitive Guide to HTTP

Client:

If the client is sending an entity to the server and is willing to wait for a 100 Continue response before sending the entity, it sends an Expect request header with a value of 100 Continue. If the client is not sending an entity, you should not send the 100 Continue Expect header, because this will fool the server into thinking that the client is sending an entity

Server side:

If the server receives a request with an Expect header with a value of 100 Continue, it responds with either a 100 Continue response or an error code. The server should never send a 100 Continue status code to a client that does not expect to send a 100 Continue.

If the server receives some (or all) of the entities before it has a chance to send the 100 Continue response, the server intends to Continue sending data, so the server does not need to send the status code, but should still send a final status code for the request after it completes the request

That is, there will be no response until 100 Continue is received from the client

conclusion

Therefore, most frameworks try to send HTTP requests within a TCP packet, but there are frameworks that send HTTP headers and then body. But how many TCP packets to send, which is not HTTP, is a matter of the OPERATING system’s TCP stack and code, not HTTP

Three minutes a day