Fetch: [Suggestion] Add more per-file (custom) header to multipart

[jimmywarting]

Some demonstration code

fd = new FormData()
file = new File(['abc'], 'dummy.txt', { type: 'text/plain', lastModified: Date.now() })
fd.set('x', file)
await new Response(fd).text()

What's generated:

Content-Disposition: form-data; name="x"; filename="dummy.txt"
Content-Type: text/plain

abc
------WebKitFormBoundaryI2aNXnjBifHTBeH1--

---

I think some more per-file headers could enhance the server validation
for instance. it would be useful to know before you receive the hole file how large a per file size is, not the hole formdata content-length. So you can abort upload request prematurely if one is sending a too large file. While we are at it, why can't we as well throw in the less useful Last-Modified header as well? that is also known on the client side before it's being uploaded.

Content-Disposition: form-data; name="x"; filename="dummy.txt"
Content-Type: text/plain
Content-Length: 3
Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
Last-Modified: 2021-05-10T11:23:51.076Z // iso standard instead maybe?

abc
------WebKitFormBoundaryI2aNXnjBifHTBeH1--

This things could easily be added if you pass in a Blob/File without changing any code. But another idea could also be to allow sending custom headers as well when using the FormData api

// something like
headers = new Headers({
  'Content-Length': 3
})
fd.set('x', file, { headers } )

This could allow for a way to batch a bunch of requests into one request also. if you get a bit creative
I have seen some developer use a custom multipart library to batch multiple request/responses into one

As opposite to this a way to read individual per-entries headers could also be useful so you can decode it also.
I have no idea how it would fit into the existing getter function (fd.get(x)) but with fd.entries() you have the option to append stuff (?)

fd.entries().next().value // [key, entry, headers]
for (let [key, entry, headers] of fd) {

}

[annevk]

This seems somewhat reasonable once there is a much more solid definition of multipart/form-data and interoperable implementations of that (see existing issues against whatwg/html).

[jimmywarting]

if content-length was know for each entry (not just for file's) then it would make it easier for backends to pass x amounts of bytes throught instead of scanning the hole body for a boundary every time and make the decoding of form-data faster.
(makes the boundary a bit obsolete)

Imo i think that the boundary was a bad style decision. smarter containers like zip, tar and other multi file container specifies the byte length instead in the beginning or before every entry or at the end in some central dictionary so you can jump/scan a hole blob without having to scan for a boundary separator.

So i think that a content-length header would be an enhancement to the old multipart/form-data specification.

[andreubotella]

For the record, I'm working on defining multipart/form-data in https://github.com/andreubotella/multipart-form-data, including a parser for use in Body.prototype.formData() and potentially in servers. I'm trying to reach something interoperable, rather than add new stuff, but having the format solidly defined would be necessary before adding Content-Length.