Http/Smtp MIME multipart. Why boundary?

Question

I have a question regarding the design of these protocols. Why do we use boundary to separate parts of the multipart message instead of introducing a content-length for each part? Using length the parsing would easier. Do I miss some principal reason for using boundaries and not length parameter? Thanks!

Answer 1

Using length the parsing would [be] easier

This is where you are wrong. The authors of multipart MIME had cases in mind where you could not determine beforehand the length of a message part. Think of content encodings that alter message lengths such as base64, UUencode and others. There's also compression, encryption and whatnot. Also: Content-Length is an entity header. This means if you reach it, you've already begun to parse a message part. It comes with literally no advantage over a boundary marker.

If you study older protocols, you will often encounter some marker (usually \0) to indicate the end of a message. Sending the byte count of a message is another solution, but you won't find it a lot in places where message content has to be converted on-the-fly or is to be streamed in some fashion.

Bottom line: The multipart boundary allows some interesting applications with message contents of unpredictable size. HTTP server pushing is a notable example.

Answer 2

Because in good old days the MIME Standard was defined this way. One of the reasons was probably that content-length has a problem with text/plain data, where the newline might be either CR (old mac), LF (unix) or CR LF (windows, dos). The other might be that it is easier for a human to read, which is IMHO a bad argument but happens a lot when preferring textual representations like HTTP, XML or SOAP instead of the more effective binary ways like ASN.1 or SUN RPC.

You might also view it as a successful attempt of the industry to sell more powerful servers by introducing useless overhead into the protocols :)