Re: IPP> Re: MIME multipart/* vs HTTP

I have been trying to pick up the thread of the discussion about HTTP
chunked transfers,  and am a little puzzled.  I pulled out the HTTP/1.1
reference,  section 3.5 and 3.6;  this dicusses transfer-codings. Here
is the excerpt from the standard:


# .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

Received on Saturday, 3 May 1997 08:00:10 UTC