# .6 Transfer Codings
# Transfer coding values are used to indicate an encoding
# transformation that has been, can be, or may need to be applied to an
# entity-body in order to ensure "safe transport" through the network.
# This differs from a content coding in that the transfer coding is a
# property of the message, not of the original entity.
# transfer-coding = "chunked" | transfer-extension
# transfer-extension = token
# All transfer-coding values are case-insensitive. HTTP/1.1 uses
# transfer coding values in the Transfer-Encoding header field (section
# 14.40).
# Transfer codings are analogous to the Content-Transfer-Encoding
# values of MIME , which were designed to enable safe transport of
# binary data over a 7-bit transport service. However, safe transport
# has a different focus for an 8bit-clean transfer protocol. In HTTP,
# the only unsafe characteristic of message-bodies is the difficulty in
# determining the exact body length (section 7.2.2), or the desire to
# encrypt data over a shared transport.
# The chunked encoding modifies the body of a message in order to
# transfer it as a series of chunks, each with its own size indicator,
# followed by an optional footer containing entity-header fields. This
# allows dynamically-produced content to be transferred along with the
# information necessary for the recipient to verify that it has
# received the full message.
# ielding, et. al. Standards Track [Page 24]
# FC 2068 HTTP/1.1 January 1997
# Chunked-Body = *chunk
# "0" CRLF
# footer
# CRLF
# chunk = chunk-size [ chunk-ext ] CRLF
# chunk-data CRLF
# hex-no-zero = <HEX excluding "0">
# 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 chunked encoding is ended by a zero-sized chunk followed by the
# footer, which is terminated by an empty line. The purpose of the
# footer is to provide an efficient way to supply information about an
# entity that is generated dynamically; applications MUST NOT send
# header fields in the footer which are not explicitly defined as being
# appropriate for the footer, such as Content-MD5 or future extensions
As I see this, the length of the data is specified as part of the transfer.
This means that you do not have to worry about the content, etc.
What am I missing in this discussion?
Patrick Powell