Keep-alive in HTTP

HTTP is based onRequest-Responsemode, where the client sends a request message to the server to respond to this information. In the old HTTP version, each request will be created with a newCustomer and serverconnection, send a request on this connection, and then receive the request. One of the great advantages of such a model is that it is simple, easy to understand and programmed to implement; it also has a big drawback that it is inefficient, so keep-alive is proposed to solve the problem of low efficiency.

1. In the http/1.0 version, there is no official standard to specify how keep-alive works, so it is actually attached to the http/1.0 protocol, and if the client browser supports Keep-alive, add a field to the HTTP request header Connection:keep-alive, when the server receives a request with connection:keep-alive attached, it also adds an identical field to the response header to use keep-alive. In this way , the HTTP connection between the client and the server is maintained, not disconnected (except for the time specified by keep-alive, unexpected power outages, etc.), and when the client sends another request, the established connection is used

2. In the http/1.1 version, the official keep-alive usage standard differs somewhat from the http/1.0 version, where all connections are maintained by default in HTTP1.1 unless indicated in the request header or response header to be closed: Connection:close, That's why the connection:keep-alive field doesn't make sense anymore. In addition, a new field keep-alive is added: Because this field does not describe in detail what is used to do, ignore it

Not reliable (unreliable)

HTTP is a stateless protocol, which means that each request is independent and keep-alive failed to change the result. In addition , Keep-alive does not guarantee that the connection between the client and the server must be active , as is the case in the HTTP1.1 version. The only guarantee is that when the connection is closed you can get a notification, so you should not let the program rely on keep-alive to maintain the connection characteristics, otherwise there will be unintended consequences

Keep-alive and Post

It is stated in the HTTP1.1 rules that there cannot be any characters behind a post message body, and that the standard may not be followed for a particular browser (such as placing a CRLF character behind the post message body). As far as I know, most browsers will automatically follow a CRLF character after the post message body, how to solve this problem? Depending on the instructions above, it is forbidden to use keep-alive in the POST request header, or the server automatically ignores the CRLF, and most of the servers are automatically ignored, but it is not possible to know whether a server will do this without testing.

A URL length

   Microsoft Internet Explorer (Browser)
   the maximum URL limit for Internet Explorer is 2083 characters, if this number is exceeded, the submit button has no response.

Firefox (Browser)
The length of the Firefox browser URL is limited to 65,536 characters, but when I test, the maximum processing time is 8,182 characters, because the length of the URL is limited by the Web server in addition to the browser restrictions.

Safari (Browser)
The maximum URL length is limited to 80,000 characters.

Opera (Browser)
The maximum URL length is limited to 190,000 characters.

Google (Chrome)
Once the URL length exceeds 8,182 characters.

Keep-alive in HTTP