Re: [whatwg/fetch] Add size limiter to `Body#formData` method (Issue #1592)

I'm not particularly +1 or -1 on this idea. but there are other way to battle this as well (to not hit OOM)

for starter
- you can check the `content-length` header yourself already. and also reject request that do not have them.
  - ofc not all requests have a `content-length` but then maybe perhaps you could do something cool/useful in combination of having a [fetch observer](https://github.com/whatwg/fetch/issues/607) that can track how much you have downloaded / upload. and if it have downloaded more than `x` bytes then you could abort the request / response with `abortSignal` or something. I have long been waiting for something like a progress monitoring solution that XHR have had for years but fetch don't
- browser rarely never have any problem doing things like `.formData()` as files are often backed up by the filesystem anyways. I have proposed that decoding large file from `.formData()` also gets saved directly to the disc and handed back to you as a `File` backed up by the file system and isn't something that isn't kept in memory. 
  - same could be applied for `Body.blob()` to also be backed up by the file system.
- You could also use other solutions other then the historical old `.formData()` solution like `WebTransports` instead.
- You could send how large each individual file size is within a custom `x-` headers, so you would know how large each file is before you even begin to parse the payload with `.formData()`

The only value i see for this `maxSize` is within servers (not browsers) that's why i'm leaning more towards applying internal solutions that circumvents this OOM issues by doing the same thing browser dose to solve this problem without necessary adding new syntactic feature on top that isn't "really" necessary or can be solved in other ways without extra features/option that's only going to be useful for the server.

I know Bun.js use parts of webkits builtin web api's rather then trying to reimplement things.
I know that they can represent a file backed up by the file system, i hear the verdic is that they do not support `Body.formData()` yet cuz [HTMLFileElement](https://github.com/oven-sh/bun/issues/621#issuecomment-1181620043) made it a bit tricky. But if i could guess, then their solution would be to write files to the disc and hand you a native File handle back

--- 

Other cool (off-topic) thing would be if it where a 2 way communication where you could send file descriptions (extra streams) within a stream. but such things only exist in HTTP/2. then you could decide for yourself if you want to read file xyz and knowing beforehand how large the file is. but this would be something completely different.
perhaps maybe a better solution is just to simply post one individual file per request and not use `FormData` at all if you intend to send/accept large files. 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1592#issuecomment-1419448903
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1592/1419448903@github.com>