W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Re: MIME multipart/* vs HTTP

From: Phillip M. Hallam-Baker <hallam@ai.mit.edu>
Date: Thu, 1 May 1997 12:19:41 -0400
Message-Id: <199705011613.MAA17836@life.ai.mit.edu>
To: Scott Lawrence <lawrence@agranat.com>, Larry Masinter <masinter@parc.xerox.com>
Cc: ipp@pwg.org, http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3192
>> 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
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

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
like us.

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


Received on Thursday, 1 May 1997 09:18:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC