The article talks about multipart/form-data in particular.

Another thing one might run across is multipart/x-mixed-replace. I wrote a crate for that. [1] I didn't see a spec for it, but someone since pointed out to me that it's probably identical to multipart/mixed, and now seeing an example in the multer README it clicks that I should have looked at RFC 2046 section 5.1.1, [2] which says this:

> This section defines a common syntax for subtypes of "multipart". All subtypes of "multipart" must use this syntax.

...and written a crate general enough for all of them. Maybe I'll update my crate for that sometime. My crate currently assumes there's a Content-Length: for each part, which isn't specified there but makes sense in the context I use it. It wouldn't be hard to also support just the boundary delimiters. And then maybe add a form-data parser on top of that.

btw, the article also talks specifically about proxying the body. I don't get why they're parsing the multipart data at all. I presume they have a reason, but I don't see it explained. I'd expect that a body is a body is a body. You can stream it along, and perhaps also buffer it in case you want to support retrying the backhaul request, probably stopping the buffering at some byte limit at which you give up on the possibility of retries, because keeping arbitrarily large bodies around (in RAM or even spilling to SSD/disk) doesn't sound fun.

[1] https://crates.io/crates/multipart-stream

[2] https://datatracker.ietf.org/doc/html/rfc2046#section-5.1.1

> Another advantage of multipart is that the server can stream each part separately. For example, say you're uploading 5 files by encoding them into a JSON object. Your server will have to buffer the entire JSON object into memory, decode it, and examine each file.

That's not true. You can stream JSON, too. You just have to do something fancier than JSON.stringify().

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

Shameless plug for my multipart crate: https://github.com/cetra3/mpart-async which I've been using happily in production for a long time now

One thing the article doesn't mention, but that's also interesting is that multipart is also heavily used for email. With multipart, you can send an HTML version along with a plan text version of your email. Email attachments are also solved via multipart. So I think this explains some of the decisions that were made when specifying HTTP Multipart.

In just the past week I used multipart/form-data to proxy an incoming file upload stream to another backend server which then streamed it to a cloud bucket. Working great so far and was fairly simple to set up!

Does HTTP/2 have support for parallel uploads? As an end-user if I happen to select 1 huge file first, followed by a bunch of tiny files, having to wait for the entire huge file to be streamed to the server before it even knows about any of the others seems less than ideal. It also seems odd there's no way to provide a hint to the server about individual file-sizes up-front (only Content-Length which is your upper bound for the total size of all files). I'm also curious how clients are expected to generate boundary strings and what is supposed to happen if the uploaded file is discovered to have an instance of the boundary string in it. Or are we just relying on that being sufficiently improbable not to worry about it (a la guid uniqueness...)?

> You can gzip the entire Multipart response, but you cannot pick and choose compression for particular parts.

Sure you can. I designed a system where the client uploads a multipart-form that's three parts, the first part is JSON ("meta") and the next two parts are gzipped blobs ("raw.gz" and "log.gz"). The server reads the first part which is metadata that tells it how to handle the next two parts.

I happen to be using Falcon and streaming-form-data on the server side.

https://falcon.readthedocs.io/en/stable/

https://streaming-form-data.readthedocs.io/