Chunk encoding of HTTP protocol (chunked transfer encoding)

chunked transfer encoding (Chunked transfer encoding) is a transport data mechanism in Hypertext Transfer Protocol (HTTP) that agrees that HTTP is sent by application server to the client application ( Data that is typically a Web browser) can be divided into multiple parts. Chunked transfer encoding is provided only in the HTTP Protocol 1.1 version number (http/1.1).

Typically, the data sent in an HTTP reply message is sent throughout. The Content-length message header field represents the length of the data. The length of the data is important because the client needs to know where the answer message ends and perhaps the start of the reply message. However, with chunked transfer encoding, the data is decomposed into a series of blocks of data and sent in one or more blocks, so that the server can send data without having to know the total size of the sent content beforehand.

Usually the size of the data block is consistent. But it's not always the case.

 

The introduction of chunked transfer encoding in HTTP 1.1 provides the following advantages:

2. the HTTP chunked transfer encoding agrees that the server maintains an HTTP persistent connection for dynamically generated content. In general, a persistent link requires that the server send the Content-length message header field before the originating send message body, but for dynamically generated content. It is not known until the content has been created. [dynamic content, content-length unpredictable]
4. The chunked transfer encoding agrees with the server at the end of the Send Message header field.

   It is important for situations where the header field values cannot be known until the content is generated. For example, the content of the message is to be signed with a hash, and the result of the hash is transmitted over the HTTP message header field.

   When there is no chunked transfer encoding, the server must buffer the content until it is complete, calculate the value of the header field and send the values of those header fields before sending the content. [hash signature, need to buffer complete talent calculation]

6. Httpserver sometimes use compression (gzip or deflate) to shorten the time it takes to transfer. chunked transfer encoding can be used to separate multiple parts of a compressed object. In such a case, the block is not compressed separately, but the entire load is compressed, the compressed output using the description described in this article of the scheme for chunked transmission. In the case of compression, chunked encoding is advantageous for sending data while compressing, rather than completing the compression process to know the size of the compressed data. [gzip compression. Compression and transmission at the same time]

Common HTTP headers include the Content-length field to indicate the length of the newspaper style. Sometimes the service generated HTTP response is unable to determine the size of the message, such as the download of large files, or the background requires complex logic to all the processing of the page request, when the need to generate a real-time message length. The server generally uses chunked encoding.

When the chunked encoding is transmitted. The headers of the reply message has a transfer-coding domain value of chunked, which means that the content will be transmitted with chunked encoding.

Use chunked encoded headers such as the following (able to use Firefox's Firebug plugin or httpwatch to view headers information):

coded in the following way:
Chunked-body=*chunk
"0" CRLF
Footer
CRLF
Chunk=chunk-size[chunk-ext]crlf
Chunk-datacrlf
    
hex-no-zero=
    
Chunk-size=hex-no-zero*hex
chunk-ext=* (";" chunk-ext-name["=" chunk-ext-value])
Chunk-ext-name=token
chunk-ext-val=token|quoted-string
chunk-data=chunk-size (OCTET)
    

Footer=*entity-header

The encoding consists of several chunk. The end of a chunk with a length of 0, each chunk has two parts, the first part is the length and length of the chunk unit (generally not written), the second part is the specified length of the content. Each part is separated by a CRLF. The content in the last chunk of length 0 is the content called footer.   Is something that is not written in the header. The following is a chunked decoding process (available in the RFC document)
length:=0
Readchunk-size,chunk-ext (ifany) Andcrlf
While (chunk-size>0) {
Readchunk-dataandcrlf
Appendchunk-datatoentity-body
length:=length+chunk-size
Readchunk-sizeandcrlf
}
Readentity-header
While (entity-headernotempty) {
Appendentity-headertoexistingheaderfields
Readentity-header
}
Content-length:=length
Remove "chunked" fromtransfer-encoding

Chunk encoding of HTTP protocol (chunked transfer encoding)