I wonder why we didn't use a framed representation rather than delimiters that have to be searched for (which isn't so simple). It makes writing a streaming MIME parser much harder. With a compulsory Content-Length things would be much easier.
At least with multipart/form-data we get to avoid transfer encodings, which are also quite annoying to handle (especially as they can be nested, which is probably the worst aspect of RFC2046).
I agree Content-Length should be mandatory. It's not even specified. Arguably and unfortunately with the standard as is, parsers shouldn't even use it if it's there, because if there's a boundary before that length, your results will differ from other parsers. (My crate expects it though.)
> [Not having Content-Length:] makes writing a streaming MIME parser much harder.
I don't think that's a big problem for Rust application servers where there are nice crates for efficient text searching you can plug in. Maybe more so for folks doing low-dependency and/or embedded stuff, especially in C.
But it's just dumb IMHO when you want to send arbitrary data to have to come up with a random boundary that you hope isn't in the data you're sending. With a strong random number generator you can do this to (un)reasonable statistical confidence, but that shouldn't be necessary at all.
I speculate that it's because it would be easier for humans to read and write boundaries than count bytes.
Multipart predates http/1.0 and was written for email. It wasn't unheard of in the early days to directly enter SMTP commands. It would also be more readable on clients that didn't support mime.
Streaming. What if the part(s) are being generated on the fly, and don't exist to have a length? Requiring that the sender specify the length up front requires the length to be known. Maybe I'm (e.g.) tarring/zipping up a lot of data, and I don't want to hold it all in memory/write it to a temporary file first.
At least with multipart/form-data we get to avoid transfer encodings, which are also quite annoying to handle (especially as they can be nested, which is probably the worst aspect of RFC2046).