top | item 35708107

(no title)

alduin32 | 2 years ago

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).

discuss

order

scottlamb|2 years ago

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.

arantius|2 years ago

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.