This topic, we will start with three new features in HTTP 1.1 understanding them is crucial to understanding the internal working of the default connector.
Persistent Connections
Prior to HTTP 1.1, whenever a browser connected to a web server, the connection was closed by the server right after the requested resource was sent. However, an internet page can contain other resource, such as image files, applets, etc. Therefore, when a page is requested, the browser needs to download the resource referenced by the page. If the page and all resources it references are download using difference connections, the process will be very slow. That’s why HTTP 1.1 produces persistent connections. With a persistent connection, when a page is download, the sever does not close the connection straight away. Instead it waits for the web client to request all resources referenced by the page. This way, the page and the referenced resource can be downloaded suing the same connection. This saves a lot of work and time for the web server, client, and network, considering that establishing and tearing down HTTP connections are expensive operations. The persistent connection is the default connection of HTTP 1.1. Also to make it explicit, a browser can send the request header connection with the value keep-alive:
connection:keep-alive
Chunked Encoding
The consequence of establishing a persistent connection is that the server can send byte stream from multiple resource, and the client can send multiple requests suing the same connection. As a result, the sender must send the content length header of each request or response so that the recipient would know how to interrupt the bytes. However, often the case is that the sender does not know how may bytes it will send. For example, a servlet container can start sending the response when the first few bytes become available and not wait until all of them ready. This means, there must be a way to tell recipient how to interrupt the byte stream in the case that content-length header cannot be known earlier.
Even without having to sending multiple requests or many resources, a server or a client does not necessarily know how much data it will send. In HTTP 1.0, a server could just leave out the content-length header and keep writing to the connection. When it finished, it would simply close the connection. In this case, the client would keep reading until it got a –1 as an indication that the end of the file had been reached.
HTTP 1.1 employs a special header called transfer-encoding to indicate that the byte stream will be sent in chunks. For every chunk, the length (in hexadecimal) followed by CR/LF is sent prior to the data. A transaction marked with a zero length chunk. Suppose you want to sent the following 38 bytes in 2 chunks, the first with the length of 29, and the second 9.
I’m as helpless as a kitten up a tree.
You would send the following:
1D/r/n
I'm as helpless as a kitten u
9/r/n
p a tree.
0/r/n
1D, the hexadecimal of 29, indicates that the first chunk consists of 29 bytes. 0/r/n indicates the end of the transaction.
Use of 100 (continue) status
HTTP 1.1 clients may send the Expect: 100-continue header to the server before sending the request body and wait for acknowledgement from the server. This normally happens if the client is going to send a long request body but is not sure that the server is willing to accept it. It would be a waste if the client sent the long body just to find out the server turned it down.
Upon receipt of the Expect:100-continue header, the server responses with the following 100-continue header if it is willing to or can process the request, followed by two pairs of CRLF characters.
HTTP/1.1 100 Continue
The server should then continue reading the input stream.