Sometimes the server cannot determine the message size when generating an HTTP response. In this case, Content-Length cannot be used to write the message length in advance, but the server needs to generate the message length in real time. In this case, the server generally uses chunked encoding.
During chunked encoding transmission, the header of the reply message contains transfer-coding and is set to chunked, indicating that the content will be transmitted using chunked encoding. The encoding method is as follows:
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
Encoding is composed of several chunks, ending with a chunk with a length of 0. Each chunk consists of two parts. The first part is the length and length unit of the chunk (generally not
The second part is the content with the specified length, and each part is separated by CRLF. In the last chunk with a length of 0, the content is called footer and is in some unwritten headers.
.
The following describes the chunked decoding process (included in RFC)
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