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

From: "Phillip M. Hallam-Baker" <[email-masked]>
Date: Thu, 1 May 1997 12:19:41 -0400

>> Besides searching for the boundary marker was very expensive
computationally, every byte had to be examnined.
>
>I think 'very' is pretty subjective, and using string matching
>algorithms like boyer-moore mean that the number of comparisons
>is reduced for longer boundary strings.

Its still prohibitive if you want to send video through the channel.
I want to be able to have http proxies perform high level routing
using minimal state and FSM graphs.

I don't care much about wasted bytes, provided they don't cause
the header to exceed the first "fast" packet and they are not a
performance problem at low bandwidth they are unlikely to be
a problem with large data sizes where the control/data ratio
is much lower.

There is absolutely no problem with a 1000 TPS server sending static
files using content length. The vast majority of Web files are static
and
this will remain so - few people use dynamic images.

HTTP has a solution to the content length for variable length data
- chunked. When chunked was proposed the problems with MIME
were understood. I would have liked to see MIME adopted and add 
a content length but that was politically incorrect and chunked is
better.

I don't see what the problem is, Web->Mail gateways have to perform
some relatively simple transformations. Big deal.

>The standard says only that the boundary string DOES NOT appear
>in the body. It happens that if you know nothing about the body
>at all, then you can implement this in a probabalistic way, e.g.,
>the likelihood that a randomly generated boundary string would
>appear in arbitrary data could be made arbitrarily small ("less
>than the probability that the computer would spontaneously explode").

Not true for real time streams which can become introspective. Imagine
you have a network monitor that is  pushing a record of network packets

onto a central display. The monitors own packets appear here from time
to time causing the marker to appear.

The probablistic argument is BOGUS and WRONG. The
probability is not infintessimal, it is real and most likely to bite
people
like us.

But since it is never necessary to use MIME with HTTP the problem 
does not appear.

   Phill

---

From: Patrick Powell <[email-masked]>
Date: Sat, 3 May 1997 07:57:16 -0700 (PDT)

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