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

From: Michael Giroux <[email-masked]>
Date: Wed, 30 Apr 1997 21:45:52 -0700

> In my ignorance of MIME, I've been puzzled about this boundary
> business.  Assuming each multipart contains a Content-Length header,
> does it matter what the boundary is?

I agree, but let me say something about Content-Length.

Content-Length is not a very efficient mechanism for high volume 
(tens of thousands of concurrent connections, at 200+ TPS) servers.
It requires that the server cache the entire message in order to 
determine the final length, then send the content.  This will generally
require that the data is processed at least twice.  First to cache it,
and again to send it.

It would be better if these protocols used a scheme that breaks the
message into multiple messages.  Each message would start with
a length field.  In this way, it would be easy to add a boundry marker
as defined by a zero length part at end.  Continuous streams of
bytes are nice for some applications, but for high volume server
activity, it is much better to have a protocol that is more specific
about the length of the content, and does not require intermediate
cache of content so you can calculate the length.

I'm not that familiar with MIME, but I would expect that one could
define a MIME type that does contain "records", each of which contains
a control header (length) and data (length bytes long).

Michael Giroux

---

From: Keith Moore <[email-masked]>
Date: Thu, 01 May 1997 02:55:26 -0400

> require that the data is processed at least twice.  First to cache it,

Correct, and this is one of the main reasons why content-length
mechanisms were not chosen for delimiting multipart boundaries
in MIME messages.  The other reason was differences in the 
representation of text messages on different platforms.
HTTP doesn't have the latter problem to the same degree as MIME
email does, but it does have the former problem.  Content-Length
is almost as undesirable for HTTP as it is for MIME email.

(Not to mention that mixing the protocol-level framing in with 
the description of the payload causes all sorts of confusion.)

> as defined by a zero length part at end. 

Exactly the solution adopted for SMTP chunking.

Keith