(no title)
alduin32 | 2 years ago
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).
alduin32 | 2 years ago
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).
scottlamb|2 years ago
> [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.
TheCycoONE|2 years ago
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.
https://datatracker.ietf.org/doc/html/rfc1945#section-3.6.2
https://datatracker.ietf.org/doc/html/rfc1521#section-7.2.1
arantius|2 years ago