Http/Smtp MIME multipart. Why boundary?
boundary, content-length, http, multipart, smtp
Solution
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.
Problem
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!