Please Whitelist This Site?

I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)

If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.

If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||^$document". Then just click OK.

Thanks for your understanding!

Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited.
If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The Book is Here... and Now On Sale!

Read offline with no ads or diagram watermarks!
The TCP/IP Guide

Custom Search

Table Of Contents  The TCP/IP Guide
 9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)
      9  TCP/IP Key Applications and Application Protocols
           9  TCP/IP File and Message Transfer Applications and Protocols (FTP, TFTP, Electronic Mail, USENET, HTTP/WWW, Gopher)
                9  TCP/IP World Wide Web (WWW, "The Web") and the Hypertext Transfer Protocol (HTTP)
                     9  TCP/IP Hypertext Transfer Protocol (HTTP)
                          9  HTTP Entities, Transfers, Coding Methods and Content Management

Previous Topic/Section
HTTP Data Transfer, Content Encodings and Transfer Encodings
Previous Page
Pages in Current Topic/Section
Next Page
HTTP Content Negotiation and "Quality Values"
Next Topic/Section

HTTP Data Length Issues, "Chunked" Transfers and Message Trailers
(Page 2 of 3)

Using "Chunked" Transfers

The problem of unknown message length could be resolved by buffering the entire resource before transmission. However, this would be wasteful of server memory and would delay the transmission of the entity unnecessarily—no part could be sent until the entire entity was ready. Instead, a special transfer encoding method was developed to handle this particular problem of “unsafe” transport: not knowing the length of a file. The method is called chunking.

When this technique is used, instead of sending an entity as a raw sequence of bytes, it is broken into, well, chunks. J This allows HTTP to send a dynamically-generated resource, such as output from a script, a piece at a time as the data becomes available from the software processing it. To indicate that this method has been used, the special header “Transfer-Encoding: chunked” is placed in the message. A special format is also used for the body of the HTTP message to delineate the chunks:


Basically, instead of putting the whole entity in the body and indicating its length in a Content-Length header, each chunk is placed in the body sequentially, each preceded by the length of the chunk. The length is specified in hexadecimal, and represented using ASCII characters. All chunk lengths and chunk data are terminated with a “CRLF” sequence. The recipient knows it has received the last chunk when it sees a chunk-length of zero.

Key Concept: Since HTTP/1.1 uses persistent connections that allow multiple requests and responses to be sent over a TCP connection, clients and servers need some way to identify where one message ends and the next begins. The easier solution is to use the Content-Length header to indicate the size of a message, but this only works when the length of a message can be easily determined in advance. For dynamic content or other cases where message length cannot be easily computed before sending the data, the special chunked transfer encoding can be used, where the message body is sent as a sequence of chunks, each preceded by the length of the chunk.

Message Trailers

When chunked transfer encoding is used, the sender of the message may also choose to specify one or more message trailers. These are the same as entity headers, describing the contents of the message body, but appear after the entity instead of before it. They provide flexibility in the same way that chunking itself does—they allow a device to include an HTTP header that may contain information that was not available when the HTTP message transmission began. A good example would be an integrity check field calculated based on the byte values of the entire entity.

Trailers are optional, and not always be needed. When they are used, they are processed just like regular entity headers. To give the recipient of a message a “heads up” that trailers have been used, the special Trailer header should be included at the start of the message, which lists the names of each header that appears as a trailer.

Previous Topic/Section
HTTP Data Transfer, Content Encodings and Transfer Encodings
Previous Page
Pages in Current Topic/Section
Next Page
HTTP Content Negotiation and "Quality Values"
Next Topic/Section

If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $

Home - Table Of Contents - Contact Us

The TCP/IP Guide (
Version 3.0 - Version Date: September 20, 2005

Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.