> 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